(一) MdbCluster分布式内存数据库——基础架构介绍
这个项目是怎么开始的我已经有些记不清楚了，大概是原来的内存数据库很不好用，一次次地让我们踩坑，我又自以为是地觉得可以做一个更好的出来。自从拥有自己的团队以来，我思考最多的总是如何带着团队做出有意义和有价值的产品，而不是将时间浪费在无谓的琐事上面。分布式内存数据库恰是这样一个具有挑战性，又在我们能力可控范围内的项目。于是我和团队的两个小伙伴利用工作的空隙完成了这个产品。
每次当我想从头开始做一个软件产品的时候，都会想起《人月神话》里面的章节。编程的乐趣是什么，是什么让我们愿意付出大量的时间和脑力去完成一个软件产品？
“首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样，成年人喜欢创建事物，特别是自己进行设计。”——每次看到自己孩子在堆沙堡的时候，我都会想起这句话，很庆幸在这个年纪还能拥有这样的快乐。
“整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起，看到它们精妙地运行，得到预先所希望的结果。”——完成的项目越来越复杂，当每次跨过这些难度门槛的时候，也就意味着从此可以驾驭这类等级的产品了。
“程序员，就像诗人一样，几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象，来建造自己的城堡。”——随着产品复杂的提升，设计在我工作中的占比也越来越多，大脑也逐渐习惯这样的工作方式。尽管也还偶尔做一些核心模块的编码，沉浸其中时也能感到时间飞逝。
“数据库”是一个庞大的产品，更何况是分布式内存数据库。设计的时候是如何考虑做减法的？首先，我们用fastdb做基层内存数据库，这不是我们要解决的重点。这方面业界已经很成熟了，包括timesten, altibase等等。其次，在业务层面，我们不需要实现所有数据库的复杂操作，对于内存数据库的使用，为了追求性能，一直推荐进行单表操作的，从而暂时避开了复杂的多表关联问题。最后，我们集中力量解决的是节点分片、节点主备、节点在线扩容缩容、节点故障检测、故障节点恢复、节点状态管理等等分布式的问题。
一、 单体结构
根据最初的设计方案，在实现的时候我们进一步做了减法。
MdbCluster的服务节点：
a）MdbAgent负责业务和控制消息的接入、校验、推送。
b) MdbRWNode负责管理本地内存数据库，数据同步写入内存，异步写入磁盘。
MdbCluster的客户端节点：
a) MdbClient负责与在App的驱动进行同步交互，并通过http2协议与服务端进行通讯。
二、主备结构
在MdbCluster设计之初，打算通过二阶段提交的方式来实现数据一致性。并且设计了复杂的二阶段提交流程，足有三大页的流程图。难点不在于二阶段提交本身，而在于异常发生时，系统如何保证数据不丢失，如何从故障中恢复。虽然看起来设计方案很宏伟，但一点也不优雅，实现起来一定会是个灾难。看到Redis也从低版本的二阶段提交改为高版本的主备模式。我们也修改了最初的设计方案。
Master节点和Slave节点的MdbRWNode通过异步的方式来同步数据。并且通过心跳的方式来检测对端是否异常。
a) 当Slave节点异常时，数据同步中断。在Slave节点恢复时，先从自己的数据库文件中恢复数据，再对接Master节点，对中断过程中的数据进行恢复。
b) 当Master节点异常时，MDB2检测到MDB1故障，将自己转为Master节点，承担业务消息。当MDB1恢复时，先从自己的数据库文件中恢复数据，再对接Master节点，对中断过程中的数据进行恢复。并做为Slave节点继续工作。
c) 在做主备切换时，MdbAgent会对MdbClient进行广播通知。
