高并发资金交易系统设计方案—百亿双十一、微信红包背后的技术架构

本是古典何须时尚 2022-07-12 11:09 369阅读 0赞

![640_wx_fmt_png_tp_webp_wxfrom_5][]

> 21CTO社区导读 :
> 
> 今天带来的是一个长篇文章。主要讲解高可用的互联网交易系统架构，包括双十一、支付宝&微博红包技术架构，以及微信红包的技术架构，希望能给各位提供价值。

> 概述

话说每逢双十一节或春节等节假日，对大家来讲是最欢乐的日子，可以在微信群中收发红包，此外今年微信还推出了**面对面红包**，让大家拜年时可直接收发，对于用户来讲很爽也很方便。但对于技术架构侧的考量，这使得**微信红包的收发数据成几何倍数上升**，处理的复杂度也增加了很多。

**2017年微信红包发送量**最大的时间段是除夕夜，达到了**142亿个**。如此**大规模、高并发、高峰值**的业务场景，怕是在美帝互联网的技术团队，包括EBay、Amazon等也无法想象，在这种巨大的流量与并发后面，需要什么样级别的技术架构支撑？当达百亿级别的资金交易规模时，我们该怎样来保证系统的并发性能和交易安全？

当今中国的电子商务平台，有**两个场景称得上亿级以上的并发量**：一个是**阿里的双十一**，一个是**微信的红包**，都是在一个单位时间达到亿万以以上的请求负载。

> 阿里交易系统与红包体系架构

我们先来回顾一下阿里『双十一』的业务场景。

中国移动互联网的完全普及，使得电商业务每年都几百倍甚至更高倍速的增长，包括农村用户也对电商逐渐认可。电商巨头们每年创造出的新节日，无论是『双十一』还是『双十二』，都最大化点染了用户的消费欲望，人们在这一天疯狂下单和参与秒杀活动，期望用最便宜的价格购买到心仪的商品，这导致一些平台**后端商品超卖，服务器负载过高拒绝服务等问题频频出现**。

网站以及各个客户端带来巨大的流量**对后端技术架构的要求越来越苛刻**。比如某个电商网站宕机，对用户和订单的损失是无法估量的，就算老板拿着把刀放在桌子也无法根本上解决问题，关键还是看技术团队的架构、能力，同时也包括软硬件等相关资源投入。

我们拿刚刚过去的2016年『双十一』来讲，阿里巴巴&淘宝网的当天交易额为1207亿元，而2015年的数字为912.17亿元，成交额足足增长了32.32％。1207亿的巨大交易量，背后是阿里巴巴的云平台提供的技术支撑。马云同志说，所有的创新都是被逼出来的，不管是被他逼，还是用户逼，阿里的技术平台就是这样被倒逼了出来。

在2016年的阿里技术栈中，和往年比技术平台也发生了很大变化，一部分变成了数据挖掘，有一部分演变了人工智能计算。除了传统的Web后端，还增加了直播平台流媒体应用。

视频直播系统与Web系统有相同也有不同之处，来看大部分视频直播平台的存在着一些技术瑕疵。如下图示：

以上的问题在后端需要实施不同的技术解决方案，需要进行日志采集实时监控，比如对终端类、后台类以及CDN的运行日志进行分析等。

阿里的直播端，视频传播使用了H.265编码压缩。H265编码在压缩比以及清晰度上要超过目前主流的H.264标准。阿里云使用了自己的ApsaraVideo平台完成了这些任务。这个APsaraVideo提供了以下子系统：

1、客户端推流sdk

2、云端OpenAPI

3、CDN分发

阿里通过上面一系列产品，将推流、转码、分发、播放等问题全部解决。

关于流量的负载均衡，阿里**双十一采用了双专线的CDN**，**20T以上的带宽**，这样可**支撑1000万人同时在线下单和观看视频直播**。

在视频的传播压缩，阿里率先使用H.265编码压缩。H265在压缩比以及清晰度上要超过目前主流采用的H.264标准。

数据存储

