【需求】
一句话需求：要求实现跨机房数据库同步功能。
心得：一句话需求往往是最复杂的需求。
【可选方案】
基于公司内部的 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 应用程序，需要支持的功能点包括但不限于：
d. 支持 daemon 模式运行，支持命令行选项配置（可选）（至多一周）。
最后，我做出了如下宣言：“按照上述的计算，在变更不大的情况下，基本上 12 月底提供可用的 modb 没有太大问题。”
......
上面基本上可以概括出从今年 3 月份开始到现在本人都干了哪些事情（当然还有很多不会拿到台面上说的事情，可以笼统的称为“内功修炼”）。后续会有相关博客文章，详细描述每一个功能点我是怎样思考和设计的，期间出现了哪些问题，以及我想到的解决办法。
最后附上一张最初画出来的一张图。
另外添加两张结构图：