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的出现是为了解决什么问题？
- 不同的消费速度：应用消费更新的速度不同，慢速应用不应该阻碍快消费的应用。
- 至少一次语义：所有的更新至少通知一次。
- 更新的有序性：当新更新到来的时候，应确保之前所有的更新都已经通知过了。
- 容错：系统需要能应对数据源和应用的错误。
架构
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尽可能降低对原存储系统的压力。
