回收微信号
现在位置: 首页 > 微信服务 > > 正文

微信红包系统的高并发解决方案

时间:2021-01-14 作者: 分享到:
微信红包系统是一个高并发的资金交易系统,最大的技术挑战是保障并发性能与资金安全。这种全新的技术挑战,传统的“秒杀”系统设计方案已不能完全解决。微信红包系统针对相应的技术难点,采用了下面几个方案,解决高并发问题。
 
 
 
 
  
  1.系统垂直SET化,分而治之。
  
  微信红包用户发一个红包时,微信红包系统生成一个ID作为这个红包的唯一标识。接下来这个红包的所有发红包、抢红包、拆红包、查询红包详情等操作,都根据这个ID关联。
  
  红包系统根据这个红包ID,按一定的规则(如按ID尾号取模等),垂直上下切分。切分后,一个垂直链条上的逻辑Server服务器、DB统称为一个SET。
  
  各个SET之间相互独立,互相解耦。并且同一个红包ID的所有请求,包括发红包、抢红包、拆红包、查详情详情等,垂直stick到同一个SET内处理,高度内聚。通过这样的方式,系统将所有红包请求这个巨大的洪流分散为多股小流,互不影响,分而治之,如下图所示。
  
  这个方案解决了同时存在海量事务级操作的问题,将海量化为小量。
  
  2.逻辑Server层将请求排队,解决DB并发问题。
  
  红包系统是资金交易系统,DB操作的事务性无法避免,所以会存在“并发抢锁”问题。但是如果到达DB的事务操作(也即拆红包行为)不是并发的,而是串行的,就不会存在“并发抢锁”的问题了。
  
  按这个思路,为了使拆红包的事务操作串行地进入DB,只需要将请求在Server层以FIFO(先进先出)的方式排队,就可以达到这个效果。从而问题就集中到Server的FIFO队列设计上。
  
  微信红包系统设计了分布式的、轻巧的、灵活的FIFO队列方案。其具体实现如下:
  
  首先,将同一个红包ID的所有请求stick到同一台Server。
  
  上面SET化方案已经介绍,同个红包ID的所有请求,按红包ID stick到同个SET中。不过在同个SET中,会存在多台Server服务器同时连接同一台DB(基于容灾、性能考虑,需要多台Server互备、均衡压力)。
  
  为了使同一个红包ID的所有请求,stick到同一台Server服务器上,在SET化的设计之外,微信红包系统添加了一层基于红包ID hash值的分流。
  
  其次,设计单机请求排队方案。
  
  将stick到同一台Server上的所有请求在被接收进程接收后,按红包ID进行排队。然后串行地进入worker进程(执行业务逻辑)进行处理,从而达到排队的效果。
  
  最后,增加memcached控制并发。为了防止Server中的请求队列过载导致队列被降级,从而所有请求拥进DB,系统增加了与Server服务器同机部署的memcached,用于控制拆同一个红包的请求并发数。
  
  具体来说,利用memcached的CAS原子累增操作,控制同时进入DB执行拆红包事务的请求数,超过预先设定数值则直接拒绝服务。用于DB负载升高时的降级体验。
  
  通过以上三个措施,系统有效地控制了DB的“并发抢锁”情况。
  
  3.双维度库表设计,保障系统性能稳定
  
  红包系统的分库表规则,初期是根据红包ID的hash值分为多库多表。随着红包数据量逐渐增大,单表数据量也逐渐增加。而DB的性能与单表数据量有一定相关性。当单表数据量达到一定程度时,DB性能会有大幅度下降,影响系统性能稳定性。采用冷热分离,将历史冷数据与当前热数据分开存储,可以解决这个问题。
  
  处理微信红包数据的冷热分离时,系统在以红包ID维度分库表的基础上,增加了以循环天分表的维度,形成了双维度分库表的特色。
  
  具体来说,就是分库表规则像db_xx.t_y_dd设计,其中,xx/y是红包ID的hash值后三位,dd的取值范围在01~31,代表一个月天数最多31天。
  
  通过这种双维度分库表方式,解决了DB单表数据量膨胀导致性能下降的问题,保障了系统性能的稳定性。同时,在热冷分离的问题上,又使得数据搬迁变得简单而优雅。
  
  综上所述,微信红包系统在解决高并发问题上的设计,主要采用了SET化分治、请求排队、双维度分库表等方案,使得单组DB的并发性能提升了8倍左右,取得了很好的效果。
  
  在分析了业界“秒杀”系统解决方案的基础上,微信红包采用了SET化、请求排队串行化、双维度分库表等设计,形成了独特的高并发、资金安全系统解决方案,并在平时节假日、2015和2016春节实践中充分证明了可行性,取得了显著的效果。在刚刚过去的2017鸡年除夕夜,微信红包收发峰值达到76万每秒,收发微信红包142亿个,微信红包系统的表现稳定,实现了除夕夜系统零故障。