【需求】
一句话需求：要求实现跨机房数据库同步功能。
心得：一句话需求往往是最复杂的需求。
【可选方案】
- 基于公司内部的 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 月份开始到现在本人都干了哪些事情（当然还有很多不会拿到台面上说的事情，可以笼统的称为“内功修炼”）。后续会有相关博客文章，详细描述每一个功能点我是怎样思考和设计的，期间出现了哪些问题，以及我想到的解决办法。
最后附上一张最初画出来的一张图。
另外添加两张结构图：
