【原创】modb 开发之需求和总体设计

【需求】
一句话需求：要求实现跨机房数据库同步功能。
心得：一句话需求往往是最复杂的需求。

【可选方案】

• 基于公司内部的 osp 公用库开发
• 直接使用业界已有的开源解决方案
• 利用业界已有的开源解决方案，通过二次开发实现相应功能

心得：基于公司公用库开发会被各种因素所束缚；业界已有的开源方案要么过于庞大复杂，不符合我的实现需要，要么功能上不满足要求；而基于开源方案做二次开发，需要付出相当大的学习成本，同时要求有相当的能力才能进行定制化改动。
结论：有困难要上，没有困难创造困难也要上，必须第三种。

【涉及到的相关开源项目】

• Lua（MySQL-Proxy 中用于做各种业务处理的地方，需要理解语法以及 Lua 与 C 的集成）
• Glib（MySQL-Proxy 的底层依赖库）
• JSON（modb 需要支持 json 数据解析）
• libevent（rabbitmq-c 客户端库需要基于 libevent 做事件驱动改造）
• RabbitMQ（需要理解 AMQP 协议和 RabbitMQ 的各种复杂应用方式才能做好 rabbitmq-c 客户端的改造）
• MySQL（需要理解 MySQL 的各种知识，从基础配置到高可用架构，和各种常见错误处理）
• MySQL Connector/C（需要理解 MySQL C API 的用法和常见错误）
• MySQL Proxy（一个已经废弃的、经典的 MySQL 数据库代理软件）
• Atlas（360 公司开源的、基于 MySQL-Proxy 改进的数据库代理软件）
• Haproxy（RabbitMQ 做复杂应用时使用）

心得：当一个人不知道困难有多大时，才可能更猛的向前冲。
结论：无知者无畏。

【半年时间】

• 研究 AMQP 协议
• 研究 rabbitmq-c 源码
• 研究 libevent 源码
• 完成基于 libevent 的 rabbitmq-c 的改造
• 研究 RabbitMQ 官网上给出的各种用法以及《RabbitMQ in Action》整本书的内容
• 研究 MySQL 协议、常规配置、集群方案、高可用等方面内容。
• 研究 MySQL-Proxy 0.8.3 源码
• 学习 Lua 语法以及和 C 的集成
• 研究 Atlas 相对于 MySQL-Proxy 的改进，跟踪可能出现的问题
• 研究 MySQL Connector/C 的用法，以及注意事项

结论：涉及到的东西非常多，各种信息如何整合到一起，并为我所用是难点。

【MoDB 的工作内容和安排】

在没有明确需求的情况下，经过大半年的各种研究后，最终在 11 月初制定出如下计划。

基于 rabbitmq-c 改造后的 modb 应用程序，需要支持的功能点包括但不限于：
a. 支持多消费者单生产者 （一周）；
b. 支持部分 My SQL 客户端协议[1][2][3]（至少一周）；
c. 支持对 sql 语句的相关日志记录（常规操作），分析 （可能的冲突操作）；可能需要支持对 Atlas 自带的 sql 日志的反查（一周）。
d. 支持 daemon 模式运行，支持命令行选项配置（可选）（至多一周）。

最后，我做出了如下宣言：“按照上述的计算，在变更不大的情况下，基本上 12 月底提供可用的 modb 没有太大问题。”
......
......
      上面基本上可以概括出从今年 3 月份开始到现在本人都干了哪些事情（当然还有很多不会拿到台面上说的事情，可以笼统的称为“内功修炼”）。后续会有相关博客文章，详细描述每一个功能点我是怎样思考和设计的，期间出现了哪些问题，以及我想到的解决办法。

最后附上一张最初画出来的一张图。

另外添加两张结构图：



=== 未完待续 ===