集群实现原理
架构释义：
- 整个部署形态遵从Redis Cluster集群拓扑并引入Predixy作为集群的代理层
- Redis Cluster的group对应一个statfulset，比如XX-0，那么group中的主备将名为XX-0-0和XX-0-1，而在CR对象中的status会动态记录对应group对应的槽位
- Redis实例的底层存储是可选的，结合storageclass可以接入本地盘（empty dir）或者ceph（pvc）等
- 每个Redis Pod具备sidecar exporter镜像，可以流畅接入prometheus
Redis Cluster CRD定义示例
集群的组织过程完全有Operator负责，整个流程是将运维部署过程编码化
以下是几个关键步骤：
- 前台服务通过用户键入的存储大小计算group数量以及单节点的maxmemroy
- 根据group数量创建sts的过程中，会等待所有（group数量*2）的Redis Pod正常提供服务后，此时Pod均是独立且不存在角色，此时调用cluster创建API命令组织X-N-0成为集群
- X-N-1作为slave分别加入集群中对应的group中
集群扩容是个复杂的过程一方面扩容分为横向扩容和纵向扩容，另一方面作为在线扩容如何对线上的影响最小化也是需要考虑的
1. 纵向扩容
- 纵向扩容对在线服务影响是最小的，只有存储需求大小未超过当前group数量*32G（单节点存储上限）即实施纵向扩容
- 只要被Opertor识别为纵向扩容需求，那么计算好单节点新容量，将通过config set和configmap更新持久化
2. 横向扩容
- 当存储寻求超过当前group数量*32G，那么将进入横向扩容逻辑
- 计算好需要新增的group数量，创建对应的statefulset，并依次加入集群后,通过Rebalance来达到数据均衡
- 数据平衡好后新的slot信息将会被记录到CR对象的status中
存在的问题：存在同步延迟时，会出现版本丢失高/数据交替性变化
- 比如US同一条记录变更了10个版本，而且很快同步到了HZ，而HZ因为同步数据大，同步延迟，后续单向回环中将10个版本又在US进行了一次重放，导致出现数据交替
- 比如HZ同一条记录变更了10个版本，而且很快同步到了US，而US因为同步延迟，将一个比较早的版本同步到了HZ，后续通过单向回环，将此记录重放到了US，导致之前HZ到US的10个版本丢失.
解决方案：
- 反查数据库同步 (以数据库最新版本同步，解决交替性，比如设置一致性反查数据库延迟阀值为60秒，即当同步过程中发现数据延迟超过了60秒，就会基于PK反查一次数据库，拿到当前最新值进行同步，减少交替性的问题)
- 字段同步 (降低冲突概率)
- 同步效率 (同步越快越好，降低双写导致版本丢失概率，不需要构建冲突数据KV表)
- 同步全局控制 (比如HZ->US和US->HZ一定要一起启动，一起关闭，保证不会出现一边数据一直覆盖另一边，造成比较多的版本丢失)
同步全局控制方案：(分布式Permit)
注意：A,B,C三点状态都正常才允许进行同步(解决数据单向覆盖)。 任何一边的canal不正常工作，都应该停掉整个双向同步，及时性越高越好。
算法描述：
1. 首先定义两个时间概念
- 数据变更时间A ：代表业务数据在A地数据库中产生的时间，即图中的时间A
- 数据同步时间B：代表数据变更载入到B地数据库的时间，即图中的时间B
2. 针对每条或者一批数据都记录变更时间A和同步时间B，同时保留历史同步过的数据记录
3. 图中纵轴为时间轴，Aa代表从数据库A同步到数据库B的一个同步过程，Ba代表从数据库B到同步到的数据库A的一个同步过程,每个同步过程在纵轴上会有两个点，分别代表变更时间A和同步时间B.
4. 根据同一时间的定义，在两边数据库的各自同步过程中，以数据库A为例，在数据库B的同步过程找到与Aa有时间交集的批次，比如这里就是Aa 与 (Ba , Bb , Bc)有时间交集
5. 针对步骤４中的批次，根据同一数据的定义，在交集的每个批次中，比如首先拿Aa和Ba的历史同步数据记录，根据同一数据定义进行查找，然后再是Aa和Bb，依次类推。
6. 针对步骤５中找到的同一数据，最后确定为需要进行单向回环的一致性算法的数据。
此方案相比于单向回环方案：减少单向回环同步的数据量，解决A和B地数据对等的case，不过目前开源版本暂未实现。