阿里巴巴开源项目: 基于mysql数据库binlog的增量订阅&消费

早期canal依赖binlog解析是来自于b2b的erosa（canal产品的孵化也是在b2b），后来合并到淘宝后，替换为dbsync的binlog解析（精卫也是基于此）
db事件和业务事件的转化，目前是得由第三方的业务系统，现在canal分为server和client，提供socket服务的方式方便业务接入（典型的b2b风格），而精卫主要是二方库的方式，整个binlog解析都运行在业务系统

vlinux指出了一个此类产品的共有问题，很多时候是个平衡，但有个基本原则是尽量在让业务系统(业务开发团队)无感觉(透明)的情况下，通过此类产品向外提供更多灵活、方便的功能。所以，如果当不得不让业务系统提供更多数据时(透明性就损失了)，在这种情况下，canal的价值就并不比metaq等显示调用更有优势了。个人观点，欢迎讨论。

metaq的数据存储主要也是byte流，可以添加header信息，canal的数据主要是binlog，格式相对固定。基于byte流可以方便利用工具序列化，同样针对binlog对象你也可以构建序列化工具。
canal的定位本身就和metaq有差别，有点扯远了，vlinux的提到metaq主要是想利用其文件存储的功能

哈哈，内部版本我有基于disruptor的Ringbuffer使用，但存在一个比较大的问题，要求get操作是个独立的线程，多了很多线程之间的数据交换，未必适合canal场景。

1：因为大部分业务消息处理速度要小于业务产生速度，所以get batch是最合适的
2：因为存在事务投递，需要保证其事务可见性，所以需要支持put batch
3：不同业务场景对于get方式有所不同，目前按照batch size和timeout进行，后续考虑融合disruptor的推送功能（注册一个消费者，推送模式，推数据到客户端）

所以，就取巧借用了ringbuffer的sequence设计，揉合一些自己的需求，经过几个版本迭代，就成目前这样了，也可以说活学活用，而非生搬硬套，是吧？

LinkedIn的Databus这个功能
Infinite lookback: One of the most innovative components of Databus is the ability to support infinite lookback for consumers. When a consumer needs to generate a downstream copy of the entire data (for example a new search index), it can do so without putting any additional load on the primary OLTP database. This also helps consumers when they fall significantly behind the source database.
Canal是不是整好到metaq上就具备了？

按照我的理解，DataBus应该实现了一份binlog解析数据的持久化，数据保存有几个要求：
a. 有序性。 数据读取时需要严格按照当时写入的顺序读取
b. 大容量。 需要引入分布式存储，单机存储的架构无法满足容量扩展的需求
c. 可靠性。 需要考虑备份，考虑硬盘，操作系统crash的情况

目前metaq的设计，只能保证单机单partition有序，无法满足大容量锁需要的分布式架构，而可靠性目前通过客户端写多份来保证，所以从理论上来说无法达到所描述的那样的功能.

其实大容量，可扩展的存储架构也不会太难，之前看过bookeeper和hedwig的相关实现.
bookeeper的一些实现：
a. 有序性： 依赖zookeeper的PERSISTENT_SEQUENTIAL机制来保证
b. 大容量： 每次qurom的机器列表变更都会有版本记录，也就是你可以根据一个long id，结合qurom集群的变更版本，反推出当时写入数据的机器列表。
c. 可靠性： 一样是写多份，不过一台机器出现硬盘crash后，数据的恢复和搬迁需要手工干预.

bookeeper的缺点：
1. 效率问题：写多分，单条读取等
2. 缺少管理系统，和zookeeper一样都是独立软件式，没有强大的后台管理系统，解决动态扩展的问题。

忘记说了，还有一种有序的保证就是写入关系型数据库的一张表，比如oracle，利用oracle的小型机+TB的硬盘存储，基本上可以保存很长一段时间的数据了.

这也是最简单，最快速的解决方案，我们也有用这种机制存储过binlog解析结果，哈哈

实际应用中碰到一个问题：当client关掉时，再次期间内的增量数据，在client重新启动后，这些增量数据不会通知到client？

当然会重新通知，不会丢失，除非你下次重连的时间超过了binlog的保存时间 (因为我的增量数据来源都是源自binlog，只要它不删除，你就可以得到你离线过程的增量数据)

马上会发布canal 1.0.1版本，这个版本修复了不少小问题，canal 1.0.1版本已经正式在阿里巴巴100多个同步业务中进行了部署，相对稳定了