Redis集群

一、单机、单节点、单实例的问题

1、单点故障

2、容量有限

3、压力太大

二、AKF

1、X轴（做数据的副本）：解决单点故障。

全量镜像，主提供读写，备提供读。

2、Y轴（数据按业务功能进行划分）：解决容量有限。

3、Z轴（按优先级逻辑再拆分）：解决压力问题。

同一个业务，0到999放到一个Redis库里，1000到1999放到一个Redis库里，也就是一个业务放到多个Redis库里，同时也得加上规则，让对应的数据能够放到对应的库里。

主备与主从的区别？

主备：客户端只能访问主，不能访问备用机，备用机是在主挂掉之后能够接替主，然后对外提供服务。
主从：客户端不仅能访问主，还能访问备用机。
主自己也是一个单节点，所以一般会对主做HA（高可用）。高可用不是说主不会挂，而是主挂掉之后马上能够重新选择一个备机或从机作为主，对外表现是一直可用的。

通过AKF实现一变多，数据一致性问题如何解决？

1、强一致性：所有节点阻塞，直到所有数据全部一致。如果其中一个节点因为网络问题导致数据迟迟不能同步，不能一致，那么整个集群都在阻塞着，就不可用了，所以极易破坏可用性。而一变多就是为了解决单节点的单点故障、可用性的问题，而强一致性又破坏了可用性。

2、弱一致性：容忍数据丢失一部分。通过异步方式同步数据。

3、最终一致性：通过一个集群可靠快速的中间件（例如kafka）来同步数据，保证数据的一致性。

三、Replication（复制）

Redis使用默认的异步复制，其特点是低延迟和高性能。也就是采用的弱一致性。

1、窗口1：cd ~，mkdir test，cd test

2、窗口2：cd /root/soft/redis-5.0.9/utils
（1）./install_server.sh 6381
（2）service redis_6379 stop（停掉所有redis）

3、窗口1：cp /etc/redis/* ./
（1）vi 6379.conf，
（2）daemonize yes改为no（前台阻塞运行），
（3）#logfile /var/log/redis_6379.log（注释掉日志文件），
（4）appendonly yes改为no（不产生aof）。6380,6381也做同样的修改。

4、窗口2：cd /var/lib/redis/6379，rm -rf ./*，6380,6381也做同样的修改。

5、窗口1：redis-server ~/test/6379.conf

6、窗口2：redis-server ./6380.conf

7、新开一个窗口（窗口3）：redis-server ./6381.conf

8、新开3个窗口分别连上3个server，keys *查看是否为空。

9、窗口7：cd /var/lib/redis 查看6379、6380、6381是否为空。

10、窗口5（连接6380服务器的客户端）：REPLICAOF 127.0.0.1 6379（5.0之前是SLAVEOF 127.0.0.1 6379），6380以6379作为主节点。（此时在连接6379的客户端的读写操作会同步到6380上，6380默认只能读、不能写）

11、窗口6（连接6381服务器的客户端）：REPLICAOF 127.0.0.1 6379（连接后，之前6379的数据会同步过来，同时自己的老数据会被清空）

12、窗口7：此时/var/lib/redis下6380和6381就有数据了

13、窗口3：Ctrl+c（模拟从节点挂掉），然后再redis-server ./6381.conf --replicaof 127.0.0.1 6379（此时6381不会flush old data，同时会把它挂掉之后主节点的数据进行增量更新）。此时主节点6379不会落rdb文件（以redis-server ./6381.conf --replicaof 127.0.0.1 6379 --appendonly yes启动 主节点又会落rdb文件，自己会落aof文件）。

14、窗口1：Ctrl+C（模拟主节点挂掉），此时6380和6381仍然只能读，主节点之前的数据还能查询。

15、窗口5：replicaof no one（不再追随6379，自己成为主节点）。

16、窗口6：REPLICAOF 127.0.0.1 6380。

四、配置文件

1、replica-serve-stale-data yes（当连接到某个主节点后到load主节点的RDB文件结束期间，是否对外提供旧数据的查询）

2、replica-read-only yes（从节点是否只读）

3、repl-diskless-sync no（no：主节点先把数据load到磁盘，再通过网络发送给从节点；yes：主节点直接把RDB文件通过网络发送给从节点）

4、# repl-backlog-size 1mb（从节点挂掉后，到重新恢复期间主节点产生的数据可以存储在一个队列里<这就是配置此队列的大小>，从节点恢复后可以根据偏移量直接从此队列取增量数据，而不需要再次同步全量数据）

5、# min-replicas-to-write 3，# min-replicas-max-lag 10（最小必须向几个从节点写成功数据），开启就渐渐向强一致性靠拢。

五、High Availability（高可用）

Redis Sentinel是Redis官方的高可用性解决方案。

1、监控（Monitoring）：Sentinel 会不断地检查你的主服务器和从服务器是否运作正常。

2、提醒（Notification）：当被监控的某个 Redis 服务器出现问题时， Sentinel 可以通过 API 向管理员或者其他应用程序发送通知。

3、自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时， Sentinel 会开始一次自动故障迁移操作， 它会将失效主服务器的其中一个从服务器升级为新的主服务器， 并让失效主服务器的其他从服务器改为追随新的主服务器；当客户端试图连接失效的主服务器时， 集群也会向客户端返回新主服务器的地址， 使得集群可以使用新主服务器代替失效服务器。

演示：

1、停掉所有节点，退出所有客户端。

2、窗口1：vi 26379.conf，输入
port 26379
sentinel monitor mymaster 127.0.0.1 6379 2

3、窗口1：cp 26379.conf 26380.conf，cp 26379.conf 26381.conf，修改端口号

4、窗口1：redis-server ./6379.conf

5、窗口2：redis-server ./6380.conf --replicaof 127.0.0.1 6379

6、窗口3：redis-server ./6381.conf --replicaof 127.0.0.1 6379

7、窗口4：cd ，cd test/，redis-server ./26379.conf --sentinel（此时通过日志可以看到，尽管配置文件只配置了监控6379主节点，但是却显示了此主节点的两个从节点，是通过发布订阅来实现的）

8、窗口5：cd ，cd test/，redis-server ./26380.conf --sentinel（不仅显示了主节点下的从节点信息，还显示了该主节点的其他sentinel）

9、窗口6：cd ，cd test/，redis-server ./26381.conf --sentinel

10、窗口1：Ctrl+C，模拟主节点挂了，因为网络问题不会立马就选出一个主节点来。（同时sentinel会修改自己的配置文件）

11、窗口7：连上6380的client，PSUBSCRIBE * （可以看到各个sentinel之间发送的消息）

12、redis源码路径/root/soft/redis-5.0.9下的sentinel.conf文件可以看到哨兵的配置文件信息。