资源下载：redis_5.0.14
一、主从复制
redis单节点虽然有通过RDB和AOF持久化机制能将数据持久化到硬盘上，但数据是存储在一台服务器上的，如果服务器出现硬盘故障等问题，会导致数据不可用，而且读写无法分离，读写都在同一台服务器上，请求量大时会出现I/O瓶颈。
为了避免单点故障 和 读写不分离，Redis 提供了复制（replication）功能实现master数据库中的数据更新后，会自动将更新的数据同步到其他slave数据库上。
下载安装文件后解压，修改配置文件( redis.windows.conf)的端口； 
启动redis实例
redis-server.exe redis.windows.conf
查看实例当前信息(使用命令行或者桌面应用):
#启动客户度命令 redis-cli.exe -p 6001 #可视化工具参考文章 https://blog.csdn.net/qq_29752857/article/details/113876463
info replication
实现方式：
在客户端直接输入或配置文件添加replicaof 主节点IP 端口
replicaof 127.0.0.1 6001
输入命令后查看信息：
修改配置文件启动：
在主节点添加数据，观察从节点数据变化。
从节点变主节点：
replicaof no one
主从模式优缺点
- 优点: 主从结构具有读写分离，提高效率、数据备份，提供多个副本等优点。
- 不足: 最大的不足就是主从模式不具备自动容错和恢复功能，主节点故障，集群则无法进行工作，可用性比较低，从节点升主节点需要人工手动干预。
二、哨兵模式
第一种主从同步/复制的模式，当主服务器宕机后，需要手动把一台从服务器切换为主服务器，这就需要人工干预，费事费力，还会造成一段时间内服务不可用，这时候就需要哨兵模式登场了。
哨兵模式是从Redis的2.6版本开始提供的，但是当时这个版本的模式是不稳定的，直到Redis的2.8版本以后，这个哨兵模式才稳定下来。
哨兵模式核心还是主从复制，只不过在相对于主从模式在主节点宕机导致不可写的情况下，多了一个竞选机制：从所有的从节点竞选出新的主节点。竞选机制的实现，是依赖于在系统中启动一个sentinel进程。
#哨兵模式配置文件： sentinel monitor master 127.0.0.1 6001 1 #启动命令： redis-server.exe redis.windows.conf --sentinel
启动后的哨兵客户端日志： 
当主节点关掉之后，重新选举，切换主节点：
哨兵客户度： 
1.优点
- 哨兵模式是基于主从模式的，解决可主从模式中master故障不可以自动切换故障的问题。
2.不足-问题
- 是一种中心化的集群实现方案：始终只有一个Redis主机来接收和处理写请求，写操作受单机瓶颈影响。
- 集群里所有节点保存的都是全量数据，浪费内存空间，没有真正实现分布式存储。数据量过大时，主从同步严重影响master的性能。
- Redis主机宕机后，哨兵模式正在投票选举的情况之外，因为投票选举结束之前，谁也不知道主机和从机是谁，此时Redis也会开启保护机制，禁止写操作，直到选举出了新的Redis主机。
三、集群
因为单机的内存容量最大就那么多，已经没办法再继续扩展了，但是现在又需要存储更多的内容，这时我们就可以让N台机器上的Redis来分别存储各个部分的数据（每个Redis可以存储1/N的数据量），这样就实现了容量的横向扩展。同时每台Redis还可以配一个从节点，这样就可以更好地保证数据的安全性。
一个Redis集群包含16384个插槽，集群中的每个Redis 实例负责维护一部分插槽以及插槽所映射的键值数据。
实际上，插槽就是键的Hash计算后的一个结果，注意这里出现了计算机网络中的CRC循环冗余校验，这里采用CRC16，能得到16个bit位的数据，也就是说算出来之后结果是0-65535之间，再进行取模，得到最终结果：
Redis key的路由计算公式：slot = CRC16（key） % 16384
结果的值是多少，就应该存放到对应维护的Redis下，比如Redis节点1负责0-25565的插槽，而这时客户端插入了一个新的数据a=10，a在Hash计算后结果为666，那么a就应该存放到1号Redis节点中。简而言之，本质上就是通过哈希算法将插入的数据分摊到各个节点的。
#redis实例配置文件开启集群 cluster-enabled yes
#redis实例配置文件开启集群 cluster-enabled yes
