数据总线erosa和精卫

erosa eromanga otter VS 精卫（dbsync+meta）

--eromanga 伊罗曼加（澳大利亚一座山）

http://wenku.baidu.com/view/fcffbf9d6bec0975f465e2c3.html 《阿里巴巴分布式数据库中间件》

http://taobao.github.com/metaq/document/design/design.htm   metaq原理和应用

为了描述把前者简称为EEO，后者还叫做精卫。

数据的抓取和分发是据总线的两个主要功能，目的是分享mysql的变化数据，关联业务方可以实时（<100ms）收到主业务的数据。

erosa for mysql

1 精卫封装了dbsync和metaq，目标：面向业务方数据使用者，提供便利的接入方式。

2 dbsync 解析mysql binlog转换成java对象 event，event对象封装变化数据的操作，schema、table、action，一条记录的字段所有内容（如果是insert或者delete），如果是update操作则包含修改后的字段的值。参考http://forge.mysql.com/wiki/MySQL_Internals_Binary_Log。

3 为方便通信和存储，EEO 使用google的protocol buffer序列化协议，精卫使用Facebook的thrift协议，均达到了跨平台的目的。不同的是EEO和精卫使用的Event对象定义有所不同，但可互相转换。

4 对事务处理。众所周知，数据库具有ACID的特性，那么数据传输管道能在多大程度上保证这一点？

   （1）打破事务，大事务被拆开，分别消费。

   （2）可见性，消费者消费了

5 缺点  但是不保证数据重复，dump程序出现故障的时候，要从上一次记录的位点，继续抓取binlog，从上一次位点到真正成功消费的位点这段event会重复。记录位点是间隔一段时间或成功消费了若干条event（注意一定是成功消费了的位点）。

6 抓取方面，EEO现在已经有了erosa for mysql和erosa for oracle，扩展上性上，以后可方便开发erosa for hbase，for other store，只要数据源是基于log机制的，开发出相应的解析器

7 容灾    mysql主备切换或者 mysql挂掉--通过（dbsync+精卫+diamond） 解决

            

8 消息分发：精卫使用metaq（一个优秀的分布式消息中间件）作为消息分发器，高吞吐量，消费端负载均衡框架。

  EEO使用eromonga

9 otter 跨机房数据同步

10 异常情况处理：erosa、eromaga、client挂掉

    EEO

    精卫

     mysql主备切换、精卫、meta-server、meta-client挂掉

    （1）精卫封装switch逻辑，切换dbsync连接不通的mysql实例。通过diamond 获取主备，其实dbsybc连主还是连备，没什么影响（如果忽略mysql自己master-->slave的复制延迟的话）；

            mysql集群增加、减少机器，也是通过diamond通知精卫的，精卫就知道可选的要连接的mysql实例。效果是dba运维mysql的时候，例如要维修master： 下掉master，把备机变成master，修复后，master还原成master，slave还原成slave），精卫随着切换连接，保证始终连着master。

     （2）精卫挂掉

       通过zookeeper集群做协调，精卫程序部署在不同机房，做到机房间备用。

      （3）meta-server挂掉

       顶上meta的备机

       （4）meta-client挂掉

        a 消费者的位点记录在zookeeper上，重启后从zookeeper上获得上次消费进度

        b 集群环境下，如果同一个group有多台机器，一台机器挂掉，meta提供了消费负载框架，剩下的机器重新组织，分担挂掉的哪台机器正常时消费的分区；如果后端消费不及时，可以在同一个group里增加机器，便于水平扩展。

11    eromanga-server、eromanga-store、eromanga client、erosa、erosa-protocol、erosa paser

12  精卫给meta提的需求

（1）一台meta server上，随着partition的增加，meta server的load会急剧升高，分析原因，主要是IO导致。多个生产者（精卫抓取binlog），通过meta client写到meta server，多个消费者从不同的partition抓取消息，众多的生产者和消费者争抢读写磁头，io飙高，内存、cpu还正常。未解决这个问题，meta开发2.0支持10K以上的队列而不会导致IO飙升。

（2）服务端消息过滤

原本可以所有的消费者把消息抓取到Client端消费，这样增加了网络消耗，消费者增加的时候可能会撑爆网卡，线上千兆网卡，每条消息4K大小，生产者tps达到10K时候，就是40M/S，一个消费者占40m/S，

（3）按时间回溯  

原来消费者的消费进度保存在zk或者broker上，consumer重启的时候可以从zk（或者server）开始继续消费，保证消息不丢失

但是不能回溯几个小时（搜索dump 那边会有这个需求，一般是24小时以内的）

现在2.0支持这个根据时间回溯的功能了

（4）