redis 模式对比
master-slave模式：
主从模式单纯的讲就是多个实例，可以是一主多从也可以是多主多从，主从模式的作用就是备份数据，数据层面的容灾，这样当一个master节点数据丢失的时候（硬件损坏），可以依据slave的数据恢复，
1.另外一个作用就是做读写分离所有读操作都会访问slave节点，减轻master节点的负载。 默认情况下master节点可以进行读和写，slave节点只能进行读操作，写操作被禁止
2.另外不要修改配置让slave节点支持写操作，没有意义，原因一，写入的数据不会被同步到其他节点；原因二，当master节点修改同一条数据后，slave节点的数据会被覆盖掉。
3.slave节点挂了不影响其他slave节点的读和master节点的读和写，重新启动后会将数据从master节点同步过来。
该种模式下，master节点挂了以后，slave不会竞选成为master。需要手动修改slaveof NO ONE
哨兵模式（sentinel）：
1.sentinel模式是建立在主从模式的基础上，如果只有一个Redis节点，sentinel就没有任何意义。
2.当master节点挂了以后，sentinel会在slave中选择一个做为master，并修改它们的配置文件，其他slave的配置文件也会被修改，比如slaveof属性会指向新的master。
3.当master节点重新启动后，它将不再是master，而是作为slave接收新的master节点的同步数据
4.sentinel因为也是一个进程有挂掉的可能，所以sentinel也会启动多个形成一个sentinel集群。
5.当主从模式配置密码时，sentinel也会同步将配置信息修改到配置文件中，不需要担心。
6.一个sentinel或sentinel集群可以管理多个主从Redis。
7.sentinel最好不要和Redis部署在同一台机器，不然Redis的服务器挂了以后，sentinel也挂了。
8.sentinel监控的Redis集群都会定义一个master名字，这个名字代表Redis集群的master Redis。
当使用sentinel模式的时候，客户端就不要直接连接Redis，而是连接sentinel的ip和port，由sentinel来提供具体的可提供服务的Redis实现，这样当master节点挂掉以后，sentinel就会感知并将新的master节点提供给使用者。
Sentinel本身也支持集群，只使用单个sentinel进程来监控redis集群是不可靠的，当sentinel进程宕掉后，sentinel本身也有单点问题。所以有必要将sentinel集群，这样有几个好处：
1.如果只有一个sentinel进程，如果这个进程运行出错，或者是网络堵塞，那么将无法实现redis集群的主备切换（单点问题）。
2.如果有多个sentinel，redis的客户端可以随意地连接任意一个sentinel来获得关于redis集群中的信息。
3.sentinel集群自身也需要多数机制，也就是2个sentinel进程时，挂掉一个另一个就不可用了。
4.当有足够数量的 Sentinel（哨兵）进程（大于等于配置文件指定的值）在指定的时间范围内确认Master主服务器进入了主观下线状态（SDOWN）， 则Master主服务器会被标记为客观下线（ODOWN）。
Sentinel模式下有个缺陷是slave节点保存的数据都是完整的，也就是说matser收到的数据会并发同步到每个slave里，这样导致占用了大量内存。
redis cluster模式：
官方推荐模式 使用hash slot方式 将16348个hash slot 覆盖到所有节点上 对于存储的每个key值 使用CRC16(KEY)&16348=slot 得到他对应的hash slot 并在访问key时就去找他的hash slot在哪一个节点上 然后由当前访问节点从实际被分配了这个hash slot的节点去取数据 节点之间使用轻量协议通信 减少带宽占用 性能很高 自动实现负载均衡与高可用 自动实现failover 并且支持动态扩展 官方已经玩到可以1000个节点 实现的复杂度低 总之个人比较喜欢这个架构 因为他的去中心化思想免去了proxy的消耗 是全新的思路
kubernetes redis cluster搭建：
git clone https://github.com/yingjianjian/docker
cd kubernetes-redis-statefulset
docker build -t [email protected]/redis-4.0.1 .
详细见README.md
