一.主从复制
从服务器连接主服务器,发送SYNC命令.主服务器接收到SYNC命令后,执行命令生成RDB文件并使用缓冲区记录此后执行的所有写命令.主服务器执行完后,向所有的从服务器发送快照文件,并在发送期间继续记录被执行的写命令.从服务器收到快照文件后丢弃所有的旧数据,载入收到的快照.主服务器快照发送完毕后开始向从服务器发送缓冲区的写命令.
从服务器完成对快照的载入,开始接收请求命令,并执行来自主服务器缓冲区的写命令.主服务器每执行一个写命令就会向从服务器发送相同的写命令.
优点:支持主从复制,主机自动将数据同步到从机,可以进行读写分离.
缺点:Redis不具备自动容错和恢复功能,主机从机的宕机都会导致前端部分读写请求失败,需要等待机器重启或者手动切换到前端IP才能恢复.
二.主从如何做到故障自动切换？
主节点挂了 ，从节点是无法自动升级为主节点的，这个过程需要人工处理，在此期间 Redis 无法对外提供写操作。此时，Redis 哨兵机制就登场了，哨兵在发现主节点出现故障时，由哨兵自动完成故障发现和故障转移，并通知给应用方，从而实现高可用性。
Redis 在 2.8 版本以后提供的哨兵（Sentinel）机制，它的作用是实现主从节点故障转移。它会监测主节点是否存活，如果发现主节点挂了，它就会选举一个从节点切换为主节点，并且把新主节点的相关信息通知给从节点和客户端。
哨兵一般是以集群的方式部署，至少需要 3 个哨兵节点，哨兵集群主要负责三件事情：监控、选主、通知。哨兵节点通过 Redis 的发布者/订阅者机制，哨兵之间可以相互感知，相互连接，然后组成哨兵集群，同时哨兵又通过 INFO 命令，在主节点里获得了所有从节点连接信息，于是就能和从节点建立连接，并进行监控了。
三.哨兵机制
每个哨兵以每秒钟一次的频率向整个集群中的主服务器,从服务器及进程发送ping命令.如果一个实例距离最后一次有效回复ping,命令的时间超过指定值.这个实例会被哨兵标记为主观下线.如果一个主服务器被标记为主观下线,则哨兵进程以每秒一次的频率确认主服务器的确进入了主观下线状态.当有足够数量的哨兵在指定时间内确认主服务器进入了主观下线状态.则主服务器会被标记为客观下线.若没有足够数量的哨兵同意主服务器下线,主服务器客观下线的状态就会被移除.当主服务器向哨兵发送PING命令得到有效回复,主服务器主管下线状态就会被移除.
优点:哨兵模式是基于主从模式的,所有主从的优点,哨兵模式都具有.主从可以自动切换,系统更加健壮,可用性更高.
缺点:redis较难支持在线扩容,在集群容量达到上限时在线扩容会变得很复杂.
四.数据库和缓存如何保证一致性？
在更新数据库的同时,调用删除缓存数据.这么做或有耦合过高及调用失败的情况.可以使用「消息队列来重试缓存的删除」，或者「订阅 MySQL binlog 再操作缓存」，这两种方法有一个共同的特点，都是采用异步操作缓存。
五.为什么要出现集群?
redis的哨兵模式基本已经实现高可用,读写分离,但这种模式下每台redis都存储相同的数据,很浪费内存.redis集群实现分布式存储,每台redis节点上存储不同的内容.redis集群采用无中心结构:所有节点彼此互连PING-PONG机制,内部使用二进制协议优化传输速度和带宽.节点fail是通过集群中超过半数的节点检测失效时才生效.
