8. 标准玩法@集群化

[toc]

背景

之前我们说了主从的小团体模式, 这个模式有一个瓶颈, 就是快照的大小可能是一个麻烦, 如果在海量访问的背景下, Buffer会快速长大, 同时快照也会立刻增大, 那么主从同步就很有可能会出现问题, 此时写就成了这个小团体的瓶颈.

这种情况下, 如果把多个小团体并在一起形成一个大团体, 也就是我们说的集群, 不同的小团体负责不同的范围的key, 那么写入能力还能进一步增强

集群: 沟通

小团体内部的协作方式之前已经说过了, 现在说说集群内各小团体间是如何彼此协作的, 各小团体之间也是去中心化的, 意思就是彼此互相联系, 但是没有一个Master, 同时也没有选举的过程, 这种模式下, 如果其中某一个Master挂了, 第一个发现联系不上它的Master进入PFail(Possibly Fail)模式, 并广播让大家去确认, 一旦过半则直接确认, 强迫这个小团体开始主从切换.

集群: 沟通内容

他们互相联系, 联系什么呢? 每个Master单独开了一个端口16379负责集群内部事务, Master们通过这个端口联络彼此, 内容大致协调出, 谁负责那一个范围的key, 协调出的结果会形成一张配置表, 在客户端连接的时候发送给客户端, 告诉客户端你在写什么key的时候应该找谁(这一步本来是由Proxy负责完成的)

如何找到正确的小团体

这个配置表的生成, 就是一个典型的"一致性哈希问题", 我们知道一致性哈希是针对普通哈希来说的, 我们会先(通过crc32算法)把一个key化成一个整数, 接下来就是一致/普通哈希算法的区别了: 模什么数?

• 模去Master数量, 得到MasterID: 如果现在增加一个Master, 那么之前哈希出的所有结果都会变: 因为一个整数模去5跟模去6得到的结果完全是不一样的, 换句话说, 整个集群内所有缓存全都失效, 别人来找你要的都是你之前没缓存过的, 全部回MySQL临时查, GG

• 模去一个非常大的, 固定的整数: 假设是N, N很大, 那么所有Key模完的结果是[0~N-1], 我们把这0~N-1均匀的映射到ID为0~5所有的Master上, 现在假设减少了一个Master, 我们只要修改一下映射关系, 把原先映射到#5-Master上的Key均匀的分散给0~4号, 这样失效的就只有5号Master上的所有Key了

在Redis-Cluster中, 这个非常大的整数是一万六千多, 所生成的配置表, 也是整数与MasterID之间的映射关系. 计算出[0~16384]的整数, 对着配置表, 找到MasterID, 接下来你就知道找谁了.

如果你找错人了

如果现在客户端已经连上了, 已经拿到配置表了, 但是这个时候Master增加一个, 此时客户端怎么感知到这件事呢? 客户端仍然会去老的那个Master哪儿尝试, 但是此时因为增加了一个新Master, 配置表已经更新, 这个整数现在已经归新的Master了, 老Master会回复你一个MOVED指令, 包含整数, 以及这个整数对应Master的IP, 客户端拿到以后就会更新自己的配置表