在**手机淘宝中的用户关注信息存储在云服务器的Redis**中，**订单等持久化数据保存在RDS**（阿里云的MySQL集群）中。

在阿里的电商平台，从双11节开始后，每笔交易队列都是通过**消息中间件系统**来做流转，包括**消息发布订阅，状态，定时**，监控报警等消息服务——这个消息系统是阿里自研的产品称为**AliwareMQ（内核为RocketMQ）**，当然我们也可以使用**ActiveMQ,RabbitMQ等开源软件**。

商品支付成功后的订单完成后，发给**各个物流公司的订单数据**采用了**PetaData的产品，支持OLTP和OLAP注**。（注：PetaData分布式数据库之一，OLTP:On-Line Transaction Processing[联机事务处理][Link 1]系统(OLTP) 也称为面向交易的处理系统，其基本特征是顾客的[原始数据][Link 2]可以立即传送到计算中心进行处理，并在很短的时间内给出处理结果;联机分析处理 (OLAP) 的概念最早是由关系数据库之父E.F.Codd于1993年提出的联机分析处理OLAP（On-Line Analytical Processing），OLTP是传统的关系型数据库的主要应用，主要是基本的、日常的事务处理，例如银行交易。OLAP是数据仓库系统的主要应用，支持复杂的分析操作，侧重决策支持，并且提供直观易懂的查询结果。）不需要把一份数据进行多次复制，然后再进行数据分析，免去在线与离线数据仓库之间海量数据的传输和加载时间，实现在线分析决策。

支付宝与微博红包架构

支付宝红包通过**性能较高的分布式文件系统**保证用户数据的高可靠与高可用。分布式文件系统需要考虑**多机集群之间的一致性与效率问题**。

新浪微博红包在2017年除夕的发抢数量也达到了16亿个以上，**参与的用户有不同的类型与地域**，对**架构、监控与性能优化**具有一定的挑战。除了通过**CDN，分布式图片系统**等处理性能问题，另外还有**系统底层的内核进行优化，安全修复以及软硬件扩容**。

> 微信红包技术架构

2017年1月28日，正值农历正月初一，腾讯微信平台公布了在除夕当天用户收发微信红包的数量达到142亿个，**收发峰值为76万/秒**。

2015年的春节数据：除夕摇一摇总次数110亿次，**峰值1400万次/秒**，8.1亿次每分钟，微信红包收发达10.1亿次，除夕红包为1.2亿个。

2014年的红包峰值每分钟被拆开红包数量为2.5万个。我们可以看到，2017年是2014峰值的5000倍，红包数量达到百亿级别。

保障并发性能与资金交易安全，带来了超级挑战。

微信技术平台总结过红包技术有三大难点：

快——如何保证用户快速摇到红包？

准——如何保证摇到的红包能成功拆开？

稳——如何保证拆开的红包能分享出去？

微信红包技术结合电商平台设计的秒杀系统之基础，采用了以下技术解决方案：

*  **SET集合化**
 *  **串行化请求队列**
 *  **双维度分拆数据库表**

通过以上方案设计，形成了自己的高并发、资金安全系统解决方案。

我们先回到使用场景中。

当大量的微信用户在同一时间摇红包，就会产生每秒千万级请求。需要对请求**疏导分流**。

如果不进行负载均衡，分离流量，直接到达后端服务器，多大的服务器集群都会被如此大的流量负何过大而崩溃。

我们来看除夕当天后台监控数据曲线便能说明一切。如下图示：

各位可以看到，在前台红包重重的分流减压下，后端服务器负载仍然瞬间飙升几十倍甚至更高。

红包产品特点

微信红包，特别是群里的红包，我们称之为**微信群红包**。这个东西的产品形态上像极了电商平台上的**商品“秒杀”活动**。

举个场景栗子，某位土豪在微信群里发一个红包，这相当于商品“秒杀”商品上架。然后群里的其它人开始疯狂抢之，这个场面相当于“秒杀”的库存查询——看看还有没有货。当用户抢到红包后，红包在眼前晃呀晃时，食指轻点开拆红包的操作，它对应了“秒杀”活动中点击秒杀按钮动作。

