本文作者腾讯WXG后台开发工程师jeryyzhang，收录时有改动，感谢原作者的分享。
1、引言
大约3年前，微信技术团队分享了《微信后台基于时间序的海量数据冷热分级架构设计实践》一文，文中总结了微信这种超级IM基于时间序的海量数据存储架构的设计实践，也得以让大家了解了微信后台的架构设计思路。
时隔3年，微信再次分享了基于时间序的新一代海量数据存储架构的设计实践（可以认为是《微信后台基于时间序的海量数据冷热分级架构设计实践》一文中所述架构的升级版），希望能带给你启发。
本文将同步发布于“即时通讯技术圈”公众号，欢迎关注：
推荐阅读：阿里团队也分享过IM基于时序的数据同步和存储方案，有兴趣可以一并阅读：《现代IM系统中聊天消息的同步和存储方案探讨》。
本文中提到的KV存储技术，微信团队在多篇技术文章中都有提及，以下是这些文章：
《微信海量用户背后的后台系统存储架构(视频+PPT) [附件下载]》
《快速裂变：见证微信强大后台架构从0到1的演进历程（一）》
《快速裂变：见证微信强大后台架构从0到1的演进历程（二）》
《架构之道：3个程序员成就微信朋友圈日均10亿发布量[有视频]》
学习交流：
- 即时通讯/推送技术开发交流5群：215477170[推荐]
- 移动端IM开发入门文章：《新手入门一篇就够：从零开发移动端IM》
（本文同步发布于：http://www.52im.net/thread-2970-1-1.html）
2、微信基于时序的数据业务场景
作为以手机为主要平台的移动社交应用，微信内大部分业务生成的数据是有共性可言的：数据键值带有时间戳信息，并且单用户数据随着时间在不断的生成，我们将这类数据称为基于时间序的数据。例如朋友圈的发表，支付账单流水，公众号文章阅读记录等。
这类基于时间序的数据通常不会删除，而是会随着时间流逝不断积累，相应需要的存储空间也与日俱增：key 量在万亿级别、数据量达到 PB 级别、每天新增 key 十亿级别。同时在十亿用户的加持下，每天的访问量也高达万亿级别。
3、微信的数据访问模式
经过数据分析，我们发现基于时间序的存储一般有如下三个特点。
特点1——读多写少：
这类基于时间序的存储，如果需要访问一段时间内的数据就需要对对应时间段内的所有键值对都进行一次访问。与全部写入到一个键值对的场景相比可以视为读扩散的场景。部分业务场景下的读写比甚至高达 100:1。
特点2——冷热分明：
这类基于时间序的存储，数据的时效性往往也决定了访问频率。比如对用户进行公众号文章的推荐，用户近期的阅读记录会更加具有参考意义。这就导致数据的访问不是均匀的，而会更集中在最近一段时间所产生的数据。以某业务场景为例，70%以上的访问来自最近一天内的新增数据，90%来自 3 个月内的新增数据。一年外的数据访问占比只有 5%。
特点3：数据安全性要求高：
这类数据通常是由用户主动产生，一旦丢失，非常容易被用户感知，导致投诉。
下图是数据的读取分布情况统计：
（▲ 本图在上篇《微信后台基于时间序的海量数据冷热分级架构设计实践》也有类似统计）
4、本次升级之前的架构及其面临的挑战
在本次升级之前，我们使用一致性缓存层+SSD 热数据层+机械盘冷数据层的分层架构方案来解决此类基于时间序的存储。更多的技术细节可以参考上篇《微信后台基于时间序的海量数据冷热分级架构设计实践》。
对于冷数据集群，我们使用微信自研的 WFS（Wechat File System 微信分布式文件系统）对其进行了一次升级，极大的简化了运维成本。不过这部分不是本文重点，在此不再详述。
旧架构在过去几年微信后台的发展过程中始终表现平稳，但是也依然面临着一些挑战。
首先是扩展能力方面的挑战：旧架构中，考虑到读多写少的访问模型，为了加快宕机后的数据 catchup 速度，我们使用了细粒度的 paxos group，即每个 key 有一个独立的 paxos group。这样在进程重启等宕机场景下，只有少量写入的 key 需要进行 catchup。理想很丰满，现实很骨感。在 PaxosStore 架构中，数据的扩缩容是以 paxos group 为粒度的。也就是说，对于使用细粒度 paxos group 的存储，进行扩缩容是逐 key 的，耗时可以看成与 key 量成正比；单机百亿级别的 key 量放大了这一问题，即使我们采取一系列的工程优化缩短耗时，整体的迁移周期依然比较长，需要几周时间。
另外一个方面则是来自容灾能力的挑战：PaxosStore 使用 KV64+三园区的部署方式（PaxosStore在上篇《微信后台基于时间序的海量数据冷热分级架构设计实践》中，被认为是该架构中的技术关键点）。同一个 key 的三个副本分属三个园区，同一个园区的两台机器服务分片没有重叠，因此可以容忍园区级别的故障。然而对于同组两台不同园区机器故障的情况，则有占比 1/6 的数据只剩余单个副本，无法提供读写服务。
可能有同学会认为，同组两台不同园区机器故障，概率无异于中彩票。然而根据墨菲定律：“凡是可能出错的事情，最终一定会出错”。在过去几年也曾出现过同 Set 两台不同园区机器先后发生故障的情况。
我们都知道，分布式系统的一个核心观点就是基于海量的，不可靠的硬件，构造可靠的系统。那么硬件究竟有多不可靠呢？
Jeff Dean 在 2009 年的一次 Talk 中曾经提到过：
Jeff Dean是谁？
Jeff Dean是谷歌Level 11（Google Senior Fellow）级别的超级工程师。Jeff Dean被认为是谷歌技术的代名词，谷歌之所以如此强大，Jeff Dean是其中的很重要的原因之一。可以看看知乎上的这个讨论：zhihu.com/question/22081653
PaxosStore 使用 no raid 的磁盘阵列，磁盘故障导致单盘数据丢失时有发生。在机器故障检修以及数据恢复的过程中，有大量数据（占单组 50%，逐渐收敛为 0）是以 2 副本形式存在，这就进一步削弱了系统的容灾能力。
总结一下，我们面临如下几个挑战：
1）单机百亿级别 key 量，10TB 级别数据，如何快速扩容？
2）如何低成本的提升系统的容灾能力，使之容忍任意双机故障？
3）磁盘故障，数据清空后如何快速恢复。
4）作为一款十亿月活的国民 APP，对其进行改造无异于给一架正在飞行的飞机更换发动机，改造过程稍有不慎都可能招致用户投诉，甚至上个热搜。
接下来我会针对这几个难点逐一展开，介绍我们的解决思路与方案。
5、本次架构升级过程的技术的详细实践总结
5.1 计算和存储分离的思路
对于细粒度的的 paxos group，迁移过程中，扫 key、迁移、校验等步骤都是逐 key 粒度的。这会产生大量的磁盘 IO 与 CPU 消耗，导致迁移速度上不去，需要几周才可以完成迁移。
那么我们能否可以采取粗粒度 paxos group 以加快迁移呢？答案是肯定的。
对比细粒度的 paxos group，单个粗粒度的 paxos group 可以同时保证多个 key 的内容强一致。因此迁移校验等过程中，可以减少大量的 paxos 交互。
然而粗粒度 paxos group 的存储，与细粒度 paxos group 的存储相比，在迁移过程中对目标集群的写入不会减少，总体依然涉及了大量数据的腾挪。而由于 LSMTree 存储引擎存在的写放大问题，数据大量写入目标机这一过程会成为瓶颈。
总体来看，扩容时间可以缩短为原来的 1/2 甚至 1/3，达到天级别的水平。
看起来相比细粒度 paxos group 的迁移已经有很大改进，我们能否更进一步？
首先我们分析一下在什么场景下需要扩容，一般来说是以下两个场景：
1）由于数据增加，磁盘容量达到瓶颈；
2）由于请求增加，CPU 处理能力达到瓶颈。
对于情况 1：如果我们使用分布式文件系统替代本地文件系统，当容量达到瓶颈时只需要增加分布式文件系统的机器就可以实现容量的快速扩容，对上层应用而言相当于获得了一块容量可以无限增长的磁盘。
对于情况 2：采用计算存储分离结构后。计算节点无状态，不涉及数据腾挪，自然可以实现快速扩容；如果是存储层节点 CPU 瓶颈，也可以通过文件块级别的腾挪来实现快速扩容以及热点打散。
应用计算存储分离的思路，我们基于 WFS（微信分布式文件系统）以及微信 Chubby（分布式锁），实现了一套计算存储分离的存储架构，代号 Infinity，寓意无限的扩展能力。
5.2 “任何计算机问题都可以通过增加一个中间层来解决”
计算机科学经典名语：“All problems in computer science can be solved by another level of indirection”。
在 Infinity 中，我们引入了一个被称为 Container 的中间层。Container 可以近似理解为一个数据分片。每台机器可以装载一个或多个 Container，我们称之为 ContainerServer。ContainerServer 会处理其上 Container 对应数据的读写请求，Master 负责 Container 在 ContainerServer 间的调度，Chubby 则提供了分布式锁服务以及 Container 位置信息在内的元信息存储。
当 master 发现有新加入的机器时，会主动触发负载均衡，将其他 ContainerServer 上的 Container 调度到新机。整个调度过程中，不涉及数据的腾挪。在我们实际的测试中，Container 腾挪的平均耗时在百毫秒级别。
如上图所示，这是一个多园区部署的 Infinity 示意图。每个园区内都有独立的 WFS 与 Chubby 存储，每个园区都对应全量的数据。对于同一个数据分片，分别位于 3 个园区的 3 个 container 组成一个 paxos group。
对于这样一个方案，我们是可以对每个园区实现弹性伸缩的，系统整体的可用率由最上层的 paxos 提供保证。
我们来计算下这一方案的存储成本：园区内 3 副本的 WFS 存储 X 园区间的 3 副本 Replica，整体就是 9 副本。对于 PB 体量的存储，这一方案所增加的存储成本是我们难以承担的。既然多 zone 部署的 Infinity 存在成本问题。我们自然想到，能否使用单 zone 部署的 Infinity 来负责存储。
首先分析成本：单 zone 部署 Infinity 的存储成本为 3 副本 WFS，与现有架构的成本一致。其次分析扩展能力，单 zone 部署的 Infinity 一样具有出色的扩展能力，优于现有架构。对于 Chubby 这一中心点依赖，我们可以实行 Set 化改造来尽量消除风险。
分 Set 改造后，我们不由得又想起那些年旧架构经常遇到的一种情况：单组请求突增。
此处有必要简单介绍一下 PaxosStore 的路由方案，组间一致性 Hash，单组内是 KV64 结构。一致性 Hash 消除访问热点，一切看起来很美好。然而假设由于某些原因，大量请求集中访问某组 KV 时，如何应急？
此时我们既无法快速增加该组内的机器处理请求（KV64 限制），也无法快速分散请求到其他组（如果这组 KV 需要 3 倍容量，那就要把整个服务整体扩容 3 倍才可以）。
这就引发了一个尴尬的局面：
1）一组 KV 水深火热，其他组 KV 爱莫能助；
2）只能反复调整前端请求的访问比例，直到业务低峰期。
那么在 Infinity 中，我们如何解决这一问题呢？
首先：我们的 Set 化本质上是对 Container 进行分组，其中 Container 到组的映射关系是存储于 Chubby 中的。如果我们想分散一组请求到其他组，只需要依次修改每一组 Chubby 中存储的映射关系即可。在实际实现中还有一些工程细节需要考虑，比如对于要移入其他组的 Container，必须在原组进行 Unload 并停止调度等。这里就不一一展开了。
我们在线上也进行了一次大规模腾挪 Container 到其他组的实验：结果显示，单个 container 腾挪到其他组，平均耗时不足 1 秒。
5.3 单 zone Infinity 架构的一些问题
单 zone Infinity 架构解决了多 zone Infinity 成本问题的同时，也必然做出了取舍。
对于某个 container，任一时刻必须只在最多一个 containersvr 上服务。否则就有导致数据错乱的风险。类比多线程中的 data race。我们通过引入分布式锁服务来避免 double assign。同时为了减少分布式锁开销，我们将锁的粒度由 Container 级别收敛到 ContainerSvr 级别。每台 ContainerSvr 开始提供服务后会定期前往 chubby 续租。如果一台 ContainerSvr 崩溃，master 也需要等到锁租约过期后才可以认为这台 ContainerSvr 挂掉，并将其上的 container 分配出去。
这就会导致存在一部分 container 在租约切换期间（秒级别）不能服务。
我们引入两个可靠性工程的常见指标来进行说明：
1）MTTR：全称是 Mean Time To Repair，即平均修复时间。是指可修复系统的平均修复时间，就是从出现故障到修复中间的这段时间。MTTR 越短表示易恢复性越好；
2）MTBF：全称是 Mean Time Between Failure，是指可修复系统中相邻两次故障间的平均间隔。MTBF 越高说明越不容易出现故障。
可以说，单 zone Infinity 架构缩短了 MTTR，但是也缩短了 MTBF，导致整体的可用性依然不高。
5.4 不可能三角？
在很多领域中，都有类似“不可能三角”的理论。比如分布式理论中经典的 CAP 定理，经济学理论中的蒙代尔不可能三角等。
在我们上面的讨论中，其实也蕴含了这样的一个“不可能三角”：
1）成本
2）扩展性
3）可用性。
具你本来说：
1）PaxosStore 兼顾了成本与可用性，但扩展能力稍逊；
2）多 zone Infinity 可用性与扩展性都为上乘，但成本是个问题；
3）单 zone Infinity 牺牲了一点可用性，换来了成本和扩展性的优势。
三者不可得兼，我们该如何取舍？
1）首先是成本：是我们必须考虑的因素，这关系到我们架构实际落地还是成为巴贝奇的分析机；
2）其次是可用性：这关系到用户的使用体验。
在我们的新架构中，可用性不仅不能下降，甚至还应该有所提升。比如：容忍任意双机故障。结合上面的讨论，一个核心的目标逐渐浮出水面：低成本双机容灾改造。
5.5 低成本双机容灾改造
我们首先来分析一下如何实现双机容灾改造。
一个简单的思路是：提升我们的副本数，由 3 副本提升为 5 副本。
5 副本自然可以容忍小于多数派（<=2）的机器故障，实现双机容灾。然而考虑到成本问题，3 副本改造为 5 副本，成本增加 66%，这是我们无法接受的。
此时我们想到了函数式编程中的常见思想：Immutable! 对于静态不可变的数据而言，只要有 3 个副本，那么我们也可以在丢失 2 个副本的情况下，信任唯一的副本。
然而对于一个存储系统而言，我们没办法控制用户不修改 Key 对应的 Value 值，那么我们该如何实现静态化 3 副本呢？
5.6 LSMTree Revisited
关于 LSMTree 这一存储引擎的介绍，资料有很多。这里就不再详述了。
这里引用一张 LSMTree 的架构图：
我们分析一下图中每个类型的文件：
1）对于 SSTable 文件，写入完成后即不可变，而且是 LSMTree 中主要的数据存储（占比超过 99%），对于这一部分文件我们只需要存储 3 副本即可；
2）对于其他的文件如 WAL log，以及 Manifest，我们使用 5 副本存储，总体的存储成本增长可以忽略不计。
这样，我们就可以使用单 zone Infinity，在保持存储成本不变的情况下，获得双机容灾的能力。
5.7 分而治之
架构的不足之处：
1）单 zone Infinity 可以以 3 副本的存储成本实现双机容灾，然而存在租约切换期间的不可用问题；
2）5 副本 KV 实现了无租约的双机容灾，然后存储成本相比原来增加了 2/3。
两种架构各有不足，看似我们陷入了死局。然而回顾基于时间序数据的访问模型，我们发现对于热数据与温数据，他们表现出了截然不同甚至相反的一些有趣性质。
我们可以采取计算机科学中的重要思想——分治来解决：
1）对于热数据：访问量较大，我们希望他有最高的可用性，同时它的数据占比又不大，适于采用 5 副本 KV 的方案进行双机容灾改造；
2）对于温数据：数据量较大，不能采取 5 副本方案改造，而使用单 zone Infinity 的方案，则可以完美解决成本问题。
虽然会有偶尔短暂的不可用时长，但是由于整体的访问占比不多，系统整体的可用率依然可以保持在很高的水准。
对新架构的成本分析：
这样我们就在不显著增加存储成本，不牺牲可用性的前提下，实现了双机容灾的目标。
为了提升热数据部分的扩展性，我们可以使用粗粒度 paxos group 的交互方案。对于热数据，在数据量减少+粗粒度 paxos group 双重改进下，扩容时间可以提升到小时级别。同时，我们实现了热数据由 5 副本 KV 到单 zone Infinity 的自动下沉。一方面可以保持总体的存储成本不膨胀，另一方面也减少了热数据的总量，热数据集群的扩容需求也就没有那么强烈。
5.8 磁盘清空后的数据快速恢复
对于 Infinity 部分的数据，可以依靠 WFS 自动检测，补全副本数。在机器检修期间就可以完成大部分数据的补全。对于热数据部分的数据，虽然数据减少，但是恢复过程中还是会受限于 lsmtree 的写入过程中 Compact 产生的写放大问题。
经过一些业界的调研，对于 lsmtree 批量导入的场景，一种常见的做法是 BulkLoad，也即先将所有 key 进行排序，生成有序的 SSTable 文件，直接提交到 lsmtree 的最后一层，这样可以完全绕过写放大实现数据的导入。
我们经过分析，发现这种做法还不是最优的。首先，我们对于 SSTable 中的数据会进行 block 级别的压缩，在遍历数据的过程中需要进行解压；而在生成 SSTable 的过程中，为了减少存储成本，又需要进行压缩。经过研究，发现我们这种场景下有更优的恢复方案：基于目录级别的快速恢复。
5.9 目录级别的快速恢复
要想实现目录级别的快速恢复，首要条件就是：需要数据的路由规则与目录分布是完全对齐的。这样才可以保证恢复目录后，不会获得不属于本机的数据，也不会遗漏数据。
在此前的 kv 中都忽略了这一设计，导致无法通过拷贝文件实现快速恢复。结合 5 副本的路由方案，我们获得了一个可以实现对齐的目录分布方案。推导后的方案非常简洁，用一张图片即可说明。
我们进行的测试也印证了这一改造的效果，基于目录拷贝的恢复方案相比原来逐 paxos group 恢复方案取得了近 50 倍的速度提升，从小时级进入到分钟级。
5.10 新架构终得成型
对几个架构方案的对比：
5.11 平稳升级到最新架构成果
至此我们的改造方案有了，然而改造过程同样值得注意。我们必须在保证系统稳定的前提下，平稳的完成数据与访问的切换。
首先是灰度能力，我们做了两个粒度的灰度控制：
1）一是访问时间级别，按照 key 上面的时间，分批将数据从原架构中腾挪出来；
2）二是命令字级别，数据腾挪完成后，我们会先保持双写状态观察，先逐步切换读请求到新架构中，观察正常后才会去掉双写，完成切换。
其次是改造的正确性：
1）我们采取了全量的数据校验方案，保证改造过程中不会丢失数据；
2）最后是在腾挪过程中，我们开发了一套基于机器资源以及监控上报的自动反馈机制，当业务高峰期或者出现失败时自动降速，低峰期自动加速，减少了人为介入。
目前，我们已经完成部分核心存储集群的架构改造，实现了全程无故障切换。
6、本文小结
2019 年，微信后台通过如上持续不断的改造，在不增加成本的前提下，极大提升了基于时间序存储的扩展能力，从周级别的扩容速度升级到整体小时级的扩容速度，并且温数据部分的计算节点做到了分钟级的扩容速度。
同时，利用数据的特性进行集群划分，将 5 副本 PaxosStore 存储与计算存储分离架构进行有机结合，在极大提升了扩展能力的同时，将可用性提升到容忍双机故障的水平。
附录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的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《QQ设计团队分享：新版 QQ 8.0 语音消息改版背后的功能设计思路》
《微信团队分享：极致优化，iOS版微信编译速度3倍提升的实践总结》
《IM“扫一扫”功能很好做？看看微信“扫一扫识物”的完整技术实现》
《微信团队分享：微信支付代码重构带来的移动端软件架构上的思考》
>> 更多同类文章 ……
附录2：更多IM架构方面的文章汇总
[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的技术演进》
《社交软件红包技术解密(三)：微信摇一摇红包雨背后的技术细节》
《社交软件红包技术解密(四)：微信红包系统是如何应对高并发的》
《社交软件红包技术解密(五)：微信红包系统是如何实现高可用性的》
《社交软件红包技术解密(六)：微信红包系统的存储层架构演进实践》
《社交软件红包技术解密(七)：支付宝红包的海量高并发技术实践》
《社交软件红包技术解密(八)：全面解密微博红包技术方案》
《社交软件红包技术解密(九)：谈谈手Q红包的功能逻辑、容灾、运维、架构等》
《社交软件红包技术解密(十)：手Q客户端针对2020年春节红包的技术实践》
《即时通讯新手入门：一文读懂什么是Nginx？它能否实现IM的负载均衡？》
《即时通讯新手入门：快速理解RPC技术——基本概念、原理和用途》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从游击队到正规军(一)：马蜂窝旅游网的IM系统架构演进之路》
《从游击队到正规军(二)：马蜂窝旅游网的IM客户端架构演进和实践总结》
《IM开发基础知识补课(六)：数据库用NoSQL还是SQL？读这篇就够了！》
《瓜子IM智能客服系统的数据架构设计（整理自现场演讲，有配套PPT）》
《阿里钉钉技术分享：企业级IM王者——钉钉在后端架构上的过人之处》
《从游击队到正规军(三)：基于Go的马蜂窝旅游网分布式IM系统技术实践》
《微信后台基于时间序的新一代海量数据存储架构的设计实践
>> 更多同类文章 ……
[2] 更多其它架构设计相关文章：
《腾讯资深架构师干货总结：一文读懂大型分布式系统设计的方方面面》
《快速理解高性能HTTP服务端的负载均衡技术原理》
《子弹短信光鲜的背后：网易云信首席架构师分享亿级IM平台的技术实践》
《知乎技术分享：从单机到2000万QPS并发的Redis高性能缓存实践之路》
《新手入门：零基础理解大型分布式架构的演进历史、技术原理、最佳实践》
《阿里技术分享：深度揭秘阿里数据库技术方案的10年变迁史》
《阿里技术分享：阿里自研金融级数据库OceanBase的艰辛成长之路》
《达达O2O后台架构演进实践：从0到4000高并发请求背后的努力》
《优秀后端架构师必会知识：史上最全MySQL大表优化方案总结》
《小米技术分享：解密小米抢购系统千万高并发架构的演进和实践》
《一篇读懂分布式架构下的负载均衡技术：分类、原理、算法、常见方案等》
《通俗易懂：如何设计能支撑百万并发的数据库架构？》
《多维度对比5款主流分布式MQ消息队列，妈妈再也不担心我的技术选型了》
《从新手到架构师，一篇就够：从100到1000万高并发的架构演进之路》
《美团技术分享：深度解密美团的分布式ID生成算法》
《12306抢票带来的启示：看我如何用Go实现百万QPS的秒杀系统(含源码)》
>> 更多同类文章 ……
（本文同步发布于：http://www.52im.net/thread-2970-1-1.html）