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

原创
2013/12/12 19:47
阅读数 676

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

【可选方案】
  • 基于公司内部的 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 月份开始到现在本人都干了哪些事情(当然还有很多不会拿到台面上说的事情,可以笼统的称为“内功修炼”)。后续会有相关博客文章,详细描述每一个功能点我是怎样思考和设计的,期间出现了哪些问题,以及我想到的解决办法。

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

另外添加两张结构图:



=== 未完待续 ===







展开阅读全文
打赏
0
4 收藏
分享
加载中
看到OSP我知道你是哪个公司的了,那玩意不错的。RabbitMQ听起来更好,我要学习一下去。

计划好紧凑,按期交活了?
2014/05/01 13:30
回复
举报
摩云飞博主

引用来自“摩云菜”的评论

拜读了,偷偷地知道了你都干些啥20

偷偷?哈哈~~
2013/12/26 13:26
回复
举报
拜读了,偷偷地知道了你都干些啥20
2013/12/25 16:59
回复
举报
更多评论
打赏
3 评论
4 收藏
0
分享
OSCHINA
登录后可查看更多优质内容
返回顶部
顶部