微信十几年不崩的秘密：消息收发、存储演进、春节红包的系统架构全拆解

本文由 莫潇羽@无忆研习社（www.wuyi.wiki）撰写，转载请注明出处。

快速摘要

微信的月活跃用户到2026年一季度已经超过14亿（腾讯财报口径），每天产生几百亿条消息，春节高峰一秒钟要处理几十万笔到上百万笔红包。一个系统能在这个量级上常年稳定运行，靠的从来不是堆服务器，而是从第一天开始就埋下的几个关键架构决策：消息采用"收件箱模型"，用存储成本的翻倍换取读取的极致简单；存储从关系型数据库起步，经历分库分表、自研KV、冷热分离三次被动的升级；在CAP理论"一致性"和"可用性"二选一的约束下，微信坚定地选了可用性，所以才有"已发送但对方还没收到"这种看似像bug的体验；而红包这类"真钱"业务，靠异步化拆解加乐观锁，在每秒上百万的峰值下依然一分不多、一分不少。

想看完整拆解，往下翻。

引子：一个你每天都做的动作

打开微信，给朋友发一句"晚上吃什么"，手指一按，屏幕上立刻出现"已发送"。两三秒钟之后，对方那头显示"正在输入"。就这么简单的一件事，你我一天要做几十次。

可你有没有想过，这句话从你的手机出发，到对方手机落地，中间到底经历了什么？

不是一台服务器，也不是十台，而是成百上千台机器，在你按下发送的瞬间同时动起来，接力把这几个字送到对方面前。这么一说你可能觉得玄乎，但这就是真实情况。我自己研究这套体系的时候，最震撼的恰恰是这种反差：你以为很简单的事，背后复杂到让人头皮发麻。

再往大了看。2026年一季度的财报数据里，微信和WeChat合并的月活跃用户已经到14.32亿，创了历史新高。这是什么概念？中国移动互联网的网民规模大约在12亿多，微信一个人就把几乎全国人都装进去了，还要再加上海外用户。每天产生的消息量，保守估计是几百亿条。

微信这套系统也不是一天建成的，它的成长曲线本身就是一部浓缩的互联网史。2011年1月上线，到2012年3月注册用户就破了1个亿，这个速度在当时快得惊人；2013年突破6亿，2018年跨过10亿大关，到2026年一季度，合并月活已经来到14.32亿。你回头想想，一个系统要在十几年里，从几百万用户一路扛到十几亿用户，中间每一次量级的翻倍，对底层架构都是一次生死考验。很多产品就死在了某一次翻倍上，微信却活了下来，还活得相当稳，这背后一定有值得琢磨的东西。

所以问题来了：这么大的体量，为什么微信能常年不崩？明明前几年每逢节假日、每年春节，都有各种App被挤爆的新闻，为什么微信就像没事人一样？

很多人第一反应是：不差钱呗，多买几台服务器不就完了。我一开始也这么想，后来发现根本不是这么回事。服务器能解决"量"的问题，解决不了"设计"的问题。钱买不来架构，买不来那一天天堆出来的决策。选错一个关键决策，今天的微信可能就是另一个样子。

这篇文章，我想把微信这套系统的骨架给你拆一遍。我不会只讲结论，我会把"它为什么这么设计""这里面到底赌了什么""换了你会不敢这么选"都掰开揉碎讲清楚。你会看到，这套系统能长成今天这样，背后其实就是三条线：消息怎么收发，数据往哪存，以及在高并发下敢不敢做取舍。

对了，我是莫潇羽，无忆研习社（www.wuyi.wiki）的站长，平时就爱琢磨这些大厂系统的内部设计。这篇文章是我自己啃资料、画图、一点点验证之后整理出来的学习总结，全程不带任何一家公司的立场，放心看。

一、把"发一条消息"拆开看：一次点击背后的接力

1.1 从你按下发送那一刻起

要理解微信为什么设计成今天这样，得先搞清楚消息到底是怎么走的。

微信的后台结构大致分成三层：接入层、逻辑层、存储层。

• 接入层，负责和你手机上的微信建立连接。你的手机和微信服务器之间有一条长连接，相当于一根一直通着的电话线，服务器可以随时把消息推给你，不用每次现拨号。
• 逻辑层，负责处理业务。比如校验你发的消息有没有问题、黑名单过滤、判断消息该给谁，这些"动脑子"的活都在这一层干。
• 存储层，负责把消息真正存下来，是数据的"仓库"。

