Redis集群

什么是集群

所谓的集群，就是通过添加服务器的数量，提供相同的服务，从而让服务器达到一个稳定、高效的状态。

1. 主从复制

和MySQL一样，为了实现读写分离以减轻数据库的读的压力也就是读写分离，因此需要有一种主从复制的机制。实际上Redis的主从复制与MySQL的区别并不是很大。

命令：

slave of

全量同步

在从服务ping通主服务器之后，也就是与主服务器建立好了连接之后，开始进行全量同步

• 从服务器连接主服务器发送SYNC命令，请求同步
• 主服务器接收带SYNC之后开始BGSAVE，也就是后台生成RDB快照。并开始在记录这一快照后的所有被执行的写命令（为了增强数据的一致性）
• 主服务器发送RDB文件
• 主服务器发送这期间的所有被执行的写命令
• 从服务器载入RDB文件并执行收到的命令

总结
和MySQL差不多，总体可以分为

• 主服务器备份
• IO发送数据
• 从服务器回放
  实际上RDB可以与MySQL中的二进制日志进行比较，不过MySQL中的二进制日志保存的是类似SQL语句的格式（准确的来说是<sql反效果，sql语句>）

增量同步

主服务器执行了一个命令就像从服务器发送一个命令

部分同步

在Redis2.8之后，支持了部分同步。因为网络连接不一定是稳定的，如果网络波动导致连接断开，那么可以从中断处继续进行复制，而不必重新同步。

工作原理：
主服务器维持一个内存缓冲区，主从均维护一个复制偏移量与master run id（主id），当从服务器的偏移量在内存缓冲区内仍然有效且master run id主从一致时，进行部分同步（PSYNC）

由于master run id 存储在内存中而不是持久化在硬盘中，因此一旦从服务器重启了的话，就不能与主master run id一致了，也就不能部分同步了，而只能全量同步。

2. 哨兵机制

为什么需要哨兵

为了保证项目的高可用性。因为在主从架构中，如果主Redis挂了，那么我们需要手动的切换主数据库，这个过程比较麻烦且耗时。因此我们需要一种自动管理Redis集群的方案

功能

1. 监控：不断监控主服务器与从服务器是否正常
2. 报警：出现Redis异常时，可通过Api向管理员报警
3. 自动故障迁移：选举出一个从服务器代替主服务器提供服务

故障迁移流程

1. 判断节点下线

• 主观下线
  一个Sentinel节点与Master连接超时
• 客观下线
  超过major个节点与Master连接超时

2. Leader选举
   通过以下参数进判断

• 选择slave-priority最低的节点
• 选择offset最高的节点（看部分同步那里，这意味着同步的数据多）
• 选择runId最小的节点

3. Cluster

哨兵机制虽然已经保证了集群的高可用性，但是他的主（master）服务器数据却始终只能存储在单台服务器上，这样会有2个问题

• 单机容量不够
• 写的效率低
  Redis Cluster通过数据水平分片解决这个问题。那么如何进行分片呢？

hash算法

• 取模
  缺点：如果宕机一台，或者新加入一台，数据必须整体重新映射
• 一致性hash

一致性hash将所有的hash值构造成了一个环，环周长为2^32，每台服务器对应环上的一个hashcode节点，当我们需要找到一个hashcode对应的服务器时，只需要顺时针找到第一台即可。

总结

在哨兵模式下，master仍然只有一个，它只是在主从模式下增加了一个哨兵或哨兵集群作为对master的状态监控或故障选举。在数据量很大时，读性能可能可以增加slave来扩展，但写性能仍然是瓶颈。而cluster模式不同，多master多slave，数据共享，工作节点自己做状态监控及故障迁移，读写性能都可以通过水平扩展来解决。

参考
https://blog.csdn.net/miss1181248983/article/details/90056960