有的时候，点击出红包会提示网络出问题，则是秒杀时你的库存队列没有别人的快，微信给了一个友好的提示罢了。

这点上，和我们在**12306网站抢火车票**是同样的道理。

且不急下定论，微信红包在产品形态上和商品秒杀相比，也有着自己的一些特点和难点。来看都是哪两点：

第一：微信红包产品与商品“秒杀”，**数量大&并发量更高**。

为啥这么说？各位看，当土豪在群里发了一个红包，相当在网站发布了一次秒杀活动对吧？有10万个微信群里的人在 同一时刻发起红包请求，也就是说在瞬息之间，时时存在10万个“秒杀”活动发布出来。

接下来，10万个微信群里的用户同时开抢红包，便产生了**海量的并发查询请求**。

第二：微信红包产品**需要极高的安全级别**。

红包的收发，本质上就是资金的交易。微信红包本身是微信支付（底层支撑是财付通平台在干活）的一个商户，由微信红包来提供资金流转服务。

群里土豪发红包时，相当使用微信红包商户名义**向微信支付申请购买了一笔“钱”**，而**收货地址是当前的微信群**。

当土豪**支付成功后，红包就“发货”到该微信群中**，群里的人拆开红包后，微信红包商户提供将“钱”转入拆红包成功用户的微信零钱服务。

由于是和钱相关的交易业务，它比普通商品“秒杀”活动有更高的业务严密和安全级别要求，与银行的在线交易有过之而无不及。

而电商平台上“秒杀”商品由商家提供的，库存是被事先预设好的，即使出现“超卖”（即实际被抢的商品数量比计划的库存多）、“少卖”（即实际被抢的商户数量比计划的库存少）时也有办法解决，比如和用户商量、不发货或者做虚假繁荣，BD小伙伴对外吹吹牛也就算了。

对于微信红包产品就非常非常严谨，一块钱也不能多，一分钱也不能少，绝不能有半点错误。比如群里土豪发249元的红包绝对不可以被拆出250块钱，用户发了100块钱未被领取，在24小时的退还期内要精确地退还给原路——发红包的用户。

第三：**微信红包与接口效率**。

**微信红包和微信支付与支付宝的最大区别是，自己不做金融（余额宝业务）**，所有的支付操作均与用户绑定的银行卡银行接口交互。因此，**与银行接口的安全，效率性能等需要有严密的设计**。

微信红包架构难点

上面几次说，红包架构与秒杀系统有着些许相似。我们先重温下**典型的秒杀系统架构设计**，来看下图所示。

这个系统可谓是经典。它由**网关代理接入层**、**商业逻辑服务层**、**缓存与实体存储层**等构成。其中：

代理层，可使用**Nginx或Varnish来处理请求接**入

（注：Varnish 是内存缓存，速度一流，但是内存缓存也限制了其容量，缓存页面和图片一般是挺好的）

Web服务器使用Nginx承载主要的业务逻辑，Cache层如使用Memcached或Redis来缓存库存数量、数据库

（注：Memcached是以LiveJurnal旗下Danga Interactive公司的Bard Fitzpatric为首开发的高性能分布式内存缓存服务器。其本质上就是一个内存key-value数据库，但是不支持数据的持久化，服务器关闭之后数据全部丢失；Redis是一个开源、支持网络、基于内存、键值对存储[数据库][Link 3]，使用ANSI C编写。）

使用MySQL/MariaDB集群中，做数据库的持久化存储。

（注：MariaDB数据库管理系统是MySQL的一个分支，主要由开源社区在维护，采用GPL授权许可 MariaDB的目的是完全兼容MySQL，包括API和命令行，使之能轻松成为MySQL的代替品。）

业务逻辑层可以是多个Nginx的集群，Cache层可以是多台机器组成的大的内存池，包括**数据库缓存，OpCode缓存**等不同类型

