电商项目_秒杀_架构升级

1. 秒杀当前架构设计

• nginx节点和订单服务都可以方便的扩容（增加机器）
• redis扩容需则需要考虑架构设计

当前架构面临的痛点：

        秒杀系统redis是单节点（主从）部署，读redis时并发量会成为瓶颈。

        所以考虑将增加redis从节点个数。秒杀系统为提交读库存的性能，将redis从节点和nginx节点部署在一起的， 如果升级成redis集群， nginx读哪个从节点呢？-》考虑将nginx也水平扩展。

（nginx可以扩容原因：商品详情页的静态页面发布到OpenResty上， 那么就可以考虑将不同商品的页面发布到不同的openResty上）

2. redis增加从节点 + nginx水平扩展

• 1个redis主节点n个redis从节点
• 不同的商品详情页发布到不同的nginx

        当前架构面临的痛点：

        秒杀商品比较多时， 单个主redis节点更新库存、主redis节点同步从节点数据，会成为性能瓶颈。所以考虑将Redis升级成集群。

3. Redis垂直拆分

• nginx读取的redis从节点，就可能不在一个机器了。
• Redis 的集群化部署，多个 SKU 的数据，会分散到各个 Redis 节点当中，就可以解决 Redis 数据量太⼤的问题。并且，基于 Redis 集群的⽅式，Redis 服务的可⽤性也得到了提⾼。我们可以通过再加⼊哨兵机制等⽅式，保证少量 Redis 节点挂了后，整个 Redis 集群不会出现问题。        

当前架构面临痛点：

• 采⽤集群部署 Redis 后，因为⼤部分的 Redis 客户端都是通过连接池实现的，此时Redis 的连接数就会逐渐成为瓶颈。
• 无法确定Redis中的数据分布，也就⽆法保证每个Nginx只读取本地的 Redis

       Redis连接池：取决于具体的客户端实现，客户端可以配置针对单节点的连接池，也可以配置集群的连接池。

通过中间件减少连接数

1. 使⽤TwemProxy于 Redis 之间建⽴单链接交互，并通过Twemproxy实现分⽚逻辑。这样我们就可以⽔平扩展出更多的Twemproxy来增加连接数。
2. Twemproxy实例众多，应⽤维护、配置困难，需要在这之上做负载均衡。⽐如，通过LVA/HaProxy 实现VIP(虚拟 IP)，就可以做到节点切换对应⽤透明、故障⾃动转移。还可以通过实现内⽹ DNS 来做其负载均衡。

4. 库存预分配方案

        解决 无法保证Nginx只读本地 Redis的问题。同时也解决了集群redis线程池的问题。

        在很多互联⽹企业中，不会直接使⽤ Redis 的集群架构，⽽是搭建多个 Redis 节点。并通过库存预分配的⽅式，⾃⾏控制 Redis 中的数据分布。

优点：

• 每个应用都有独立的库存数据，大大降低了并发度，另外，各个应用扣减库存的速度不一样，一定程度防止了羊毛党
• 不同商品详情页配置到不同的OpenResty上，前端引导用户进入不同的静态页面 
• 一定程度解决热点商品问题，因为每个二级redis中可以配置多个SKU的活动信息

缺点：

• 前端引导用户进入不同的静态页面 ，但是如果想要多个服务承担同一个商品的秒杀服务， 前端如何进行合理的引导，需要将引导与库存进行沟通
• 服务出现问题，库存很难回收：二级redis是单点部署（主从），如果redis在活动过程崩溃，基于这个redis的库存数据无法回滚，从而影响整体库存管理。（纯粹单节点，活动数据可以通过日志恢复，后续的返厂活动进行补救）
• 各个服务之间无法沟通，导致有库存，但是用户秒杀不到的问题。 APP1有库存，APP2无库存，但是APP2进来的秒杀请求却无法下单。抢购多个商品也是类似问题。

5. 动态库存方案

5.1 动态分配二级Redis库存

解决不同二级redis服务之间不沟通的问题。

解决前端引导问题：库存分配服务可以动态管理各个二级redis缓存的库存，前端引导用户进入不同的商品静态页面，引导策略也可以使用库存分配服务（读取各个redis缓存的库存）

1. 独立出库存分配服务
2. 每个二级redis缓存配置个阈值，当库存低于域阈值时，通知库存分配服务，库存分配服务再访问各个Redis， 对库存进行统一分配
   • 优先从一级redis分配，这样速度更快
   • 一级redis扣减完成后，再协调二级redis进行动态库存分配
3. 当秒杀活动快结束时或者库存快全部售完时，所以二级redis的库存都低于一个临界值，可以将所有库存回收，统一分配给某一个二级Redis。

存在问题：

• 服务出现问题，库存很难回收：二级redis是单点部署（主从），如果redis在活动过程崩溃，基于这个redis的库存数据无法回滚，从而影响整体库存管理。（纯粹单节点，活动数据可以通过日志恢复，后续的返厂活动进行补救）

5.2 本地存储库存

        库存分配服务，是可以监听到各个redis缓存中的库存的， 那么就可以将二级redis缓存移除，直接将二级redis缓存的库存放到本地的DB中存储，这样openResty直接从本地DB读取，而不用跨进程调用，直接在进程内扣减库存。性能得到进一步提升。

5.3 商品分配服务

        现在这个架构下，二级redis缓存的库存是秒杀开始时分配好的，但是app层可能并没有配置某一商品的入口，但其对应的二级redis缓存确有这个商品的库存，最后就只能被动态回收。  所以可以提供一个库存配置服务，定义好每个app配置哪些SKU。 那么发布静态页面时可以读这个配置，开始分配二级redis缓存时也可以读取这个配置。

5.4 负载均衡

现在架构下部署了多个Nginx节点，对用户来讲，访问路径都是不一样的。

6. 秒杀与直播带货

相同点：

• 流量来的非常突然， 瞬间巨大流量
• 热点数据
• 都要处理三高问题

不同点：

• 直播带货允许超卖
• 直播带货持续时间更长