轻量级高并发架构

轻量级高并发架构

今天吃饭的时候，听到隔壁聊起抢红包，联想起在北京工作的时候，正好之前在北京工作同事有一个流量红包的项目，结合北京移动抢红包场景，整理一下架构思路

场景case分析

简单抽象用户会做三种场景

• 发红包（这里都是指发群红包，一对多用户，一对一可以认为是一对多特例）
• 抢红包
• 查询抢红包记录
  

发红包

1. 发红包之前前置条件为扣款相关操作，然后才产生一个红包
2. 通过nginx+keepalived做虚拟ip集群，防止入口宕机
3. 通过nginx + tomcat做负载均衡，方便后端app扩容，理论上app无上限
4. 将通过app红包校验的数据，拼接统一报文，发送mq消息队列
5. 将数据做水平拆分，减少宕机影响范围，同时预留公共节点，做备节点
6. 将数据持久化，同时做数据库主备模式，做到读写分离，读库后期作为二级缓存查询，同时将数据写入redis，做一级缓存
7. 通知用户抢红包
   

抢红包

1. 用户N倍流量发起抢红包，携带红包订单号与用户编号
2. 先将用户请求导向redis
   2.1 redis内部嵌LUA脚本，执行红包数量扣减逻辑，不访问数据库
   2.2 当redis中红包数据为0，启动一个异步线程，持久化抢红包红包记录。
   2.3 红包redis缓存失效时间为十分钟，当红包数据为0以后，其他请求直接返回，
   2.4 当缓存失效以后，访问数据库的主从同步库
3. 执行【黑线逻辑】，某一个红包数量为0，发送数据持久化消息
4. 将请红包消息持久化到数据库
5. 数据库做主备同步

异步进程需要处理的逻辑

• 有的红包不是那么活跃，可能某段时间抢不完，那么这部分按照之前的设计将不能持久化到数据库，则由后台进程触发， 具体参考【执行红线逻辑】
• 用户抢到的大量红包需要对账，对接第三方即可。

查询红包

1. 查询redis缓存
2. 查询mysql读表
   

详细图

完整架构图：流量红包架构图