(注：当解释器完成对脚本代码的分析后，便将它们生成可以直接运行的中间代码，也称为操作码（Operate Code，opcode）。Opcode cache的目地是避免重复编译，减少CPU和内存开销。)。

从数据库侧阐述，数据库可以**根****据不同业务或日期**进行**分表分库，读写分离**等组成一个**负载平衡的集群**。

在秒杀业务中，表现就是一个秒杀活动对应Inodb中的一条库存。

（注：InnoDB，是MySQL的数据库引擎之一，为[MySQL AB][]发布binary的标准之一。InnoDB由Innobase Oy公司所开发，2006年五月时由[甲骨文公司][Link 4]并购。与传统的[ISAM][]与[MyISAM][]相比，InnoDB的最大特色就是支持了[ACID][]兼容的[事务][Link 5]（Transaction）功能，类似于[PostgreSQL][]。）

当某个用户开始点秒杀动作时，系统的主要逻辑在于数据库中对库存的操作上。

这样，在数据库的事务中包含以下3个步骤：

1、锁定库存LOCK

2、插入秒杀记录 INSERT

3、**更新库存 UPDATE**

可以肯定的是，所有的大小电商网站均是依此套路。详解解释如下：

首先锁定库存为避免并发请求时出现“超卖”的情形，同时下单的用户需要等待此事务执行完后再执行下一个事务。

在数据库的事务完整性要求，这三步需要在一个时间段一个系列中完成，当中间有一处错误发生即进行回滚，相当于放弃当前事务，若无错误发生，则整体事务的执行顺利被完成。

商品库存在数据库中记为一行，大量的用户同时点击购买同一件SKU时，第一个到达数据库的请求就锁住了这行库存记录。

在第一个事务完成提交之前这个锁一直被**第一个请求占用**，后面的所有请求就需要排队等待。

同时参与“秒杀”的用户越多，并发进数据库的排队请求就越多，如同旅行时去卫生间，队形被排的很长。

所以**并发请求抢锁的事备**，成为典型的“秒杀”或抢购类系统的设计难点。

在微信红包系统的设计上，事务级操作量级更大。即便在普通的时间下，每一时刻都会有数以万计的微信群在同一时间端发起红包，就是引发几万并发请求抢锁同时在排队，这使得数据库的压力比普通单个商品“库存”被锁放大更多倍。

解决高并发的常用解决方案

常见商品秒杀活动，解决高并发问题，可以有如下几种解决方案：

一，内存数据库替代数据库事务

如上图所示，我们把**实时扣库存的行为上移**到**内存数据库或者叫缓存层来干活**，缓存操作完毕后再**返回服务器成功**，通过**队列异步返回到数据库进行持久化**。

使用内存操作替代磁盘操作，会明显提升并发性能。但是需要注意引发的缺点，如果在**内存操作完成，数据库保存失败，或内存出现Crash，数据库的存储进程不会进行**。因此，*这种解决方案不适合与钱相关的交易系统应用*，特别是微信红包。

二，使用乐观锁替代悲观锁

我们来回顾一下关系数据库管理系统中的**两种锁的概念**。

**悲观锁**是DBMS里的一种并发控制的方法，它**阻止一个事务以影响其他用户的方式来修改数据**。若一个事务执行的操作对某行数据加了锁，只有这个事务将锁释放，其他事务才能够执行与该锁冲突的操作。此描述对应于上面所说的**并发请求抢锁行为**。

而**乐观锁**，**假设多用户并发的事务在处理时不会彼此互相影响**，各事务能够在不产生锁的情况下处理**各自影响的那部分数据**。在提交数据更新之前，每个事务会先检查在该事务读取数据后，有没有其他事务又修改了该数据。**如果其他事务有更新的话**，正在提交的事务会进行回滚。

秒杀系统中，使用**乐观锁**会在库存记录中**维护一个版本号**。在更新库存操作进行前，先取当前版本号，在更新库存的事务提交时，**检查该版本号是否已被其他事务修改**。若**版本未被修改**，则**提交事务，版本号加1**。如果**版本号已被其他事务修改**，则**回滚事务，并给上层报错**。

