微信红包后台系统设计

背景

微信作为一款国民应用，已经进入每个互联网用户手中，微信支付作为其杀手级功能，在每一次佳节期间都会产生巨大流量，以2017年除夕为例，峰值QPS在76w左右，整个系统核心功能和金融相关，需要做好高可用​

微信红包支付流程图

一个发红包的流程经过抽象可得到如下路径：包 -> 发 -> 抢 -> 拆​

微信红包的核心知识

1.
包红包：系统给每个红包分配一个唯一ID，也就是发红包的订单号，红包发送给用户，红包的个数、金额写入存储​

2.
发红包：用户使用微信支付完成付款，微信红包后台收到微信支付成功的通知。红包系统将红包发送订单状态更新，更新为用户已支付，并写入用户发红包记录表，这样用户可以在钱包中找到用户的发红包流水和收发红包的记录，之后微信红包系统调用微信通知，将微信红包信息发送到微信群​

3.
抢红包：微信群中的用户收到红包消息之后，点开红包，开始抢红包，这个过程微信红包系统会检查红包是否已经被抢完，是否已经过期，是否已经抢过等验证逻辑​

4.
拆红包：拆红包是整个发红包流程最复杂的一个操作，需要查询这个红包的红包订单，判断用户是否可以拆包，计算本次可拆到的红包金额。记录抢红包流水​

最后的拆红包过程类似于一个秒杀活动的过程，需要做好库存扣减和秒杀记录的操作。更新库存就是更新红包发送的订单，写入秒杀记录就是写入红包领取的信息流水，还需要以用户为中心记录用户整体的红包领取记录，最后调用支付系统将拆红包后的金额转入用户零钱中，成功之后更新抢红包的订单状态为转账成功​

架构

影响系统可用性的指标有哪些？

计划外逻辑：很多意想不到的因素都可能对我们系统可用性带来挑战，系统需要可以应对所有可能的故障，有些故障无法避免，那么我们是否可以缩短故障周期进行快速修复或是止损​

•
系统级故障：主机、操作系统、中间件、数据库、网络、电源​

•
数据和中介故障：人员操作、硬盘故障​

•
其他：自然灾害、人为破坏、供电问题​

计划内逻辑：要是业务升级或迭代导致，或是运维的主从操作导致，或是一些定时的备份逻辑等。这一些因素需要做到精细化的方案，可以避免或是降低影响​

•
日常任务：备份、容量规划、用户和安全管理​

•
运维升级相关：数据库维护升级、应用维护升级、中间件运维升级、网络维护、操作系统维护升级​

微信红包架构在可用性上做了哪些事？

•
业务逻辑层：部署方案，异步化，降级和柔性可用​

•
订单存储层：SET化，DB故障自愈能力建设​

部署方案

上海深圳两地部署，同城三园区部署，每个园区容量冗余1/3

在部署上的收益：就近接入，单机，单IDC故障不影响正常业务，避免宏观单点​

弊端：资源，需要做好数据同步

异步化

基本思路：简化关键路径，快慢分类

微信红包后台系统设计​