【背景】
XXX服务，前后使用了两个redis cluster集群：集群A（2018.1.23前使用，在1.23之后没有流量，但是服务没停），集群B（2018.1.23后使用）。
【原因】
根本原因：两个集群使用相同的实例，导致两个集群的拓扑信息互相伤害拓扑乱掉
诱因：老集群下线流程有误，服务未停，却把记录服务实例信息的db数据删除了
恢复缓慢原因：缺少处理cluster的工具&经验，临时写脚本处理
【过程】
1、给集群B增加新的redis实例（其中选出了和集群A相同的ip和port）
2、启动集群B的新实例失败，发现和集群B的某个实例相同的ip和port
3、停掉集群A的具有相同ip和port的实例，集群A的相应实例起来（目前集群B还未将该实例加入自己集群，该实例目前与集群A的其他实例通信）
4、对集群B操作同步拓扑信息（将上诉实例加入了集群B，上诉实例与集群B中的其他实例相互交换拓扑信息）
5、集群B中的主都把自己作为了集群A中实例的从，开始主从同步，集群崩溃
【处理过程】
1、停掉集群A的所有实例
2、强制提升集群B中的相应实例为主（cluster failover takeover -> 将某个从强制提升为主且不与其他实例通信）
3、修复拓扑状态，检查slot分配，给没有分配master的slot分配master（cluster setslot <slot> node <node-id> -> 发给每个主分配slot信息）
4、给缺少slave的master挂上slave（cluster replicate ip port）
【改进方案】
1、完善集群下线流程：1）避免删除集群基本信息；2）下线集群时停掉服务（停服务发现、检查流量、停服务、注销systemd）
2、针对cluster的拓扑修复，提供工具：1）集群拓扑比较工具，找出拓扑不一致的实例；2）批量将实例踢出集群；3）批量提升实例为主？？
【思考】
对于redis cluster这种无中心的架构来说，如果拓扑信息不一致了，如何修复信息确实是挺麻烦的。想到好的方式后，后续补充。