乐观锁方案解决了“并发请求抢锁”的问题，可以提高数据库的并发处理能力。

似乎问题被解决，使用乐观锁对于一般的应用系统足够，但将它应用于**微信红包系统中，会引发下面几个问题**。

如果**拆红包采用乐观锁**，在并发抢到相同版本号的拆红包请求中，**只有一个人能拆红包成功，其他的请求将事务回滚并返回失败**，给用户报错，用户完全不可能接受这种体验。

采用**乐观锁**将会导致**第一时间同时拆红包的用户有一部分直接返回失败**，反而**那些『网慢手慢』的**，会有可能因为**并发减小后拆红包成功**，这也会带来用户体验上的负面影响。

如果采用**乐观锁**的方式，会**带来大数量的无效更新请求、事务回滚**，给DB造成不必要的额外压力。

有鉴于以上原因，微信红包系统也不能用乐观锁的方式解决并发抢锁问题。

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

我们综合上面的一系列分析，微信红包针对相应的技术难点，采用了下面几个方案来解决高并发问题。

1 系统垂直集合化

**集合（SET）化，即分组进行管理**。

当微信红包用户发一个红包时，微信红包系统生成一个**ID当它的唯一标识**，接下来针对于这个红包的所有发、抢、拆、查询详情等操作都根据这个ID关联。

红包系统根据这个红包ID，按一定的规则（如按ID尾号取模等），垂直上下切分。切分后，一个**垂直链条上的逻辑服务器、服务器统称为一个SET**（集合）。

这样，每个集合间相互独立，互相解耦，不存在任何关联。

同一个红包ID的所有请求，包括发、抢、拆、查详情详情等，**合并在一个集合内处理**，形成**高内聚**。

通过此法，系统将所有红包请求这个**巨大的洪流**分散为**多股小流**，犹似诸侯各国，互不影响，各自治理。请看下图所示：

综上所述内容，这个方案对同时存在海量事务级操作的问题，将海量化为微量，问题得以解决。

2 逻辑服务层将HTTP请求队化列化，解决数据库并发

前面提到过，微信红包系统是个交易系统，而数据库操作的事务性（悲观/乐观锁，回滚等特性）是不可能不用的，因此势必会存在“并发抢锁”的现象。

我们把到达数据的事务操作（拆红包行为）的**并发改为串行**，由统一一个通道出口，就**不会存在“并发抢锁”**的问题了。

这个其实和很多电商平台，以及**PUSH系统**等原理相似。

这样我们的策略就清晰明白了，接着来把拆红包的事务操作**串行地进入数据库**，来将请求在服务器层以**FIFO（先进先出）**的方式排队，就可以达成串行的效果。

关于服务器的FIFO队列系统，在前面提到过阿里的RoketMQ、ActiveMQ还有RabbitMQ等消息中间件产品。当然腾讯的技术团队自己设计了一个**分布式的、轻巧的、灵活的FIFO队列**产品。

具体解决方案实现如下：

首先，将同一个红包ID的**所有请求归聚到同一台服务器**。使用集合化，将同一个红包ID的全部请求，**提到到同一个集合中**。同个**SET中会存在多台服务器同时连接同一台数据库服务器**。这是基于容灾、性能等考虑，**多台服务器互备冗余，并且将流量进行均衡负载**。

怎样将同一个红包ID所有请求，提到同一台服务器上？在集合化的设计之外，微信红包系统添加了一层**基于红包ID 哈希值的分流**，如下图所示：

这和很多分布式系统很像，如图片的分布式存储，数据库的哈希分布等，可谓大道相通。

我们接下来再设计单机请求排队之方案。当同一台服务器上的所有请求被接管后，然后按红包ID进行排队，串行地进入工作进程处理，达到排队的效果。看下图所示：

接下来我们使用memcached来控制并发数量，具体实施为：

