当前位置：首页 > news >正文

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

news 2025/7/26 8:17:08

1. 秒杀当前架构设计

当前架构面临的痛点：

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

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

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

当前架构面临的痛点：

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

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

当前架构面临痛点：

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

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

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

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

优点：

缺点：

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

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

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

存在问题：

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