ToB企服应用市场:ToB评测及商务社交产业平台

标题: Redis几种部署模式介绍 [打印本页]
作者: 温锦文欧普厨电及净水器总代理    时间: 2024-6-9 07:04
标题: Redis几种部署模式介绍
Redis 提供了几种差别的部署模式，以满足差别的利用场景和可用性需求。这些模式包罗单机模式、主从复制、哨兵模式和集群模式。下面我将扼要介绍每种模式的特点和用途：
每种模式都有其适用的场景，选择哪种模式取决于你的具体需求，好比数据量大小、读写哀求的频率、对数据可用性和稳固性的要求等。
主从复制（Replication）

Redis 主从复制（Replication）是 Redis 提供的一种数据复制机制，用于实现数据的高可用性和读写分离。通过主从复制，Redis 可以将数据从一个主节点（Master）复制到一个或多个从节点（Slave），从而进步体系的容错本领和读性能。下面是主从复制的工作原理及其详细解释。
主从复制的工作原理

1. 初始化复制

当从节点启动时，它会发送 PSYNC 下令哀求从主节点举行同步。主节点会根据从节点的哀求举行相应的处理。

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
你应该看到类似以下的输出，显示主节点和从节点的关系：
  1. # Replication
  2. role:slave
  3. master_host:192.168.1.100
  4. master_port:6379
  5. master_link_status:up
  6. ...
复制代码
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.conf 文件中，可以调整复制缓冲区的大小：
repl-backlog-size 64mb
监控复制耽误

在从节点上，利用以下下令监控复制耽误：
redis-cli info replication
输出中包罗以下字段，可以用于监控复制耽误：

通过监控这些数据，可以了解主从复制的实时状态，并采取相应的优化步伐。
总结

明确和优化 Redis 的复制耽误和一致性标题对于确保体系的可靠性和性能至关重要。通过优化网络连接、增加从节点性能、调整复制缓冲区大小和监控复制耽误，可以有效减少复制耽误和一致性标题，确保 Redis 体系的高可用性和数据一致性。
哨兵模式（Sentinel）

哨兵的工作原理

Redis 哨兵（Sentinel）是一种用于实现 Redis 高可用性的机制。哨兵体系监控主节点和从节点，自动执行故障转移，确保体系的持续可用性。
哨兵体系由一个或多个哨兵实例构成，这些实例协同工作以监控 Redis 集群，并在必要时执行故障转移。哨兵的主要功能包罗：
哨兵的组件和流程

1. 哨兵监控

每个哨兵实例会定期向主节点和从节点发送 PING 下令，以检查它们的状态。如果一个节点在设置的时间内没有相应 PING 下令，哨兵会将其标记为主观下线（Subjectively Down，简称 SDOWN）。
2. 哨兵协商

如果多个哨兵实例都将同一个节点标记为主观下线，并且凌驾了设置的阈值时间（通常为几秒钟），哨兵体系会将该节点标记为客观下线（Objectively Down，简称 ODOWN）。此时，哨兵体系会触发故障转移流程。
3. 故障转移

当主节点被标记为 ODOWN 时，哨兵会从从节点中选举一个新的主节点。选举过程包罗以下步骤：

4. 通知客户端

哨兵可以作为设置提供者，客户端可以连接哨兵获取当前主节点的地址。这样，即使发生故障转移，客户端也能自动连接到新的主节点，保持高可用性。
设置 Redis 哨兵

设置 Redis 哨兵体系可以确保 Redis 的高可用性，通过监控主节点和从节点，自动执行故障转移。以下是详细的设置步骤，包罗设置主节点、从节点和哨兵实例。
环境假设

假设我们有三台服务器：

1. 设置主节点

  1. sudo apt update
  2. sudo apt install redis-server
  3. sudo systemctl start redis-server
复制代码

  1. bind 0.0.0.0        # 允许所有 IP 访问
  2. port 6379           # Redis 端口
  3. daemonize yes       # 以守护进程模式启动
复制代码

2. 设置从节点

在从节点1和从节点2上举行相同的设置步骤。
  1. [/code] [code]sudo apt update
  2. sudo apt install redis-server
  3. sudo nano /etc/redis/redis.conf
复制代码

  1. bind 0.0.0.0              # 允许所有 IP 访问
  2. port 6379                 # Redis 端口
  3. daemonize yes             # 以守护进程模式启动
  4. 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 上各运行一个哨兵实例。
