Otter源代码解析（九）

全部文档索引：

Otter源代码解析（一）： http://eyuxu.iteye.com/blog/1941894

Otter源代码解析（二） ： http://eyuxu.iteye.com/blog/1942518

Otter源代码解析（三）： http://eyuxu.iteye.com/blog/1942519

Otter源代码解析（四）： http://eyuxu.iteye.com/blog/1942521

Otter源代码解析（五）： http://eyuxu.iteye.com/blog/1942522

Otter源代码解析（六）： http://eyuxu.iteye.com/blog/1942549

Otter源代码解析（七）： http://eyuxu.iteye.com/blog/1942578

Otter源代码解析（八）： http://eyuxu.iteye.com/blog/1942780

Otter源代码解析（九）： http://eyuxu.iteye.com/blog/1942786

 

总结篇：

 1. 并没有针对所有的源代码进行解析（因为太多了），重点解析的地方为Node的SETL过程；

 

 2. 使用Otter的时候，因为数据的传输都是重要的，所以需要对Otter的实现细节有比较清楚的了解，否则出了问题比较难搞定（总不能出了问题找作者来Debug吧）；

 

 3. Otter的结构比较清楚的，对于性能和高可用上做了比较多的考虑，所以如果做数据传输的话确实是首选，不过Otter开发的更多是像是产品，而不是框架（易用性比较好，但是定制性比较一般，所以如果有定制化的需求，还是要想想办法）

评论

1 楼 agapple 2013-09-18  

Otter开发的更多是像是产品，而不是框架.

这个主要看当时做otter的初衷，就是做专业的数据库双A同步系统，服务阿里巴巴B2B的全部业务，当时人员参次不齐，所以在系统扩展性这块没有做好，先完成了产品功能，后期在逐步的完善. 但就目前阿里使用了近2年情况来看，业务自定义扩展性基本都是在数据转化处理层面，所以扩展性这块一直没跟上

而canal是后期的产出，主要代码和设计基本是一个人完成，产品的结构化和扩展性相比于otter会有一些改善，既可以做为产品，也可以做为工具.