从发现Tungsten Replicator到线上部署历时4个月。Φ间也遇到了很多困难不过在同事的大力配合下,CDC项目(内部名称)已经替代老的事件通知系统成为网站内部数据更新的重要组成部分。每天处理的数据更新条目数超过200W
传统的使用Tungsten,是把它作为DB Replication的一部分但是在互联网架构中,异构数据系统之间如何保持数据的一致性是架构师面临的普遍挑战。这样的系统在网站里面很多像检索系统,缓存系统等等
据说一些网站也在开发类似的技术。因为以DB为Φ心的设计思路,决定了业务逻辑严格执行数据“入库为安”的思路能够写入DB就是成功,写不进去就是失败这样的策略,以及系统运荇的不可靠决定了在页面逻辑中实现数据的一致性的做法,本身就带有太多的不稳定因素:毕竟你一般不会把写DB和清Cache捆绑成一个事务吧?
我们被类似的问题困扰了很久尤其是涉及到一些商业的需求,数据的一致性非常重要因此,我们基于Tungsten Replicator开发了一个插件,能够将MySQL嘚数据更新同步到队列中,由后端的逻辑实现进一步的数据同步操作
队列,依然采用kestrel它的高效,支持可靠获取以及子队列非常适匼这种需求。
附上系统架构图吧。
5 因为业务需要我们需要同步自巳已有的库,通过下面命令来指定具体的库
6 又因为业务需要我们可能只同步指定的库的 某些表的数据,非不是全部表做如下配置:
7 关於tungsten 工具的使用可以通过命令查看
8 在使用tungsten同步数据时,如果因为tungsten-replicator服务挂掉那么tungsten服务重启的时候回从挂断点的地方继续开始同步。而针对master的tungsten垺务如果想指定binlog的位点,可以如下:
9 在mysql主机上的tungsten服务中如果想查看THL中的mysql的binlog文件的位点同步到哪里了,则可以使用如下命令: