- 基于Redis集群解决单机Redis存在的问题，在之前学Redis一直都是单节点部署
单机或单节点Redis存在的四大问题：
- 数据丢失问题：Redis是内存存储，服务重启可能会丢失数据 => 利用Redis数据持久化的功能将数据写入磁盘
- 并发能力问题：单节点Redis并发能力虽然不错，但也无法满足如618这样的高并发场景 => 搭建一主多从集群，实现读写分离
- 单点故障 - 故障恢复问题：如果Redis宕机，则服务不可用，需要一种自动的故障恢复手段 => 利用Redis哨兵，实现健康检测和自动故障恢复
- 存储能力问题：Redis基于内存存储，单节点能存储的数据量难以满足海量数据要求 => 搭建分片集群，利用插槽机制实现动态扩容，从理论上来讲，它的存储能力是没有上限的
1. Redis主从
- 搭建主从架构
- 主从数据同步原理
单节点Redis的并发能力是有上限的，要进一步提高Redis的并发能力，就需要搭建主从集群，实现读写分离。
1.1.主从集群结构
- Redis的集群往往都是主从集群，它往往会有一个Master主节点，多个Slave / Replica从节点。
下图就是一个简单的Redis主从集群结构：
如图所示，集群中有一个Master主节点、两个Slave从节点（现在叫Replica） => 起码要包含三个节点，要有三个Redis实例，一主两从。
- 在Redis 5.0以前，从节点是叫Slave的，后来改名叫Replica => 都是代表从节点
当我们通过Redis的Java客户端访问主从集群时，应该做好路由：
-
如果是写操作，应该访问Master主节点，Master主节点会自动将数据同步给两个Slave从节点
-
如果是读操作，建议访问各个Slave从节点，从而分担并发压力
Master主节点可以执行set命令（写操作），Replica从节点只能执行get命令（读操作） 。
为什么Redis要做成这种主从的集群，而不是传统的负载均衡集群呢？
- 这是因为Redis应用当中大多数都是读多写少的场景，也就是查询比较多，而增删改比较少，既然如此，我们更多要应对的是读的压力，那我做了主从以后，我们还可以去做读写分离， 也就是说，我在执行写操作时，我让它去访问Master主节点，但如果执行的是读操作，那我就把你的请求分发到各个Slave或Replica从节点，这样我们一主多从，多个从节点共同承担读的请求，我们的读并发能力就可以得到一个比较大的提升，所以这就是为什么要搭建主从集群的一个原因了。
- 但是做主从集群，必须保证一点，就是客户端在读取的时候，不管访问到哪个Slave从节点，都必须要保证拿到相同的结果 => 如何保证？ 需要让Master主节点把它上面的数据同步给每一个Slave从节点，这就是Redis主从架构的一个基本模式了
1.2 搭建主从集群
1. 准备实例和配置
- 我们会在同一台虚拟机中开启3个Redis实例，模拟主从集群。
-
我们会在同一个虚拟机中利用3个Docker容器来搭建主从集群。
-
要在同一台虚拟机开启3个实例，必须准备三份不同的配置文件和目录，配置文件所在目录也就是工作目录。
-
在同一个机器下还要修改每个实例的端口
2. 启动 & 开启主从关系
分别启动多个Redis实例，虽然我们启动了3个Redis实例，但是它们并没有形成主从关系，我们需要通过命令来配置主从关系：
# Redis5.0以前
slaveof <masterip> <masterport>
# Redis5.0以后
replicaof <masterip> <masterport>有临时和永久两种模式：
-
永久生效：在redis.conf文件中利用slaveof命令指定Master主节点的IP和端口
-
临时生效：直接利用redis-cli控制台输入slaveof命令，指定Master主节点的IP和端口
INFO replication：查看集群的状态信息
这样，就可以实现读写分离了，如果在Slave从节点上执行set写操作，会报错：
假设有A、B两个Redis实例，如何让B作为A的Slave从节点？
- 在B节点执行命令：slaveof A的IP A的Port端口
1.3 数据同步原理