sudo nano /etc/redis/sentinel.conf
  1. [/code] [code]port 26379                            # 哨兵监听的端口
  2. sentinel monitor mymaster 192.168.1.100 6379 2  # 监控的主节点名称、IP 和端口，以及多数投票的哨兵数量
  3. sentinel down-after-milliseconds mymaster 5000  # 标记主节点为主观下线的超时时间（毫秒）
  4. sentinel failover-timeout mymaster 10000        # 故障转移超时时间（毫秒）
  5. 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
输出示例：
  1. # Replication
  2. role:slave
  3. master_host:<new-master-ip>
  4. master_port:6379
  5. master_link_status:up
  6. ...
复制代码

总结

通过设置 Redis 哨兵，可以实现 Redis 的高可用性。当主节点发生故障时，哨兵会自动执行故障转移，选举新的主节点，确保体系的持续可用性。哨兵的设置相对简单，但在生产环境中起到关键作用。
哨兵的主观下线和客观下线

Redis 哨兵体系中的主观下线（Subjectively Down，简称 SDOWN）和客观下线（Objectively Down，简称 ODOWN）是用于描述哨兵对 Redis 节点（主节点或从节点）状态的判断。这两个状态用于决定是否必要举行故障转移。以下是详细解释：
主观下线（Subjectively Down，SDOWN）

主观下线是单个哨兵实例对一个节点（主节点或从节点）做出的独立判断。具体步骤如下：
设置示例

在哨兵设置文件 sentinel.conf 中，可以通过以下设置设置主观下线的超时时间：
sentinel down-after-milliseconds mymaster 5000
上述设置表示如果主节点在 5000 毫秒（5 秒）内没有相应 PING 下令，哨兵会将其标记为主观下线。
客观下线（Objectively Down，ODOWN）

客观下线是多个哨兵实例共同对一个节点（通常是主节点）做出的判断。具体步骤如下：
设置示例

在哨兵设置文件 sentinel.conf 中，可以通过以下设置设置必要多少哨兵实例的判断才会将节点标记为客观下线：
sentinel monitor mymaster 192.168.1.100 6379 2
上述设置表示至少必要 2 个哨兵实例以为主节点下线，才会将其标记为客观下线。
工作流程示例

总结

Redis 哨兵体系通过主观下线和客观下线机制，确保在主节点发生故障时，能够及时、可靠地检测到故障并举行自动故障转移。主观下线是单个哨兵实例的独立判断，而客观下线是多个哨兵实例共同确认的效果。通过这种机制，Redis 能够在高可用性环境中提供可靠的数据服务。
哨兵的故障转移机制

Redis 哨兵的故障转移机制是确保 Redis 集群在主节点故障时能够自动选举新的主节点，从而保证体系的高可用性。以下是详细的解释和工作流程。
故障转移机制的工作原理

故障转移（Failover）是指当哨兵检测到主节点故障（客观下线，ODOWN）时，哨兵体系会自动选举一个新的从节点为主节点，并重新设置其他从节点，以保持集群的正常运行。
故障转移的详细步骤

故障转移示例

假设我们有以下环境：

哨兵设置示例

哨兵设置文件 sentinel.conf 示例：
  1. [/code] [code]port 26379
  3. # 监控的主节点名称、IP 和端口
  4. sentinel monitor mymaster 192.168.1.100 6379 2
  6. # 标记主节点为主观下线的超时时间（毫秒）
  7. sentinel down-after-milliseconds mymaster 5000
  9. # 故障转移超时时间（毫秒）
  10. sentinel failover-timeout mymaster 10000
  12. # 故障转移时，最多同时对多少个从节点进行同步
  13. sentinel parallel-syncs mymaster 1
复制代码

启动哨兵实例

在每台服务器上启动哨兵实例：
redis-sentinel /etc/redis/sentinel.conf
模仿故障转移

总结

Redis 哨兵的故障转移机制通过监控主节点和从节点的状态，自动选举新的主节点，并重新设置集群，确保体系的高可用性。哨兵的设置和运行相对简单，但在生产环境中起到关键作用，是确保 Redis 高可用的重要机制。通过详细明确哨兵的工作原理和设置，可以更好地保障 Redis 体系的稳固运行。
Redis 集群（Cluster）

