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

默认
打赏 发表评论 1
社交软件红包技术解密(六):微信红包系统的存储层架构演进实践

本文为CSDN的《程序员》杂志原创文章,原题为“ 微信红包订单存储架构变迁的最佳实践”。


1、引言


南方企业一直有过年找老板“逗利是”的习俗,每年春节后开工的第一天,腾讯大厦都会排上长长的队伍,集体上楼找老板们领红包。按照广东习俗,已经结婚的同事也要给未婚同事发红包,这一天腾讯员工就在春茗和寻找红包中度过。

由此孵化了一个内部项目,通过微信来收发红包,把这个公司全员娱乐活动与最活跃的IM平台微信结合起来。最初这个项目并没有预期对外,但是入口不小心开放后,成为了现象级产品。2014年开始爆发性增长,每年的发放量都是上一年的若干倍。根据腾讯公布的数据,到2016年春节,已经是每秒十万次支付,每天近十亿订单的系统。

微信红包本质是小额资金在用户帐户流转,有发、抢、拆三大步骤。在这个过程中对事务有高要求,所以订单最终要基于传统的RDBMS,这方面是它的强项,最终订单的存储使用互联网行业最通用的MySQL数据库。支持事务、成熟稳定,我们的团队在MySQL上有长期技术积累。但是传统数据库的扩展性有局限,需要通过架构解决。

补充说明:本文对应的演讲PPT详见《微信红包数据架构演变(PPT) [附件下载]》。

二、分享者


1477730360.jpg
莫晓东:微信支付高级DBA,拥有丰富的数据架构和运维实战经验,擅长大规模MySQL数据库集群的架构、优化和高可用。2010年起在腾讯从事DBA工作,目前专注于微信社交支付的存储层运维和架构优化。

三、系列文章


❶ 系列文章目录:


❷ 其它相关文章:


4、前端流量控制


发十亿红包,难在哪里?

  • 1)大量用户在同一时间发抢红包,瞬间产生每秒数万次的请求,除夕可能成百千万次;
  • 2)这个量级的请求如果不加以疏导处理直接到达后台,必定会导致后端服务过载甚至崩溃。

主要思路是缩短关键业务流程,分离可以通过异步、缓存等方式解决的问题,减轻系统压力,加快响应速度,在存储层前面建上一座大坝。

CGI无状态:

接入层无状态,逻辑层也无状态,可以方便地水平扩展。但依赖MySQL事务保证交易完整,保证红包系统的精简,减少瓶颈的存在。

资源静态化:

利用腾讯强大的基础资源优化部署,尽量把动态内容转为静态资源。静态资源和CGI分离,静态资源通过CDN就近接入,减少用户和CGI的交互,减少内网、访问延时和数据请求。

业务流程异步化:

微信红包的发、抢、拆背后都有多个内部环境,关键流程精简,非关键流程和后续业务逻辑进入异步队列进行处理,减少了用户的等待时间,也极大降低了峰值雪崩的概率。繁多的非关键链路也不会影响到主流程。

过载保护:

  • 前端保护后端,能在前端处理,就不传递到后端:
  • 1)前端需要按后端能力做削峰限流;
  • 2)客户端、接入层、逻辑层逐层控制流量;
  • 3)前端更容易容错处理,全力保护存储层。

微信的过载保护在客户端已提前预埋了策略,在连接失败或超时情况下会有相应提示,减少用户重复请求次数。接入层针对频繁发出请求的客户端限制响应速度,并对系统负载划分出若干等级,达到不同阈值时引导客户端使用不同限速速率;在异常情况出现时,异步限流降速减轻服务器端压力防止过载。

多级读缓存:

发一个群红包,抢红包的请求量远大于发红包,如果已经领过完全可以拒绝。逻辑层增加缓存,类似可以缓存的请求都缓存起来,进一步减少存储层流量。

订单写缓存:

订单系统有很多请求不会真正完成全流量,创建这些废单不但浪费存储资源,还会挤占逻辑层和数据层的处理能力,影响其他交易。订单在完成支付前可以先落在缓存中,完成支付后再持久化。

1.jpg

5、存储层的高可用设计


在数百倍千倍的业务增长下,存储层很难简单无限扩容,一方面设备成倍增加的成本巨大,另一方面存储层瓶颈堆积不一定能解决问题。

读写分离:

写请求需要在主机上,实时读也需要走主机。有大量对延时不那么敏感,又影响性能的查询,完全可以放到从机。读写分离策略是MySQL分布式的入门,简洁地提高了系统容量。