用大白话打个比方：接入层是门口的传达室，逻辑层是里面的办事员，存储层是后面的仓库。

你发一条消息，大概走这么几步：

1. 你的手机通过长连接，把"我要给B发一句话"的请求送到接入层；
2. 接入层转手交给逻辑层的发送服务，它先做各种检查；
3. 检查通过，消息写入存储层落盘；
4. 逻辑层通知推送服务：B有了一条新消息；
5. 推送服务找到B手机所在的接入服务器，从长连接把"你有新消息"的提醒推给B；
6. B的微信收到提醒，主动来拉取消息内容。

画成图更直观：

graph LR
    A[手机A] -- 发送请求 --> B(接入层 连接服务)
    B --> C[逻辑层 发送服务]
    C --> D[(存储层 消息库)]
    C --> E[推送服务]
    E -- 新消息提醒 --> F(手机B的长连接)
    F --> D
    D -- 拉取消息 --> G[手机B]

有个细节值得单独拿出来说：微信在线消息的送达速度可以做到100毫秒这个级别，也就是十分之一秒。你发出去，对方几乎同时就收到了提示。这个速度不是靠运气，是长连接加分层设计一点点抠出来的。

这里有个容易忽略的点：为什么不用更省事的短连接，每次发消息现连一下？因为建立连接是有成本的，握一次手就要来回好几趟，发一条消息现连一次，延迟全耗在握手上了。长连接的意义就在于把"建立连接"这件事一次做完、长期复用，把每一笔消息的延迟压到最低。当然，长连接也有代价，每台接入服务器能扛的长连接数量有限，服务器还得靠我们前面说的心跳来管理海量连接的状态。这些细节互相咬合，最后才拼出"秒回"的体验。

1.2 收件箱模型 vs 发件箱模型：微信赌的第一个决策

消息链路是框架，真正决定命运的是里面装的东西怎么组织。这里有一个微信最底层的设计选择，行话叫"收件箱模型"和"发件箱模型"。名字听着绕，用邮局来理解就特别清楚。

发件箱模型是这样的：你寄一封信，这封信先存在你手里。收件人想读的时候，系统要到你这里取一次，再送给对方。你的这封信，全世界只存在一个地方。

收件箱模型是这样的：你寄信的瞬间，系统把信抄了很多份，直接塞进每个人的信箱。收件人不用去找谁要，打开自己的信箱就有。

差别看起来不大？放到500人的群里，区别就天翻地覆了。

你往一个500人群里发一条消息：

• 用发件箱模型，消息只存在你这里一份。可群里500个人都要读，系统就得去你那儿取500次。500次全部指向同一个地方，这个点一旦卡住，500个人全都收不到。像春运时只有一个售票窗口，所有人都堵在一扇门前。
• 用收件箱模型，消息在发出的一瞬间被复制成500份，分别塞进500个人的收件箱。每个人各读各的，互不干扰。你卡了不影响我，我卡了不影响你。

微信选的，就是收件箱模型。

这个选择不是免费的。代价是存储成本暴涨，一条消息变成500份，空间直接烧掉500倍。换来的是读取时的极致简单：读自己的信箱，永远只有一个动作，高并发下不会因为一个热点全崩。

我把它俩做个对比，你一眼就能看懂微信为什么敢这么选：

1.3 换手机不丢消息：收件箱模型的"隐藏福利"

收件箱模型还有一个好处，你平时可能完全没意识到。

你换手机了，登录微信，历史消息从老手机直接导过来，全部回来了。你大概率觉得这是理所当然的吧？我换机的时候也是这么想的，直到我顺着架构往下追才发现：这背后就是收件箱模型在默默工作。

因为每个用户有一个独立的收件箱，系统只需要把你的收件箱同步给新设备，就完事了。它根本不需要去追溯每一个发件人，不需要满世界找"这条消息当初是谁发给我的"。收件箱在，消息就在，一次性搬走。

用工程话说，这叫"以收件箱为中心"的同步设计，天然支持多设备、多端登录。反过来说，如果是发件箱模型，换设备想恢复聊天记录，就得从每一个历史发件人那里重新取，那工程复杂度就不是一个量级了。

