这是我参与2022首次更文挑战的第25天，活动详情查看：2022首次更文挑战
分区再平衡
随着时间的变化，数据库的存储情况可能会发生一些变化
- 查询压力增加
- 数据量增加
- 节点失效
以上的过程都涉及到节点流量的再分配，这个过程被称为分区再平衡，在这个过程中需要满足以下条件：
- 平衡后数据分布更加均匀
- 平衡过程中，集群依旧向外提供正常服务
- 整个过程要快，同时避免更多的网络带宽与磁盘I/O的消耗
动态再平衡策略
不好的策略：取模
取模之后，随着底数N的变化，大量的数据需要进行迁移，增加了数据迁移的成本
固定数量的分区
在初始设置远超实际节点数的分区数，当出现新增节点或者分区再分配的时候，直接使用分区迁移即可
-
数据与分区的映射关系不会改变
-
在分区进行迁移的过程中，旧的分区可以支持服务
-
在实际过程中，可以支持分区的合并与拆解\
-
- 但是固定数量的分区操作会更加简单
动态分区
当分区的数据超过设置的阈值的时候就会进行分区的拆解，如果小于某个阈值就会进行分区的合并
- 一个分区总是分配给一个节点
- 一个节点可以拥有多个分区
- 依赖底层的HDFS分布式文件系统进行分区文件的传输
需要注意的是：
-
分区一开始是没有数据的，这意味着在一开始的时候，可能只有一个分区，而这个分区只在一个节点上\
-
- 在后续数据库支持了预分区
按节点比例进行分区
分区数与节点数成正比，每一个节点拥有的分区数是固定的，节点数据增长的时候，分区数据也是成比例的数据增长
- 新节点加入的时候，会从已有节点中进行分裂，拿走一半的数据量
请求路由
当客户进行数据请求的时候，如何知道应该连接哪一个节点，这个就属于服务发现问题了
几种结局策略：
- 循环式处理：当前节点没有该分区的时候，继续转发给下一个分区，接受下一个节点发过来的答复并且将答复返回给客户端
- 路由层：起到类似代理的作用，有中间层来起到一个节点选择与转发的作用
- 客户端感知：客户端来直接感知与分配节点
实际上三者的逻辑是类似的，不同的地方只是在于谁来进行路由的决策
- 可以通过zookeeper来维护节点分区的映射关系，路由决策者可以通过订阅zookeeper的方式来或其对应的变动信息
- 也有节点之间同步集群的状态变化，请求可以发给任何节点，有该节点根据集群状态进行转发，减少对外部组件的依赖
