微信红包高并发架构设计

1. 微信红包业务特点以及技术难点

1.1 业务特点

类似于线上的秒杀,海量的并发请求;更严格的安全级别,因为牵扯到资金交易,所以就不可以有像用秒杀活动当中的那种超卖的方式。

1.2 流程

  • proxy

    • 处理请求接入
  • server

    • 主要业务逻辑
  • DB

    • 数据持久化
    • 事务级别的完成 - 完全执行或者完全不执行
      • 锁库存
        • 为了避免并发请求时出现超卖情况
        • 技术难点,当大量用户同时做秒杀操作的时候,第一个到达DB的请求锁住了这行库存记录。在第一个事务完成提交之前这个锁一直被第一个请求占用。——> 技术难点,并发请求抢锁
      • 插入秒杀记录
      • 更新库存
  • Cache

    • 缓存库存数量

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

2.1 高并发问题常用方案

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

server 到内存Cache,做扣库存的操作,然后内存Cache异步持久化到数据库。但是如果内存Cache炸了,或者内存Cache更新,但是DDB没有更新,都会很崩。多个服务器之间的同步也会是一个不小的问题。

2.1.2 使用乐观锁 instead of 悲观锁

  • 乐观锁
    • 假设多用户并发的事务处理时不会相互影响。在提交数据更新之前,每个事务会检查在该事务读取数据之后,有没有其他事务又修改了数据。如果其他事务用更新的话,正在提交的事务会进行回滚。
  • 悲观锁
    • 阻止一个事务以影响其他用户的方式来修改数据

对于微信红包的使用场景,即需要在DB里维护一个版本号,在更新库存的操作进行之前,先去DB获取当前版本号,然后在更新库存的事务提交的时候,检查是否被修改。

这么做的问题在于:

  • 乐观锁,多个用户同时抢红包,那势必只有一个成功,另外的都会显示失败 - 报错,这就用户体验很差劲了
  • 而且会造成刚开始可能失败,后面因为并发小了,有成功的案例的可能性
  • 大量无效请求,回滚,给DB带来很大压力

2.2 微信红包系统的解决方案

  • 系统垂直SET化
    • 生成ID作为红包的唯一标识
    • 红包系统根据ID做垂直切分,一个垂直逻辑链条上的Server和DB们叫做一个SET
    • 各个SET相互独立,且解耦,每个红包ID的所有请求都会在同一个SET当中来处理
      • 看起来像是需要主备两台服务器,备用服务器平常没有流量,完全用来在主服务器出问题的时候,直接转备用
  • 逻辑Server层将请求排队,解决DB并发问题
    • 将拆红包的事务操作做串行处理,在Server层做FIFO的排队处理
  • memcached控制并发
    • 利用CAS原子累增操作,控制同时进入DB拆红包的请求数,超过预定值就直接拒绝服务,通过这种方式来做DB负载过高时的降级体验
  • 双维度库存表设计
    • TTL
    • 冷热数据分离

转载请注明来源,欢迎对文章中的引用来源进行考证,欢迎指出任何有错误或不够清晰的表达。可以在下面评论区评论,也可以邮件至 stone2paul@gmail.com

文章标题:微信红包高并发架构设计

文章字数:877

本文作者:Leilei Chen

发布时间:2020-02-04, 11:24:04

最后更新:2020-02-04, 11:24:25

原始链接:https://www.llchen60.com/%E5%BE%AE%E4%BF%A1%E7%BA%A2%E5%8C%85%E9%AB%98%E5%B9%B6%E5%8F%91%E6%9E%B6%E6%9E%84%E8%AE%BE%E8%AE%A1/

版权声明: "署名-非商用-相同方式共享 4.0" 转载请保留原文链接及作者。

目录
×

喜欢就点赞,疼爱就打赏