首发 | 微信成功挑战10亿人聊天记录的背后，核心技术原来是它

AI科技大本营

发布于 2018-04-27 16:22:07

1.7K0

发布于 2018-04-27 16:22:07

文章被收录于专栏：AI科技大本营的专栏AI科技大本营的专栏

翻译 | AI科技大本营（rgznai100）

参与 | Shawn，周翔

作为数据库领域的顶级会议，VLDB (Very Large Data Base)是数据库研究人员、供应商、参与者、应用开发者、以及用户一年一度的主要国际论坛。今年的 VLDB 于 8 月 28 日——9 月 1 日在德国慕尼黑举行，涵盖了数据管理、数据库和信息系统研究领域的问题。

AI科技大本营发现，此次微信团队也有论文被 VLDB 收录，如下图所示：

在这篇题为《 PaxosStore: High-availability Storage Made Practical in WeChat 》的论文中，微信团队介绍了微信中高可用性的存储系统——PaxosStore。该系统在存储层采用了组合式设计，针对不同存储模型开发不同的存储引擎。(编辑注：在AI科技打本营微信公众号后台回复：微信，下载完整论文)

PaxosStore 的特点在于，它将基于 Paxos 的分布式一致性协议(consensus protocol)提取出来作为一个中间件，底层的多模型存储引擎在各种情况下都可以访问这个中间件。这使得存储引擎的调整、维护、缩放和扩展更加容易。

微信团队表示，在工程实践方面的经验，实现一个实用的一致性读写协议要比理论复杂得多。为了解决这样复杂的工程难题，他们提出了一种层级式的基于 Paxos 的存储协议堆栈。协议中使用的基本数据结构 PaxosLog 的作用是，将以编程为导向的一致性读写桥接到以存储为导向的 Paxos 程序。另外，文章还介绍了基于 Paxos 的优化方法，这种方法可以使容错(fault-tolerance)更加有效。围绕如何构建实用的分布式存储系统，这篇论文还对几种切实可行的解决方案进行了讨论。

以下是论文简介：

引言

微信是最受欢迎的手机应用程序之一，其月活跃用户人数接近10 亿人(编辑注：据腾讯2017第二季度财报，截止6月30日，微信月活跃用户9.63亿，逼近10亿大关)。微信为用户提供即时通讯、网络社交、移动支付和第三方授权等服务。支持这些综合业务的后端由很多功能组件构成，这些组件是由不同的团队开发的。尽管这些业务的商业逻辑不同，但是大部分后端组件的应用都需要可靠的存储支持。

起初，各开发团队随机选用现有的存储系统作为独立组件的原型。但是各种各样的零散存储系统不仅需要花费巨大的精力来维护，而且还难以扩展。因此需要开发一种通用的存储系统，为微信多种多样的业务提供支持，PaxosStore 正是基于此开发的第二代存储系统(第一代微信存储系统是基于 quorum protocol 开发的)。

在微信的业务单元中，以下关于存储服务的要求均属常规要求。

第一，大数据具备著名的三 V 特性： volume、 velocity、 variety(大量、高速、多样)。微信每天平均生成约 1.5TB 的数据，这些数据包含各种各样的内容，如文本信息、图像、音频、视频、金融交易以及朋友圈文章等。在白天，每秒发出的应用请求就有成千上万次，而且系统使用以单记录访问（single-record accesses）为主。

第二，高可用性是存储服务的首要特性。大多数应用的实现都要依赖 PaxosStore，例如点对点讯息传递、群聊、浏览朋友圈文章等。高可用性对用户体验至关重要。微信的大多数应用需要PaxosStore 的 latency overhead 控制在 20 ms 以内。而且，还必须按 urban scale 的需求来满足这样的延迟要求。

除了借助 PaxosStore 为用户提供高可用性存储服务，我们还面临以下挑战：

有效且高效的一致性保证。根本上，PaxosStore 使用 Paxo 算法处理一致性问题。尽管原始的 Paxos 协议有提供一致性保证，但是应用的复杂性(例如，复杂状态机器需要进行妥善的维护和跟踪)和高额运行成本(例如同步所要求的带宽)使得该协议无法为微信的综合业务提供支持。
弹性和低延迟。 PaxosStore 需要按城市级的需求来为低延迟读写提供支持。在运行时，需要妥善处理负载冲击(Load surge)。
跨数据中心自动容错。在微信的运营中，PaxosStore 的应用横跨全球多个数据中心的数千商用服务器。在如此大规模的系统中，硬件故障和网络中断屡见不鲜。容错系统应能在不影响系统整体效率的条件下，进行错误检测和恢复。

PaxosStore 是一个实用的高可用性存储解决方案，它的应用为微信后端提供了强大的存储支持。该系统在存储层采用了组合式设计，针对不同存储模型开发不同的存储引擎。PaxosStore 的特点在于，它将基于 Paxos 的分布式一致性协议(consensus protocol)提取出来作为一个中间件，隐含的多模型存储引擎在各种情况下都可以访问这个中间件。这种基于 Paxos 的存储协议在经过扩展以后，可以为针对各种应用构建的编程模型中各种各样的数据结构提供支持。而且，PaxosStore 采用 leaseless 设计，可以实现很好的系统可用性和容错能力。本论文的主要贡献可概括为以下几点：

