这阵子遇到的一个项目，就是写到MySQL数据库的数据如果同步到异构的数据库。我们知道的NoSQL产品：MongoDB，Redis，Memcached等。写着写着，发现身边的朋友也有不少类似的需求，于是一折腾就把代码整理规范，写成通用的服务去了。我就管它叫——MySQL Syncer

　　github：https://github.com/Terry-Mao/MySQL-Syncer

　　本文着重描述下该服务的用途，核心思想。

　　一：项目的用途

　　我想朋友们应该也遇到不少，需要存入MySQL数据库持久化，但是也需要做一些刷新cache之类的需求吧，最典型的Memcached的使用。有不少的方式实现，比如App直接注入过期或失效策略来刷新缓存，也有通过MySQL触发器来直接操作Memcached的。MySQL Syncer不同于前面所述，主要依赖解析binlog来获取数据源，实现数据的异步复制的方案。

　　

 点击放大

　　二：基本流程

　　(1)./rs_slave 读取自独有的 slave.info(类似MySQL Slave从库的master.info)获取binlog的文件名和偏移(/var/log/mysql/mysql-binlog.000001,0)发送给主服务./rs_master。

　　(2)./rs_master 获取dump cmd 命令参数，用标准IO打开binlog 文件，解析数据，更新到ring buffer(环形缓冲区)，这是IO线程。另外一个线程dump thread无锁(lock-free)读取数据(文件名,偏移,命令类型,数据)全部网络发送给slave。

　　(3)./rs_slave IO线程读取发送过来的数据写入ring buffer，SQL 线程更新到异构的数据源

　　(4)./rs_slave SQL线程Flush最新的文件信息到slave.info

　　三：核心思想

　　(1) 为什么不使用类似relay.log来持久化数据?我们必须明确我们的需求，虽然是异步复制，但是这里针对的对象主要还是内存数据库或者NoSQL，不需要复杂的机制确保落后了进度，因为大多数我们需要数据是实时的，所以抛弃relay.log，使用纯内存ring buffer方式。

　　(2) ring buffer为什么无锁，在这个方案里，生产者和消费者都是 1 对 1，因此可以简单的利用ring buffer 的 读写计数来实现无锁 多线程 读写数据，避免过多的mutex开销。

　　(3) 引入memcached 的slab内存管理机制，代码中，有rs_ring_buffer.c和rs_ring_buffer2.c两种实现，前者是定长，后者是把内存管理托付给rs_slab管理，实现复杂数据的长度不一的情况，最大程度节省和高效利用内存。

　　(4) MySQL Syncer暂时是只支持SBR binlog格式的，主要原因是我还没来得及写RBR格式的，：)

　　四：可能存在的问题

　　(1) 如果是用纯内存数据库作为slave，需要应用层来出发 no key 的情况，需要从DB库读取，避免内存数据库重启之后，数据丢失，因为MySQL Syncer 只保存了当前解析的binlog，否则就要从头开始解析。

　　(2) 如果MySQL主从库配置了高可用方案，切换之后如果继续同步?因为MySQL Replication复制方案中，MySQL主从的binlog 位置偏移都可能不一致，很难实现MySQL Syncer的简单Failover，所以我参考了Google的一个Patch，引入了Global Transaction ID，而且MySQL 5.6已经开始有类似的机制实现，期待下个版本解决这个问题。

　　五：希望大家多支持，多给点意见!!