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尽可能降低对原存储系统的压力。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏纯洁的微笑

微服务架构—服务降级

什么是服务降级?当服务器压力剧增的情况下,根据实际业务情况及流量,对一些服务和页面有策略的不处理或换种简单的方式处理,从而释放服务器资源以保证核心交易正常运作或...

1882
来自专栏沃趣科技

MySQL 8.0 | CATS调度算法的性能提升

原文地址:https://mysqlserverteam.com/contention-aware-transaction-scheduling-arrivin...

4877
来自专栏恰童鞋骚年

谈谈对于企业级系统架构的理解—李平

原文地址:http://www.cnblogs.com/liping13599168/archive/2011/05/11/2043127.html

1214
来自专栏Python中文社区

你真的了解网络爬虫吗?

Google 与 Yahoo 等网站的背后,都有一个强大的网页收集程序,可以将全世界的网页通通抓回去储存以便提供搜寻之用,这个程式就称为 "爬虫...

2389
来自专栏大数据架构

超大规模 Spark 集群灰度发布 CI CD

目前主流的代码管理工具有,Github、Gitlab等。本文所介绍的内容中,所有代码均托管于私有的 Gitlab 中。

2343
来自专栏数据和云

创新,才能不被淘汰-机器学习时代,运维将何去何从?

我们曾经分享过一篇文章,云时代的DBA,何去何从?,在文中我们讨论了Oracle最近几年重点转而向云的变革,它全力以赴在做的一件事情就是把所有的产品和服务转移到...

2826
来自专栏机器学习算法与Python学习

原创:scikit-learn 在Ubuntu上环境的搭建详解

之前一直想在Ubuntu下搭建一个机器学习的框架,由于忙于各种事情一直拖到先在。终于在上周成功的在Ubuntu下搭建了scikit-learn的学习矿机。 首先...

3315
来自专栏CRPER折腾记

VS Code折腾记 - (1)扯淡

距离上篇介绍VSCode的文章已经过去四十多天,已经在正式项目作为主力开发工具了。 社区的发展非常快速,更新迭代够快,功能基本已经满足我所需了; 这个系列教程基...

861
来自专栏恰童鞋骚年

谈谈对于企业级系统架构的理解

在我们刚开始学习架构的时候,首先会想到分层的概念,分层架构比较经典的是三层架构,那么,什么是三层架构呢?它包括表现层,业务层,数据访问层;而对于一个新手来说,从...

1272
来自专栏杨建荣的学习笔记

时间序列数据库InfluxDB初探(r12笔记第74天)

性能监控中的很多数据都是根据时间维度来生成的,就算是很少的几台服务器,如果设置了大量的监控项,每天的数据量也是很客观的,再加上是成千上万的服务器,这个量级就...

3507

扫码关注云+社区

领取腾讯云代金券