关于redis主从架构重新选举master带来的问题
redis嘛，主要问题就是关乎数据的问题；分布式嘛，主要问题就是C（一致性）A（可用性）P（分区容错性）。
在这里考虑两个问题：数据不一致，数据丢失。
数据不一致：
有时候master会挂那么十几秒钟或者几秒钟然后又恢复正常，然后redis的调用者就觉得redis的master是没问题的，他就接着使用这玩意，但是哨兵在这段时间内已经把这个master淘汰出去，不但如此还选了一个新的master供redis集群内部共享数据。这样子就带来了一个问题，新的master会很自以为是的同步它的数据给他的slave，但是redis的调用者并不向这个新的master发送任何数据，也就是他的数据压根就不更新，导致他的slave数据也无法更新，最后实际对外提供服务的是那个被哨兵淘汰的master。
这就是传说中的redis脑裂倘若集群部署的相对完善的话，新选举的master还应向被哨兵淘汰的master同步数据，并且将被哨兵淘汰的master置为新master的一个slave，那就更有意思了，master在被淘汰之前还在工作，也就是还在接收数据并且试图将数据写入自己的缓存中，直到新的master开始向它同步数据，为了同步数据，旧的master会将自己的数据同步成新的master一样，带来的问题就是旧的master数据丢失。当主从节点间数据同步时间间隔设置的比较久的话就会使问题变得很严重。但是显而易见的，像这样的数据丢失问题是没有办法避免，只能减小数据同步时间间隔，以求减小数据丢失的数据量。
脑裂：
解决方法：
min-slaves-to-write 1
min-slaves-max-lag 10
说明：