为了防止服务器中的请求队列过载，导致队列被降级，所有请求又冲进了数据库，造成数据库锁与响应过慢，红包系统又增加了与服务器同机部署的**memcached内存数据库**，把它**用来控制拆同一个红包的请求并发数**。我们实际是利用memcached的CAS原子性累增操作

（CAS是单词compare and set的缩写，意思是指在set之前先比较该值有没有变化，只有在没变的情况下才对其赋值。）

来控制同时进入数据库中执行拆红包事务的请求数，苦超过预先设定数值则直接拒绝服务，用于处理数据库负载升高时的降级体验。

通过以上三个措施，我们就控制了数据库的“并发抢锁”问题。

3 双维度库表设计，保障系统性能稳定

任何**系统的进化**，在**持久层都开始分库分表**，微信红包系统也不例外。

微信红包的分库表规则，最开始是**根据红包ID的哈希值分为多库多表**。

随着红包数据量逐渐增大，单表数据量也逐渐增加，数据库的性能与单表数据量有一定相关性，例如I**nndoDB单表数据量达到几T的时水平**时，**性能**会有不同程序的**下降**，这样就影响系统性能稳定性。

我们可以采用**冷（不经常被查询到）热（频率存取的）数据的分离**，将**历史冷数据与当前热数据分开存储**，来解决这个问题。

在处理冷热数据的分离时，在红包ID维度分库表的基础上，**增加了以循环天分表的维度**，形成了双维度分库表的特色。

具体如下，比如分库表规则使用哈希+月份的开工，类似db\_xx.t\_y\_dd设计。其中：xx/y是红包ID的哈希值的后3位，dd是月份，取值范围在01~31，代表一个月天数最多到31天。

通过两种维度的分库表，我们解决了数据单表的大量膨胀，导致性能下降的问题，从而保障了系统性能的稳定性。同时在热冷数据分离的问题上，使得数据迁移变得简单优雅。

以上是微信红包系统在解决高并发问题上的设计方案。总结起就是：采用集合化分治、队列系统、多维度分库分表方案，使得单集群数据库的并发性能提升了多倍，取得了良好的用户体验。

在平时节假日、2015和2016春节实践中充分证明了可行性，取得了显著的效果。在刚刚过去的2017鸡年除夕夜，微信红包收发峰值达到76万每秒，收发微信红包142亿个。微信红包系统的表现稳定，实现了除夕夜红包收发顺畅零故障。

小结

本文从实战出发，讲解了电商平台以及交易系统的典型红包系统的构建，包括分布式集群系统的灵活应用，实现Web服务器、内存、缓存以及数据库的有效利用。通过秒杀系统触类而旁通到红包系统，用简单有效的思维来解决复杂问题。

> 作者：21CTO社区
> 
> 说明：本文参考了腾讯大讲堂关于微信红包架构的文章，原文一部分生涩部分做了优化。阿里架构一部分内容参考了阿里云社区关于双十一的部分内容。

[640_wx_fmt_png_tp_webp_wxfrom_5]: /images/20220710/bb46d88d8179486ba08ae869b68156b2.png
[Link 1]: http://www.bing.com/knows/%E8%81%94%E6%9C%BA%E4%BA%8B%E5%8A%A1%E5%A4%84%E7%90%86
[Link 2]: http://www.bing.com/knows/%E5%8E%9F%E5%A7%8B%E6%95%B0%E6%8D%AE
[Link 3]: http://www.bing.com/knows/%E6%95%B0%E6%8D%AE%E5%BA%93
[MySQL AB]: http://baike.baidu.com/view/2270659.htm
[Link 4]: http://baike.baidu.com/view/22424.htm
[ISAM]: http://baike.baidu.com/view/1631256.htm
[MyISAM]: http://baike.baidu.com/view/1238940.htm
[ACID]: http://baike.baidu.com/subview/600227/5926023.htm
[Link 5]: http://baike.baidu.com/view/121511.htm
[PostgreSQL]: http://baike.baidu.com/view/28196.htm