微信红包的高并发设计方案

微信红包具有量大、实时、秒杀的特点。不仅如此，相比普通的秒杀，微信红包1）更海量 2）更严格的安全级别。

针对这些特点，我们看一下微信官方是如何设计红包业务，让它能够应对百万量级并发需求的。

传统的业务处理系统长这样：

秒杀过程中，更多的逻辑在于入库操作上。

高并发的常用方案

使用内存代替实时的DB事务操作

所有的操作现在Cache中操作，然后再异步落库持久化。

优点是：内存代替磁盘，更高性能
问题是：一旦出现掉电等异常，会丢失数据

使用乐观锁代替悲观锁

所有操作尽管进行，通过CAS的方式更新数据，如果出现数据不一致，报给上层

优点是：取消的对关键资源的锁定，减少锁等待时间
问题是：出现数据不一致时，数据更新的顺序发生逆转（早的更新请求被排队到末尾重新CAS），因此而出现的大量数据更新会给系统造成额外的负担。

微信红包高并发解决方案

针对海量不同红包

给每个红包分配一个ID，通过算hash的方式，基于这个红包ID的所有请求及操作均分摊在某一个逻辑server上。这样不同的红包由不同的server来处理。
这里的server是逻辑server，实际可以有个多个server对一个DB，处于容灾考虑。

针对同一红包

• 在接入层排队所有的红包请求。
• 使用memcached 缓存过载的红包请求。

总结一句就是通过队列的方式避免加锁。

最后在数据库层面： 分库分表 + 冷热数据分离

分库分表，根据红包ID分成不同的库或者表。
冷热数据分离，将不常访问的数据转入磁盘等外设。

2024.06.19 更新总结

以上策略可以总结为垂直和水平方向对server的优化，包括：

• 利用cache实现红包交易过程，然后异步落库
• 使用memcached缓存过量红包交易
• 在接入层排队，避免使用锁
• 数据库层面，分库分表，减少查询或者修改DB耗时
• 通过红包ID，通过hash分派到不同的server上处理，分而治之。

另外，还可以：

• 网络层面
  • tcp 优化，提前告知rwnd，并通过cwnd预热方式避免线路拥塞
  • 如果是用http，采用http2 实现请求头压缩和分帧传输的多路复用策略
  • 如果是rpc，可以采用protobuf实现对消息的压缩传输
  • 尽量减少传输字节
• 单机垂直优化
  • Mem: 通过NVMe技术，将现代的快速SSD磁盘当内存使用，避免了掉电数据丢失。
  • CPU: 减少进程切换，对server进程设置高优先级，独占CPU，像F5 BIG-IP上的TMM。
  • Net: 参考上边