【需求】
一句話需求：要求實作跨機房資料庫同步功能。
心得：一句話需求往往是最複雜的需求。
【可選方案】
基于公司内部的 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 月份開始到現在本人都幹了哪些事情（當然還有很多不會拿到台面上說的事情，可以籠統的稱為“内功修煉”）。後續會有相關部落格文章，較長的描述每一個功能點我是怎樣思考和設計的，期間出現了哪些問題，以及我想到的解決辦法。
最後附上一張最初畫出來的一張圖。
另外添加兩張結構圖：