简介

Leader-Follower 架构是一种常见的架构模式，用于实现数据复制和故障转移。在该架构中，一个节点充当 Leader，负责接收和处理写操作，而其他节点则作为 Follower，负责复制 Leader 节点的。这种架构能够确保数据的一致性和可靠性。

Leader-Follower 架构在 Redis 中的应用

在 Redis 中，Leader 节点负责接收客户端的写操作，并将这些操作复制给 Follower 节点。Follower 节点通过复制 Leader 节点的，实现与 Leader 节点的。

数据一致性

在 Leader-Follower 架构中，数据一致性是一个重要的考虑因素。以下是一些措施，用于确保数据在 Leader 和 Follower 之间的一致性： 写操作复制：当 Leader 节点接收到一个写操作时，它会将这个操作记录到日志中，并将相应的写操作发送给所有的 Follower 节点。Follower 节点会按照接收到的写操作顺序，逐一执行这些操作，以确保数据的一致性。 数据同步：为了保证数据的一致性，Follower 节点需要定期从 Leader 节点同步数据。这可以通过 Redis 的复制功能来实现。Follower 节点会连接到 Leader 节点，并发送一个 SYNC 命令，Leader 节点将会将自己的数据快照发送给 Follower 节点，以进行初始化。之后，Leader 节点会将自己的写操作发送给 Follower 节点，以保持数据的同步。 读操作转发：当客户端发送一个读操作时，代理服务器通常会将该请求转发给 Follower 节点。这样可以减轻 Leader 节点的负载压力，并提高系统的读吞吐量。尽管读操作是在 Follower 节点上执行的，但由于 Leader 和 Follower 之间的数据是一致的，所以客户端可以获得正确的结果。 异步复制：Leader 节点和 Follower 节点之间的数据复制通常是异步进行的。这意味着 Leader 节点不会等待 Follower 节点的确认，就继续处理其他操作。虽然这样可以提高系统的性能和响应速度，但也可能导致数据的稍微滞后。在某些情况下，如果 Leader 节点宕机，可能会有一小部分数据丢失。 数据完整性校验：为了确保数据在复制过程中的完整性，Leader 节点通常会使用校验和或哈希函数对数据进行签名。Follower 节点会在接收到数据后，使用相同的校验和或哈希函数进行验证。如果数据的签名不匹配，说明数据可能被篡改或丢失，Follower 节点会重新请求数据。

结论

在 Redis 高可用性中，Leader-Follower 架构是一种常见的架构模式，用于实现数据的复制和故障转移。通过写操作的复制、数据同步、读操作的转发、异步复制和数据完整性校验等措施，可以确保数据在 Leader 和 Follower 之间的一致性和可靠性。

---

Redis目前在绝大多数的项目中扮演怎样的角色

目前memcache已经被redis所取代，很想知道redis在项目中扮演怎样的角色，是作为功能更强大的但依旧是数据缓存的角色，还是说已经可以胜任并取代MySQL地位的角色了替代不了mysql 第一 它不具有SQL的功能，没有关系的概念，第二它的数据持久化和事务管理的功能远远不及mysql 。 它目前的确可以代替较为简单的memcache作为一个具有多种数据结构的缓存服务器进行使用。 对我来说处于核心地位。 1.持久化已经很成熟，性能让人感动，3.简单的k-v结构可以组合幻变出各种数据结构，比如文档、树、图、网络4.数据能设生命周期简直太舒服了数据在内存里运行萌萌哒，反正有钱任性。 程序与数据库之前的位置Redis做数据库不太靠谱1、支持的数据类型太少2、查询功能太弱3、数据也不是实时存储到磁盘主要还是缓存一些需要频繁访问的数据现在网站大多数不需要频繁的登陆了。 一般都把session存在数据库中 我只用redis 就是做过这个工作

玩转Redis的高可用（主从、哨兵、集群）

所谓的高可用，也叫 HA（High Availability），是分布式系统架构设计中必须考虑的因素之一，它是保证系统SLA的重要指标。Redis 高可用的主要有三种模式： 主从模式 ， 哨兵模式和集群模式 。

Redis 提供了 Redis 提供了复制(replication)功能，当一台 redis 数据库中的数据发生了变化，这个变化会被自动地同步到其他的 redis 机器上去。

Redis 多机器部署时，这些机器节点会被分成两类，一类是主节点（master 节点），一类是从节点（slave 节点）。一般 主节点可以进行读、写操作 ，而 从节点只能进行读操作 。一个主节点可以有多个从节点，但是一个从节点只会有一个主节点，也就是所谓的 一主多从结构 。

· 支持主从复制，主机会自动将数据同步到从机，可以进行读写分离;

· Master 是以非阻塞的方式为主 Slaves 提供服务。所以在 Master-Slave 同步期间，客户端仍然可以提交查询或修改请求;

· Slave 同样是以非阻塞的方式完成数据同步。在同步期间，如果有客户端提交查询请求，Redis 则返回同步之前的数据。

· Redis 不具备自动容错和恢复功能，主机从机的宕机都会导致前端部分读写请求失败，需要等待机器重启或者手动切换前端的 IP 才能恢复;

· 主机宕机，宕机前有部分数据未能及时同步到从机，切换 IP 后面还会引入数据不一致的问题，降低了系统的可用性;

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂;

· Redis 的主节点和从节点中的数据是一样的，降低的内存的可用性

实际生产中，我们优先考虑哨兵模式。这种模式下，master 宕机，哨兵会自动选举 master 并将其他的 slave 指向新的 master。

在主从模式下，redis 同时提供了哨兵命令redis-sentinel，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵进程向所有的 redis 机器人发送命令，等待 Redis 服务器响应，从而监控运行的多个 Redis 实例。一般为了便于决策选举，使用 奇数个哨兵 。多个哨兵构成一个哨兵集群，哨兵直接也会相互通信，检查哨兵是否正常运行，同时发现 master 战机哨兵之间会进行决策选举新的 master

哨兵模式的作用:

· 通过发送命令，让 Redis 服务器返回监控其运行状态，包括主服务器和从服务器;

· 然而一个哨兵进程对 Redis 服务器进行监控，也可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多种哨兵模式。

哨兵很像 kafka 集群中的 zookeeper 的功能。

· 哨兵模式是基于主从模式的，所有主从的优点，哨兵模式都具有。

· 主从可以自动切换，系统更健壮，可用性更高。

· 具有主从模式的缺点，每台机器上的数据是一样的，内存的可用性较低。

· Redis 较难支持在线扩容，在集群容量达到上限时在线扩容会变得很复杂。

Redis 集群模式本身没有使用一致性 hash 算法，而是使用 slots 插槽 。

Redis 哨兵模式基本已经可以实现高可用，读写分离 ，但是在这种模式下每台 Redis 服务器都存储相同的数据，很浪费内存，所以在 redis3.0 上加入了 Cluster 集群模式，实现了 Redis 的分布式存储，对数据进行分片，也就是说每台 Redis 节点上存储不同的内容；每个节点都会通过集群总线(cluster bus)，与其他的节点进行通信。 通讯时使用特殊的端口号，即对外服务端口号加 。例如如果某个 node 的端口号是 6379，那么它与其它 nodes 通信的端口号是 。nodes 之间的通信采用特殊的二进制协议。

对客户端来说，整个 cluster 被看做是一个整体，客户端可以连接任意一个 node 进行操作，就像操作单一 Redis 实例一样， 当客户端操作的时候 key 没有分配到该 node 上时，Redis 会返回转向指令，指向正确的 node，这有点儿像浏览器页面的 302 redirect 跳转。

根据官方推荐，集群部署至少要 3 台以上的 master 节点，最好使用 3 主 3 从六个节点的模式。

在 Redis 的每一个节点上，都有这么两个东西， 一个是插槽（slot），它的的取值范围是：0-， 可以从上面执行的结果看到这 个 slot 在三个 master 上的分布。还有一个就是 cluster，可以理解为是一个集群管理的插件，类似的哨兵。

当我们的存取的 Key 到达的时候，Redis 会根据 crc16 的算法对计算后得出一个结果，然后把结果和 求余数，这样每个 key 都会对应一个编号在 0- 之间的哈希槽，通过这个值，去找到对应的插槽所对应的节点，然后直接自动跳转到这个对应的节点上进行存取操作。

为了保证高可用， redis-cluster 集群引入了主从模式 ，一个主节点对应一个或者多个从节点。当其它主节点 ping 主节点 master 1 时，如果半数以上的主节点与 master 1 通信超时，那么认为 master 1 宕机了，就会启用 master 1 的从节点 slave 1，将 slave 1 变成主节点继续提供服务。

如果 master 1 和它的从节点 slave 1 都宕机了，整个集群就会进入 fail 状态，因为集群的 slot 映射不完整。 如果集群超过半数以上的 master 挂掉，无论是否有 slave，集群都会进入 fail 状态。

redis-cluster 采用去中心化的思想 ，没有中心节点的说法，客户端与 Redis 节点直连，不需要中间代理层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。

对 redis 集群的扩容就是向集群中添加机器，缩容就是从集群中删除机器，并重新将 个 slots 分配到集群中的节点上（数据迁移）。

扩缩容也是使用集群管理工具 。

扩容时，先使用 add-node将新的机器加到集群中，这是新机器虽然已经在集群中了，但是没有分配 slots，依然是不起做用的。在使用 reshard进行分片重哈希（数据迁移），将旧节点上的 slots 分配到新节点上后，新节点才能起作用。

缩容时，先要使用 reshard移除的机器上的 slots，然后使用 add-del移除机器。

采用去中心化思想，数据按照 slot 存储分布在多个节点，节点间数据共享，可动态调整数据分布;

可扩展性：可线性扩展到 1000 多个节点，节点可动态添加或删除;

高可用性：部分节点不可用时，集群仍可用。通过增加 Slave 做 standby 数据副本，能够实现故障自动 failover，节点之间通过 gossip 协议交换状态信息，用投票机制完成 Slave 到 Master 的角色提升;

降低运维成本，提高系统的扩展性和可用性。

Cluster 是无中心节点的集群架构，依靠 Goss 协议(谣言传播)协同自动化修复集群的状态。但 GosSIp 有消息延时和消息冗余的问题，在集群节点数量过多的时候，节点之间需要不断进行 PING/PANG 通讯，不必须要的流量占用了大量的网络资源。虽然 Reds4.0 对此进行了优化，但这个问题仍然存在。

2.数据迁移问题

Redis Cluster 可以进行节点的动态扩容缩容，这一过程，在目前实现中，还处于半自动状态，需要人工介入。在扩缩容的时候，需要进行数据迁移。

而 Redis 为了保证迁移的一致性，迁移所有操作都是同步操作 ，执行迁移时，两端的 Redis 均会进入时长不等的阻塞状态，对于小 Key，该时间可以忽略不计，但如果一旦 Key 的内存使用过大，严重的时候会接触发集群内的故障转移，造成不必要的切换。

主从模式：master 节点挂掉后，需要手动指定新的 master，可用性不高，基本不用。

哨兵模式：master 节点挂掉后，哨兵进程会主动选举新的 master，可用性高，但是每个节点存储的数据是一样的，浪费内存空间。数据量不是很多，集群规模不是很大，需要自动容错容灾的时候使用。

集群模式：数据量比较大，QPS 要求较高的时候使用。 Redis Cluster 是 Redis 3.0 以后才正式推出，时间较晚，目前能证明在大规模生产环境下成功的案例还不是很多，需要时间检验。