水平切分:

数据的水平切分,实质就是分库分表;选取一张数据表按照主要纬度把数据拆分开。实现存储层的平行扩展。有效降低了单台数据库机器的负载,也减小了服务不可用的可能性。单台数据库宕机只会导致部分数据不能访问。主要需要考虑路由规则的选定,方便扩缩容以及数据的均衡分布。

垂直切分:

数据表除了水平切分,行内数据可以按属性进一步分开。核心表只保留最关键的字段,保证数据文件短小紧凑。以红包为例,昵称和祝福语这类较长的信息,不属于核心数据,完全可以切分到别的机器上,进一步提升核心数据库的容量。不同数据适合的存储类型也不一样,这类重复率高的长字符串更适合NoSQL存储,对存储空间和性能都是节约极大。

空间换时间:

按不同维度组织表,比如按订单属性和用户属性进行组织;适应不同的请求场景,避免复杂的查询。不同维度的表可以通过对账对齐,非核心表可以适当冗余,减少多次请求。

锁的优化:

多人争抢红包通过数据库事物来保证,必然存在竞争MySQL行锁。核心事物必须尽量精简,避免死锁。同一个订单的所有请求,尽量在逻辑层进程预排队后通过一个连接发送请求到数据库。

冷热分离:

核心数据库存放高频数据,其他数据可以定时移到成本低的冷数据库中。这样可以为核心数据库使用最好的SSD设备,快速设备容量较小较贵,不可能在全量数据上使用。同时可以保证数据表的容量不会一直积累,大表也会导致性能下降。

2.jpg

6、异地多活


当系统足够大时,就必须开始考虑异地部署的问题,让数据尽可能离用户更近。而且进一步的高可用不能局限在同一地域,必须跨数据中心跨城多活才能抵御系统性风险。因为跨城的几十毫秒延时,微信红包的异地活动设计为多数据中心相互独立。非灾难灰度不会将其他数据中心的数据导入到线上。

就近接入:

以微信红包系统的异步部署为例,第一个好处是用户就近接入,减少跨城的穿越流量。根据发送者的地域标志数据落地到不同数据中心,在不同地域实现业务闭环。

数据分离:

当前的网络技术限制,使用光纤也无法保证跨城数据的同步延时问题。所以微信红包的跨城数据中心并不进行数据实时同步。不同区域各自承载业务流量,地域上实现平衡,各地的订单数据各自独立存储。

异地容灾:

如果出现地域性故障,我们需要有机制去保证服务可用性。有了异步部署,假如深圳出现系统性故障,那么我们可以直接把请求接入上海。各数据中心独立部署,如果某地系统达到最大容量,可以进行跨地域分流。

7、有损服务和柔性降级


我们遇到最多的问题就是海量请求,通过分布式系统来实现海量请求,根据CAP理论不能同时保证一致性和高可用,必须有取舍。我们首先保证可用性,同时实现最终一致性。有以下原则。

有损服务:

要追求高可用性,可以牺牲部分数据一致性和完整性从而保证核心功能。在资源一定的前提下,满足用户的核心需求。微信红包的核心点是抢、拆红包,系统必须尽最大可能保证核心步骤流畅,但在瓶颈时立即降级防止引起系统雪崩。但是要保证数据能最终对齐,金融属性的系统数据安全硬要求。

柔性可用:

柔性可用是在有损服务价值观支持下的方法,结合具体场景提供不同级别的用户体验,保证尽可能成功返回关键数据。把握用户在每一个场景中的核心需求,设计不同层次满足核心诉求的办法。系统首先要实现容灾和自动切换;其次逻辑资源应该隔离;服务过载时必须自动快速拒绝。

8、结束语


本文简单介绍了微信红包的存储层服务设计准则,在业务从起步到小跑再到腾飞的过程中,背后的海量服务能力将对其最终成败有着越来越深远的影响。在互联网爆发性增长中,海量服务能力决定项目成败,必须在项目初期就做好海量服务的准备。

附录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大表优化方案总结
小米技术分享:解密小米抢购系统千万高并发架构的演进和实践
一篇读懂分布式架构下的负载均衡技术:分类、原理、算法、常见方案等
通俗易懂:如何设计能支撑百万并发的数据库架构?
>> 更多同类文章 ……

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

上一篇:社交软件红包技术解密(五):微信红包系统是如何实现高可用性的下一篇:社交软件红包技术解密(七):支付宝红包的海量高并发技术实践

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

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

返回顶部