一个大型分布式系统往往存在多种的存储系统,mysql,tair,redis,memcache,hbase等等。一些重要的或者需要事务支持的数据操作,通常都会放到mysql处理。但是,为了满足高性能的访问需求或者做一些服务定制化的查询,业务上通常又会把mysql的数据再写到tair或者redis等外部存储中一份。
以业务将tair作为mysql的高速缓存为例,通常业务在代码中会有这么一段逻辑,读取tair,数据不存在,从mysql读取数据,然后写入tair。用户变更mysql,然后会同时刷新tair,或者将tair数据删除。为了降低客户端复杂度并且防止缓存穿透,常会引入MQ进行异步同步,如下图所示:
image.png
但是无论客户端同步方式还是MQ方式,其实都会存在数据一致性问题,这些场景,如果没有一个强一致协议(比如两阶段提交,paxos等)是很难解决掉的。
现在,有了Databus,上面提到的这些一致性问题就都没有了,并且,那些冗长的双写逻辑也可以去掉了。
Databus是一个实时的、可靠的、支持事务的、保持一致性的数据变更抓取系统。 2011年在LinkedIn正式进入生产系统,2013年开源。
Databus通过挖掘数据库日志的方式,将数据库变更实时、可靠的从数据库拉取出来,业务可以通过定制化client实时获取变更。
Databus的传输层端到端延迟是微秒级的,每台服务器每秒可以处理数千次数据吞吐变更事件,同时还支持无限回溯能力和丰富的变更订阅功能。
Databus概要结构:
image.png
图中显示:Search Index和Read Replicas等系统是Databus的消费者。当主数据库发生写操作时,连接其上的中继系统会将数据拉到中继中。签入在Search Index或是缓存中的Databus消费者客户端,就会从中继中拉出数据,并更新索引或缓存。
image.png
上图中介绍了Databus系统的构成,包括中继Relay、bootstrap服务和客户端库。Bootstrap服务中包括Bootstrap Producer和Bootstrap Server。快速变化的消费者直接从Relay中取事件。如果一个消费者的数据更新大幅落后,它要的数据就不在Relay的日志中,而是在 Bootstrap Producer里面,提交给它的,将会是自消费者上次处理变更之后的所有数据变更快照。
在LinkedIn,Databus支持的系统有: