我们平时用到的微博、QQ、12306是典型的高并发的场景。其中QQ、微博不仅仅是高并发，他们还是大数据量。
1 .我们怎么来设计高并发请求的秒杀系统？
降读：可以通过缓存
降写：将请求拦截在服务请求的上层
2.类似于12306我们的业务场景是怎么样的？
车次 读数据量比较大
余票 读数据量比较大
下单支付 写的压力比较大
3.上下游的分层架构
我们一般的架构设计基本是：浏览器层->站点层->服务层->数据层
插一句：站点层和服务层为了有利于扩容，尽量是无状态化。
4.设计思路
1.下单和支付分离
通过异步的处理方式，这样会降低用户的体验，但是可以降低系统的风险。
2.不同的地域不同时间开始售票
3.按钮只能点一次
一个用户点击。立马将按钮置灰★
4.库存显示的粒度
只显示有票/无票，这样的话可以降低缓存的淘汰率。因为如果实际显示具 体的票数，票数的改变会带来缓存的淘汰，会增加db的压力
5.案例
1.秒杀服务器部署与主站分离，防止整体宕机。
2.秒杀商品提前存入RedisList，size为秒杀数量。
3.在Nginx层 Web 层分别做限流，活动开始后，将用户购买请求放入 RabbitMQ中排队，消费者依次生成订单，同时减少Redis List中商品数 量，并将生成的订单插入Redis和MySQL中供用户查询购买结果。
4.当商品数量为0时，剩余消息处理为抢购失败。
通过模拟测试，上述架构可支撑10w人抢购2000件商品的情景，并在60秒内 处理完全部订单，配置如下：在 aws 上，共启用6台 ec2 实例 ( Nginx + Workerx 4 + RabbitMQ + Redis cluster)
百万级网关层设计我们需要知道哪些
服务架构的网关层好比护城墙的性质，主要的作用就是阻拦和过滤掉一些本不能直接进入的请求或者攻击。
一般网关层的作用是:
请求的鉴权
比如发布商品，登录鉴权
数据完整性的检查
数据包定长header+body的变化
协议的转换
JOSN----->HashMap(String,Object)
路由的转发
根据URI转发到不同的业务逻辑层
服务治理
限流、降级、熔断等
网关层的架构以及定位基本都是按如下的架构图设计：
那如果我们需要打造高性能的分布式网关，实现HTTP请求转RPC服务，接口权限教验，反作弊拦截等相关功能，需要击破哪些技术壁垒呢？
关键字 对应方案
高性能 无状态设计
鉴权功能 过滤器责任链
路由功能 反作弊设计
简单的反作弊 路由方案设计
整体架构
1.基于springboot
2.不做业务逻辑处理，维持高性能
3.缓存设计
4.异步线程设计
自研网关各个击破
跨域
• CORS（Cross-Origin Resources Sharing）解决跨域问题
• 对HTTP 请求头进行豁免的一个策略
• 建立豁免清单
• Access-Control-Allow-Origin
• Access-Control-Allow-Credentials
• 是否允许cookie跨域
• Access-Control-Allow-Methods
• 允许提交请求的方法
Session
• Session 绑定
• 将 uid hash到固定的节点
• Session 复制
• 优点：
• 每台机器存储全量的Session
• 做到了高可用
• 缺点：
• 集群同步复杂
• 适应于小规模网关
• 数据存储不合理，内存开销大
• Session 共享
• 使用缓存服务Redis，统一存储Session
• 优点：
• 网关层无状态
• 缓存服务本身高可用
• 缺点：
• 多一次服务调用IO
• Session客户端缓存
• 优点：
• 简单高性能
• 接入层无状态
• 缺点：
• 依赖客户端Cookie存储
sessiion生成算法
• Session包含的信息字段，和各个公司业务强相关
• deviceId、clientType、uid、ts
• AES 加密方案
• 加解密过程都在服务端
• 网关高性能
• 本地算法 + 远程校验
反作弊
• 业务维度
• 爬虫
• 恶意攻击
• 技术解决 -- 黑名单
• IP
• deviceId
• uid
• 特点
• 读多写少
• 命中率低
路由
1.核心实现URL 对 服务的映射
• 协议约定
• 网关和前端协议Json
• 网关层RPC调用入参统一Map<String, String>
• 数据返回统一Result对象{code, data, msg}