这里我再补充一个微信公开技术分享里的细节，帮你看得更实：每个用户的收件箱是一个带序号的列表，每条消息进信箱就按顺序领一个号，客户端只记住自己读到哪个号了，下次同步就拉"比这个号大的"消息。这种方式叫序号增量同步，好处是弱网断了也不怕，客户端只有确实拿到消息才更新自己记的序号，就算服务器的回执丢了，超时后用旧序号重新拉一遍，照样一条不丢。

看到这，你可能已经品出点东西了：微信在消息这块的每一个决策，几乎都在做同一个方向的取舍，用更多的存储、更多的复制，换取读取的简单和稳定。这条主线，从第一天就埋下了。

1.4 群聊和在线状态：收件箱模型的延伸

收件箱模型把单聊安排得明明白白，那群聊呢？群里好几百个人，消息到底怎么分？

微信的做法叫写扩散，其实还是收件箱模型的延伸：你往群里发一条消息，系统把这条消息复制几百份，分别写进每个人的收件箱。等于把单聊的玩法原封不动套到群上，每个人同步群消息时，用的还是"读自己信箱"那套逻辑，跟单聊完全一样，代码都不用写两套。

为什么敢这么干？因为微信群的人数上限是500，复制成本是可控的。几百份消息的存储，在微信那个体量下不值一提，换来的却是同步逻辑的统一和极致的简单。至于那种动辄上万人的大群，业界也有另一种思路叫读扩散：消息只存一份，大家来读的时候各自去取，省存储但增加读取压力。微信之所以大部分场景坚持写扩散，核心还是那句话——宁可在写入时多花点成本，也要让读取保持简单。

还有一个你几乎天天在用、却完全感知不到的机制，叫心跳保活。你的手机和微信服务器之间那根"长连接"，其实不是永远通电的，手机待机、网络切换，连接随时可能断。微信的做法是客户端每隔一段时间发一个"我还活着"的小信号，这个信号就叫心跳包。服务器靠心跳判断你在不在线：心跳正常，说明你在，消息直接推过来；心跳断了，说明你离线了，消息就先进收件箱存着，等你下次上线再拉。

顺带把"已发送""已送达""已读"这三个状态也讲清楚，它们同样是这个模型上的小动作。消息进了你的收件箱，显示已发送；推送到了你手机、客户端收到了，显示已送达；你点开聊天窗口真正看到了，你的客户端回一个"我读到第几号了"，对方那头才亮起已读。每一个状态背后，都是收件箱里那串序号在悄悄说话。

二、数据往哪儿放：存储架构的三次被动进化

消息模型定了，下一个问题扑面而来：这么多数据，往哪儿存？

2.1 起步：人人都从关系型数据库开始

微信2011年上线，用的是MySQL这种传统关系型数据库。绝大多数互联网产品起步都是这个套路，数据有结构、有关系，直接用关系型数据库最省心。微信刚上线那会儿用户量小，MySQL完全够用，没毛病。

但用户量涨起来之后，问题就一点点爆出来了。

关系型数据库有个天生的软肋：不擅长横向扩展。

什么叫横向扩展？说人话就是"加机器"。普通人的直觉是：装不下了，多买几台服务器，把数据分摊开，压力不就小了？可关系型数据库不是这么回事。它的数据之间有关联关系、有事务、有各种约束，比如"张三给李四转账"这种操作，必须保证要么都成功、要么都失败。你把数据拆开放到不同机器上，这些关联怎么办？事务怎么保证？跨机器的联合查询怎么搞？这可不是买几台机器就能解决的，这是极其复杂的工程问题。

再往深里说一层，关系型数据库难扩展，根源在于它承载了太多"承诺"。它保证数据的一致性，靠的是锁和事务，锁住一段数据，别人就得等着；它保证数据有关系，靠的是把表与表之间的关联都建好索引，索引越多，写入越慢；它保证主从一致，靠的是日志同步，主库写入再复制给从库，规模一大，复制延迟就压不住。这些承诺在单机上都是优点，放到"要拆成一百台机器"的场景里，全都变成拖累。不是数据库不行，是它被设计成"一台机器就能搞定一切"，而互联网的流量偏不让你一台机器搞定一切。

微信就是硬生生撞上了这堵墙。

2.2 第一阶段：分库分表，土办法先顶着

撞墙之后的第一反应，是把数据按用户ID切开：不同用户的数据放到不同的库里，每个库只管自己那一份人。这个办法业界有个名字，叫分库分表，思路特别朴素，既然一台机器装不下，那就把数据横着切成很多块，一人扛一块。

