(二) MdbCluster分布式内存数据库——分布式架构1
分布式架构是MdbCluster的核心关键,业界有很多相关的实现,却很少有文章详细的解释每个架构实现背后的细节和这么做的原因。在MdbCluster整个研发和测试的过程中,我们不断的遇到各种各样的问题,分析问题的原因,修改相应的设计和实现,再回归测试。很多在设计的时候一些颇为得意的trick,却造成测试时整个系统运行的灾难。无数次的推到重来警醒我们——在没有详细的测试数据支撑的情况下,不要在设计阶段以增加系统复杂度为代价来进行某些想象的优化。虽然我们一直知道这是一条真理,但总有忍不住、自作聪明的时候。现实总能一次次地将我们拉回原地——Keep it simple,stupid! 本文试图总结这一年来我们交的经验税,来详细阐述那些看似简单架构设计背后的复杂细节。
接我们上一章单节点的架构图,两个节点的架构图如下:
。
MdbClient与每个节点的MdbAgent建立连接,但只与Master节点进行业务通讯。这个架构本身很简单,几乎可以从1-N无限复制,是一个完全的分布式架构,无单点故障。下面我们通过假设读者的问题,来一步步的介绍整个架构。
1. 数据是根据什么策略
来进行分片的?
2. 整个业务的交互流程是怎么样的?
3. 当某个节点状态和数量发生变化时,其它节点如何感知?
4. 扩容和缩容时,分片是如何调整的?
5. 业务消息是如何校验、错误消息如何重定向、超时消息如何处理?
1、 数据是根据什么策略来进行分片的?
关于MdbCluster的Sharding策略,我们直接采用了Redis的策略。Redis Cluster 采用虚拟哈希槽分区,所有的键根据哈希函数映射到 0 ~ 16383 整数槽内,计算公式:slot = CRC16(key) & 16383。每一个节点负责维护一部分槽以及槽所映射的键值数据。
从我们项目实际使用过程,来说说这个分片规则的好处。
1. 通过 keys -> slot -> node的映射关系,解决了从表的partitionid到Mdbcluster分片nodeid的对应关系。
2. 为什么不是keys->node直接映射?在扩容和缩容的过程中,这种解耦将带来迁移的便利。利用上图举个简单例子,如果要将节点从5个扩到10个的时候,上述分片策略,只要将node1的slot(1638-3276)挪到node6。node2的slot(4914-6553)挪到node7。依此类推……只要进行5次节点间的数据迁移。但如果是直接映射,分片策略从keys%5->node 转为 keys%10->node,就会面临node1->(node2, 3, 4, 5, 6, 7, 8, 9,10)都要挪数据的场景,总共需要迁移的次数为9*5=45。反之,缩容也一样。
3. 为什么slot的数量是16384? 2的14次方。网上有很多说法,但我们的经验是:在扩缩容做数据迁移的时候,需要对这个slot的数据进行加锁。如果slot数量太少,锁定的数据量太大,从而造成迁移过程中业务请求失败太多。如果slot数量太多,迁移的批次过多,每次迁移的数据条数太少,造成迁移性能受影响。所以这个数字的大小其实是跟业务每张表的数据量有直接关系的。
2、整个业务的交互流程是怎么样的?
有两点需要特别说明,第一是App的驱动到MdbClient是同步请求,有超时管理。这样做的好处是简化业务逻辑。其它的环节均为异步消息,为了最大化的提高性能。第二是MdbClient到MdbAgent之间具备消息重定向的能力。这样做的好处是,在扩缩容的时候,可以减少App侧返回错误消息的数量.
。
最后此篇关于(二)MdbCluster分布式内存数据库——分布式架构1的文章就讲到这里了,如果你想了解更多关于(二)MdbCluster分布式内存数据库——分布式架构1的内容请搜索CFSDN的文章或继续浏览相关文章,希望大家以后支持我的博客! 。
我是一名优秀的程序员,十分优秀!