Wormhole:可靠的发布-订阅系统

Wormhole是Facebook内部使用的一个Pub-Sub系统,目前还没有开源。
在网上搜索论文相关内容的时候,发现几个网站,首先是该篇论文有个视频:
https://www.usenix.org/conference/nsdi15/technical-sessions/presentation/sharma
由此知道了OSDI(Operating Systems Design and Implementation )大会,并且搜索到一个最佳论文的网址:
https://www.usenix.org/conferences/best-papers
以后可以关注下。
第二个发现的好的内容是:
https://blog.acolyer.org/2015/05/14/wormhole-reliable-pub-sub-to-support-geo-replicated-internet-services/
该博客会每天推送一篇论文,特别棒。
第3个是发现的一个学校课程:https://courses.engr.illinois.edu/cs525/sched.htm
里面有介绍该篇论文的ppt,其他内容也特别棒,可以关注下。

下面开始正式开始论文阅读,本文是mit 6.824课程的第16课学习记录。


意义

首先回答下,我们为什么阅读这篇论文,pub-sub在分布式系统中常见的模块,也已经有好多类似的系统,如Kafka,SIENA,Thialfi,RabbitMQ等等,那为什么又来了一个Wormhole呢?

不像其他pub-sub系统,Wormhole没有自己的存储来保存消息,它也不需要数据源在原有的更新路径上去插入一个操作来发送消息,是非侵入式的,那Wormhole怎么获取到更新的数据呢?

Wormhole目前支持的数据源有 MySQL, HDFS, 和 RocksDB,Wormhole直接扫描transaction logs,Wormhole直接部署在数据源的机器上,这样子还带来一个好处,Wormhole本身不需要做任何的地域复制(geo-replication)的策略,只需要依赖于数据源的geo-replication策略即可。当本地的sub收到update通知的时候,意味着本地的数据源也已经收到更新了。

下面阐述下Wormhole的出现是为了解决什么问题?

  1. 不同的消费速度:应用消费更新的速度不同,慢速应用不应该阻碍快消费的应用。
  2. 至少一次语义:所有的更新至少通知一次。
  3. 更新的有序性:当新更新到来的时候,应确保之前所有的更新都已经通知过了。
  4. 容错:系统需要能应对数据源和应用的错误。

架构

图片

Wormhole通过读取事务日志来获取更新,但是最后传递给sub的更新都是格式统一的key-value形式,称为:Wormhole update。

Wormhole将所有的订阅者信息存储在基于ZooKeeper的配置系统中,订阅者收到的一系列updates称为flow,每个flow都会维护一个当前订阅者已经消费的更新位置,这个信息是由在publisher维护的,每个flow都会有这个信息,称为datamarkers,那如何更新这个信息呢?如果采用传统的应用ack机制,会对性能造成影响,于是采取的做法是周期性的ack机制,另一个原因是由于pub和sub之间采用tcp通信,我们可以不用担心消息丢失,可以放心的周期性更新datamarkers

A datamarker for a flow is essentially a pointer in the datastore log that indicates the position of the last received and acknowledged update of the flow by the subscriber.

下面回答下一个问题:datamarkers存储在哪?
Wormhole支持两种类型的数据中心:单副本和多副本,多副本一般是多地域分布数据中心。于是Wormhole就有了两种投递:

  • single-copy reliable delivery (SCRD)
  • multiple-copy reliable delivery (MCRD).

对于SCRD,datamarkers可以直接存储在本地的存储设备上,因为存储设备挂了,markers丢失也无所谓了。
对于MCRD,markers存储在zookeeper上,如果一个publisher挂了,新的publisher可以从zookeeper中读取markers,接着发送。但是这带来的一个问题是不同的副本,其存储的位置可能不同,如图:

图片

于是就发明了logical position。但是经常性的同步数据到zookeeper会有性能损耗,因此也是周期性的动作。

优化

回到之前提过的Wormhole有别于其他pub-sub系统的一个点就是直接读取transaction log,这样子就会导致对于db读压来大,于是就有了优化Caravan,其背后的思想是:如果每个flow都有一个reader,会对DB造成太大的负载,而且稳定的情况下,其实每个reader读取到的都是同样的updates;如果所有的flows都是同一个reader呢?这会造成速度不一样的应用都需要同样速度读,那解决方案自然就是相同速度的flows分配一个reader,叫caravan,给出一张图


图片

可以看到caravan多,延迟就少,但是读压力大,caravan少,延迟大,但是读压力小。

总结

Wormhole提供了一个不一样的pub-sub系统,Wormhole利用了存储系统的transaction log来提供一个可靠的、有序的更新事件流,并能支持单副本和多副本数据存储,通过优化读取transaction log尽可能降低对原存储系统的压力。

推荐阅读更多精彩内容