请选择 进入手机版 | 继续访问电脑版

默认
打赏 发表评论 0
社交软件红包技术解密(五):微信红包系统是如何实现高可用性的

本文来自微信团队工程师方乐明的技术分享,由InfoQ编辑发布,即时通讯网收录时有修订和改动。原文地址:mp.weixin.qq.com/s?__biz=MjM5MDE0Mjc4MA==&mid=2650996535&idx=1&sn=95f32730f45cae1bce23ee796b0277c1,感谢原作者的分享。


一、引言


微信红包业务量级的高速发展,对后台系统架构的可用性要求越来越高。在保障微信红包业务体验的前提下,红包后台系统进行了一系列高可用方面的优化设计。

本次分享介绍了微信红包后台系统的高可用实践经验,主要包括后台的 set 化设计、异步化设计、订单异地存储设计、存储层容灾设计与平行扩缩容等。听众可以了解到微信红包后台架构的设计细节,共同探讨高可用设计实践上遇到的问题与解决方案。

补充说明:本文对应的演讲PPT详见《微信红包系统可用性设计实践(PPT) [附件下载]》。

二、分享者


方乐明:现任微信支付应用产品系统负责人,主要从事微信红包、微信转账、微信群收款等支付应用产品的系统设计、可用性提升、高性能解决方案设计等,曾连续多年负责春节微信红包系统的性能优化与稳定性提升,取得良好的效果。

三、系列文章


❶ 系列文章目录:


❷ 其它相关文章:


四、微信红包介绍


微信红包从 2014 年开始发展到现在,中间经历了几年时间。在这几年的时间里,整个系统可用性产生了很大的提升。2015 年年初的时候,每天晚上九点钟是微信红包的业务高峰期,系统经常性地出现性能问题。到了今天,即使在节假日高峰期,系统也不会出现问题。

1.jpg
▲ 红包印象 – 产品形态(点此查看本图出处

如上图所示,微信红包的业务包含包、发、抢、拆、查询发送红包和收红包数量,其中最关键的步骤是发红包和抢红包。

微信红包是微信支付的商户,微信红包这个商户出售的是钱。发红包用户在微信红包平台使用微信支付购买一份钱,微信红包将钱发放到相对应的微信群。群里的用户抢红包得到微信零钱。这个过程中,微信红包和微信支付之间的关系是商家和第三方支付平台的关系。

微信红包和微信支付之间的交互,与普通商家与微信支付的交互一样,需要经过六个步骤。用户发红包时,进入微信红包下一笔订单,系统记录发红包用户、发红包金额、红包数量和要发送到的用微信群。然后微信红包系统请求微信支付服务器进行下单,用户使用微信支付进行支付。

支付成功后,微信支付后台系统通知微信红包后台系统支付成功结果,微信红包后台系统收到通知后推送微信红包消息到微信群。微信群里用户便可抢红包。这就是微信红包和微信支付的关系以及交互过程。

五、微信红包系统架构


5.1微信红包的系统流程


2.jpg
▲ 微信红包的系统流程(点此查看本图出处

上图是微信红包系统角度上的流程,业务主流程是包、发、抢、拆四个操作,每个操作包括几个关键步骤。

包红包:系统为每个红包分配一个唯一 ID,即红包发送订单号,然后将发红包用户、红包个数、红包数额写入存储,最后去微信支付下单。

发红包:用户使用微信支付完成付款,微信红包后台系统收到微信支付系统的支付成功通知。红包系统将红包发送订单状态更新为用户已支付,并写入用户发红包记录(用户发红包记录,就是微信钱包中,查看到的用户每一年总共发出及收到的红包记录)。最后微信红包后台系统发送微信红包消息到微信群。

抢红包:指微信群里的用户收到微信红包消息后,点开红包消息。这个过程,微信红包后台系统会检查红包是否已被抢完,是否已过期,是否已经抢过。

拆红包是最复杂的业务是操作,包括:

  • 1)查询这个红包发送订单,判断用户是否可拆,然后计算本次可拆到的红包金额;
  • 2)然后写入一条抢红包记录。如果把拆红包过程,类比为一个秒杀活动的过程,相当于扣库存与写入秒杀记录的过程;
  • 3)更新库存对应于更新红包发送订单,写入秒杀记录对应于写入这个红包的领取红包记录;
  • 4)另外,还要写入用户整体的红包领取记录;
  • 5)最后请求微信支付系统给拆到红包用户转入零钱,成功后更新抢红包的订单状态为已转账成功。

