修改Python脚本，每隔1s写入一条数据，目的是便于观察在主节点宕机，集群自动故障转移这个时间段之之内（1s钟左右），对于应用程序的影响，或者说应用程序在自动故障转移前后的表现。
如下脚本循环往Redis集群中写入数据，执行期间，强制杀掉一个主节点，观察应用程序连接情况。
同时，如果发生异常，暂停应用程序2s，因为上面一开始配置的集群故障转移时间是1s，如果应用程序暂停2s，完全可以跳过故障转移的过程，
当故障转移完成之后，应用程序又恢复成正常状态，虽然8001节点宕机，应用程序继续连接8001节点，但是应用程序完全无感知。
import time from time import ctime,sleep from rediscluster import StrictRedisCluster startup_nodes = [ {"host":"111.231.253.***", "port":8001}, {"host":"111.231.253.***", "port":8002}, {"host":"111.231.253.***", "port":8003}, {"host":"111.231.253.***", "port":8004}, {"host":"111.231.253.***", "port":8005}, {"host":"111.231.253.***", "port":8006} ] redis_conn= StrictRedisCluster(startup_nodes=startup_nodes, decode_responses=True,password="root") for i in range(0, 100000): try: redis_conn.set('name' + str(i), str(i)) print('setting name' + str(i) +"--->" + time.strftime('%Y-%m-%d %H:%M:%S',time.localtime(time.time()))) time.sleep(1) except: print("connect to redis cluster error") time.sleep(2)
发现在杀掉主节点之后，仅发生了一次连接错误，随后因为Redis集群的自动故障转移成功，对应于程序来说是透明的，因此应用程序随后正常工作，不受其中一个主节点宕机的影响。
集群此时的状态，8001节点宕机，明显，8001对应的从节点8004接管主节点，升级为master，对外提供服务
观察升级为主节点的8004实例日志，会发现在强制杀掉原8001主节点之后，1秒钟之内，成功替代8001升级为master节点
如果在故障转移的过程中，没有应用程序访问Redis，应用程序甚至完全不知道Redis集群发生了故障转移，只要不发生集群中某一个节点的主从节点同时宕机，整个集群就没有问题，且对应用程序完全透明。
随后重启宕机的8001节点，会发现8001节点自动变为其原从节点（8004）的从节点
整体上来看，Redis集群的配置和使用以及自动故障转移还是比较简单易容的，这里没有用redis-trib.rb 而是采用手动分配slot和创建集群的方式，目的是了解完整的配置流程。
需要注意的是：
1，如果开启了密码验证模式，所有的主从节点必须配置masterauth，因为某一个节点宕机重启之后，会自动变为从节点，此时如果想要从master复制数据，就必须需要主节点的密码
2，StrictRedisCluster决定了所有主从节点的密码必须要是一样的。
表面上看Redis集群简单易用，自动故障转移是没有问题的，保证了高可用，看似没有问题。
如果细想，这个过程还是有问题的，有没有发现，虽然故障转移保证了高可用，但是当从节点升级为主节点之后，如果保证升级为主节点的从节点（8004）一定能够完全复制原主节点（8001）上的数据？