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

更新时间:2017-08-29 09:28:35 点击次数:1881次

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





设计


整体架构

图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 的开发过程中,我们总结了几个设计原则和经验教训:





原文地址:

http://www.vldb.org/pvldb/vol10/p1730-lin.pdf

本站文章版权归原作者及原出处所有 。内容为作者个人观点, 并不代表本站赞同其观点和对其真实性负责,本站只提供参考并不构成任何投资及应用建议。本站是一个个人学习交流的平台,网站上部分文章为转载,并不用于任何商业目的,我们已经尽可能的对作者和来源进行了通告,但是能力有限或疏忽,造成漏登,请及时联系我们,我们将根据著作权人的要求,立即更正或者删除有关内容。本站拥有对此声明的最终解释权。

回到顶部
嘿,我来帮您!