Redis几种部署模式介绍
Redis 提供了几种差别的部署模式，以满足差别的利用场景和可用性需求。这些模式包罗单机模式、主从复制、哨兵模式和集群模式。下面我将扼要介绍每种模式的特点和用途：[*] 单机模式：
[*]描述：单个 Redis 服务器实例运行在一台机器上，不举行任何复制或数据共享。
[*]用途：适用于数据量不大，对数据可用性要求不高的场景。由于没有数据复制和分布式处理，设置简单，耽误较低。
[*] 主从复制：
[*]描述：设置一个主节点和一个或多个从节点。数据从主节点复制到全部从节点，从节点可以担当读哀求，分担主节点的读取负载。
[*]用途：增强数据的可用性和读取性能。在主节点不可用的环境下，可以手动切换到一个从节点作为新的主节点，但这个过程不是自动的。
[*] 哨兵模式（Sentinel）：
[*]描述：在主从复制的底子上，通过利用哨兵体系自动完成故障转移和主节点选举。哨兵是一个独立的历程，用于监控全部Redis节点的运行状态，并在主节点故障时自动将一个从节点提升为新的主节点。
[*]用途：提供更高的可用性。适用于对自动故障转移有要求的环境。
[*] 集群模式：
[*]描述：通过设置多个节点，实现数据的自动分片，每个节点只保存数据的一部分。集群模式支持多台机器间的数据共享，可以在节点间自动均衡数据和负载。
[*]用途：适用于大规模数据处理，能够提供高可用性和数据分区，支持水平扩展。
每种模式都有其适用的场景，选择哪种模式取决于你的具体需求，好比数据量大小、读写哀求的频率、对数据可用性和稳固性的要求等。
主从复制（Replication）
Redis 主从复制（Replication）是 Redis 提供的一种数据复制机制，用于实现数据的高可用性和读写分离。通过主从复制，Redis 可以将数据从一个主节点（Master）复制到一个或多个从节点（Slave），从而进步体系的容错本领和读性能。下面是主从复制的工作原理及其详细解释。
主从复制的工作原理
1. 初始化复制
当从节点启动时，它会发送 PSYNC 下令哀求从主节点举行同步。主节点会根据从节点的哀求举行相应的处理。
[*]全量复制：当从节点第一次连接到主节点时，通常会举行全量复制。主节点会创建一个 RDB 快照文件，并将其发送给从节点。从节点接收并加载 RDB 文件，然后继续接收主节点的 AOF 文件（如果有），以便将主节点的全部数据完全同步到从节点。
[*]部分复制：如果从节点之前已经与主节点同步过，且连接因网络原因停止后重新连接，主节点会尝试举行部分复制，只将这期间发生的增量数据发送给从节点。如果部分复制失败，会退回到全量复制。
2. 数据复制
一旦初始化复制完成，主节点会将全部新的写操作下令发送给从节点。从节点会执行这些下令，以确保其数据与主节点保持一致。
3. 下令传播
主节点会将每个写操作下令（如 SET、DEL 等）发送给全部从节点。从节点接收并执行这些下令，从而保持数据的一致性。下令传播是异步举行的，从节点不会阻塞主节点的写操作。
4. 心跳检测
主节点和从节点之间会定期发送心跳（PING）消息，以检测连接的状态。如果主节点长时间没有收到从节点的心跳回复，大概从节点长时间没有收到主节点的心跳消息，会以为连接已断开并采取相应步伐（如重新连接或选择新的主节点）。
设置 Redis 主从复制
设置 Redis 主从复制可以确保数据的高可用性和读写分离。以下是详细的步骤，包罗主节点和从节点的设置方法。
1. 安装 Redis
确保你已经在主节点和从节点的服务器上安装了 Redis。如果尚未安装，可以利用以下下令举行安装（以 Ubuntu 为例）：
sudo apt update sudo apt install redis-server
2. 设置主节点
主节点无需特别设置，只需启动 Redis 服务器即可。
redis-server /etc/redis/redis.conf
3. 设置从节点
在从节点的 Redis 设置文件 redis.conf 中，添加或修改以下设置，将 <master-ip> 和 <master-port> 替换为主节点的现实 IP 地址和端口号。
利用 replicaof 下令
在 Redis 5.0 及之后的版本中，利用 replicaof：
replicaof <master-ip> <master-port>
例如：replicaof 192.168.1.100 6379
利用 slaveof 下令
在 Redis 5.0 之前的版本中，利用 slaveof：
slaveof <master-ip> <master-port>
例如：
slaveof 192.168.1.100 6379
保存设置文件后，启动从节点 Redis 服务器：
redis-server /etc/redis/redis.conf
4. 动态设置主从复制
可以利用 redis-cli 动态设置主从复制，而无需修改设置文件并重启 Redis。
利用 replicaof 下令
redis-cli replicaof 192.168.1.100 6379
利用 slaveof 下令
复制代码
redis-cli slaveof 192.168.1.100 6379
5. 验证主从复制
在从节点上执行以下下令，以验证主从复制设置是否乐成：
redis-cli info replication
你应该看到类似以下的输出，显示主节点和从节点的关系：
# Replication
role:slave
master_host:192.168.1.100
master_port:6379
master_link_status:up
...
6. 停止从节点复制
如果必要停止从节点对主节点的复制，可以利用以下下令：
利用 replicaof 下令
redis-cli replicaof no one
利用 slaveof 下令
redis-cli slaveof no one
完整示例
以下是一个完整的设置示例：
主节点设置
启动 Redis 服务器：
redis-server /etc/redis/redis.conf
从节点设置
编辑 redis.conf 文件，添加以下设置：
replicaof 192.168.1.100 6379
然后启动从节点：
redis-server /etc/redis/redis.conf
或在运行时利用 redis-cli 动态设置：
redis-cli replicaof 192.168.1.100 6379
验证主从复制
在从节点上执行以下下令：
redis-cli info replication
确保输出中 role 为 slave 且 master_link_status 为 up。
了解 Redis 的复制耽误和一致性标题
在设置和利用 Redis 主从复制时，了解复制耽误和一致性标题对于确保体系的可靠性和性能非常重要。下面是对这些标题标详细解释：
复制耽误
复制耽误是指从节点接收和应用主节点发出的写操作下令所花费的时间。在 Redis 中，复制耽误主要由以下几个因素决定：
[*] 网络耽误：
[*]主节点和从节点之间的网络传输速率和耽误会直接影响复制耽误。如果网络连接不稳固或带宽有限，复制耽误会增加。
[*] 从节点性能：
[*]从节点的硬件性能和负载环境也会影响复制耽误。如果从节点处理本领有限或体系负载高，接收和应用写操作下令的速率会变慢。
[*] 主节点写入速率：
[*]如果主节点的写操作频率非常高，从节点可能无法及时处理全部写操作，导致复制耽误增加。
一致性标题
Redis 主从复制是异步的，这意味着主节点在完成写操作后不会等待从节点确认复制乐成。这种异步复制机制会导致以下一致性标题：
[*] 最终一致性：
[*]在大多数环境下，从节点的数据最终会与主节点保持一致，但在某些环境下（如网络分区或从节点故障），从节点的数据可能会有短暂的不一致。
[*] 读写一致性：
[*]如果读操作同时在主节点和从节点上执行，可能会出现读到差别数据的环境。例如，写操作在主节点上完成，但从节点还没有同步到最新数据，此时在从节点上举行的读操作会返回旧的数据。
[*] 数据丢失：
[*]在极端环境下，如主节点故障且从节点还未同步最新数据时，可能会导致数据丢失。这种环境在主节点和从节点之间的复制耽误较大时更为显着。
减少复制耽误和一致性标题标方法
[*] 优化网络连接：
[*]利用低耽误、高带宽的网络连接主节点和从节点，以减少网络传输时间。
[*]利用本地网络连接主从节点，避免跨地域的网络耽误。
[*] 增加从节点性能：
[*]利用高性能的硬件来运行从节点，以确保其能够快速处理主节点发来的写操作下令。
[*]优化从节点的设置和性能调优，减少体系负载对复制的影响。
[*] 调整复制缓冲区大小：
[*]调整主节点的复制缓冲区大小，确保从节点能够及时接收和处理写操作下令。
[*] 监控和调优：
[*]利用 Redis 提供的监控工具和第三方监控体系，实时监控主从复制的状态和耽误。
[*]根据监控数据，调整设置和优化网络，以减少复制耽误。
[*] 利用半同步复制：
[*]Redis 5.0 引入了 PSYNC2 协议，可以设置部分同步复制。在部分同步复制模式下，从节点断开连接后重新连接时，可以减少全量复制的频率，减少复制耽误。
示例设置和监控
调整复制缓冲区大小
在主节点的 redis.conf 文件中，可以调整复制缓冲区的大小：
repl-backlog-size 64mb
监控复制耽误
在从节点上，利用以下下令监控复制耽误：
redis-cli info replication
输出中包罗以下字段，可以用于监控复制耽误：
[*]master_last_io_seconds_ago：从节点最后一次接收到主节点写操作下令的时间（秒）。
[*]slave_repl_offset：从节点的复制偏移量。
通过监控这些数据，可以了解主从复制的实时状态，并采取相应的优化步伐。
总结
明确和优化 Redis 的复制耽误和一致性标题对于确保体系的可靠性和性能至关重要。通过优化网络连接、增加从节点性能、调整复制缓冲区大小和监控复制耽误，可以有效减少复制耽误和一致性标题，确保 Redis 体系的高可用性和数据一致性。
哨兵模式（Sentinel）
哨兵的工作原理
Redis 哨兵（Sentinel）是一种用于实现 Redis 高可用性的机制。哨兵体系监控主节点和从节点，自动执行故障转移，确保体系的持续可用性。
哨兵体系由一个或多个哨兵实例构成，这些实例协同工作以监控 Redis 集群，并在必要时执行故障转移。哨兵的主要功能包罗：
[*]监控（Monitoring）：哨兵实例不断检查主节点和从节点是否可用。
[*]通知（Notification）：当检测到节点故障时，哨兵可以通知管理员或其他应用。
[*]自动故障转移（Automatic Failover）：如果主节点发生故障，哨兵会从从节点中选举一个新的主节点，并将其提升为主节点。
[*]设置提供者（Configuration Provider）：客户端可以连接哨兵以获取当前主节点的地址，从而实现高可用的连接。
哨兵的组件和流程
1. 哨兵监控
每个哨兵实例会定期向主节点和从节点发送 PING 下令，以检查它们的状态。如果一个节点在设置的时间内没有相应 PING 下令，哨兵会将其标记为主观下线（Subjectively Down，简称 SDOWN）。
2. 哨兵协商
如果多个哨兵实例都将同一个节点标记为主观下线，并且凌驾了设置的阈值时间（通常为几秒钟），哨兵体系会将该节点标记为客观下线（Objectively Down，简称 ODOWN）。此时，哨兵体系会触发故障转移流程。
3. 故障转移
当主节点被标记为 ODOWN 时，哨兵会从从节点中选举一个新的主节点。选举过程包罗以下步骤：
[*]确定具备资格的从节点：哨兵会检查从节点的状态，确保其最新的复制偏移量、无故障时间和复制耽误在可担当范围内。
[*]选举新的主节点：哨兵会利用 Raft 一致性算法或其他选举算法，从及格的从节点中选出一个新的主节点。
[*]提升从节点：被选中的从节点会被提升为主节点，接受原主节点的角色。
[*]更新设置：哨兵会通知其他从节点，将它们的复制目标更新为新的主节点。
4. 通知客户端
哨兵可以作为设置提供者，客户端可以连接哨兵获取当前主节点的地址。这样，即使发生故障转移，客户端也能自动连接到新的主节点，保持高可用性。
设置 Redis 哨兵
设置 Redis 哨兵体系可以确保 Redis 的高可用性，通过监控主节点和从节点，自动执行故障转移。以下是详细的设置步骤，包罗设置主节点、从节点和哨兵实例。
环境假设
假设我们有三台服务器：
[*]主节点（Master）：192.168.1.100
[*]从节点1（Slave1）：192.168.1.101
[*]从节点2（Slave2）：192.168.1.102
[*]哨兵实例（Sentinel）：可以部署在上述任意服务器上，假设我们在每台服务器上都运行一个哨兵实例。
1. 设置主节点
[*]安装 Redis 并启动主节点：
sudo apt update
sudo apt install redis-server
sudo systemctl start redis-server
[*]确保主节点的 redis.conf 文件中有以下设置：
bind 0.0.0.0 # 允许所有 IP 访问
port 6379 # Redis 端口
daemonize yes # 以守护进程模式启动
2. 设置从节点
在从节点1和从节点2上举行相同的设置步骤。
[*]安装 Redis 并编辑 redis.conf 文件：
sudo apt update
sudo apt install redis-server
sudo nano /etc/redis/redis.conf
[*]在 redis.conf 文件中添加以下设置，使其连接到主节点：
bind 0.0.0.0 # 允许所有 IP 访问
port 6379 # Redis 端口
daemonize yes # 以守护进程模式启动
replicaof 192.168.1.100 6379# 配置主节点的 IP 地址和端口
[*]启动从节点：
sudo systemctl start redis-server
3. 设置哨兵
在每台服务器上运行一个哨兵实例，假设在 192.168.1.100, 192.168.1.101, 和 192.168.1.102 上各运行一个哨兵实例。
[*]在每台服务器上创建一个哨兵设置文件 sentinel.conf：
sudo nano /etc/redis/sentinel.conf
[*]设置文件内容如下：
port 26379 # 哨兵监听的端口
sentinel monitor mymaster 192.168.1.100 6379 2# 监控的主节点名称、IP 和端口，以及多数投票的哨兵数量
sentinel down-after-milliseconds mymaster 5000# 标记主节点为主观下线的超时时间（毫秒）
sentinel failover-timeout mymaster 10000 # 故障转移超时时间（毫秒）
sentinel parallel-syncs mymaster 1 # 故障转移时，最多同时对多少个从节点进行同步
[*]启动哨兵实例：
redis-sentinel /etc/redis/sentinel.conf
在每台服务器上都执行上述下令，启动多个哨兵实例以形成哨兵集群。
4. 验证哨兵设置
在哨兵实例上执行以下下令，查看哨兵状态和主节点信息：
redis-cli -p 26379
执行以下下令查看哨兵信息：
SENTINEL masters SENTINEL slaves mymaster
5. 测试故障转移
[*]模仿主节点故障：
sudo systemctl stop redis-server
[*] 在哨兵日志中观察故障转移过程。哨兵会检测到主节点下线，选举一个从节点作为新的主节点，并更新设置。
[*] 验证新的主节点：
在从节点上执行以下下令，验证新的主节点信息：
redis-cli info replication
输出示例：
# Replication
role:slave
master_host:<new-master-ip>
master_port:6379
master_link_status:up
...
总结
通过设置 Redis 哨兵，可以实现 Redis 的高可用性。当主节点发生故障时，哨兵会自动执行故障转移，选举新的主节点，确保体系的持续可用性。哨兵的设置相对简单，但在生产环境中起到关键作用。
哨兵的主观下线和客观下线
Redis 哨兵体系中的主观下线（Subjectively Down，简称 SDOWN）和客观下线（Objectively Down，简称 ODOWN）是用于描述哨兵对 Redis 节点（主节点或从节点）状态的判断。这两个状态用于决定是否必要举行故障转移。以下是详细解释：
主观下线（Subjectively Down，SDOWN）
主观下线是单个哨兵实例对一个节点（主节点或从节点）做出的独立判断。具体步骤如下：
[*]检测节点状态：每个哨兵实例会定期向主节点和从节点发送 PING 下令，以检测节点的可用性。
[*]超时判断：如果一个节点在设置的时间内（由 sentinel down-after-milliseconds 设置项决定）没有相应 PING 下令，哨兵会将该节点标记为主观下线（SDOWN）。
[*]局部判断：主观下线是哨兵单独做出的判断，并不代表整个哨兵体系的判断。此时，只有这个哨兵实例以为该节点下线。
设置示例
在哨兵设置文件 sentinel.conf 中，可以通过以下设置设置主观下线的超时时间：
sentinel down-after-milliseconds mymaster 5000
上述设置表示如果主节点在 5000 毫秒（5 秒）内没有相应 PING 下令，哨兵会将其标记为主观下线。
客观下线（Objectively Down，ODOWN）
客观下线是多个哨兵实例共同对一个节点（通常是主节点）做出的判断。具体步骤如下：
[*]主观下线的传播：当一个哨兵实例将某个节点标记为主观下线后，它会将这一判断传播给其他哨兵实例。
[*]投票协商：如果有充足数量（由 sentinel monitor 设置项中的数量决定）的哨兵实例都以为该节点已经下线，这些哨兵实例会将该节点标记为客观下线（ODOWN）。
[*]启动故障转移：一旦节点被标记为客观下线，哨兵体系会启动故障转移流程，选举新的主节点并通知全部从节点举行切换。
设置示例
在哨兵设置文件 sentinel.conf 中，可以通过以下设置设置必要多少哨兵实例的判断才会将节点标记为客观下线：
sentinel monitor mymaster 192.168.1.100 6379 2
上述设置表示至少必要 2 个哨兵实例以为主节点下线，才会将其标记为客观下线。
工作流程示例
[*] 哨兵实例 A 和 B 向主节点 PING：
[*]哨兵实例 A 发送 PING 下令，但没有收到主节点的相应，在设置的超时时间内（例如 5000 毫秒）没有相应。
[*]哨兵实例 A 将主节点标记为主观下线（SDOWN）。
[*]哨兵实例 B 发送 PING 下令，但也没有收到主节点的相应，在设置的超时时间内（例如 5000 毫秒）没有相应。
[*]哨兵实例 B 将主节点标记为主观下线（SDOWN）。
[*] 传播和投票：
[*]哨兵实例 A 和 B 将其主观下线的判断传播给其他哨兵实例。
[*]如果有充足数量的哨兵实例（例如 2 个）都将主节点标记为主观下线，则这些哨兵实例会将主节点标记为客观下线（ODOWN）。
[*] 故障转移：
[*]当主节点被标记为客观下线后，哨兵体系会启动故障转移流程。
[*]哨兵体系从从节点中选举一个新的主节点，并将其提升为主节点。
[*]哨兵体系通知其他从节点更新其复制目标为新的主节点。
总结
Redis 哨兵体系通过主观下线和客观下线机制，确保在主节点发生故障时，能够及时、可靠地检测到故障并举行自动故障转移。主观下线是单个哨兵实例的独立判断，而客观下线是多个哨兵实例共同确认的效果。通过这种机制，Redis 能够在高可用性环境中提供可靠的数据服务。
哨兵的故障转移机制
Redis 哨兵的故障转移机制是确保 Redis 集群在主节点故障时能够自动选举新的主节点，从而保证体系的高可用性。以下是详细的解释和工作流程。
故障转移机制的工作原理
故障转移（Failover）是指当哨兵检测到主节点故障（客观下线，ODOWN）时，哨兵体系会自动选举一个新的从节点为主节点，并重新设置其他从节点，以保持集群的正常运行。
故障转移的详细步骤
[*] 检测主节点故障：
[*]哨兵实例通过 PING 下令检测主节点的状态。如果主节点在指定时间内没有相应，哨兵将其标记为主观下线（SDOWN）。
[*]如果多个哨兵实例都将主节点标记为主观下线，并达到设置的投票数，则主节点被标记为客观下线（ODOWN）。
[*] 选举领头哨兵（Leader Sentinel）：
[*]当主节点被标记为客观下线后，哨兵实例会通过选举算法选举出一个领头哨兵（Leader Sentinel），由它来执行故障转移操作。
[*]选举过程基于 Raft 算法，保证在网络分区或部分节点故障的环境下，也能选出一个领头哨兵。
[*] 选择新的主节点：
[*]领头哨兵根据从节点的复制偏移量、无故障时间等条件，从及格的从节点中选择一个新的主节点。
[*]优先选择数据最接近主节点的从节点，以减少数据丢失。
[*] 提升从节点为主节点：
[*]领头哨兵向选中的从节点发送下令，将其提升为新的主节点。
[*]新的主节点开始担当写操作，并向其他从节点提供数据复制。
[*] 重新设置集群：
[*]哨兵通知其他从节点，更新它们的复制目标为新的主节点。
[*]全部从节点重新与新的主节点建立复制关系。
[*] 通知客户端：
[*]哨兵可以作为设置提供者，客户端可以连接哨兵获取当前主节点的地址。
[*]哨兵会通知客户端新的主节点地址，确保客户端能够连接到新的主节点。
故障转移示例
假设我们有以下环境：
[*]主节点（Master）：192.168.1.100
[*]从节点1（Slave1）：192.168.1.101
[*]从节点2（Slave2）：192.168.1.102
[*]哨兵实例分别运行在上述三台服务器上。
哨兵设置示例
哨兵设置文件 sentinel.conf 示例：
port 26379
# 监控的主节点名称、IP 和端口
sentinel monitor mymaster 192.168.1.100 6379 2
# 标记主节点为主观下线的超时时间（毫秒）
sentinel down-after-milliseconds mymaster 5000
# 故障转移超时时间（毫秒）
sentinel failover-timeout mymaster 10000
# 故障转移时，最多同时对多少个从节点进行同步
sentinel parallel-syncs mymaster 1
启动哨兵实例
在每台服务器上启动哨兵实例：
redis-sentinel /etc/redis/sentinel.conf
模仿故障转移
[*] 停止主节点：
sudo systemctl stop redis-server
[*] 观察哨兵日志： 哨兵会检测到主节点下线，并启动故障转移过程。你可以在哨兵日志中看到故障转移的详细过程。
[*] 选举新的主节点： 哨兵会根据从节点的状态，选举出一个新的主节点（假设从节点1被选为新的主节点）。
[*] 验证新的主节点： 在从节点1上执行以下下令，确认其已成为新的主节点：
redis-cli info replication
输出示例：
# Replication
role:master
connected_slaves:1
slave0:ip=192.168.1.102,port=6379,state=online,offset=12345,lag=0
[*] 验证从节点设置： 在从节点2上执行以下下令，确认其已连接到新的主节点：
redis-cli info replication
输出示例：
# Replication
role:slave
master_host:192.168.1.101
master_port:6379
master_link_status:up
...
总结
Redis 哨兵的故障转移机制通过监控主节点和从节点的状态，自动选举新的主节点，并重新设置集群，确保体系的高可用性。哨兵的设置和运行相对简单，但在生产环境中起到关键作用，是确保 Redis 高可用的重要机制。通过详细明确哨兵的工作原理和设置，可以更好地保障 Redis 体系的稳固运行。
Redis 集群（Cluster）
Redis 集群的工作原理
Redis 集群（Redis Cluster）是一种分布式的 Redis 部署模式，用于在多个节点之间分配数据，从而实现数据的水平扩展和高可用性。Redis 集群通过数据分片（sharding）和节点间的自动故障转移机制，确保在大规模和高负载环境下的性能和可靠性。下面是 Redis 集群的工作原理的详细解释。
Redis 集群的根本概念
[*] 数据分片（Sharding）：
[*]Redis 集群通过将数据分片（sharding）分布到多个节点上，每个节点只存储一部分数据。
[*]数据分片利用哈希槽（hash slot）举行管理。整个 Redis 集群有 16384 个哈希槽，每个键通过 CRC16 算法计算哈希值，并将其映射到对应的哈希槽。
[*] 节点角色：
[*]Redis 集群中的节点分为主节点（Master）和从节点（Slave）。
[*]主节点负责处理数据的读写哀求，从节点作为主节点的副本，用于实现数据的高可用性。
[*] 高可用性：
[*]每个主节点可以有一个或多个从节点，主节点负责数据的写操作和部分读操作，从节点作为主节点的备份，当主节点发生故障时，从节点可以自动提升为主节点。
数据分片和哈希槽
[*] 哈希槽的分配：
[*]Redis 集群有 16384 个哈希槽，每个键根据 CRC16 算法计算出的哈希值分配到相应的哈希槽。
[*]哈希槽匀称地分配给全部主节点。例如，如果有 4 个主节点，则每个主节点负责 4096 个哈希槽。
[*] 键的映射：
[*]每个键根据哈希值映射到一个哈希槽，然后哈希槽分配给某个主节点。这样，键值对分布在差别的主节点上。
节点间通信
[*] Gossip 协议：
[*]Redis 集群中的节点通过 Gossip 协议举行通信。每个节点定期向其他节点发送心跳消息，交换状态信息。
[*]通过 Gossip 协议，节点可以了解整个集群的拓扑结构和其他节点的状态。
[*] 故障检测和故障转移：
[*]如果一个节点没有相应其他节点的心跳消息，集群会标记该节点为下线状态（PFAIL）。
[*]如果大多数主节点同意某个节点下线，该节点会被标记为正式下线（FAIL）。
[*]当主节点下线时，集群会选举一个从节点作为新的主节点，并将其提升为主节点。
设置 Redis 集群
以下是设置 Redis 集群的步骤：
环境假设
假设我们有 6 台服务器：
[*]节点1（Master1）：192.168.1.101
[*]节点2（Master2）：192.168.1.102
[*]节点3（Master3）：192.168.1.103
[*]节点4（Slave1）：192.168.1.104
[*]节点5（Slave2）：192.168.1.105
[*]节点6（Slave3）：192.168.1.106
设置 Redis 实例
[*]在每个节点上安装 Redis，并编辑 redis.conf 文件：
port 6379
bind 0.0.0.0
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
daemonize yes
[*]启动 Redis 实例：
redis-server /path/to/redis.conf
创建集群
[*]在任意一台机器上，利用 redis-cli 创建集群，并指定全部节点的 IP 地址和端口：
redis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:6379 192.168.1.105:6379 192.168.1.106:6379 --cluster-replicas 1
--cluster-replicas 1 参数表示为每个主节点分配一个从节点。
测试集群
[*]利用 redis-cli 连接到任意节点，验证集群状态：
redis-cli -c -h 192.168.1.101 -p 6379
[*]在 Redis CLI 中，执行以下下令查看集群信息：
cluster info cluster nodes
故障转移测试
[*]模仿主节点故障，停止某个主节点：
redis-cli -h 192.168.1.101 -p 6379 shutdown
[*]在其他节点上查看集群状态，验证故障转移是否乐成：
redis-cli -c -h 192.168.1.102 -p 6379
在 Redis CLI 中，执行以下下令查看集群信息：
cluster info cluster nodes
总结
Redis 集群通过数据分片和高可用性机制，实现了大规模数据的分布式存储和自动故障转移。通过设置 Redis 集群，可以确保在高并发和大数据量环境下的性能和可靠性。了解和设置 Redis 集群，对于构建高可用、高性能的分布式体系至关重要。
集群的分片机制（哈希槽）
Redis 集群通太过片机制（Sharding）将数据分布在多个节点上，以实现数据的水平扩展和高可用性。分片机制通过哈希槽（Hash Slot）来管理数据分布。下面是对 Redis 集群分片机制的详细解释。
哈希槽（Hash Slot）
Redis 集群中的每个键都会被映射到一个哈希槽中，整个集群有 16384 个哈希槽。每个哈希槽可以分配给差别的主节点（Master）。通过这种方式，Redis 集群可以将数据匀称地分布在全部节点上。
哈希槽的分配和映射
[*] 哈希计算：
[*]每个键通过 CRC16 算法计算哈希值，然后将其对 16384 取模，得到一个哈希槽编号。
[*]计算公式：slot = CRC16(key) % 16384
[*] 哈希槽分配：
[*]Redis 集群将 16384 个哈希槽分配给集群中的主节点。例如，如果有 4 个主节点，每个主节点负责 4096 个哈希槽。
[*]当节点数量变化时，Redis 集群可以重新分配哈希槽，以保证数据匀称分布。
分片机制示例
假设我们有 3 个主节点（Master），每个主节点负责一部分哈希槽：
[*]主节点1（Node1）：负责哈希槽 0 到 5460
[*]主节点2（Node2）：负责哈希槽 5461 到 10922
[*]主节点3（Node3）：负责哈希槽 10923 到 16383
数据写入和读取流程
[*] 数据写入：
[*]客户端发送写操作（如 SET key value）时，Redis 集群根据键计算哈希值，并确定该键所属的哈希槽。
[*]然后，集群会将该操作路由到负责该哈希槽的主节点上。
[*] 数据读取：
[*]客户端发送读操作（如 GET key）时，Redis 集群根据键计算哈希值，并确定该键所属的哈希槽。
[*]然后，集群会将该操作路由到负责该哈希槽的主节点上。
哈希槽的再分配
当集群中的节点数量发生变化时（如增加或减少节点），Redis 集群会重新分配哈希槽，以保证数据的匀称分布。
[*] 增加节点：
[*]当增加新节点时，集群会将一些哈希槽从现有节点迁徙到新节点，以均衡数据分布。
[*]迁徙过程是渐进式的，不会影响集群的正常运行。
[*] 删除节点：
[*]当删除节点时，集群会将该节点负责的哈希槽迁徙到其他节点。
[*]迁徙完成后，该节点将从集群中移除。
集群状态查看
可以利用以下下令查看 Redis 集群的状态和哈希槽分配环境：
redis-cli -c -h <node-ip> -p 6379 cluster nodes
输出示例：
07c37dfeb2353c20114c644e901b70cd6e01d0b7 192.168.1.101:6379@16379 master - 0 1620293852000 1 connected 0-5460
1c291c192b23f07a02314d3a3c5a3bdb88b5bb27 192.168.1.102:6379@16379 master - 0 1620293854000 2 connected 5461-10922
2f1e3fcb6bdf0aeaa5d0f17c0be839da9b7c92e3 192.168.1.103:6379@16379 master - 0 1620293853000 3 connected 10923-16383
每行表示一个节点的信息，此中最后一部分显示该节点负责的哈希槽范围。
设置 Redis 集群
以下是设置 Redis 集群的步骤：
环境假设
假设我们有 6 台服务器：
[*]节点1（Master1）：192.168.1.101
[*]节点2（Master2）：192.168.1.102
[*]节点3（Master3）：192.168.1.103
[*]节点4（Slave1）：192.168.1.104
[*]节点5（Slave2）：192.168.1.105
[*]节点6（Slave3）：192.168.1.106
设置 Redis 实例
[*]在每个节点上安装 Redis，并编辑 redis.conf 文件：
port 6379
bind 0.0.0.0
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
daemonize yes
[*]启动 Redis 实例：
redis-server /path/to/redis.conf
创建集群
[*]在任意一台机器上，利用 redis-cli 创建集群，并指定全部节点的 IP 地址和端口：
redis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:6379 192.168.1.105:6379 192.168.1.106:6379 --cluster-replicas 1
--cluster-replicas 1 参数表示为每个主节点分配一个从节点。
总结
Redis 集群通过哈希槽机制将数据分布在多个节点上，实现数据的水平扩展和高可用性。哈希槽确保数据匀称分布，避免单点故障。明确 Redis 集群的分片机制对于构建高可用、高性能的分布式体系至关重要。
节点的主从关系
在 Redis 集群中，节点分为主节点（Master）和从节点（Slave），每个主节点负责管理一部分哈希槽，并处理与这些哈希槽相干的读写哀求。从节点作为主节点的副本，主要用于数据的高可用性和读取负载的分担。当主节点发生故障时，从节点可以自动提升为新的主节点，从而保证体系的高可用性。
节点的主从关系
主节点（Master）
[*] 职责：
[*]负责管理特定范围的哈希槽，并处理与这些哈希槽相干的全部读写哀求。
[*]负责与其他主节点和从节点举行数据同步和通信。
[*] 数据分片：
[*]在集群中，16384 个哈希槽会匀称分布在全部主节点上，每个主节点负责管理一部分哈希槽。
[*]通过哈希槽，Redis 集群实现数据的水平分片，将数据匀称分布在多个主节点上。
从节点（Slave）
[*] 职责：
[*]作为主节点的数据副本，从节点会定期与主节点同步数据，以确保数据的一致性。
[*]当主节点发生故障时，从节点可以被提升为新的主节点，以保证体系的高可用性。
[*]可以分担主节点的读取负载，从节点可以处理读取哀求，从而进步集群的读取性能。
[*] 数据同步：
[*]从节点会定期从主节点拉取数据更新，以保持数据与主节点一致。
[*]当数据变化时，主节点会将变化通知从节点，从节点会更新其数据副本。
主从关系的设置
在 Redis 集群中，主从关系可以通过启动 Redis 实例并创建集群时指定。
环境假设
假设我们有 6 台服务器：
[*]主节点1（Master1）：192.168.1.101
[*]主节点2（Master2）：192.168.1.102
[*]主节点3（Master3）：192.168.1.103
[*]从节点1（Slave1）：192.168.1.104
[*]从节点2（Slave2）：192.168.1.105
[*]从节点3（Slave3）：192.168.1.106
设置 Redis 实例
在每个节点上安装 Redis，并编辑 redis.conf 文件：
port 6379
bind 0.0.0.0
cluster-enabled yes
cluster-config-file nodes.conf
cluster-node-timeout 5000
appendonly yes
daemonize yes
启动 Redis 实例：
redis-server /path/to/redis.conf
创建集群
在任意一台机器上，利用 redis-cli 创建集群，并指定全部节点的 IP 地址和端口：
redis-cli --cluster create 192.168.1.101:6379 192.168.1.102:6379 192.168.1.103:6379 192.168.1.104:6379 192.168.1.105:6379 192.168.1.106:6379 --cluster-replicas 1
--cluster-replicas 1 参数表示为每个主节点分配一个从节点。
故障转移
[*] 检测故障：
[*]如果一个主节点发生故障，其他主节点和哨兵节点会检测到这一故障，并将其标记为下线（FAIL）。
[*]集群中的哨兵节点会通过投票机制选举一个新的主节点。
[*] 从节点提升为主节点：
[*]选举过程中，集群会从该主节点的从节点中选择一个状态良好的从节点，提升为新的主节点。
[*]新的主节点接受该哈希槽范围内的全部数据和哀求。
[*] 重新设置集群：
[*]提升后的新主节点会通知其他从节点更新其设置，重新与新主节点同步数据。
[*]整个过程是自动举行的，确保集群在主节点故障时仍然能够正常运行。
示例：验证节点状态
可以利用以下下令查看 Redis 集群的节点状态和主从关系：
redis-cli -c -h 192.168.1.101 -p 6379 cluster nodes
输出示例：
07c37dfeb2353c20114c644e901b70cd6e01d0b7 192.168.1.101:6379@16379 master - 0 1620293852000 1 connected 0-5460
1c291c192b23f07a02314d3a3c5a3bdb88b5bb27 192.168.1.102:6379@16379 master - 0 1620293854000 2 connected 5461-10922
2f1e3fcb6bdf0aeaa5d0f17c0be839da9b7c92e3 192.168.1.103:6379@16379 master - 0 1620293853000 3 connected 10923-16383
4acfa2b1e14b7e6d351cf1f6d4d2dfbd04e4e65d 192.168.1.104:6379@16379 slave 07c37dfeb2353c20114c644e901b70cd6e01d0b7 0 1620293855000 4 connected5bb9f9e92b1a5d7ec6f9e0f3f3e7b5bf30ac7e2b 192.168.1.105:6379@16379 slave 1c291c192b23f07a02314d3a3c5a3bdb88b5bb27 0 1620293856000 5 connected6e2b96b8ebdc95a6b9f7e4f0d6d5d5fb9c5e2b7d 192.168.1.106:6379@16379 slave 2f1e3fcb6bdf0aeaa5d0f17c0be839da9b7c92e3 0 1620293857000 6 connected
每行表示一个节点的信息，此中最后一部分显示该节点负责的哈希槽范围或其作为从节点跟随的主节点。
总结
Redis 集群中的节点分为主节点和从节点，主节点负责数据的读写操作和数据分片，从节点作为主节点的副本，提供数据高可用性和读操作分担。当主节点发生故障时，从节点可以自动提升为主节点，保证体系的高可用性。明确和设置 Redis 集群中的主从关系，对于构建高性能和高可用性的分布式体系至关重要。
集群的重均衡和扩容
Redis 集群的重均衡和扩容是确保数据在集群节点间匀称分布的重要操作。通过重均衡和扩容，Redis 集群可以在添加或删除节点时，动态调整数据分布，以保持体系的性能和可靠性。
集群重均衡（Rebalancing）
重均衡是指在现有的 Redis 集群中重新分配哈希槽，使数据在节点间更加匀称地分布。重均衡通常在以下环境下举行：
[*]集群中的某些节点负载过重，必要将部分数据迁徙到负载较轻的节点。
[*]集群添加或删除节点后，必要重新分配哈希槽。
1. 重均衡的触发
重均衡可以手动触发，也可以通过自动化工具实现。常见的场景包罗：
[*]手动添加或删除节点后，通过下令触发重均衡。
[*]监控体系检测到某些节点负载过高，自动触发重均衡。
2. 手动重均衡
可以利用 redis-cli 工具手动触发重均衡操作。以下是具体步骤：
[*]查看集群状态：
redis-cli --cluster check <node-ip>:<port>
此下令会检查集群的状态，并显示哈希槽的分布环境。
[*]重均衡集群：
redis-cli --cluster rebalance <node-ip>:<port>
例如：
redis-cli --cluster rebalance 192.168.1.101:6379
此下令会根据当前集群的负载环境，重新分配哈希槽。
集群扩容
扩容是指向 Redis 集群中添加新的节点，以增加存储容量和处理本领。扩容操作必要确保新节点能够匀称地分担负载，并且数据能够正确地迁徙到新节点。
1. 添加新节点
假设我们有一个已经运行的 Redis 集群，现在我们要添加一个新的节点。
[*]启动新节点：
在新节点上安装 Redis，并启动实例：
redis-server /path/to/redis.conf
[*]将新节点添加到集群：
利用 redis-cli 工具将新节点添加到现有集群：
redis-cli --cluster add-node <new-node-ip>:<port> <existing-node-ip>:<port>
例如：
redis-cli --cluster add-node 192.168.1.107:6379 192.168.1.101:6379
2. 重新分配哈希槽
在添加新节点后，必要重新分配哈希槽，以确保数据在全部节点间匀称分布。
[*]重新分配哈希槽：
利用 redis-cli 工具重新分配哈希槽：
redis-cli --cluster reshard <node-ip>:<port>
例如：
redis-cli --cluster reshard 192.168.1.101:6379
[*]指定哈希槽数量和目标节点：
体系会提示输入要迁徙的哈希槽数量和目标节点。输入要迁徙的哈希槽数量，然后指定目标节点（新添加的节点）：
How many slots do you want to move (from 1 to 16384)? 4096
What is the receiving node ID? <new-node-id>
集群缩容
缩容是指从 Redis 集群中移除节点，以减少存储容量或处理本领。缩容操作必要确保数据能够正确地迁徙到其他节点，以保持数据的完整性。
1. 移除节点
假设我们要从集群中移除一个节点。
[*]查看节点状态：
利用 redis-cli 工具查看集群的节点状态，找到要移除的节点 ID：
redis-cli --cluster nodes <node-ip>:<port>
[*]移除节点：
利用 redis-cli 工具移除节点：
redis-cli --cluster del-node <node-ip>:<port> <node-id>
例如：
redis-cli --cluster del-node 192.168.1.101:6379 <node-id>
示例操作
假设我们有一个集群，初始有 3 个主节点，现要添加一个新的主节点，并举行重均衡。
1. 添加新节点
[*]启动新节点：
redis-server /path/to/redis.conf
[*]将新节点添加到集群：
redis-cli --cluster add-node 192.168.1.104:6379 192.168.1.101:6379
2. 重新分配哈希槽
[*]启动重均衡：
redis-cli --cluster rebalance 192.168.1.101:6379
体系会自动计算哈希槽的最佳分配，并迁徙数据到新节点。
总结
Redis 集群的重均衡和扩容通过动态调整哈希槽分配，实现数据的匀称分布和高可用性。重均衡确保集群中的节点负载均衡，而扩容则允许集群在必要时增加新的节点，以进步存储容量和处理本领。明确和正确操作这些机制，对于保持 Redis 集群的高性能和高可用性至关重要。
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。
页:
[1]