Redis 集群的工作原理

Redis 集群（Redis Cluster）是一种分布式的 Redis 部署模式，用于在多个节点之间分配数据，从而实现数据的水平扩展和高可用性。Redis 集群通过数据分片（sharding）和节点间的自动故障转移机制，确保在大规模和高负载环境下的性能和可靠性。下面是 Redis 集群的工作原理的详细解释。
Redis 集群的根本概念

数据分片和哈希槽

节点间通信

设置 Redis 集群

以下是设置 Redis 集群的步骤：
环境假设

假设我们有 6 台服务器：

设置 Redis 实例

  1. [/code] [code]port 6379
  2. bind 0.0.0.0
  3. cluster-enabled yes
  4. cluster-config-file nodes.conf
  5. cluster-node-timeout 5000
  6. appendonly yes
  7. daemonize yes
复制代码

redis-server /path/to/redis.conf
创建集群

  1. [/code] [code]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 -c -h 192.168.1.101 -p 6379
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 集群可以将数据匀称地分布在全部节点上。
哈希槽的分配和映射

分片机制示例

假设我们有 3 个主节点（Master），每个主节点负责一部分哈希槽：

数据写入和读取流程

哈希槽的再分配

当集群中的节点数量发生变化时（如增加或减少节点），Redis 集群会重新分配哈希槽，以保证数据的匀称分布。
集群状态查看

可以利用以下下令查看 Redis 集群的状态和哈希槽分配环境：
redis-cli -c -h <node-ip> -p 6379 cluster nodes
输出示例：
  1. [/code] [code]07c37dfeb2353c20114c644e901b70cd6e01d0b7 192.168.1.101:6379@16379 master - 0 1620293852000 1 connected 0-5460
  2. 1c291c192b23f07a02314d3a3c5a3bdb88b5bb27 192.168.1.102:6379@16379 master - 0 1620293854000 2 connected 5461-10922
  3. 2f1e3fcb6bdf0aeaa5d0f17c0be839da9b7c92e3 192.168.1.103:6379@16379 master - 0 1620293853000 3 connected 10923-16383
复制代码

每行表示一个节点的信息，此中最后一部分显示该节点负责的哈希槽范围。
设置 Redis 集群

以下是设置 Redis 集群的步骤：
环境假设

假设我们有 6 台服务器：

设置 Redis 实例

  1. [/code] [code]port 6379
  2. bind 0.0.0.0
  3. cluster-enabled yes
  4. cluster-config-file nodes.conf
  5. cluster-node-timeout 5000
  6. appendonly yes
  7. daemonize yes
复制代码

redis-server /path/to/redis.conf
创建集群

  1. [/code] [code]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）


从节点（Slave）


主从关系的设置

在 Redis 集群中，主从关系可以通过启动 Redis 实例并创建集群时指定。
环境假设

假设我们有 6 台服务器：

设置 Redis 实例

在每个节点上安装 Redis，并编辑 redis.conf 文件：
  1. [/code] [code]port 6379
  2. bind 0.0.0.0
  3. cluster-enabled yes
  4. cluster-config-file nodes.conf
  5. cluster-node-timeout 5000
  6. appendonly yes
  7. daemonize yes
复制代码

启动 Redis 实例：
redis-server /path/to/redis.conf
创建集群

在任意一台机器上，利用 redis-cli 创建集群，并指定全部节点的 IP 地址和端口：
  1. 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-cli -c -h 192.168.1.101 -p 6379 cluster nodes
输出示例：
  1. [/code] [code]07c37dfeb2353c20114c644e901b70cd6e01d0b7 192.168.1.101:6379@16379 master - 0 1620293852000 1 connected 0-5460
  2. 1c291c192b23f07a02314d3a3c5a3bdb88b5bb27 192.168.1.102:6379@16379 master - 0 1620293854000 2 connected 5461-10922
  3. 2f1e3fcb6bdf0aeaa5d0f17c0be839da9b7c92e3 192.168.1.103:6379@16379 master - 0 1620293853000 3 connected 10923-16383
  4. 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
体系会提示输入要迁徙的哈希槽数量和目标节点。输入要迁徙的哈希槽数量，然后指定目标节点（新添加的节点）：
  1. [/code] [code]How many slots do you want to move (from 1 to 16384)? 4096
  2. 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企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4