计算与存储分离实践—swift消息系统

<div class="rich_media_content" id="js_content">






 云栖君导读：swift是搜索事业部自主研发分布式消息系统，它的主要存储基于分布式文件系统，资源需求基于分布式调度系统。swift能支持每秒数亿的消息传递，支持PB级消息的存储。 一、相关背景 搜索事业部与计算平台事业部目前使用消息队列主要有以下三种场景： <ol class="list-paddingleft-2"><li>每天有上万张表需要通过Build Service来构建索引。这些表主要来自主搜索，IGRAPH，Rank Service等业务，且每个表包含的文档数差别很大。总数据量为PB级别，总文档数达万亿级。文档的大小不一，小到几十Byte大到几百KB。在Build Service内部，文档处理与索引构建需要一个消息队列来传送消息。因此在build时，容易产生突发大流量（几百G/秒，几千万条/秒）持续消息写入与读取。 </li><li>搜索的在线服务如主搜索查询服务，RankService打分服务或IGRAPH服务需要毫秒级的实时文档更新。这些服务引擎基本上是多行多列结构，即每一行是一个完整的服务单元，由多台机器组成，多行提升服务的总能力。大的服务通常包含数百行，所以一条实时消息通常会被消费数百次，在线同时实时消费的机器规模也达上万台。 </li><li>在线的实时消息主要来自离线实时模型训练，用户的实时浏览、点击、加购行为或者商家的增删改宝贝等。离线训练任务会同时启动几十万个worker对上千张表产生实时消息，写请求每秒达千万次。</li></ol> 对于这几种场景，传统的消息队列（如Kafka等）要同时满足，至少需要成百上千台物理机，且系统还需要做改造来适用于每天上万个topic的增减和几十万的生产者与消费者同时读写消息。另外这些机器的failover管理也是个大问题。现实中，搜索团队所有的机器都是由调度系统统一管理和复用，没有专门的物理机可给消息系统独占使用。 本文将介绍搜索事业部目前使用消息系统swift。主要介绍系统结构和消息可靠传递机制这两方面。最后介绍下swift系统在今年双十一期间的表现。 二、Swift介绍 传统的消息队列通常为消息的安全性，一般先要求消息落盘到本机后才返回成功。这限制的机器的迁移，扩展和复用。因为消息数据只存一两台机器，机器迁移必然导致数据的迁移。传统消息队列要有较高的性能，通常先要解写磁盘的毛刺等io问题。特别是机器与其它应用复用时IO问题并不好解决。所以传统的消息队列一般要求机器独占使用。 计算与存储分离一直是最近年来研究与应用的热点。计算与存储分离带来最大的好处是机器的迁移与调度不再受到数据存储大小与位置的限制。计算资源在调度系统的管理下可以近无限的扩展。存储系统如HDFS，PANGU能提供的PB级的存储空间以及百万级的文件读写。 计算与存储的分离在消息中间件系统中的应用还比较少，主要的问题是传统的分布式文件系统的读写响应latency远大于本机的磁盘。如果要保证消息先落盘，导致整个请求的latency就会飙升，影响整个消息系统的吞吐率。但随着硬件水平的提升如25G/100G网络和RDMA等新技术的出现，分布式文件系统也有了质的飞跃，例如集团盘古2.0等系统为低延时高可靠的存储提供很好的存储平台。 2.1 Swift系统结构 Swift消息系统是在计算与存储分离上的一次尝试。它主要有以下特点： 首先，Swift的每个计算结点都是无状态的，即每个worker上除log记录，不存储任何消息系统相关数据。在swift消息系统中，系统的状态数据存储在zookeeper上，消息的内容则存储在分布式文件系统如HDFS, PANGU等上。 其次，Swift的每个计算结点都是等价的，只要消息系统需要计算资源，就可以通过调度系统不停的申请并提升整个消息系统的服务能力。目前Swift可以跑在Hippo或者Yarn上面。 Swift消息系统每次申请的资源粒度也比较小，可以充当调度系统的碎片利用者。 最后，Swift自身的client与server的消息读写协议，能够保证消息高效可靠的传递。 <img alt="640?wx_fmt=png" class="img_loading" src="https://201907.oss-cn-shanghai.aliyuncs.com/cs/5606289-5b1bee3e9f3ea3f463abb028789ec9ec" style="ver