轻量级高并发架构
今天吃饭的时候，听到隔壁聊起抢红包，联想起在北京工作的时候，正好之前在北京工作同事有一个流量红包的项目，结合北京移动抢红包场景，整理一下架构思路
场景case分析
简单抽象用户会做三种场景
- 发红包（这里都是指发群红包，一对多用户，一对一可以认为是一对多特例）
- 抢红包
- 查询抢红包记录
发红包
- 发红包之前前置条件为扣款相关操作，然后才产生一个红包
- 通过nginx+keepalived做虚拟ip集群，防止入口宕机
- 通过nginx + tomcat做负载均衡，方便后端app扩容，理论上app无上限
- 将通过app红包校验的数据，拼接统一报文，发送mq消息队列
- 将数据做水平拆分，减少宕机影响范围，同时预留公共节点，做备节点
- 将数据持久化，同时做数据库主备模式，做到读写分离，读库后期作为二级缓存查询，同时将数据写入redis，做一级缓存
- 通知用户抢红包
抢红包
- 用户N倍流量发起抢红包，携带红包订单号与用户编号
- 先将用户请求导向redis
2.1 redis内部嵌LUA脚本，执行红包数量扣减逻辑，不访问数据库
2.2 当redis中红包数据为0，启动一个异步线程，持久化抢红包红包记录。
2.3 红包redis缓存失效时间为十分钟，当红包数据为0以后，其他请求直接返回，
2.4 当缓存失效以后，访问数据库的主从同步库 - 执行【黑线逻辑】，某一个红包数量为0，发送数据持久化消息
- 将请红包消息持久化到数据库
- 数据库做主备同步
异步进程需要处理的逻辑
- 有的红包不是那么活跃，可能某段时间抢不完，那么这部分按照之前的设计将不能持久化到数据库，则由后台进程触发， 具体参考【执行红线逻辑】
- 用户抢到的大量红包需要对账，对接第三方即可。
查询红包
- 查询redis缓存
- 查询mysql读表
详细图
完整架构图：流量红包架构图