5.2微信红包的整体架构


3.jpg
▲ 微信红包的系统架构(点此查看本图出处

上图所示,是微信红包的系统架构。包括微信统一接入层,下面是微信红包系统 API,包括发、抢、拆、查红包详情、查红包用户列表。再下面是封装微信红包关键业务的逻辑服务;最下面一层是数据存储层,微信红包最主要的数据是订单数据,包括发红包订单和拆红包订单两部分。业务逻辑和存储服务器之间是数据接入层,它最重要的作用是封装数据库操作的领域逻辑,使得业务逻辑服务不需要感知对 MySQL 的连接管理、性能、容灾等问题。

微信红包数据的访问热度,随着时间流逝会急剧降低,也就是数据的访问时间段非常集中,一般红包发出三天后,99% 的用户不会再去点开这个红包了。因此微信红包系统采取按时间做冷热数据分离,降低数据的存储成本,同时提升了热数据的访问性能。

数据平台用于对红包数据的分析计算,比如朋友圈里的文章,统计从 某年 1 月 1 日到 2017 年 1 月一个用户总共抢红包的金额,在全国的排名情况,发红包数最多的城市等。另外一个作用就是对账,红包的订单和微信支付的订单需要对账,以保证最终资金的一致性;订单的数据和订单的 cache 需要做对账,以保证数据的完整性;订单数据和用户的收发记录需要对账,以保证用户列表完整性。

六、微信红包系统可用性实践


6.1系统可用性影响因素


系统的可用性影响因素可分成两类:

  • 一类计划外;
  • 一类计划内。

计划外包含很多因素,系统用到的所有东西都可能产生故障,都可能成功影响可用性的因素。从这个角度上来讲,可以说故障是无法避免的,系统的运作一定会产生故障,尤其是服务器有成千上万个的时候。计划内的影响因素,主要有与升级相关、运维相关的操作,以及日常的备份等。这一类影响因素,通过精细地设计方案,是可以避免对可用性造成影响的。

6.2微信红包系统可用性设计方向


基于上面两个分析结论,可以总结出微信红包后台系统的可用性的设计方向。就是在不能避免意外故障的情况下,尽可能降低出现意外故障时对可用性的影响。另一方面,绝大多数计划内的日常维护可以通过方案的设计避免影响可用性,其中平行扩容特指关于存储层的平行扩容。

下面从降低故障影响和微信红包系统的平行扩容两方面进行分析。

首先是降低意外故障的影响,重点讲解订单存储层在订单 DB 故障的情况下如何降低对红包系统可用性的影响。

6.3业务逻辑层 - 部署方案设计


首先是业务逻辑层的部署方案。业务逻辑层是无状态的,微信红包系统的业务逻辑层,部署在两个城市,即两地部署,每一个城市部署至少三个园区,即三个 IDC。并且每个服务需要保证三个 IDC 的部署均衡。另外,三个 IDC 总服务能力需要冗余三分之一,当一个 IDC 出现故障时,服务能力仍然足够。从而达到 IDC 故障不会对可用性产生影响。

6.4业务逻辑层 - 异步化设计


4.jpg
▲ 业务逻辑层 – 异步化(点此查看本图出处

第二是异步化设计。如上图所示,微信红包的某些步骤不实时完成也不会影响用户对红包业务可用性的体验。比如拆红包,正常的业务流程很长,但关键步骤只有订单相关的几步。至于转零钱、写红包记录等操作不需要实时。用户抢到红包时,一般不会实时去钱包查看微信零钱,而是在微信群中点开消息查看本次抢到金额和他人抢红包金额。所以拆红包时只需要从 cache 查询用户是否拆过红包,然后写入拆红包的订单记录,更新发红包订单,其他的操作都可以异步化。当然,不是每个业务都可以进行异步化设计,需要进行业务分析,判断是否存在非关键步骤之外的事情可以将其异步化,并通过异步对账保证最终一致。

5.jpg
▲ 订单存储层 – 早期架构(点此查看本图出处

接下来是微信红包订单存储设计。上图是 2014 年微信红包存储层的模型。业务逻辑层请求数据层操作时,使用订单号 hash 路由到订单 SERVER。订单 SERVER 与每一组 MYSQL 数据库连接。

微信红包的订单号是在发红包时系统生成唯一标识,使用序列号服务生成唯一 ID,后面拼接三位微信红包的订单分库表的标识。所以,总共可以分一百个逻辑库,每个逻辑库含有十张表。一百个逻辑库均匀地分布到十组物理 DB,每组 DB 存十个逻辑库。

这个架构的最大问题是,一组 DB 故障时,会影响其他 DB。2014-2015 年期间,微信红包量涨得特别快,扩容速度跟不上业务增长速度。一组 DB 的性能出现瓶颈时,数据操作变慢, 拆红包的事务操作在 MYSQL 排队等待。由于所有十组 DB 机器与所有的订单 SERVER 连接,导致所有的订单 SERVER 都被拖住,从而影响红包整体的可用性。这个架构的另一个问题是扩容不方便,后面会介绍。

为解决 DB 间的相互影响,需要将 DB 间相互隔离,订单存储层 SET 化。SET 化指订单 DB 和订单接入 SERVER 垂直 stick 一起。业务逻辑层访问订单时,根据订单倒数第二、三位数字找到所属订单 SET,一个 SET 的请求不能路由到其他 SET。

找到对应的订单接入服务器之后,在服务器内的多个进程中找到指定进程,让同个红包的所有拆请求串行化。当一组 DB 出现故障,只会影响该组 DB 对应的 SERVER。

这里有一个问题,DB 故障拖住某些订单 SERVER,会不会也拖住更上层业务逻辑服务?业务逻辑层为什么不一起 SET 化?业务逻辑层承载了用户维度相关的业务操作,不可以按照订单的维度分业务逻辑,例如务逻辑层会请求用户的头像、昵称等,如果继续按照订单分业务逻辑,会导致跨地域调用。

微信红包系统采取的方案是,在订单 SERVER 服务端增加快速拒绝服务的能力。SERVER 主动监控 DB 的性能情况,DB 性能下降、自身的 CPU 使用升高,或者发现其他的监控维度超标时,订单 SERVER 直接向上层报错,不再去访问 DB,以此保证业务逻辑层的可用性。

一组 DB 故障不会影响整个系统的可用性。有影响的,只有十分之一,若扩成 100 组,影响便只有一百分之一。所以通过 SET 化得到的好处是,控制 DB 连接数、隔离故障影响和分流并发。

6.jpg
▲ 订单存储层 – 故障自愈(点此查看本图出处

完成 SET 化之后,DB 故障仍对业务有十分之一影响,那么这十分之一该怎么解决?通过对系统进行研究分析之后,发现 DB 可以做到故障自愈。

如上图所示,所设尾号 90-99 的 SET 故障时,如果业务逻辑服务后续不再生成属于这个 SET 的订单,那后续的业务就可以逐渐恢复。

也就是在发生故障时,业务逻辑层发布一个版本,屏蔽故障号段的单号生成,就可以恢复业务。进一步想,除了人为发版本,有没有方法可以让 DB 故障时自动恢复?在 DB 故障导致业务失败时,业务逻辑层可获取到故障 DB 的号段,在发红包时,将这些故障的号段,换一个可用的号段就可恢复业务。订单号除了最后三位,前面的部分已能保证该红包唯一性,后面的数字只代表着分库表信息,故障时只需要将最后三位换另外一个 SET 便可自动恢复。

完成这个设计后,即使 DB 出现故障,业务的可用性也不会有影响。这里还有一点,新的发红包请求可避免 DB 故障的影响,但那些故障之前已发出未被领取的红包,红包消息已发送到微信群,单号已确定,拆红包时还是失败。对这种情况,由于不会有增量,采用正常的主备切换解决即可。

6.5平行扩缩容设计


7.jpg
▲ 平行扩缩容 – 早期方案(点此查看本图出处

上图是微信红包早期的扩缩容方式。这个扩容方式,对扩容的机器数有限制。前面讲到,红包系统按红包单号后面两个数字分多 SET,为了使扩容后数据保持均衡,扩容只能由 10 组 DB 扩容到 20 组、50 组或者 100 组。另外,这个扩容方式,过程也比较复杂。首先,数据要先从旧数据库同步复制到新扩容的 DB,然后部署 DB 的接入 SERVER,最后在凌晨业务低峰时停服扩容。

这个扩容方式的复杂性,根本原因是数据需要从旧 SET 迁到新 SET。如果新产生数据与旧数据没关系,那么就可以省掉这部分的迁移动作,不需停服输。分析发现,需要把旧数据迁出来的原因是订单号段 00-99 已全部被用,每个物理数据库包含了 10 个逻辑库。如果将订单号重新设计,预留三位空间,三位数字每一个代表独立的物理 DB,原来 10 组 DB 分别为 000-009 号段。

这种设计,缩容时,比如要缩掉 000 这组,只需在业务逻辑服务上不生成订单号为 000 的红包订单。扩容时,比如扩为 11 组,只需多生成 010 的订单号,这个数据便自动写入新 DB。当然,缩容需要一个前提条件,也就是冷热分离,缩容后数据变为冷数据,可下线热数据机器。以上就是红包的平行扩缩容方案。

8.jpg
▲ 改进后的平行扩容(点此查看本图出处

七、写在最后


微信红包系统的可用性实践,主要包括了部署设计、SET 化设计、异步化设计、DB 故障自愈能力建设、平行扩容设计。在完成这些设计后,微信红包系统的可用性得到了很大提升,在 近几年的春节实现了 0 故障,在平常的运行中达到 99.99% 可用性。

(原文链接:点此进入

附录1:有关微信、QQ的文章汇总


微信朋友圈千亿访问量背后的技术挑战和实践总结
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(图片压缩篇)
腾讯技术分享:腾讯是如何大幅降低带宽和网络流量的(音视频技术篇)
微信团队分享:微信移动端的全文检索多音字问题解决方案
腾讯技术分享:Android版手机QQ的缓存监控与优化实践
微信团队分享:iOS版微信的高性能通用key-value组件技术实践
微信团队分享:iOS版微信是如何防止特殊字符导致的炸群、APP崩溃的?
腾讯技术分享:Android手Q的线程死锁监控系统技术实践
微信团队原创分享:iOS版微信的内存监控系统技术实践
让互联网更快:新一代QUIC协议在腾讯的技术实践分享
iOS后台唤醒实战:微信收款到账语音提醒技术总结
腾讯技术分享:社交网络图片的带宽压缩技术演进之路
微信团队分享:视频图像的超分辨率技术原理和应用场景
微信团队分享:微信每日亿次实时音视频聊天背后的技术解密
QQ音乐团队分享:Android中的图片压缩技术详解(上篇)
QQ音乐团队分享:Android中的图片压缩技术详解(下篇)
腾讯团队分享:手机QQ中的人脸识别酷炫动画效果实现详解
腾讯团队分享 :一次手Q聊天界面中图片显示bug的追踪过程分享
微信团队分享:微信Android版小视频编码填过的那些坑
微信手机端的本地数据全文检索优化之路
企业微信客户端中组织架构数据的同步更新方案优化实战
微信团队披露:微信界面卡死超级bug“15。。。。”的来龙去脉
QQ 18年:解密8亿月活的QQ后台服务接口隔离技术
月活8.89亿的超级IM微信是如何进行Android端兼容测试的
以手机QQ为例探讨移动端IM中的“轻应用”
一篇文章get微信开源移动端数据库组件WCDB的一切!
微信客户端团队负责人技术访谈:如何着手客户端性能监控和优化
微信后台基于时间序的海量数据冷热分级架构设计实践
微信团队原创分享:Android版微信的臃肿之困与模块化实践之路
微信后台团队:微信后台异步消息队列的优化升级实践分享
微信团队原创分享:微信客户端SQLite数据库损坏修复实践
腾讯原创分享(一):如何大幅提升移动网络下手机QQ的图片传输速度和成功率
腾讯原创分享(二):如何大幅压缩移动网络下APP的流量消耗(下篇)
腾讯原创分享(三):如何大幅压缩移动网络下APP的流量消耗(上篇)
微信Mars:微信内部正在使用的网络层封装库,即将开源
如约而至:微信自用的移动端IM网络层跨平台组件库Mars已正式开源
开源libco库:单机千万连接、支撑微信8亿用户的后台框架基石 [源码下载]
微信新一代通信安全解决方案:基于TLS1.3的MMTLS详解
微信团队原创分享:Android版微信后台保活实战分享(进程保活篇)
微信团队原创分享:Android版微信后台保活实战分享(网络保活篇)
Android版微信从300KB到30MB的技术演进(PPT讲稿) [附件下载]
微信团队原创分享:Android版微信从300KB到30MB的技术演进
微信技术总监谈架构:微信之道——大道至简(演讲全文)
微信技术总监谈架构:微信之道——大道至简(PPT讲稿) [附件下载]
如何解读《微信技术总监谈架构:微信之道——大道至简》
微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]
微信异步化改造实践:8亿月活、单机千万连接背后的后台解决方案
微信朋友圈海量技术之道PPT [附件下载]
微信对网络影响的技术试验及分析(论文全文)
一份微信后台技术架构的总结性笔记
架构之道:3个程序员成就微信朋友圈日均10亿发布量[有视频]
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
快速裂变:见证微信强大后台架构从0到1的演进历程(二)
微信团队原创分享:Android内存泄漏监控和优化技巧总结
全面总结iOS版微信升级iOS9遇到的各种“坑”
微信团队原创资源混淆工具:让你的APK立减1M
微信团队原创Android资源混淆工具:AndResGuard [有源码]
Android版微信安装包“减肥”实战记录
iOS版微信安装包“减肥”实战记录
移动端IM实践:iOS版微信界面卡顿监测方案
微信“红包照片”背后的技术难题
移动端IM实践:iOS版微信小视频功能技术方案实录
移动端IM实践:Android版微信如何大幅提升交互性能(一)
移动端IM实践:Android版微信如何大幅提升交互性能(二)
移动端IM实践:实现Android版微信的智能心跳机制
移动端IM实践:WhatsApp、Line、微信的心跳策略分析
移动端IM实践:谷歌消息推送服务(GCM)研究(来自微信)
移动端IM实践:iOS版微信的多设备字体适配方案探讨
信鸽团队原创:一起走过 iOS10 上消息推送(APNS)的坑
腾讯信鸽技术分享:百亿级实时消息推送的实战经验
IPv6技术详解:基本概念、应用现状、技术实践(上篇)
IPv6技术详解:基本概念、应用现状、技术实践(下篇)
腾讯TEG团队原创:基于MySQL的分布式数据库TDSQL十年锻造经验分享
微信多媒体团队访谈:音视频开发的学习、微信的音视频技术和挑战等
了解iOS消息推送一文就够:史上最全iOS Push技术详解
腾讯技术分享:微信小程序音视频技术背后的故事
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
微信多媒体团队梁俊斌访谈:聊一聊我所了解的音视频技术
腾讯音视频实验室:使用AI黑科技实现超低码率的高清实时视频聊天
腾讯技术分享:微信小程序音视频与WebRTC互通的技术思路和实践
手把手教你读取Android版微信和手Q的聊天记录(仅作技术研究学习)
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)
腾讯技术分享:GIF动图技术详解及手机QQ动态表情压缩技术实践
微信团队分享:Kotlin渐被认可,Android版微信的技术尝鲜之旅
社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等
社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进
社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节
社交软件红包技术解密(四):微信红包系统是如何应对高并发的
QQ设计团队分享:新版 QQ 8.0 语音消息改版背后的功能设计思路
>> 更多同类文章 ……

附录2:更多架构方面的文章汇总


[1] 有关IM架构设计的文章:
浅谈IM系统的架构设计
简述移动端IM开发的那些坑:架构设计、通信协议和客户端
一套海量在线用户的移动端IM架构设计实践分享(含详细图文)
一套原创分布式即时通讯(IM)系统理论架构方案
从零到卓越:京东客服即时通讯系统的技术架构演进历程
蘑菇街即时通讯/IM服务器开发之架构选择
腾讯QQ1.4亿在线用户的技术挑战和架构演进之路PPT
微信后台基于时间序的海量数据冷热分级架构设计实践
微信技术总监谈架构:微信之道——大道至简(演讲全文)
如何解读《微信技术总监谈架构:微信之道——大道至简》
快速裂变:见证微信强大后台架构从0到1的演进历程(一)
17年的实践:腾讯海量产品的技术方法论
移动端IM中大规模群消息的推送如何保证效率、实时性?
现代IM系统中聊天消息的同步和存储方案探讨
IM开发基础知识补课(二):如何设计大量图片文件的服务端存储架构?
IM开发基础知识补课(三):快速理解服务端数据库读写分离原理及实践建议
IM开发基础知识补课(四):正确理解HTTP短连接中的Cookie、Session和Token
WhatsApp技术实践分享:32人工程团队创造的技术神话
微信朋友圈千亿访问量背后的技术挑战和实践总结
王者荣耀2亿用户量的背后:产品定位、技术架构、网络方案等
IM系统的MQ消息中间件选型:Kafka还是RabbitMQ?
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
以微博类应用场景为例,总结海量社交系统的架构设计步骤
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
IM开发基础知识补课(五):通俗易懂,正确理解并用好MQ消息队列
微信技术分享:微信的海量IM聊天消息序列号生成实践(算法原理篇)
微信技术分享:微信的海量IM聊天消息序列号生成实践(容灾方案篇)
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
一套高可用、易伸缩、高并发的IM群聊、单聊架构方案设计实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
社交软件红包技术解密(一):全面解密QQ红包技术方案——架构、技术实现等
社交软件红包技术解密(二):解密微信摇一摇红包从0到1的技术演进
社交软件红包技术解密(三):微信摇一摇红包雨背后的技术细节
社交软件红包技术解密(四):微信红包系统是如何应对高并发的
社交软件红包技术解密(五):微信红包系统是如何实现高可用性的
>> 更多同类文章 ……

[2] 更多其它架构设计相关文章:
腾讯资深架构师干货总结:一文读懂大型分布式系统设计的方方面面
快速理解高性能HTTP服务端的负载均衡技术原理
子弹短信光鲜的背后:网易云信首席架构师分享亿级IM平台的技术实践
知乎技术分享:从单机到2000万QPS并发的Redis高性能缓存实践之路
新手入门:零基础理解大型分布式架构的演进历史、技术原理、最佳实践
阿里技术分享:深度揭秘阿里数据库技术方案的10年变迁史
阿里技术分享:阿里自研金融级数据库OceanBase的艰辛成长之路
达达O2O后台架构演进实践:从0到4000高并发请求背后的努力
优秀后端架构师必会知识:史上最全MySQL大表优化方案总结
小米技术分享:解密小米抢购系统千万高并发架构的演进和实践
一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等
通俗易懂:如何设计能支撑百万并发的数据库架构?
>> 更多同类文章 ……

即时通讯网 - 即时通讯开发者社区! 来源: - 即时通讯开发者社区!

上一篇:社交软件红包技术解密(四):微信红包系统是如何应对高并发的下一篇:社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

本帖已收录至以下技术专辑

推荐方案
打赏楼主 ×
使用微信打赏! 使用支付宝打赏!

返回顶部