我们介绍了 PaxosStore 的设计，重点阐述了一致性读写协议的构建及其运作方式。通过从存储层中解耦出一致性协议，PaxosStore 拥有很好的可扩展性，可以给为不同存储模型构建的多种存储引擎提供支持。
根据 PaxosStore 的设计，我们进一步论述了容错系统以及关于数据恢复的细节。文中描述的技术已在大型生产环境中实现了全面应用，它们使 PaxosStore 在微信所有的生产应用中达到了99.9999% 的可用性（此结果是通过对 6 个月的运行数据进行统计得出的）。
在日益成长的微信业务背后， PaxosStore 已经为其提供了两年多的支持。基于这些实践经验，我们探讨了 PaxosStore 设计上的取舍，并给出了我们的应用实践所得到的实验评估结果。

设计

整体架构

图1： PaxosStore的整体架构

图1显示了 PaxosStore 的整体架构，总共有 3 层。编程模型针对各种外部应用提供多种数据架构。一致性层(consensus layer)执行基于 Paxos 的存储协议。存储层包含了多个根据不同存储模型构建的存储引擎，这些引擎可以满足各种各样的性能要求。PaxosStore 的架构与传统存储设计的不同之处主要在于它能将一致性协议应用提取出来作为一个中间件，为所有潜在的存储引擎提供数据一致性保证。

通常，传统的分布式存储系统都是基于系统的单一存储模型构建的，对模型的设计和应用作出稍微调整以满足不同的应用要求。但是，这样的话往往必须在不同组件之间进行复杂的协调。虽然将多个现成的存储系统组合成一个综合系统可以满足不同的存储要求，但是这常常会使整个系统难以维护并且会削弱可扩展性。而且，每个存储系统都将数据一致性协议嵌入到存储模型中，针对一致性问题的相应的分解克服(divide-and-conquer)法可能很容易出错。这是因为整体系统的一致性保证是由单独的子系统的一致性实现度的耦合决定的。而且，需要跨模型访问数据(即跨多个存储子系统)的应用几乎无法利用任何潜在子系统的一致性支持，对于这种跨模型数据访问的情况，只能单独地自行应用一致性协议。

PaxosStore 采用组合式存储设计。存储层上应用有多个存储模型，只处理高可用性的实现问题，一致性问题则由一致性层处理。这使得每个存储引擎以及整个存储层可以按照需求进行扩展。由于一致性协议应用已从存储引擎中解耦出来，所有支持的存储模型在各种情况下都可以利用数据一致性保证。这也使得跨模型数据访问更易于实现。

这种编程模型层的设计和应用在技术上简单易懂，在本部分，我们主要介绍 PaxosStore 一致性层和存储层的设计细节。

一致层(consensus layer)

图2：存储协议栈

算法1：PaxosStore中的Paxos实现

图3：PaxosLog 结构

图4：PaxosLog + Data对象

图5：PaxosLog-as-value for key-value storage

图6：PaxosStore 中读取过程的示例

存储层(Storage Layer)

图7：PaxosStore 的区域内部署样本，C = 2

容错和可用性

图8：PaxosStore 中的数据恢复方法

评估

实验设置

图9：PaxosStore 的整体读/写性能和预准备优化的有效性

延迟

图10：迷你集群大小的测量

故障恢复

图11：监控微信中 PaxosStore 节点的故障恢复

PaxosLog-Entry 批量应用的有效性

图12：PaxosLog-Entry 批量应用的有效性

总结

在本文中，我们详细解读了 PaxosStore，它是一个高可用性的存储系统，每秒可以承受数千万次的一致性读/写操作。PaxosStore 中的存储协议基于用于分布式共享的 Paxos 算法，我们对其进行了进一步具有实操性的优化，包括用于 key-value 存储的 PaxosLog-as-value 和简明PaxosLog 结构。基于细粒度数据检查点的容错方案使 PaxosStore 能够在故障时支持快速数据恢复，而不会导致系统停机。PaxosStore已经在微信中实施和部署，为微信集成服务（如即时消息和社交网络）提供存储支持。

在 PaxosStore 的开发过程中，我们总结了几个设计原则和经验教训：

建议不要通过妥协的单一存储引擎支持存储多样性，而是设计这样的存储层，让它能够支持为不同存储模型构建的多个存储引擎。这种方法有助于开发者在操作维护的动态方面进行有针对性的性能调整。
除错误和故障外，系统过载也是影响系统可用性的关键因素。特别是在设计系统容错方案时，我们必须对过载引起的潜在雪崩效应给予足够的重视。一个具体的例子是在 PaxosStore 中使用迷你集群组(mini-cluster group)。
PaxosStore 的设计大幅借鉴了基于消息传递的事件驱动机制，这可能会涉及逻辑实现方面的大量异步状态机转换。在构建 PaxosStore 的工程实践中，我们开发了一个基于协同程序和 socket hook 的框架，以便于以 pseudo-synchronous 方式对异步过程进行编程。这有助于消除容易出错的函数回调，并简化了异步逻辑的实现过程。