这个方法有用，但上限有限。切到一定程度，你还是要面对跨库的查询、跨库的事务、扩容时的数据搬迁，每一个都是坑。分库分表只是把大问题拆成了小问题，并没有消除问题本身。

拿微信自己公开讲过的一个例子来说：群消息的存储、朋友圈的时间线这些数据，拆起来比想象中麻烦得多。你得想清楚按什么维度切，按用户切，那一个人横跨的好几个业务模块是不是也要跟着切？这些都堆在架构师头上，不是一句"多买几台机器"能打发的。

2.3 第二阶段：自研KV，用极简结构换线性扩展

分库分表撑了一阵子，微信开始琢磨更根本的解法。他们的选择是：把消息数据从关系型数据库里搬出来，放进自己研发的KV存储系统。

KV是什么？就是key-value，键值对。你可以把它理解成一个超级大的字典：你给我一个词（key），我立刻给你解释（value）。结构极其简单，没有表结构、没有关联、没有事务约束。

正因为简单，它才能线性扩展，加一倍机器，就能扛一倍压力。微信后来自研了一套KV系统，专门针对消息场景调优，能扛每秒数百万次读写。想扩容？加机器，就这么直接。

KV换来扩展性，代价是把"关系型数据库的便利"全扔了。关联查询没了、事务没了，一切都得自己造轮子。但站在那个时间点，对微信这种"消息量爆炸、读多写少"的业务来说，KV的简单粗暴反而是最合适的。

这里其实藏着一条很重要的判断标准：什么样的数据适合KV？读多写少、单条查询、不需要复杂的跨记录运算。消息恰好是这种数据的典型，一条消息就是一个键值对，读的时候按用户加序号直接定位，天然契合。反过来，如果你的业务要做各种多表联查、统计报表，那KV就是给自己找罪受。很多人一听说KV就盲目跟风，把好端端的关系型数据硬塞进去，查询逻辑写得痛不欲生。选存储这件事，从来都是"数据长什么样决定用什么装"，而不是反过来。

2.4 第三阶段：冷热分离，给成本做减法

KV解决的是扩容问题，成本问题接踵而来。

你想想自己的微信：最近三个月的聊天记录，你经常翻，这叫热数据；三个月之前的，你基本不看了，这叫冷数据。热数据要放在高性能的存储上，贵，但快；冷数据放便宜的存储上就行，反正你也不翻。

这个思路业界叫冷热分离。微信公开的技术分享里给过一组数据：90%的访问集中在3个月以内的数据上，一年前的老数据访问量只占5%左右。也就是说，如果把大量冷数据也放在昂贵的存储上，那大部分成本都烧在了没人看的东西上，纯浪费。

微信后台的存储体系，后来就长成了"内存缓存层 + SSD热数据层 + 机械盘冷数据层"这样的三层结构：

graph TD
    A[内存缓存层<br/>热点数据常驻] --> B[SSD热数据层<br/>近3个月数据]
    B --> C[机械盘冷数据层<br/>历史数据]
    C --> D[成本低 访问少]

热数据放内存和SSD，读得快；冷数据自动下沉到机械盘，成本低。关键细节是：这套冷热切换对上层是透明的，业务方根本感觉不到数据被搬走了，而且无论怎么搬，数据都是多副本的，不会因为硬件坏了丢数据。

冷热分离的收益是实打实的：既保住了体验，又砍掉了相当可观一部分存储预算。

还有一个常常被忽略的好处：冷热分离天然给了数据一条生命周期。热数据待在高性能存储上被高频访问，随着时间推移慢慢变冷，被自动搬去便宜的地方，再老一点的还能被归档甚至压缩。整个过程像给数据建了一条流水线，每一份数据都知道自己该在哪个阶段待着。这种"数据有生命周期"的意识，恰恰是很多中小团队欠缺的，他们的数据从生到死都堆在同一个库里，既不区分温度，也不规划归档，最后只能眼睁睁看着库越来越大、越来越慢。微信存储架构的演进，到今天还在这条路上继续走，从早期的KV，到后来基于时间序数据的冷热分级存储，再到计算和存储分离的新一代架构，主线始终没变过，怎么用更低的成本，装下越来越多的数据。

2.5 三个阶段不是规划出来的

