分布式存储题目：
分布式存储⼀般都是通过多副本的形式保证数据可靠，多副本之间使⽤⼀致性协议保证数据⼀致，所以⼀般都需要⼀个Leader节点负责协调写⼊，⾼并发场景下是如何避免Leader成为系统的瓶颈，给出设计⽅案
问题分析:
题目描述的情况是Zookeeper的工作模式，Leader协调写入 其本质就是中心化的问题。
所以解决的办法就是 采用去中心化的设计
设计参考：
宏观视角
参考redis cluster 模式 采用了去中心化的设计并且具备以下能力：
1. 可扩展性
- 横向扩展，通过增加机器实现增加能力上限
- 读写扩展，基于主从模式，通过读写角色分离，增强读写能力。
2. 高可用
- 避免单机故障
- 主从模式
3.负载均衡
- 数据分治
- 数据迁移
- 请求智能路由
4. 错误恢复
- 自动主从切换
微观视角
1)数据分治问题
本质就是数据和请求落在哪个节点上，或者说是一个节点都负责哪些数据的问题，即分布式存储，需要通过 数据分区策略（算法）来解决，并且需考虑以下问题：
- 可用性：仅部分不可用
- 维护方便 ：仅针对不可用部分，针对性修复
- 均衡IO，数据和请求均衡到不同的节点中
- 改善查询性能，数据精准定位到节点中
在以下分区算法中，个人比较偏好Redis cluster的虚拟槽分区
1. 范围分区
同一范围内的数据聚集连续，节点跨度小
2. 节点取余分区
实现简单，扩缩容时需迁移的数据量大，整倍扩容时，相对迁移的数据量少
3. 一致性hash
将数据散落在2的32次方个token（槽点更容易理解)，节点随机分配到不同的token，即每个节点管理一定连续范围的token，数据key通过hash得到token后，即可知自己所属的节点
它能够在添加/移除一台缓存服务器的时候，尽可能小的改变已存在key的与节点映射关系，避免大量key的重新映射
服务节点太少时，容易因为节点分部不均匀而造成数据倾斜问题
然后引入虚拟节点的方式来解决数据散落的平衡性问题，增加的这一层跟下边的虚拟槽有异曲同工之处。
即使如此，一致性hash 对数据分布和节点位置的控制依然不够友好
《一切皆是映射：代码的本质》一致性哈希算法(consistent hashing)
一致性hash的一些问题
4. 带有限负载的一致性哈希
因为一致性哈希算法的数据分布不均匀的问题，Google 在 2017 年提出了带有限负载的一致性哈希算法来解决这个问题，带有限负载的一致性哈希算法思想比较简单，给每个存储节点设置了一个存储上限值来控制存储节点添加或移除造成的数据不均匀，当数据按照一致性哈希算法找到相应的存储节点时，要先判断该存储节点是否达到了存储上限;如果已经达到了上限，则需要继续寻找该存储节点顺时针方向之后的节点进行存储
5. 虚拟槽分区
-
通过引入一层（槽），解耦数据和节点的关系
key和槽的映射不变，槽在哪个节点的关系可变，槽成为集群内数据管理和迁移的基本单位，而槽的粒度小、边界清晰，简化了节点扩容和收缩难度，只需要关注数据在哪个槽，并不需要关心数据在哪个节点上。 -
固定映射关系，放大分布空间，数据均匀分布
虚拟槽分区巧妙地使用了哈希空间，使用分散度良好的哈希函数把所有数据映射到一个固定范围的整数集合中，整数定义为槽（slot）。这个范围一般远远大于节点数，Redis Cluster 槽范围是0~16383。采用大范围槽的主要目的是为了方便数据拆分和集群扩展。每个节点会负责一定数量的槽
虚拟槽分区可以说比较好的兼容了数据均匀分布和扩展性的问题。
2)链接管理问题
通过redis虚拟槽分区的实现，基于分治原则每个节点都具备了独立的读写能力，并且管理一部分数据，
那么客户端可以与每个节点独立建立链接，并做池化处理；这就从根本上解决了需要leader单点受限的问题。
3)寻址路由问题
- key-slot的关系是固定的
- slot 和 节点的关系是可变的（分配策略决定），并且由节点管理
那么客户端在得到slot的时候也是不知道这个slot是在哪个节点上的；只有请求到节点后，如果是在当前节点上则直接给出值，如果不在当前节点上，会返回当前slot所在的节点，需要一个重定向的操作。
重定向是高频操作，会带来性能损耗，而且在slot跟节点的关系不变更的情况下这个重定向也是重复的。
数据slot的变更是低频的，如果这个slot和节点的映射关系，能够在向节点发起请求前明确，那么就会避免重定向的问题。
那么通过同步slot和节点的映射关系（拓扑信息），即可实现智能寻址路由。
4) 数据迁移问题
难免会遇到扩缩容的场景，优雅轻便的在线的方式将是我们的诉求。参考redis cluster的方式
- 启动新节点
- 检查是否孤立节点，并加入集群
- 配置数据同步（新从加入）、数据迁移的计划
- 小批量多次的将solt中的数据完成迁移，并通知slot和节点映射的变更
缩容的情况下有额外的节点下线逻辑
特别注意：
数据迁移未完成前，并没有通知slot 和 节点映射的变更，那么智能客户端依然会去原节点访问数据，此时需要另外一种重定向机制告诉客户端，数据正在迁移，新节点在哪里，你去新节点看看，这种机制就优雅的解决了在线迁移并保证了数据一致性；但需注意这是有一定的性能损耗的，能否在系统高负载的时候做需要压测演练。
参考
https://zhuanlan.zhihu.com/p/142840645
【原创】为什么Redis集群有16384个槽
网友评论