这阵子遇到的一个项目，就是写到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已经开始有类似的机制实现，期待下个版本解决这个问题。
五：希望大家多支持，多给点意见！！