1.介绍
大约三年前，微信技术团队分享了《微信后台基于时序的海量数据冷热分层架构设计实践》一文，总结了微信这一基于时序的超即时通讯海量数据存储架构的设计实践，也让大家了解了微信后台的架构设计思路。
三年后，微信再次分享了基于时间序列的新一代海量数据存储架构的设计实践(可视为《微信后台基于时间序列的海量数据冷热分层架构设计实践》一文所述架构的升级版)，希望给你带来启示。
这篇文章将同时发表在“即时通讯技术圈”的公开号上。请注意:
微信后台_52im_qr_即时通讯技术圈_400px.png基于时序的新一代海量数据存储架构设计实践
推荐阅读:阿里团队还分享了基于时间序列的即时消息数据同步和存储方案。如果有兴趣，他们可以阅读“现代即时通讯系统中聊天信息的同步和存储方案讨论”。
微信团队在很多技术文章中都提到了本文提到的千伏存储技术。以下是这些文章:
微信大用户后台系统存储架构(视频+PPT)[附件下载]
“快速裂变:见证微信强大后台架构从0到1的演变(一)”
“快速裂变:见证微信强大后台架构从0到1 (2)的演变”
“架构方式:3名程序员在微信朋友圈(有视频)中平均每天发布10亿条消息。”
2.基于时间序列的微信数据服务场景
作为一个以手机为主要平台的移动社交应用，微信中大多数服务生成的数据都具有共性:数据键值携带时间戳信息，单用户数据是随着时间不断生成的，所以我们称之为基于时间序列的数据。例如，朋友圈的出版、支付账单的流程、公共文章的阅读记录等。
这种基于时间序列的数据通常不会被删除，而是会随着时间的推移而积累，相应的存储空间也在日益增加:密钥数量达到万亿级，数据量达到PB级，每天增加十亿级密钥。与此同时，由于10亿用户的支持，每天的访问量高达数万亿。
3.微信的数据访问模式
经过数据分析，我们发现基于时间序列的存储一般有以下三个特点。
功能1-多读少写；
在这种基于时间序列的存储中，如果需要在一段时间内访问数据，就需要在相应的时间段内访问所有的键值对一次。与将它们全部写入一个键值对的情况相比，这可以被视为读取扩散的情况。在某些业务场景中，读写比率甚至高达100:1。
特征2-独特的冷热:
在这种基于时间序列的存储中，数据的及时性往往决定了访问频率。例如，如果你向用户推荐公共文章，用户最近的阅读记录将更有参考意义。因此，数据访问并不统一，而是更集中于近期生成的数据。以业务场景为例，超过70%的访问来自最近一天新增的数据，90%来自3个月内新增的数据。一年之外，数据访问仅占5%。
特征3:高数据安全性要求；
这种数据通常由用户生成。一旦丢失，很容易被用户察觉，从而导致投诉。
下图显示了数据读取分布的统计数据:
微信后台基于时间序列的新一代海量数据存储架构设计实践
(▲此图也与上一篇文章《基于时序的海量数据冷热分层架构微信后台设计实践》中的统计数据相似)
4.此次升级之前的体系结构及其面临的挑战
微信后台基于时间序列的新一代海量数据存储架构设计实践
在本次升级之前，我们采用了一致性缓存层+固态硬盘热数据层+机械磁盘冷数据层的分层架构方案来解决这种基于时间序列的存储。更多技术细节，请参考上一篇文章《微信后台基于时序的海量数据冷热分级架构设计实践》。
对于冷数据集群，我们用微信文件系统微信分布式文件系统进行了一次升级，大大简化了运维成本。然而，这部分并不是本文的重点，在此不再详细描述。
在过去的几年里，在微信的发展背景下，旧的架构一直保持稳定，但仍然面临一些挑战。
第一个是可伸缩性的挑战:在旧的架构中，考虑到多读少写的访问模式，为了加快停机后的数据采集，我们使用了细粒度的paxos组，即每个密钥都有一个独立的paxos组。这样，在停机情况下，例如流程重启，只需要捕获少量写入的密钥。理想丰满，现实瘦骨嶙峋。在PaxosStore架构中，数据扩展和收缩能力基于paxos组。也就是说，对于使用细粒度paxos组的存储，容量的扩展和收缩是关键的，并且时间消耗可以视为与密钥量成比例；这个问题被一台机器上数百亿个按键放大了。即使我们采取一系列工程优化来缩短时间，整个迁移周期仍然相对较长，需要几周时间。
另一方面，来自容灾的挑战:PaxoSTORE采用KV64+三校园部署模式(PaxoSTORE在之前的“微信后台基于时间序列的海量数据冷热分层架构设计实践”中被认为是架构中的关键技术点)。相同密钥的三个副本属于三个园区，并且同一园区中两台机器的服务切片不重叠，因此园区级故障是可以容忍的。但是，如果同一组中的两台不同的园区计算机出现故障，则只有1/6的数据会保留一份拷贝，无法提供读写服务。
一些学生可能认为同一组中两台不同的校园机器出现故障就相当于中了彩票。然而，根据墨菲定律:“任何可能出错的事情最终都会出错”。在过去的几年里，使用Set的两台不同的校园机器出现了故障。
众所周知，分布式系统的核心思想是建立一个基于大量不可靠硬件的可靠系统。那么硬件有多不可靠呢？
杰夫·迪恩曾在2009年的一次演讲中提到:
微信后台基于时间序列的新一代海量数据存储架构设计实践
杰夫·迪恩是谁？
基于时间序列的新一代海量数据存储架构在微信后台的设计实践
杰夫·迪恩是谷歌11级的超级工程师(谷歌高级研究员)。杰夫·迪恩被认为是谷歌技术的同义词，杰夫·迪恩是谷歌如此强大的重要原因之一。看看这个关于智虎:zhihu.com/question/22081653的讨论
PaxosStore不使用raid磁盘阵列，磁盘故障通常会导致单个磁盘数据丢失。在机器故障排除和数据恢复过程中，大量数据(占单个组的50%，逐渐收敛到0)以2份的形式存在，进一步削弱了系统的容灾能力。
总而言之，我们面临以下挑战:
1)如何快速扩展拥有数百亿个密钥和10TB数据的单台计算机的容量？
2)如何以低成本提高系统的容灾能力，使其能够容忍任何双机故障？
3)如何在磁盘故障和数据清空后快速恢复。
4)作为一个已有10亿个月历史的国家应用程序，它的改造相当于更换一架飞行飞机的发动机。转换过程中的任何疏忽都可能导致用户的抱怨，甚至是最后的热门搜索。
接下来，我将逐一关注这些困难，并介绍我们的解决方案。
5.该架构升级过程中技术的详细实践总结
5.1计算与存储分离的思想
对于细粒度的paxos组，在迁移过程中，扫描密钥、迁移和验证等步骤都是逐个密钥的粒度。这将产生大量的磁盘IO和CPU消耗，这将使迁移速度变慢，并且需要几个星期才能完成迁移。
那么我们可以采用粗粒度的paxos组来加速迁移吗？答案是肯定的。
与细粒度paxos组相比，单个粗粒度paxos组可以同时保证多个密钥内容的强一致性。因此，在迁移验证过程中，可以减少大量paxos交互。
但是，与细粒度paxos组的存储相比，粗粒度paxos组的存储不会减少迁移过程中对目标集群的写操作，仍然会涉及大量数据。然而，由于LSMTree存储引擎的写放大问题，将大量数据写入目标机器的过程将成为瓶颈。
总的来说，容量扩展时间可以缩短到原来的1/2甚至1/3，达到天的级别。
看来细粒度paxos组的迁移有了很大的改进。我们能走得更远吗？
首先，我们分析哪些场景需要扩展。一般来说，有以下两种情况:
1)由于数据的增加，磁盘容量达到瓶颈；
2)由于请求的增加，CPU处理能力达到瓶颈。
案例1:如果我们使用分布式文件系统而不是本地文件系统，当容量达到瓶颈时，我们只需要增加分布式文件系统的机器来实现快速的容量扩展，这相当于为上层应用程序获得一个容量无限的磁盘。
对于情况2:采用计算和存储分离的结构后。计算节点是无状态的，不涉及数据迁移，自然可以实现快速扩展；如果是存储层节点的CPU瓶颈，还可以通过文件块级实现快速扩展和热点分割。
应用计算和存储分离的思想，基于微信分布式文件系统和微信分布式锁，我们实现了一个计算和存储分离的存储架构，代码为Infinity，意味着无限的可扩展性。
5.2“任何计算机问题都可以通过添加中间层来解决”
计算机科学的经典名称:“计算机科学中的所有问题都可以通过另一个层次的教学来解决”。
在Infinity中，我们引入了一个称为容器的中间层。容器可以近似理解为一个数据切片。每台机器可以装载一个或多个容器，我们称之为容器服务器。容器服务器将处理与其上的容器相对应的数据的读/写请求，主服务器负责在容器服务器之间调度容器，查比提供分布式锁定服务和元信息存储，包括容器位置信息。
当主机发现新添加的机器时，它将主动触发负载平衡，并将其他容器服务器上的容器分派给新机器。在整个调度过程中，不涉及任何数据。在我们的实际测试中，集装箱移动的平均时间约为100毫秒。
微信后台基于时间序列的新一代海量数据存储架构设计实践
如上图所示，这是多园区部署的无限图。每个校园都有独立的工作流系统和查比存储，每个校园都对应着大量的数据。对于同一个数据切片，位于三个校区的三个容器组成了一个paxos组。
微信后台基于时间序列的新一代海量数据存储架构设计实践
对于这样的方案，我们可以实现每个校园的弹性扩展，并且系统的整体可用性由顶层的paxos保证。
让我们计算一下该方案的存储成本:园区内有3个拷贝的WFS存储x园区间有3个拷贝的副本，整体为9个拷贝。对于PB存储，这种方案增加的存储成本是我们难以承受的。因为部署在多个区域的Infinity存在成本问题。我们自然想知道是否可以使用部署在单个区域中的Infinity来负责存储。
首先，分析成本:部署在单个区域中的Infinity的存储成本是WFS的3份拷贝，这与现有体系结构的成本一致。其次，分析可伸缩性，部署在单个区域中的Infinity具有优异的可伸缩性，这优于现有的体系结构。对于依赖的中心点查比，我们可以实现集合转换来尽可能消除风险。
微信后台基于时间序列的新一代海量数据存储架构设计实践
集合转换后，我们不禁想起了当年旧架构经常遇到的一种情况:单个集合请求的突然增加。
在这里，有必要简单介绍一下PaxosStore的路由方案，它是组之间的一致散列和单个组内的KV64结构。一致性哈希消除了访问热点，一切看起来都很漂亮。然而，假设由于某种原因，当大量请求集中在访问某组KVs时，如何处理紧急情况？
此时，我们既不能快速增加该组中的机器处理请求(KV64限制)，也不能快速将请求分散到其他组(如果该组KV需要3倍的容量，则有必要将整个服务扩展3倍)。
这导致了一个尴尬的局面:
1)一个群体处于困境，其他群体处于无助状态；
2)前端请求的访问率只能重复调整，直到业务高峰期。
微信后台基于时间序列的新一代海量数据存储架构设计实践
那么我们如何在无穷远处解决这个问题呢？
首先，我们的设置本质上是对容器进行分组，其中容器和组之间的映射关系存储在查比中。如果我们想将一组请求分发给其他组，我们只需要依次修改存储在每组查比中的映射关系。在实际实施中，仍有一些工程细节需要考虑，例如，要将集装箱移入其他组，必须在原始组中卸载并停止调度。我不会在这里扩展它们。
微信后台基于时间序列的新一代海量数据存储架构设计实践
我们还进行了一项大规模的实验，将集装箱转移到网上的其他小组。结果显示，平均而言，单个容器移动到其他组不到1秒。
5.3单区域无限体系结构的一些问题
虽然单区域无限架构解决了多区域无限的成本问题，但它也做出了权衡。
对于一个集装箱，任何时候最多只能提供一个集装箱。否则，就有数据混乱的风险。模拟多线程中的数据竞争。我们通过引入分布式锁服务来避免双重分配。同时，为了降低分布式锁的开销，我们将锁的粒度从容器级收敛到容器级。每个集装箱供应商在开始提供服务后都会定期去查比公司续租。如果一个容器服务器崩溃了，主服务器需要等到锁租约到期后，才能认为这个容器服务器挂起并在其上分配容器。
这将导致一些容器在租约切换(第二层)期间无法使用。
微信后台基于时间序列的新一代海量数据存储架构设计实践
我们引入可靠性工程的两个常见指标来说明:
1)MTTR:全称是“平均修理时间”，即平均修理时间。它指的是可修复系统的平均修复时间，即从故障到修复的时间。较短的MTTR意味着更好的可恢复性。
2)平均故障间隔时间(MTBF):全称是平均故障间隔时间(Mean Time，指可修复系统中两个相邻故障之间的平均间隔时间。MTBF越高，失败的可能性就越小。
可以说，单区域无限架构缩短了MTTR，但也缩短了平均传输带宽，导致整体可用性较低。
5.4不可能的三位一体？
在许多领域，都有类似于“不可能的三位一体”的理论。例如，分布理论中的经典CAP定理，经济理论中的蒙代尔不可能三位一体等等。
在我们上面的讨论中，实际上有这样一个“不可能的三位一体”:
1)成本
2)可扩展性
3)可用性。
微信后台基于时间序列的新一代海量数据存储架构设计实践
你最初说过:
1) PaxoSTORE同时考虑了成本和可用性，但是它的可扩展性有点差；
2)多区域无限的可用性和可扩展性是优越的，但是成本是一个问题；
3)单区域无限牺牲一点可用性来换取成本和可扩展性的优势。
你不能既吃蛋糕又吃。我们应该如何选择？
1)第一个是成本:这是我们必须考虑的一个因素，它关系到我们的建筑实际上是降落还是成为巴贝奇的分析机器；
2)第二，可用性:它与用户体验相关。
在我们的新架构中，可用性不仅应该降低，甚至应该提高。例如，容忍任何双机故障。结合以上讨论，一个核心目标逐渐浮出水面:双计算机系统的低成本容灾重建。
5.5低成本双机灾难恢复转型
首先，让我们分析一下如何实现两台计算机的灾难恢复转换。
一个简单的想法是把我们的拷贝数从3份增加到5份。
5份自然可以容忍少于多数(
此时，我们想到了函数式编程中的一个常见想法:不可变！对于静态不可变数据，只要有3个副本，即使我们丢失了2个副本，我们也可以信任唯一的副本。
但是，对于一个存储系统，我们不能控制用户不修改对应于键的值，那么我们如何实现静态3拷贝呢？
5.6重树
关于存储引擎LSMTree的介绍有很多材料。这里不再详细描述。
下面是对LSMTree体系结构图的参考:
微信后台基于时间序列的新一代海量数据存储架构设计实践
让我们分析图中的每种文件类型:
1)对于表文件，它在写入后是不可变的，并且它是LSMTree中的主要数据存储(占99%以上)。对于这部分文件，我们只需要存储3份；
2)对于其他文件，如WAL日志和清单，我们使用5个副本进行存储，总体存储成本的增加可以忽略不计。
这样，我们可以使用单区域无限，并在保持存储成本不变的情况下获得两台计算机的容灾能力。
5.7分而治之
架构的缺陷:
1)单个区域Infinity可以以3个副本的存储成本实现两台计算机的灾难恢复，但是在租约切换期间存在不可用的问题；
2)5个拷贝的千伏实现了两台计算机的无租用容灾，存储成本比原来增加了2/3。
这两种架构都有各自的缺点，我们似乎处于死胡同。然而，回顾基于时间序列数据的访问模型，我们发现热数据和温度数据显示了一些非常不同甚至相反的有趣特性。
微信后台基于时间序列的新一代海量数据存储架构设计实践
我们可以采用计算机科学的重要思想——分而治之来解决它:
1)热数据:访问量大，希望可用性最高，数据比例不大，适合两台5千伏计算机的容灾改造；
2)对于温度数据:数据量大，不可能采用5份方案，但单区无限方案可以很好地解决成本问题。
尽管偶尔会出现短暂的不可用，但由于总访问量所占比例较小，系统的总体可用率仍可保持在非常高的水平。
新架构的成本分析；
微信后台基于时间序列的新一代海量数据存储架构设计实践
这样，我们可以实现两台计算机的容灾目标，而不会显著增加存储成本和牺牲可用性。
为了提高热数据的可扩展性，我们可以使用粗粒度paxos组的交互方案。对于热数据，通过数据缩减和粗粒度paxos组的双重改进，扩展时间可以提高到小时级。同时，我们实现了热数据从5个千伏拷贝到单区无限远的自动汇整。一方面，它可以防止整体存储成本的增长，另一方面，它还可以减少热数据的总量，并且对热数据集群的扩展需求并不那么强烈。
5.8磁盘清空后数据的快速恢复
对于Infinity数据，WFS可以自动检测并完成拷贝数。大多数数据可以在机器维护期间完成。对于热数据部分的数据，虽然数据有所减少，但恢复过程仍然受到lsmtree写过程中Compact引起的写放大问题的限制。
根据一些行业调查，批量导入lsmtree的常见方法是BulkLoad，即首先对所有密钥进行排序，然后生成一个有序的SSTable文件，该文件直接提交给lsmtree的最后一层，这样就可以通过绕过写放大来完全导入数据。
经过分析，我们发现这种做法并不是最优的。首先，我们将在块级别压缩SSTable中的数据，并且我们需要在遍历数据的过程中解压缩它；在生成存储表的过程中，为了降低存储成本，需要进行压缩。经过研究，我们发现在这种情况下我们有一个更好的恢复方案:基于目录级别的快速恢复。
5.9目录级快速恢复
为了在目录级别实现快速恢复，第一个条件是数据的路由规则与目录分布完全一致。通过这种方式，可以保证在恢复目录后，不会获得不属于该机器的数据，也不会丢失这些数据。
这种设计在以前的KVs中被忽略了，这使得通过复制文件来快速恢复变得不可能。结合5个副本的路由方案，我们得到了一个可以实现对齐的目录分发方案。导出的方案非常简单，可以用一幅图来说明。
微信后台基于时间序列的新一代海量数据存储架构设计实践
我们的测试也证实了这种转变的效果。与原paxos组恢复方案相比，基于目录拷贝的恢复方案速度提高了近50倍，从小时级提高到分钟级。
5.10新架构最终形成
微信后台基于时间序列的新一代海量数据存储架构设计实践
几种建筑方案的比较；
微信后台基于时间序列的新一代海量数据存储架构设计实践
5.11顺利升级到最新的建筑成就
在这一点上，我们有一个转型计划，但转型过程也值得注意。我们必须在保证系统稳定的前提下，顺利进行数据交换和访问。
首先是灰度能力。我们已经完成了两种粒度的灰度控制:
1)首先是访问时间级别，根据密钥上方的时间，将数据分批移出原架构；
2)第二个是命令字级别。在数据移动完成后，我们将首先保持双写状态观察，并逐步将读请求切换到新的体系结构。观察正常后，双写将被删除，切换将完成。
其次是转换的正确性:
1)我们采用了全面的数据验证方案，以确保数据在转换过程中不会丢失；
2)最后，在移动过程中，我们开发了一套基于机器资源和监控报告的自动反馈机制，在业务高峰或故障时自动减速，在低谷时自动加速，减少人工干预。
目前，我们已经完成了部分核心存储集群的结构转型，实现了整个故障转移过程。
6.本文摘要
2019年，通过上述持续转型，微信后台在不增加成本的情况下，大幅提升了基于时间序列存储的扩展能力，从每周扩展速度提升到每小时整体扩展速度，温暖数据部分的计算节点实现了分钟扩展速度。
同时，利用数据的特点来划分集群，将5拷贝PaxosStore存储和计算存储分离架构有机地结合起来，大大提高了可扩展性，将可用性提高到双机容错的水平。
----------------------------------------------------------------------------------
哇谷im_im即时通讯_私有云_公有云-哇谷云科技官网-JM沟通
IM下载体验 - 哇谷IM-企业云办公IM即时聊天社交系统-JM 沟通下载
IM功能与价格 - 哇谷IM-提供即时通讯IM开发-APP搭建私有化-公有云-私有化云-海外云搭建
新闻动态 - 哇谷IM-即时通讯热门动态博客聊天JM沟通APP
关于哇谷-哇谷IM-提供企业即时通讯IM开发-语音通话-APP搭建私有化-公有云-私有化云-海外云搭建
联系我们 - 哇谷IM-即时通讯IM私有化搭建提供接口与SDK及哇谷云服务
公有云和私有云之间有什么区别？类似融云、环信云、网易云、哇谷云？