说到这，我得停下来纠正一个非常容易产生的误解。

这三个阶段，分库分表、自研KV、冷热分离，不是微信一开始就画好的宏伟蓝图。真相是：每一次升级，都是被用户增长逼出来的。每一次都是先挨打，再想办法，再挨打，再想办法。

2011年上线用MySQL，是那个时代的最优解；用户多了开始分库分表，是没办法的办法；分库分表不够用了才决心自研KV；KV扛住容量了又发现成本兜不住，于是冷热分离。每一步都没有未卜先知，都是被现实一脚一脚踢着往前走。

我自己研究这些大厂演进史的时候，最大的感触就是：这才是真实的工程世界。不存在一步到位的完美设计，只有在增长中不断被打、不断爬起来迭代。那些看似惊艳的架构，多半是熬出来的，不是设计出来的。这一课，比任何一个技术方案都值钱。

2.6 数据规模大到什么程度，你可能想象不到

冷热分离不是小打小闹。微信后台存储的规模，我拿公开资料里的数字给你感受一下：按时间序的数据达到万亿级的键值对、PB级的数据总量，每天新增十亿级别的键值对，每天要扛万亿次访问。这些数字一摆出来，你就明白"加机器"这种办法早晚会失效，也明白冷热分离不只是省钱，而是能不能活得下去的问题。

支撑这个规模的是微信的自研存储体系，它也是一路进化过来的。早期用基于日志追加的存储模型，索引放内存里；后来把索引也挪到磁盘，单机能装下几十亿个键；再往后按时间序设计了冷热分级架构，把数据分到内存、SSD、机械盘三层，配合多副本，坏了能自动恢复。用工程上的话讲，就是强一致、高可用、可容灾这三件套全配齐了。

容灾这块尤其值得一提。微信的存储分布在多个机房园区，一份数据会以多副本的形式放在不同园区。平时几个园区一起服务，某个园区出了状况，另外几个立刻顶上，对用户来说就是无感切换。这背后是一整套分布式一致性协议在兜底，复杂程度早就不是"多买几台服务器"能概括的了。

有意思的是，微信客户端本地也在做类似的优化，这事很多人没注意过。Windows版微信早期把所有聊天记录都塞在同一个数据库文件里，越攒越多，慢慢暴露出查询慢、文件体积大、文件损坏的问题。后来客户端团队也搞了分库：把公众号消息单独建库，跟私人消息分开；再按时间滚动，一个库放大约半年的消息，满了就开新库。这不就是缩小版的冷热分离吗？后台的方法论，连客户端都在用，可见这套东西是真的管用。

三、当一致性撞上可用性：CAP理论下的艰难选择

讲完存储，我想问你一件事。

你有没有遇到过这种情况：给朋友发微信，手机上已经显示"已发送"了，对方却说"哎，我没收到啊"。你是不是一直以为这是个bug？

不是bug。这是微信故意设计成这样的。

3.1 先读懂CAP理论

要理解这件事，得先讲一个计算机世界里非常重要的理论，叫CAP理论。别一听理论就头大，我用大白话给你讲清楚。

这个理论告诉我们：一个分布式系统有三个特性，你最多只能同时满足其中两个。

• C，一致性。所有节点任何时候看到的数据都一样。你在A机器上改了数据，B机器必须马上也一样。
• A，可用性。系统随时能响应你，不让你等，不给你转圈。
• P，分区容错。就算部分网络断了、部分机器挂了，系统还能继续跑。

听起来三道好菜都想吃，但现实是只能挑两道。而且，在互联网这种环境里，网络出故障、机器宕机是迟早的事，所以P是放弃不了的，这是前提。剩下的选择题就变成：C和A，你要哪个？

有人会追问：为什么不能三个全都要？你想想，要保证强一致，A机器和B机器上的数据必须一模一样，那两台机器之间就必须实时同步，这就依赖网络永远通畅。可网络分区偏偏是常态，跨机房的光纤都可能被挖断。一旦网络断了，你还想让两边数据保持一致，就只能停下来干等，一等，可用性就没了。所以只要你想活得久，P就绕不开，剩下的C和A注定二选一。这不是哪个天才拍脑袋定的规矩，而是物理世界的铁律。

