如何开发一个分布式内存数据库(一)
如何开发一个分布式内存数据库(一)
目前有很多商用的内存数据库(timesten, atibase)，很多开源的分布式物理数据库，而成熟的分布式内存数据库却很少。当然mysql cluster算是一个，但其受控于oracle，真正要拿来商用，费用应该不低。我们从使用内存数据库已有近15年历史，随着系统分布式的推进，内存数据库的分布式随之也提上日程。基于目前的技术储备，我们相信我们有能力构建一个符合业务要求的(实时计费系统)、可靠的、商用级别分布式内存数据库——暂且叫她 mdbcluster。
一、目标构想：
mdbcluster应该具备如下功能：
1. 具备一个内存数据库的基本能力。
2. 数据节点容器化
3. 支持数据分片
4. 节点支持水平扩缩容(业务中断)
5. 故障节点快速恢复
6. 数据库操作界面
7. 数据3份拷贝，并且支持分布式数据一致性
8. 节点支持在线扩容
9. 数据库集群管理
10. 数据库集群监控及报表
二、如何实现
1. 找一个开源的单机版内存数据库
我们并不是要从零开始进行开发，重复造车轮并没有什么意义。因此找一个可以驾驭的、简单的、性能不错的单机版内存数据库成为不二之选。我承认这里有很大的风险，如果这一步走错，可能会导致整个项目的失败。FastDB进入我们的视线。
文章图片
先说优点：
a) FastDB是C++写的，相信性能应该很快，初步实验支持20W/S update操作。
b) 支持完整事务及数据库的基本操作，对我们后面进行能力扩展有很大益处。
c) 故障快速恢复的能力，由于打算运行在容器环境上，这点至关重要。
缺点：
a) 更新的时候需要锁库，你没听错，不是行锁，也不是表锁，而是库锁。索性他支持读、写分离，并且性能够好。考虑到将来节点可水平扩容，单节点处理能力有上限也没有太大关系。
b) 支持操作api特殊。并不是通用的SQL，NoSQL，NDBAPI等等。所幸我们在这方面有较丰富的经验，设计一套adapter并不是太难。
c) 暂时还没有想到……
2. 设计总体架构
a) MDBProxy负责与客户端通讯，转发请求消息，处理分片路由。
b) MDBAgent负责数据写入，由于涉及数据多分片的数据一致性，需要在这个节点处理数据的二阶段提交。
c) MDBRNode负责数据的读取操作，可以多进程提高速度。
d) MDBWNode负责数据的写入操作，可以一表一进程，提升性能。
e) 暂未画出分布式的其它节点，待后续更新。
文章图片
3. 接口设计
在想出总体架构后，面临的第一个问题就是数据库接口的设计。数据库通常都有个一连接管理，负责管理所有接入数据库的客户端，并且要支持连接池。考虑到这块的复杂性，我们决定数据库的接口采用http2协议。这样做有几个好处：
a) 我们有现成的http2的客户端、服务端实现方案，减少二次开发。
b) 未来趋势，通用性强，后面数据库除了有C++接口，可能还会有JAVA等语言接口。
c) 经过几年使用，我们发现http2的功能强大，比如tls，server push等功能未来可能用得到。
初步想法：在客户端发送请求时，在URL中应该带上分片的hash值，带上操作的类型（I、U、D、S）。这样MDBProxy就可以借此转发数据，而不用解包。并且包采用JSON格式，因为客户端的数据通常都比较小。JSON格式有利于快速查询。
在服务端回查询包的时候，如果测试性能不差，也考虑用JSON，便于扩展。否则，考虑采用Protocol Buffer，压缩数据，尽可能提高性能。
【如何开发一个分布式内存数据库(一)】
推荐阅读
- 详解BI系统中的任务调度
- 关于开发中的版本问题的一点小建议
- 嵌入式专栏|结合自己经历的一场机器人省赛浅谈如何学习单片机
- Java编程开发|java开发（Class.forName 和 ClassLoader的区别和联系 | 使用场景 | 多方位解析）
- Java编程开发|点击a超链接 下载而不是直接打开
- #|Zookeeper后端开发工具Curator的使用 | Curator对节点的增删改查 | ACL权限控制 | 分布式锁 | 分布式计数器 | 附带最新版本下载
- Java编程开发|Java多线程（synchronized | Volatile 和Lock和ReadWriteLock多方位剖析（一））
- #|Zookeeper 图形化的客户端工具（ZooInspector）| 图形化的监控工具（taoKeeper）的下载和使用 | 后端开发工具Curator的高级应用
- 基于Python编写一个语音合成系统
- HarmonyOS|HarmonyOS开发详解（二）——鸿蒙开发体系详解及入门实例演示运行