微信红包数据库架构演变
微信红包及其引发思考
自我 实现 尊重需要
社交需要 安全需要
生活需要
前景预测
首先，微信支付在教育用户绑定银行卡后，势必在提高用户活跃度上推出更夗功能； 其次，微信红包只是微信商业化小试牛刀的第一步： 在其他公司还在争抢C端资源时，腾讯已经早早利用公众平台这个子产品，通过为B端提供平台服务，让它 们直接和自己的用户对话，这是B端的心尖尖和心头痛。通过逆向思维，让用户直接找到商家，让商家和用户 零距离沟通。 这步骤看似是在为B端提供服务，其实已经解决了未来最难布点的商家亊宜。目前有90%的知名品牌已经主 劢开通了公众账号，幵丏维护，这也就代表布好了B端的资源。未来，微信只要开启商业化的多门就可以直接 迎客了，因为B端和C端的用户培育期早就在这几年就已布好。
未来移动支付的天下属于“马化腾”而非”马云”。
在互联网诞生乊初，用QQ坐稳PC端 在智能手机収展时，用微信坐稳移劢端
未来=移动互联网
移动互联，用手机掌控生活
目录
微信红包是什么 微信红包何以疯狂 微信红包想干嘛 微信红包现象影响几何 微信红包现象引収的思考
微信红包影响几何？
在24小时内，支付宝 红包的收发总量超过 2.4亿个，总金额达到 40亿元。
微信完胜支付宝
除夕0点-19点期间，微
信红包的收发总量达到 4亿次，摇红包的总参 与人数达到2000万。其
中，全民摇动次数超过 2亿次，最高纪录为每 分钟4000万次，春节七 天总金额60亿。
目录
微信红包是什么 微信红包何以疯狂 微信红包想干嘛 微信红包现象影响几何 微信红包现象引収的思考
微信支付的应用场景： 1. “扫一扫” 2. 表情商庖 3. 游戏支付 4. 手机话费充值 5. 理财通 6. 嘀嘀打车 7. 精选商品 8. Q币充值 9. 电影票 10. AA收款 11. ……
从0到∞｜谈谈红包类产品的设计之道(竞品分析)
从0到∞｜谈谈红包类产品的设计之道（竞品分析）从14年初，微信红包第一版产品上线之后，红包这种集合互动传播、支付、营销等众多功能于一体的产品便以不可思议的速度红遍大江南北，恰如其名。
除了每年一次的“新年红包大战”，在众多社交、电商平台上，红包俨然成为一种新兴的营销工具。
时至今日，从微信红包最初的固定金额与拼手气红包逐渐衍生出各式各样的创意新玩法：裂变红包、AR红包、口令红包、刷一刷红包、图片红包等。
除了用于社交场景中的互动破冰，还被更广泛地应用在各类非社交产品的营销场景中，并逐渐成为一种日常惯用的“工具”。
玩法再多，万变不离其红包的本质。
恰好笔者曾有幸参与过红包类产品的设计，就经验出发，尝试对红包类产品的功能结构、玩法特点进行归纳分析，浅谈红包类产品的设计之道。
本专题主要分为四章，分别从1.“红包的演变历史”2.“C2C、B2C类红包的产品结构”3.“市场上主要红包产品的玩法”4.“笔者对红包玩法的创新设计”对红包产品进行剖析与研究。
本系列文章目录•第一章：红包的演变史：从0到∞•第二章：红包的产品结构：从外到里•第三章：红包的“微创新”：案例浅析•第四章：红包的进击之路：脑洞大开的“创新”•第五章：不是后记的后记第一章：红包的演变史：从0到∞传统意义上的红包是指农历春节期间长辈给晚辈用红纸包裹的钱，象征新年祝福的寓意，尤其可见传统红包的3个核心要素是：通过红纸（视觉氛围）和钱（激励）来表达祝福（寓意）。
网传最早的时候是微信的某位开发同学曾抱怨包红包很麻烦，于是萌生将红包“数字化”的idea。
经过几番打磨，才有了微信红包的第一版：个人间的固定金额红包与群组中的固定金额红包和拼手气红包。
无论是发红包流程抑或拆红包流程，已然十分简洁流畅，且相当贴近现实生活场景中的收发红包过程。
虽然后来微信红包经过几次迭代优化，提高了红包产品的安全性和流畅度，但玩法主流程基本固化不变。
“能发红包的，请别说话”，除去节日问候的场景外，收发红包逐渐成为日常社交活动中一种不可或缺的互动方式，尤其是群组中的拼手气红包，更是将人性中的贪嗔痴暴露得淋漓尽致，君不见隐蔽在黑暗角落的红包接龙赌博活动。
发这么多红包微信IT架构为啥没崩溃？
发这么多红包微信IT架构为啥没崩溃？“地上一毛不捡，微信一分誓抢”这句话是对当前人们抢红包的形容最恰当的一句话了。
在微信群里，即使是那个永不开口的那个人，当看到红包也会“本能”的去抢一下。
2015年除夕当天，微信红包收发总量达10.1亿次，是2014年的200倍，QQ红包收发总量6.37亿个，抢红包人数为1.54亿。
如今，解决高并发的互联网用户访问几乎是所有互联网企业的难题，12306、某商城等等都会在某些时候因为访问过高而引起网站宕机。
那么微信是如何扛得住如此海量的数据洪流？如何保证用户快速抢到红包呢？抢红包环节，后台处理难在哪里？一是快，要保证用户能够快速的摇到红包？二要准，保证摇到的红包能够成功拆开？三要稳——如何保证拆开的红包能分享出去？腾讯数据中心每年节假日的时候，大量用户在同一时间摇红包，瞬间就会产生每秒千万级的请求，这个量级的请求如果不加以疏导处理直接到达后台，必定导致后端服务过载甚至崩溃。
腾讯微信团队为了解决抢红包对后台系统的高要求，做了多方面的技术创新和改进。
本篇文章笔者就跟各位探讨下微信红包的那些事儿。
数据中心成为有力支撑一款互联网产品的成功，尤其是像微信红包这样成功的产品，离不开IT系统架构的支持。
数据中心的建设是至关重要的。
从2007年开始，腾讯在全球各地建立了自己的数据中心，为的就是更好的支撑自己的业务。
而微信红包能够稳定的运行，与腾讯强大的数据中心后方支持有着很大的关系。
腾讯在2006年前后起步，称为第一代数据中心，采用的是传统的电信解决方案，数据中心PUE（能效比）在1.6左右；第二代数据中心则全面转向超大规模数据中心的建设，采用了当时国际上最为先进的自然冷却等节能技术；从2012年开始，腾讯开始自主研发以“微模块”为核心技术的第三代数据中心技术 TMDC。
腾讯数据中心TMDC即腾讯模块化数据中心（Tencent Modular Data Center），是指完全按照模块化设计思路搭建的可快速部署的数据中心模型，数据中心内部由多个完全相同的微模块（Micro Module）组成；微模块则是以若干机架为基本单位，包含制冷模块、供配电模块及网络、布线、监控在内的独立的运行单元，全部组件可在工厂预制，并可灵活拆卸，快速组装。
梁宁产品思维第十六课： 系统迭代：微信红包的意外与刻意(必学)
16 系统迭代：微信红包的意外与刻意微信确实是这个时代最伟大的产品之一，所以咱们用两讲的时间来说一说微信是怎么迭代过来的。
即使是用两课的时间来讲，也只能讲一些非常皮毛的东西。
上一讲，我们说到微信在2.2版本之后就甩开了米聊，从3.6版本之后和陌陌走上了不同的道路。
这一讲我们从微信的4.0版本说起。
迭代中，核心功能最重要微信的1.0版本，就是一个在熟人之间可以免费发文本信息和图片的工具。
微信的2.0版本，增加了微信的语音功能和“查找附近陌生人”的功能。
到这里，微信成为了陌生人语音社交的工具，但还是个工具。
微信3.0版本的时候推出了“扫一扫”、“服务号”，从这个点开始，微信开始连接世界。
4.0版本的时候，微信推出了“朋友圈”，也就是说微信从通讯工具开始进化，变成了社交平台。
微信在推出“朋友圈”功能之前，做了两个前置工作：3.5版本加了扫描二维码；3.6版本加入了微信的公众号。
这两个动作的价值在于，一个普通人的生活没有那么多可供朋友消费的内容，如果没有这两个前置功能，我们就直接打开朋友圈，会非常难看。
4.0版本时，你在朋友圈发照片，如果朋友评论，你是没有办法回复评论的。
回复评论的功能，直到4.2版本才做出来。
这说明什么呢？没有必要憋大招，没有必要把所有功能全都做好再放出来。
不能回复朋友在朋友圈下的评论又怎么样呢？如果我非常想回复他，大可以点对点跟他说。
所以产品的核心功能点有效比什么都重要，基于核心功能附加的其他功能点没有那么重要，可以一步步来。
接着就是微信的4.5版本，推出的就是今天的内容公众号，推动了一批媒体人创业，孕育了一大波网红。
微信红包的发布微信的5.0版本，对微信来说有一个巨大跃升，就是加上了“绑定银行卡”。
要知道在5.0版本之前，微信是不沾钱的。
如果微信不加“绑定银行卡”的这个动作，没有把微信和钱连在一起，微信就是一个移动版的QQ空间，大家可以在这里晒照片、聊天、彼此点赞。
但是微信绝不会成为今天的移动生活场景，甚至是移动商业帝国。
微信数据库分析与设计说明
微信数据库分析与设计一、需求分析微信作为当前的主要即时通讯工具之一，有着广泛的应用。
其主要的功能是实现即时通信，这也是微信的核心功能。
此外还有查看朋友圈动态、搜索好友、管理个人信息、建立用户自己的相册、收藏功能、摇一摇、搜索附近的人、购物、游戏等功能。
此次对于微信平台的数据库设计主要对部分需要微信平台提供存储信息功能进行需求分析及设计。
以下将对微信平台的主要需求做简要的分析并且根据分析做出数据流图使得对于微信平台数据库的设计有更好的理解。
微信的通信主要包括与微信好友进行相互通信，这其信容包括文字、语音、图片及视频。
当用户订阅了公众号之后，会接收公众号发送的消息并且也可向公众号发信息或许其提供的信息。
微信通信功能的另一个主要方面是实现群聊。
用户可以加入一个微信群进行群。
另一方面用户也可以选择自己的联系人进行群聊。
微信讯录实现了保存用户联系人的目的，并且订阅的公众号也保存于通讯录中，并且在通讯录中可以设定标签来为联系人分组。
微信朋友圈保存好友发送的与朋友共享的消息，其容可为文字、图片、视频。
在朋友圈中可以设定权限使得不同权限的用户查看的容不一样。
摇一摇功能可以获取同一时刻一起摇动手机的用户，并且暂存于微信中。
附近的人功能可以识别在一定围的微信用户，并且将获得的用户信息也暂存在微信中，对于识别附近的用户可以设定具体的条件来扫描。
漂流瓶功能相当于随机的获取微信消息或者向微信用户随机的发送消息。
对于个人信息的编辑，用户可以根据自身需要编辑一些所需的个人信息。
最后在微信用户个人信息中有相册和收藏记录用户的照片和收藏的文字语音等信息。
以上是对微信的部分功能的需求分析，现根据以上需求对微信数据库画出数据流图：第0层DFD：第1层DFD：二、概念设计在第一步的需求分析中，我们了解了微信数据库平台设计中所需要的实体及需要存储的信息。
在概念设计中将进一步明确数据库设计所需实体，实体所具有的属性及实体之间的关系。
通过分析微信数据库平台所需实体主要有：用户信息、普通消息记录、公众号信息、公众号消息记录、微信群信息、群聊消息记录、收藏信息、相册、朋友圈信息、联系人信息、附近人信息、漂流瓶信息、扫一扫信息、摇一摇信息。
微信红包精品PPT课件
01 微信红包是什么 02 03
01
微信红包是什么
02
03
微信红包是什么
腾讯产品
1
3
娱乐方式
移动支付
2
4
社会现象
微信红包是什么
趣味性强
互动性强
特点
操作简单 时代潮流
01
微信红包是什么
02
03
移动支付大战
移动支付大战
移动支付带来了什么？
PC互联网时代 线上支付 改变传统商业形态
Thanks for listening, this course is expected to bring you value and help
为方便学习与使用课件内容，课件可以在下载后自由编辑， 请根据实际情况调整
据了解，抢红包的高峰时段出现在除夕夜零点时分，前5分钟内
娱乐性
性质单一
有58.5万人次参与抢红包，其中12.1万个红包被领取。群红包发放最
常见金额是100元，抢到10元到502 03
微信红包何去何从
发展瓶颈
安全问题
……
微信红包何去何从
学习并没有结束，希望继续努力
移动互联时代 移动支付 改变人们生活方式
移动支付将会改变什么？
移动支付大战
根据腾讯微提信供的红最包新数据，从除夕开始，支截付至大宝年初一16时，
参与抢微信红包的用户超过500万，总计抢红包7500万次以上。领
“项庄舞剑，意在沛公。” 取到的红包总计高超频过应2用000万个，平均每分钟领相取对的低红频包达到9412个。
ES+Redis+MySQL，这个高可用架构设计太顶了
ES+Redis+MySQL，这个⾼可⽤架构设计太顶了⼀、背景会员系统是⼀种基础系统，跟公司所有业务线的下单主流程密切相关。
如果会员系统出故障，会导致⽤户⽆法下单，影响范围是全公司所有业务线。
所以，会员系统必须保证⾼性能、⾼可⽤，提供稳定、⾼效的基础服务。
随着同程和艺龙两家公司的合并，越来越多的系统需要打通同程APP、艺龙APP、同程微信⼩程序、艺龙微信⼩程序等多平台会员体系。
例如微信⼩程序的交叉营销，⽤户买了⼀张⽕车票，此时想给他发酒店红包，这就需要查询该⽤户的统⼀会员关系。
因为⽕车票⽤的是同程会员体系，酒店⽤的是艺龙会员体系，只有查到对应的艺龙会员卡号后，才能将红包挂载到该会员账号。
除了上述讲的交叉营销，还有许多场景需要查询统⼀会员关系，例如订单中⼼、会员等级、⾥程、红包、常旅、实名，以及各类营销活动等等。
所以，会员系统的请求量越来越⼤，并发量越来越⾼，今年五⼀⼩长假的秒并发tps甚⾄超过2万多。
在如此⼤流量的冲击下，会员系统是如何做到⾼性能和⾼可⽤的呢？这就是本⽂着重要讲述的内容。
⼆、ES⾼可⽤⽅案1. ES双中⼼主备集群架构同程和艺龙两家公司融合后，全平台所有体系的会员总量是⼗多亿。
在这么⼤的数据体量下，业务线的查询维度也⽐较复杂。
有的业务线基于⼿机号，有的基于微信unionid，也有的基于艺龙卡号等查询会员信息。
这么⼤的数据量，⼜有这么多的查询维度，基于此，我们选择ES ⽤来存储统⼀会员关系。
ES集群在整个会员系统架构中⾮常重要，那么如何保证ES的⾼可⽤呢？⾸先我们知道，ES集群本⾝就是保证⾼可⽤的，如下图所⽰：当ES集群有⼀个节点宕机了，会将其他节点对应的Replica Shard升级为Primary Shard，继续提供服务。
但即使是这样，还远远不够。
例如ES集群都部署在机房A，现在机房A突然断电了，怎么办？例如服务器硬件故障，ES集群⼤部分机器宕机了，怎么办？或者突然有个⾮常热门的抢购秒杀活动，带来了⼀波⾮常⼤的流量，直接把ES集群打死了，怎么办？⾯对这些情况，让运维兄弟冲到机房去解决？这个⾮常不现实，因为会员系统直接影响全公司所有业务线的下单主流程，故障恢复的时间必须⾮常短，如果需要运维兄弟⼈⼯介⼊，那这个时间就太长了，是绝对不能容忍的。
2024年红包市场分析现状
红包市场分析现状引言红包市场作为互联网发展的一个重要衍生品，在中国依然有着非常广泛的应用。
随着手机支付、社交媒体的普及，红包已经成为人们在节日、聚会、庆典等场合的主要礼金形式之一。
本文将对红包市场的现状进行分析，以便更好地了解红包市场的发展趋势。
1. 红包市场规模红包市场规模是衡量红包市场发展水平的重要指标之一。
根据市场研究数据，近年来红包市场规模呈现出持续增长的趋势。
据统计，2019年中国红包市场的总规模达到了1500亿元人民币，同比增长20%。
这一数据显示出红包市场的巨大潜力和广阔前景。
2. 红包使用场景红包的使用场景也是红包市场发展的重要方面。
红包最初在传统节日和亲朋好友间的互赠中应用较多，但随着互联网和移动支付的发展，红包的使用场景正在不断扩大。
目前，红包已经成为许多社交媒体平台以及电商平台的重要功能之一，人们可以通过发送红包来祝福亲友、表达感谢、推广产品等。
此外，一些线下实体店铺也开始通过线上红包的形式吸引顾客，促进消费。
3. 红包形式与创新红包形式的不断创新也是红包市场发展的一个重要动力。
传统的现金红包形式仍然占据主导地位，但也出现了许多新型红包形式，例如电子红包、代金券、实物礼品等。
此外，一些创新型的红包玩法也逐渐受到市场的欢迎，如口令红包、拼手气红包等。
这些红包形式的不断更新和创新，不仅满足了用户多样化的需求，也为红包市场的发展带来了新的活力。
4. 红包市场竞争格局红包市场的竞争格局主要体现在两个方面：一是红包服务提供商的竞争，二是红包平台的竞争。
在红包服务提供商方面，包括了支付宝、微信支付、京东支付等大型支付平台，它们之间的竞争主要体现在支付渠道的便利性、红包使用的便捷性等方面。
而在红包平台方面，如微信、支付宝、淘宝等社交媒体和电商平台，则通过不断推出新的红包玩法、提供更好的用户体验等方面展开竞争。
5. 红包市场发展趋势红包市场在当前的发展趋势中，有以下几个主要特点：•移动支付的普及将进一步推动红包市场的发展，使得红包的使用更加便捷；•社交媒体平台和电商平台红包功能的不断创新，将丰富红包玩法，提高用户的参与度；•线下实体店铺与线上红包的结合，将进一步促进红包的使用场景扩大化；•个性化红包市场的崛起，满足用户多样化的需求。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
微信红包数据架构演变
嘉宾：莫晓东
•红包印象
•2015春晚红包
•2015新的挑战
•2016再战春晚
红包映像 微信红包是什么？
包红包(支付)
发
抢拆
2014年短短几天内快速上线的内部项目，满足业务基本需求，每秒几
百发送，每秒上千拆的请求。
微信红包是什么
微信红包资金流
• A 用户发红包，C, D, E 用户抢红包
•支付(发红包)•退款（过期 24小时)
•转账(拆红包)
or
•资金原路返回
必须做到资金安全，所以需要事
务。
2015年春晚红包400倍的挑战
海量之道
全民摇红包，不能失败
存储层方案和设备选型
•项目挑战：
•预估量级是日常的100倍。
•无法借鉴、摸着石头过河。
•精确压测性能，为容量评估和限流提供依据。
•从配置、部署、容灾三方面深入优化，为业务保驾护航。
•是否继续使用MySQL？
•需要多少机器，怎样部署。
•使用什么机器类型。
•可能出现什么问题，怎么解决。
继续使用MySQL
• MySQL支持事物，满足一致性要求。
• 结构化存储，紧凑、连续。
• 支持多索引。
• 部署简单，工具支持。
• 团队技术积累。
• 设备改进。
硬盘从sas升级FusionIO SSD。
系统从SUSE linux 10升级tlinux 1.2。
• 测试先行，实践是检验真理的第一标准。
模拟测试：
吞吐量：2.6w/s
主事物：2k+/s
同步速度：6k/s
性能优化
•业务最终一致性，cap、base。
•允许丢失和对账、异步达成。
•多层Cache。
•定制列表服务，下单前验证预订单。
•接入层数据cache，标记红包抢状态。
•数据优化。
•Sharding，水平拆分。
•数据冗余，维度拆分。
•数据预生成，摇一摇红包预先导入。
•字段冗余，减少访问次数。
•默认字符集从utf8改latin1。
•部署优化。
•多实例，交错部署。
•MySQL参数优化。
•系统层参数优化。
有损服务、柔性可用、大系统小做
•什么是有损服务？有损服务是通过精心拆分产品流程，选择性牺牲一部分数据一致性和完整性从而保证核心功能绝大多数运行。
核心功能是摇，拆，发。
其它模块异常立即降级防止引起雪崩。
•过载保护，层层过滤、快速拒绝，把千万级别的请求减少到万级，减少DB负载。
•异步处理，耗时最长的入账操作，直接跳过，异步处理。
•柔性策略，关闭不重要的功能模块，比如查看收发历史、关闭祝福语。
•资源隔离，拆分红包DB为50个Set，出现故障只影响1/50。
•大系统小做，功能单一。
逻辑层需要减少模块耦合，存储层也需要多源。
•故障处理，如果DB故障直接替换空白机器，未领取的红包锁定退款。
故障预案，可控；未算胜先算拜，极端情况。
2015年春节成果
•除夕抢红包峰值增长500倍(含春晚企业红包)
•拆红包峰值增长400倍
•单日红包发送超过亿
2015年新的问题业务从3月开始快速上涨
红包订单量月增速约达2倍并持续
保持
•红包使用量急剧增长。
•拆事务性能瓶颈，高峰抖动。
•主从同步压力，对账不及时。
•存储容量压力，设备已缩容。
•需要进行业务重构。
•运维和开发处于高负荷状态。
•先应付眼前。
月增速为1.8倍并保持
运维和开发处于高负荷状态业务抖动多次扩容
需要进行业务重构
红包野蛮生长
•存储容量不足。
•使用InnoDB压缩格式，为冷热分离争取时间 。
•压缩率订单库44%，用户库57%。
•可接受的性能下降10-15%。
•性能问题。
•梳理主机SQL，索引优化、语句优化、请求精简。
•高峰期抖动，优化请求时间分布。
•新特性如线程池，4k page。
•主从同步延时。
•优化从机SQL。
•升级 Percona 5.5，多库同步。
第一阶段，争取时间
第二阶段，冷热分离
•分离依据 。
•分析数据访问情况占比， 实测订单3天内，访问占比98.9%。
•优化目标。
•提高性能，减少现网库表数据量。
•节省成本，历史数据使用低成本大容量设备。
•历史库方案。
•按日分表，proxy路由请求。
低峰时段搬迁数据，现网只保留7天。
•改善性能，从raid10+tokudb迁移到NoRaid+myisam，解决迁移问题和优化查询性能。
暂时解决问题，脱离容量问题，性能稳定性增加。
第三阶段，必须重构
•表空间回收困难，现网库删除慢，历史库存储过大。
•字段过冗余，如果按每月约翻倍的速度增长，到年底是很惊人的。
•假设到年底还有6个月，如果2^6=64倍，那到2月份过年2^8=256倍。
•目前大约占了20T历史数据，如果几十几百倍，机器数量，业务成本无法承受。
•性能同样需要优化，拆红包单组DB拆峰值仅仅2000+，预计春节10w峰值，也无法完成任务。
•红包系统的性能瓶颈在拆事务上。
精简和拆分-容量比想象中更宝贵，按字节计算需求•库表重新设计，字段缩减，去冗余。
•冗余字段精简。
•单号精简。
•字段类型精简。
•按天分表，循环使用。
•确保数据单表数据不会无限增长。
•用truncate代替delete清理。
•垂直分表力度更细。
•小表性能更佳。
•主键从单号修改为自增字段。
•自增主键减少体积，加速插入速度。
•不同的内容，不同的存储。
•有些内容使用kv更适合。
•用户维度迁入列表服务。
•扩散读和更依赖cache。
•个人红包和企业红包分离。
•企业红包特有字段去除。
性能优化-异步和cache
•事物优化。
–事物语句精简和优化。
–入账分布式事务。
–提高并发度，请求排队
机制。
•异步化。
–异步入账。
–异步用户信息。
–异步补拆，异步入账。
•语句优化。
•不查不需要的字段。
•非核心查询移到从机。
•大操作合并查询。
•先查cache。
•通过cache判断能不能抢。
•缓存常查询的内容。