(一) MdbCluster分布式内存数据库——基础架构介绍

时间:2023-02-10 17:06:36
(一) MdbCluster分布式内存数据库——基础架构介绍
 
  这个项目是怎么开始的我已经有些记不清楚了,大概是原来的内存数据库很不好用,一次次地让我们踩坑,我又自以为是地觉得可以做一个更好的出来。自从拥有自己的团队以来,我思考最多的总是如何带着团队做出有意义和有价值的产品,而不是将时间浪费在无谓的琐事上面。分布式内存数据库恰是这样一个具有挑战性,又在我们能力可控范围内的项目。于是我和团队的两个小伙伴利用工作的空隙完成了这个产品。
 
  每次当我想从头开始做一个软件产品的时候,都会想起《人月神话》里面的章节。编程的乐趣是什么,是什么让我们愿意付出大量的时间和脑力去完成一个软件产品?
  “首先是一种创建事物的纯粹快乐。如同小孩在玩泥巴时感到愉快一样,成年人喜欢创建事物,特别是自己进行设计。”——每次看到自己孩子在堆沙堡的时候,我都会想起这句话,很庆幸在这个年纪还能拥有这样的快乐。
  “整个过程体现出魔术般的力量——将相互啮合的零部件组装在一起,看到它们精妙地运行,得到预先所希望的结果。”——完成的项目越来越复杂,当每次跨过这些难度门槛的时候,也就意味着从此可以驾驭这类等级的产品了。
  “程序员,就像诗人一样,几乎仅仅工作在单纯的思考中。程序员凭空地运用自己的想象,来建造自己的城堡。”——随着产品复杂的提升,设计在我工作中的占比也越来越多,大脑也逐渐习惯这样的工作方式。尽管也还偶尔做一些核心模块的编码,沉浸其中时也能感到时间飞逝。
 
  “数据库”是一个庞大的产品,更何况是分布式内存数据库。设计的时候是如何考虑做减法的?首先,我们用fastdb做基层内存数据库,这不是我们要解决的重点。这方面业界已经很成熟了,包括timesten, altibase等等。其次,在业务层面,我们不需要实现所有数据库的复杂操作,对于内存数据库的使用,为了追求性能,一直推荐进行单表操作的,从而暂时避开了复杂的多表关联问题。最后,我们集中力量解决的是节点分片、节点主备、节点在线扩容缩容、节点故障检测、故障节点恢复、节点状态管理等等分布式的问题。
 
  一、 单体结构
 
  (一) MdbCluster分布式内存数据库——基础架构介绍

 

  根据最初的设计方案,在实现的时候我们进一步做了减法。

  MdbCluster的服务节点:

  a)MdbAgent负责业务和控制消息的接入、校验、推送。

    b)  MdbRWNode负责管理本地内存数据库,数据同步写入内存,异步写入磁盘。

    MdbCluster的客户端节点:

    a)  MdbClient负责与在App的驱动进行同步交互,并通过http2协议与服务端进行通讯。

 

  二、主备结构

 

  在MdbCluster设计之初,打算通过二阶段提交的方式来实现数据一致性。并且设计了复杂的二阶段提交流程,足有三大页的流程图。难点不在于二阶段提交本身,而在于异常发生时,系统如何保证数据不丢失,如何从故障中恢复。虽然看起来设计方案很宏伟,但一点也不优雅,实现起来一定会是个灾难。看到Redis也从低版本的二阶段提交改为高版本的主备模式。我们也修改了最初的设计方案。

(一) MdbCluster分布式内存数据库——基础架构介绍

 

 

 

  Master节点和Slave节点的MdbRWNode通过异步的方式来同步数据。并且通过心跳的方式来检测对端是否异常。

   a) 当Slave节点异常时,数据同步中断。在Slave节点恢复时,先从自己的数据库文件中恢复数据,再对接Master节点,对中断过程中的数据进行恢复。

   b) 当Master节点异常时,MDB2检测到MDB1故障,将自己转为Master节点,承担业务消息。当MDB1恢复时,先从自己的数据库文件中恢复数据,再对接Master节点,对中断过程中的数据进行恢复。并做为Slave节点继续工作。

   c) 在做主备切换时,MdbAgent会对MdbClient进行广播通知。