【原创】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. 支持部分 MySQL 客户端协议[1][2][3](至少一周);
c. 支持对 sql 语句的相关日志记录(常规操作),分析 (可能的冲突操作);可能需要支持对 Atlas 自带的 sql 日志的反查(一周)。
d. 支持 daemon 模式运行,支持命令行选项配置(可选)(至多一周)。
最后,我做出了如下宣言:“按照上述的计算,在变更不大的情况下,基本上 12 月底提供可用的 modb 没有太大问题。”
......
......
上面基本上可以概括出从今年 3 月份开始到现在本人都干了哪些事情(当然还有很多不会拿到台面上说的事情,可以笼统的称为“内功修炼”)。后续会有相关博客文章,详细描述每一个功能点我是怎样思考和设计的,期间出现了哪些问题,以及我想到的解决办法。
最后附上一张最初画出来的一张图。
另外添加两张结构图: