单机、单点、单实例缺点：
1.单点故障 2.容量有限 3. 压力
强一致性
主从复制、读写分离会带来数据一致性问题
1.通过强一致性来解决，即主redis 进行阻塞，直到从redis写成功。
弱一致性
强一致性带来阻塞问题，可能会等待很久
1.通过异步方式解决强一致性问题，但是会丢失一部分数据
最终数据一致性
弱一致性会带来数据丢失问题
1.通过类似kafka 可靠集群来保证最终数据一致性
Redis使用默认的异步复制，其特点是低延迟和高性能
在使用 Redis 复制功能时的设置中，强烈建议在 master 和在 slave 中启用持久化
任何时候数据安全性都是很重要的，所以如果 master 使用复制功能的同时未配置持久化，那么自动重启进程这项应该被禁用
多实例redis
复制redis文件夹，修改redis.windows.conf 文件，修改6379端口，注释掉 bind 127.0.0.1（也可以不注释）
打开cmd，定位到当前实例目录，输入redis-server redis.windows.conf
打开redis-cli ，开始进行主从设置。
打开cmd ，输入 redis-cli -h 127.0.0.1 -p 6380 或者 redis-cli -p 6380
6379 主，6380、6381为从
在6380、6381 redis-cli输入 slaveof localhost 6379 (老版本，新版本 REPLICAOF localhost 6379)
主可以写，但从只能读
数据同步
停掉6380，然后向主服务器中添加key，再启动6380，启动的时候使用从主服务器进行复制
redis-server redis.windows.conf --replicaof localhost 6379 或 redis-server redis.windows.conf --slaveof localhost 6379
停止追随 replicaof no one 或 slaveof no one
即当主库挂掉后，手动切换一台从库为主库，同步其余从库重新追随。
slave-serve-stale-data yes 从库数据同步过程中是否支持查询，yes 支持一边同步一边查询，no 只有跟主redis同步完才支持查询
slave-read-only yes 从库是否只读
repl-diskless-sync no 是否使用磁盘方式传输数据，yes为使用网络。使用网络则直接使用网络传输。
repl-backlog-size 1mb 积压数据大小。redis主库会维护一个队列，当从库挂掉一段时间再恢复的时候，如果修改的数据大小大于设置的值，就使用rdb进行恢复。否则使用维护的队列中的数据。
Redis 的 Sentinel（哨兵）
自动选举master 机制
新建配置文件，
port 6385
sentinel monitor mymaster 127.0.0.1 6379 2启动哨兵 redis-server redis.windows-sentinel.conf --sentinel
会显示出所有的 slave 从库
哨兵原理，消息的发布订阅
主从复制，故障转移数据一致性问题
当主库挂掉时，其它从库又没有写的能力，那是怎么保持数据一致性的呢
min-slaves-to-write <slave 数量> Redis slave 每秒钟都会 ping master，确认已处理的复制流的数量
min-slaves-max-lag <秒数> Redis master 会记得上一次从每个 slave 都收到 ping 的时间。用户可以配置一个最小的 slave 数量，使得它滞后 <= 最大秒数
如果条件不满足，master 将会回复一个 error 并且写入将不被接受。这时候哨兵会重新选出master 库，进行写入以及主从同步，最大程度保证数据丢失的比较少