• 选C（强一致性）：发一条消息，系统必须等所有节点都确认收到了，才告诉你发送成功。某个节点响应慢？你就等着。极端情况下，系统宁可一整片不响应你，也不给你一个不确定的答案。
• 选A（可用性优先）：系统保证永远活着，永远响应你。代价是数据在极短时间内可能不一致，发出去的消息，对方要等几秒才收到。

我把这个选择题的账算给你看：

3.2 微信选了A，而且选得毫不犹豫

微信的选择是：选A，优先保证系统永远活着，永远响应你。代价就是数据短暂的不一致，你发消息，本地先显示已发送，消息在后台异步送到对方那里，中间可能差上几秒钟。

这几秒钟你接受得了，对吧？但如果反过来，每次发消息都要等三秒才确认发送，或者高峰期系统直接转圈不响应，你当场就想卸载。

这里有一个特别值得琢磨的点：微信不是做不到强一致性，它是主动选择了那个对用户更友善的"不完美"。在"永远秒回但偶尔晚几秒到"和"绝对精确但偶尔卡死"之间，它用脚投了票。你品一品这个选择，好的架构，很多时候不是选最好的技术，而是选最合适用户的技术。

我还想补充一个细节：微信其实为"不丢消息"做了不少功夫，靠的是前面说的序号机制加增量同步，做到"消息可以晚到，但绝不能丢"。这是它选A的底线：可用性优先，不等于丢三落四。

3.3 这个选择对普通项目的启示

CAP不是只有微信才需要做的题。任何一个想撑住一定并发量的系统，早晚都要面对。

我自己的经验是：很多个人项目、小公司的系统，死就死在"什么都想要"上。既想强一致，又想要高可用，还想要高性能，最后做成一个四不像，哪个都没做好。反而那些想清楚"我最在乎什么"的系统，活得最好。

做技术选型的时候，你可以在心里过一遍这个清单：

• 我这个业务，数据晚几秒钟一致，用户能接受吗？能，就往可用性上靠；
• 我这个业务，钱、库存、订单这种一步错就出事的，就得认真考虑一致性；
• 我最怕的是"用户来了却用不了"，还是"数据算错了"？答案不一样，选的路就不一样。

微信赌的是前者，它赌对了。换你，你赌哪个？这个问题没有标准答案，但想清楚它，比学会任何一门具体技术都重要。

3.4 最终一致性：微信状态里藏着的真相

微信选了可用性，那"数据短暂不一致"到底是怎么被补平的？这背后有一个计算机领域很重要的概念，叫最终一致性。

最终一致性的意思是：系统不保证数据在每一毫秒都完全一样，但保证在"最终"的某个时刻，大家看到的数据是一致的。微信的消息就是这样，你发出去的瞬间，对方可能晚几秒收到，但这条消息绝不会丢，也绝不会出现"对方看到的是另一条消息"的荒诞情况。因为收件箱的序号机制给每条消息安排了一个确定的位置，异步传输只是让它晚到，不会让它变样。

其实这个思路早就渗透进了大量互联网产品。你在网上买东西，下单后订单可能先显示"已提交"，后台异步处理完才变成"已支付"；你改了头像昵称，好友那边可能要过一会儿才看到新名字。这些都是最终一致性的影子。理解了它，你就不会再觉得"已发送但对方没收到"是什么灵异事件，那只是系统正在完成它承诺的"最终一致"的路上。

顺带说一句，最终一致性不是放任数据乱来，它的前提是"最终一定会一致"，这要求系统在幕后做很多补偿动作，比如重试、对账、补单。你以为的"不严谨"，其实是另一种形式的严谨，只是把严谨搬到了后台，换走了你等待的时间。

四、春节红包：一场一年一度的金融级压测

消息、存储、一致性，这三样东西会在每年春节被拉到极限一起检验。因为红包来了。

4.1 红包到底有多猛

2015年微信红包在春节彻底引爆，从那以后每年的除夕，都是一场技术大考。给你几组公开数据感受一下：

• 2015年羊年除夕：除夕全天红包收发总量10.1亿个，零点后的两分钟是最高峰，每分钟有165万个红包被拆开；当晚春晚"摇一摇"互动峰值达到每分钟8.1亿次，整场互动总量110亿次；
• 2016年猴年除夕：收发总量80.8亿个、参与人数4.2亿，最高峰出现在年初一零点后第6分钟，每秒收发40.9万个红包；
• 2017年鸡年除夕：收发142亿个，峰值达