云南网站建设找天软,专注营销型网站建设公司 做网站,wordpress文档id初始化,广州注册公司新政策目录 1.什么是redis事务#xff1f;
2.如何使用 Redis 事务#xff1f;
3.Redis 事务为什么不支持原子性
4.Redis 事务支持持久性吗
5.Redis事务基于lua脚本的实现
6.Redis集群的主从复制模型是怎样的#xff1f;
7.Redis集群中#xff0c;主从复制的数据同步的步骤 …目录 1.什么是redis事务
2.如何使用 Redis 事务
3.Redis 事务为什么不支持原子性
4.Redis 事务支持持久性吗
5.Redis事务基于lua脚本的实现
6.Redis集群的主从复制模型是怎样的
7.Redis集群中主从复制的数据同步的步骤
8.Redis 增量复制的流程
9.Redis 为什么主从全量复制使用RDB而不使用AOF
10.Redis 为什么还有无磁盘复制模式
11.什么是Redis Sentinel 有什么用
12.Redis Sentinel集群是通过什么方式组建的
13.Redis 哨兵是如何监控Redis集群的
14.Sentinel 如何检测节点是否下线主观下线与客观下线的区别?
15.哨兵的选举机制是什么样的
16.Redis主库判定客观下线了那么如何从剩余的从库中选择一个新的主库呢
17.新的主库选择出来后如何进行故障的转移
18.Sentinel 可以防止脑裂吗
19.为什么需要 Redis Cluster解决了什么问题有什么优势
20.Redis Cluster 是如何分片的
21.为什么 Redis Cluster 的哈希槽是 16384 个?
22.如何确定给定 key 的应该分布到哪个哈希槽中
23.Redis Cluster 支持重新分配哈希槽吗
24.Redis Cluster 扩容缩容期间可以提供服务吗
25.Redis Cluster 中的节点是怎么进行通信的 1.什么是redis事务
Redis事务是指在Redis数据库中进行一组命令的操作这些命令可以被作为一个单独的、原子性的操作进行提交或者回滚。事务可以保证一组命令的原子性即在一个事务中的所有命令要么全部被执行成功要么全部不执行。
2.如何使用 Redis 事务
在Redis中使用事务需要使用MULTI、EXEC、WATCH和DISCARD等命令。下面是一个简单的例子展示如何使用Redis事务。
假设我们需要在Redis中将用户的账户余额减去一定数量的钱并将这些钱转移到另一个账户。我们可以使用Redis事务来保证这两个操作的原子性。
首先使用MULTI命令来开始一个事务
MULTI然后将要执行的命令添加到事务中例如
DECRBY user:100:balance 50
INCRBY user:101:balance 50这里我们使用DECRBY命令来减少用户100的余额使用INCRBY命令来增加用户101的余额。注意这些命令并没有直接执行而是被添加到了事务中。
接下来使用EXEC命令来提交事务
EXEC如果事务执行成功Redis将返回一个包含每个命令执行结果的数组如果事务执行失败Redis将返回一个空数组。
如果在事务执行期间我们需要监视一个或多个键以便在其他客户端对它们进行修改时取消事务我们可以使用WATCH命令。例如我们可以使用以下命令来监视用户100的余额键
WATCH user:100:balance如果在事务执行期间其他客户端修改了被监视的键那么事务将被取消所有已添加到事务中的命令都不会被执行。此时我们可以使用DISCARD命令来取消事务并清除所有已添加到事务中的命令
DISCARD这样我们就可以使用Redis事务来保证一组操作的原子性避免由并发操作引起的数据不一致问题。
3.Redis 事务为什么不支持原子性
虽然Redis的事务可以在多个命令之间执行但是在执行事务期间Redis不会将它们视为一个单独的操作单元。因此如果在一个事务中执行多个命令其中一个命令失败那么其他命令仍然会执行这就违反了原子性的要求。
Redis事务的主要目的是减少多个命令之间的通信开销并确保在执行事务期间其他客户端不能干扰正在执行的事务。因此Redis事务只是一种逻辑分组命令的方式并不能保证原子性。
Redis 官网也解释了自己为啥不支持回滚。简单来说就是 Redis 开发者们觉得没必要支持回滚这样更简单便捷并且性能更好。Redis 开发者觉得即使命令执行错误也应该在开发过程中就被发现而不是生产过程中。
4.Redis 事务支持持久性吗
Redis 的持久化方式都是异步执行的因为同步持久化会对 Redis 的性能造成很大的影响。因此在使用 Redis 事务时虽然事务本身可以保证一组命令的原子性但是对于这些命令对 Redis 中的数据所做的修改是否被持久化到磁盘上Redis 并不能做出保证。
5.Redis事务基于lua脚本的实现
Redis 事务可以基于 Lua 脚本来实现。在 Lua 脚本中可以使用 Redis 的 MULTI 命令和 EXEC 命令来开启和提交事务并在事务中执行多个 Redis 命令。Lua 脚本可以将多个 Redis 命令封装为一个整体从而保证这些命令的原子性执行。
以下是一个使用 Lua 脚本实现 Redis 事务的示例
-- 定义 Lua 脚本其中包含多个 Redis 命令
local script [[-- 开启 Redis 事务redis.call(MULTI)-- 执行多个 Redis 命令redis.call(SET, name, Alice)redis.call(INCR, count)-- 提交 Redis 事务return redis.call(EXEC)
]]-- 加载 Lua 脚本
local sha redis.call(SCRIPT, LOAD, script)-- 执行 Lua 脚本即执行 Redis 事务
redis.call(EVALSHA, sha)上述 Lua 脚本使用了 Redis 的 MULTI 命令开启一个事务然后执行了两个 Redis 命令SET 和 INCR最后使用 EXEC 命令提交事务。通过使用 EVALSHA 命令来执行 Lua 脚本从而实现了 Redis 事务的功能。
在 Lua 脚本中还可以使用 Redis 的 WATCH 命令来监控一个或多个键并在事务执行之前检查这些键的值是否被其他客户端修改过。如果这些键的值被修改过则事务执行失败需要重新执行。通过使用 WATCH 命令可以保证事务执行期间所操作的键值不会被其他客户端修改从而避免了其他客户端的干扰。
6.Redis集群的主从复制模型是怎样的
Redis集群采用主从复制模型实现高可用性和可扩展性。在Redis集群中每个节点可以是主节点或从节点。
主节点负责处理客户端请求并将写操作同步到所有从节点。从节点接收来自主节点的同步复制数据并复制主节点上的所有写操作以保持自己的数据与主节点同步。
当主节点失效时Redis集群会自动将其中一个从节点升级为主节点以确保服务的可用性和数据的完整性。当新的主节点选举完成后其他从节点将开始同步新的主节点以便它们能够快速接管主节点的工作并继续服务。
Redis集群的主从复制模型通过实现数据的多个副本提高了系统的可用性和可靠性。同时通过添加更多的从节点Redis集群还可以水平扩展以处理更多的并发请求。 7.Redis集群中主从复制的数据同步的步骤
1.同步命令当从节点重新上线后它会向主节点发送SYNC命令表示要进行全量同步。
2.全量同步主节点接收到SYNC命令后会将自己的所有数据发送给从节点从节点会将这些数据写入自己的内存中。
3.增量同步全量同步完成后主节点会将新的写操作发送给从节点从节点也会在自己的内存中执行这些写操作以保持数据同步。
需要注意的是当主节点接收到写操作后它会先将数据写入自己的内存中然后才会将命令传递给从节点。因此如果主节点在传递命令之前崩溃了可能会导致从节点的数据不完整。在这种情况下从节点需要重新向主节点发送SYNC命令进行全量同步。 8.Redis 增量复制的流程 Redis 增量复制是 Redis 主从复制的一种方式用于将主节点的数据同步到从节点。其流程如下 从节点发送 SYNC 命令到主节点请求全量复制。主节点接收到请求后开始生成 RDB 快照文件并将文件的数据同步给从节点从节点接收到数据后将其保存到本地。 主节点在生成 RDB 文件的过程中将所有的写命令包括读写命令缓存到内存中并将缓存的写命令追加到一个专门用于增量复制的内存缓冲区中。这个缓冲区称为复制缓冲区replication buffer。 主节点将 RDB 文件传输完毕后开始将复制缓冲区中的命令同步给从节点。主节点会将自己的复制缓冲区中的命令传输给从节点并等待从节点对其进行确认。主节点会记录每个从节点在哪个位置接收到了命令以便在下一次传输时只传输从这个位置开始的命令。 从节点接收到主节点的命令后将其保存到本地的数据库中并向主节点发送一个 ACK 命令表示已经接收到了这些命令。主节点接收到 ACK 命令后更新自己的记录标记该从节点已经同步到了哪个位置。 从节点定期向主节点发送 PSYNC 命令请求增量复制。主节点接收到请求后判断是否可以进行增量复制。如果从节点的复制偏移量replication offset在主节点的复制缓冲区中则可以进行增量复制否则需要进行全量复制。 如果可以进行增量复制则主节点会将从节点当前的复制偏移量所对应的命令以及其之后的命令传输给从节点。从节点接收到这些命令后将其保存到本地数据库中。 如果不能进行增量复制则主节点会重新生成 RDB 文件并将其传输给从节点。 重复执行步骤 5 到 7直到从节点与主节点同步完成。
需要注意的是增量复制的缓存空间是有限的如果主节点的缓存区已经满了就无法再缓存新的写命令了此时主节点只能进行全量复制。
9.Redis 为什么主从全量复制使用RDB而不使用AOF RDB 文件的数据格式更加简单可以更快地进行数据加载和恢复。RDB 文件只包含一份数据的快照而 AOF 文件则记录了所有的写命令因此 AOF 文件的数据格式更加复杂。 RDB 文件的体积更小传输速度更快。RDB 文件只包含一份数据的快照因此其体积相对于 AOF 文件更小传输速度也更快。在进行数据同步时传输速度是一个重要的考虑因素。 RDB 文件可以在不停止 Redis 服务的情况下进行数据备份和恢复。由于 RDB 文件只包含一份数据的快照因此可以在 Redis 不停止服务的情况下进行数据备份和恢复。而 AOF 文件则需要在 Redis 停止服务时进行备份和恢复。
10.Redis 为什么还有无磁盘复制模式
Redis 无磁盘复制模式Diskless replication是一种新的主从复制方式其主要优点是可以减少网络带宽的占用提高主从同步的速度同时也减轻了主节点的磁盘负载。其原理是将主节点中的数据直接传输给从节点而不需要将数据先写入到磁盘中。在无磁盘复制模式下主节点不需要生成 RDB 文件或 AOF 文件因此也不需要进行磁盘的读写操作。
无磁盘复制模式的优点在于可以提高主从同步的速度尤其是在大规模的集群中。由于数据传输是通过网络进行的因此在数据量较大的情况下会占用较大的带宽。使用无磁盘复制模式可以减少网络带宽的占用提高主从同步的速度。同时无磁盘复制模式还可以减轻主节点的磁盘负载避免了磁盘读写带来的性能问题。
然而无磁盘复制模式也存在一些缺点。由于数据传输是通过网络进行的因此会增加网络的负担特别是在数据量较大的情况下。此外由于数据传输是直接从主节点到从节点因此如果从节点数量较多可能会增加主节点的负载压力。
启用 Redis 无磁盘复制模式需要同时满足以下两个条件 从节点必须运行在 Redis 6.0 及以上版本。 主节点必须运行在 Redis 6.2 及以上版本并且需要在配置文件中设置 repl-diskless-sync 选项为 yes。
11.什么是Redis Sentinel 有什么用
Redis Sentinel 的主要作用是监控 Redis 主节点和从节点的健康状况并在发生故障时自动切换到备用节点保证 Redis 服务的连续性和可用性。具体来说Redis Sentinel 提供了以下功能 故障检测Redis Sentinel 可以周期性地检测 Redis 主从节点的健康状态包括网络连接状态、CPU 使用率、内存使用率等。 故障转移当 Redis 主节点宕机或不可达时Redis Sentinel 会自动将其中一台从节点切换为新的主节点使得 Redis 服务可以继续提供服务。 自动故障恢复当 Redis 主节点恢复正常运行时Redis Sentinel 会将其重新添加到主从复制架构中使得 Redis 服务恢复正常运行。 配置管理Redis Sentinel 可以动态地管理 Redis 主从节点的配置包括添加、删除、修改节点、设置节点权重等。
Redis Sentinel 的主要作用是提高 Redis 服务的可靠性和可用性保证 Redis 服务在出现故障时能够快速地自动切换到备用节点从而实现无缝切换。在生产环境中Redis Sentinel 经常被用于构建高可用的 Redis 集群保证 Redis 服务能够持续、稳定地运行。 12.Redis Sentinel集群是通过什么方式组建的
Redis Sentinel哨兵实例之间可以通过 Redis 提供的 pub/sub发布/订阅机制相互发现。当一个 Sentinel 实例启动时它会向 Redis 主节点发送 SENTINEL is-master-down-by-addr 命令询问主节点是否宕机。如果主节点未响应哨兵实例会向其他 Sentinel 实例发送同样的命令以尝试确认主节点是否宕机。这个过程就利用了 Redis 的 pub/sub 机制哨兵实例可以通过订阅特定的频道接收其他 Sentinel 实例发送的状态更新消息以便及时发现主节点故障。
在哨兵集群中每个 Sentinel 实例都会向特定的频道发送状态更新信息包括主节点的状态、从节点的状态以及哨兵实例的状态等。其他 Sentinel 实例可以通过订阅这些频道接收并处理状态更新信息从而保证 Redis Sentinel 集群的稳定性和可用性。
在主从集群中主库上有一个名为__sentinel__:hello的频道不同哨兵就是通过它来相互发现实现互相通信的。在下图中哨兵 1 把自己的 IP172.16.19.3和端口26579发布到__sentinel__:hello频道上哨兵 2 和 3 订阅了该频道。那么此时哨兵 2 和 3 就可以从这个频道直接获取哨兵 1 的 IP 地址和端口号。然后哨兵 2、3 可以和哨兵 1 建立网络连接。 通过这个方式哨兵 2 和 3 也可以建立网络连接这样一来哨兵集群就形成了。它们相互间可以通过网络连接进行通信比如说对主库有没有下线这件事儿进行判断和协商。
13.Redis 哨兵是如何监控Redis集群的
Redis Sentinel哨兵通过定期发送命令检查 Redis 主从节点的健康状况以及通过 Redis 提供的 pub/sub 机制实时监控 Redis 集群状态从而保证 Redis 集群的可用性和稳定性。具体来说Redis Sentinel 主要通过以下几个方面来监控 Redis 集群
1.定期发送命令检查 Redis 主从节点的健康状况
Redis Sentinel 会定期向 Redis 主从节点发送命令例如 PING 命令或 INFO 命令检查节点是否正常运行。如果节点未能正常响应命令Redis Sentinel 会将其标记为 DOWN 状态并开始进行自动故障转移操作。
2.通过 pub/sub 机制实时监控 Redis 集群状态
Redis Sentinel 使用 Redis 提供的 pub/sub 机制订阅特定的频道以接收 Redis 集群状态的更新信息。例如当一个 Redis 主节点发生故障时哨兵会向订阅的频道发布故障信息通知其他哨兵实例进行故障转移操作。其他哨兵实例也会通过订阅这些频道接收更新信息从而保证集群状态的一致性和正确性。
3.定义故障转移策略和选举算法
Redis Sentinel 可以通过配置文件或命令行参数定义故障转移策略和选举算法以满足不同场景下的需求。例如可以定义故障转移操作的超时时间和重试次数或者指定选举算法的优先级和权重等。
14.Sentinel 如何检测节点是否下线主观下线与客观下线的区别?
Redis Sentinel 是一个高可用性的解决方案它通过监控 Redis 实例的状态来实现自动故障转移。为了检测 Redis 节点是否下线Redis Sentinel 会使用以下两种方式
1.主观下线Subjective Down
在 Redis Sentinel 中每个 Sentinel 进程会定期向其他 Sentinel 进程发送 PING 命令来检查 Redis 实例是否正常运行。如果一个 Sentinel 进程在指定时间内没有收到 Redis 实例的 PONG 响应那么它就会将该 Redis 实例标记为主观下线。这个判断是基于 Sentinel 进程本身的主观认定。
2.客观下线Objective Down
除了主观下线外Redis Sentinel 还支持客观下线的检测。当多个 Sentinel 进程都认为某个 Redis 实例已经下线时该 Redis 实例就会被标记为客观下线。具体来说当超过一半的 Sentinel 进程在指定时间内都认为某个 Redis 实例已经下线时该 Redis 实例就会被标记为客观下线。
15.哨兵的选举机制是什么样的
哨兵的选举机制使用的是Raft选举算法。
Raft选举算法是一种分布式一致性算法它将节点分为三种角色leader领导者、follower跟随者和candidate候选者。在初始状态下所有节点都是follower。如果某个follower节点无法与leader节点保持通信它就会变成candidate并且开始新一轮的选举。
选举过程分为以下几个步骤 选举超时Election Timeoutcandidate节点会在随机的时间间隔内成为candidate状态。此时它会向其他节点发送请求投票的消息并开始计时。 收集投票Request Vote收到投票请求的节点会检查候选者的term任期是否比自己的大如果是则转换为follower状态并将自己的vote for设置为候选者的ID。如果已经投过票或者发现候选者的term比自己小则拒绝投票。 获得多数投票Winning the Election如果候选者收到了超过半数的投票则它将成为新的leader并向其他节点发送心跳消息让它们知道新的leader已经产生。 防止分裂Preventing Split Votes如果候选者的term比follower节点的term大则follower节点会转换为candidate状态开始新一轮的选举。
在哨兵中每个sentinel节点都可以成为candidate通过相互之间的投票选出新的leader节点。为了确保选举的稳定性和可靠性哨兵中的选举过程还加入了一些附加机制例如quorum机制即必须得到大部分节点的投票才能选举成功。这些机制都是为了确保哨兵集群在出现故障或者网络分裂等情况下能够快速地选出新的leader节点保证系统的可用性。
16.Redis主库判定客观下线了那么如何从剩余的从库中选择一个新的主库呢
1.首先通过 Sentinel 或其他监控工具检测出当前可用的所有从库并且筛选出健康的、回复哨兵 ping 响应的从节点。
2.接着从健康的从节点中选择一个作为新的主库可以依据以下优先级 优先选择配置文件中设置了 slave-priority 优先级最高的从节点。 如果有多个从节点的 slave-priority 优先级相同那么就选择其中的一个复制偏移量最大的从节点作为新的主库。因为复制偏移量最大的从节点的数据最新因此成为新的主库后数据的损失最小。 如果多个从节点的复制偏移量也相同那么可以随机选择其中的一个作为新的主库。
3.在选择新的主库后需要更新其他所有健康的从节点的配置文件使其成为新的从节点开始复制新的主库。这样可以确保数据的一致性。 总之通过筛选健康的、回复哨兵 ping 响应的从节点并优先选择 slave-priority 优先级最高的节点和复制偏移量最大的节点可以选择出最适合成为新主库的从节点从而实现 Redis 的高可用性。
17.新的主库选择出来后如何进行故障的转移
Redis Sentinel 实现故障转移的过程如下
1.主节点失效检测
Sentinel 定期向主节点发送 PING 命令检测主节点是否还处于正常状态。如果 Sentinel 在指定时间内未能收到主节点的 PONG 响应或者收到了一个认为主节点已经下线的 Sentinel 的通知那么 Sentinel 将判断主节点已经失效。
2.选择新的主节点
当 Sentinel 发现主节点已经失效后它会从 Redis 从节点中选择一个作为新的主节点。在选择新的主节点时Sentinel 会考虑多个因素比如从节点的复制偏移量、优先级等。
3.执行故障转移操作
一旦 Sentinel 确定了新的主节点它会向其他 Sentinel 进程发送一条 SENTINEL is-master-down-by-addr 命令要求其他 Sentinel 进程执行故障转移操作。在执行故障转移操作时Sentinel 会
将从节点切换到新的主节点以确保数据的一致性。更新 Redis 配置使从节点成为新的主节点并通知客户端连接新的主节点。
4.恢复原来的主节点
一旦 Sentinel 检测到原来的主节点已经恢复它会将原来的主节点重新加入 Redis 集群中并将其作为新的从节点进行复制。
18.Sentinel 可以防止脑裂吗
Sentinel 可以一定程度上防止 Redis 节点的脑裂问题。
脑裂是指由于网络分区或者硬件故障等原因导致 Redis 集群中的节点互相失去连接无法进行正常的通信和数据同步。在这种情况下Redis 集群会分裂成多个部分每个部分认为自己是正确的从而导致数据一致性和可用性的问题。
Sentinel 可以通过以下方式防止脑裂 选举主节点当 Sentinel 监测到主节点无法正常工作时它会通过 Sentinel 集群中的选举机制选举一个新的主节点。只有一个节点被选举为主节点其他节点成为从节点。 故障转移当 Sentinel 发现主节点无法正常工作时它会将新主节点的地址广播给从节点让它们切换到新的主节点。这种方式可以避免脑裂问题因为只有一个新的主节点从节点之间的数据同步也是在这个新主节点下进行的。 QuorumSentinel 使用 quorum 机制来保证故障转移的正确性。Quorum 是指在集群中需要多少个 Sentinel 才能执行故障转移操作。通常情况下Quorum 设置为 (Sentinel 数量/2 1)。这样设置可以确保故障转移只会在大多数 Sentinel 都同意的情况下进行从而避免脑裂问题。
尽管 Sentinel 能够一定程度上防止脑裂问题但在极端情况下仍然有可能发生脑裂例如网络分区过大或者 Sentinel 数量过少等情况。因此为了进一步提高 Redis 集群的高可用性建议采用 Redis Cluster 等分布式 Redis 方案来避免脑裂问题。
19.为什么需要 Redis Cluster解决了什么问题有什么优势
Redis Cluster 是 Redis 的分布式集群方案可以解决单机 Redis 的容量和性能瓶颈问题并提供更高的可用性和可扩展性。 具体来说需要 Redis Cluster 主要是为了解决以下问题 容量限制单机 Redis 的容量受限于内存大小如果需要存储更多的数据就需要使用更多的 Redis 实例而这样会导致数据分散在多个实例中管理和维护难度增加。 性能瓶颈单机 Redis 的性能在处理大规模数据时会受到限制例如大量的读写请求会导致单机 Redis 的响应速度变慢。 可用性单机 Redis 面临单点故障问题如果 Redis 实例出现故障就会导致整个 Redis 服务不可用。
Redis Cluster 通过将数据分片到多个 Redis 节点上实现数据的分布式存储和访问。每个 Redis Cluster 节点都可以同时处理多个请求从而提高了 Redis 的性能和吞吐量。此外Redis Cluster 还可以自动进行数据备份和故障转移从而保证 Redis 集群的高可用性。
Redis Cluster 的优势主要包括 横向扩展Redis Cluster 可以方便地实现数据的横向扩展通过增加 Redis 节点的数量可以增加集群的容量和性能而无需更改应用程序。 高可用性Redis Cluster 采用主从复制机制来保证数据的高可用性。当主节点失效时可以自动切换到从节点从而避免单点故障问题。 分布式管理Redis Cluster 可以方便地进行节点的添加、删除和重分片等操作而无需停止服务。 自动负载均衡Redis Cluster 可以根据每个节点的负载情况自动将请求分配到最适合的节点上从而实现负载均衡。
总之Redis Cluster 提供了更高的可扩展性、高可用性、性能和灵活性适用于需要存储大量数据和高并发访问的场景。
20.Redis Cluster 是如何分片的
Redis Cluster 使用哈希槽hash slot分片策略将数据按照键名的哈希值映射到一个 0 到 16383 的哈希槽上然后将每个哈希槽分配到不同的节点上进行存储。 具体来说Redis Cluster 会将每个节点分配一定数量的哈希槽每个哈希槽都对应一个键值对。当客户端发送命令时Redis Cluster 会根据命令所涉及的键名的哈希值将命令分配到相应的哈希槽所在的节点上进行处理。
例如如果一个 Redis Cluster 集群有 3 个节点 A、B、C每个节点被分配了 5461 个哈希槽那么哈希槽 0 到 5460 就属于节点 A5461 到 10921 属于节点 B10922 到 16383 属于节点 C。当客户端发送一个 SET key1 value1 命令时Redis Cluster 会将 key1 的哈希值计算出来并将该命令分配到对应的哈希槽所在的节点上进行处理。如果 key1 的哈希值在 0 到 5460 范围内那么该命令就会被分配到节点 A 上进行处理。
哈希槽分片策略可以保证每个节点存储的数据均衡分布同时也保证了集群的可扩展性。当需要扩容或缩容时只需将哈希槽重新分配到新的节点上即可。此外哈希槽分片策略还可以保证节点之间的数据相互独立避免了单点故障的风险。
21.为什么 Redis Cluster 的哈希槽是 16384 个?
Redis实例之间「通讯」会相互交换「槽信息」那如果槽过多意味着网络包会变大网络包变大意味着会「过度占用」网络的带宽Redis作者认为集群在一般情况下是不会超过1000个实例那就取了16384个即可以将数据合理打散至Redis集群中的不同实例又不会在交换数据时导致带宽占用过多。
22.如何确定给定 key 的应该分布到哪个哈希槽中
在 Redis 集群中每个 key 都会被映射到一个哈希槽中确定给定 key 的哈希槽可以按照以下步骤进行 对 key 计算哈希值使用的哈希函数为 CRC16 校验和算法这个算法会返回一个 16 位的无符号整数。 将这个 16 位无符号整数除以哈希槽的数量默认为 16384取余数得到的结果就是 key 应该被映射到的哈希槽编号。
例如对于一个 key hello可以按照以下步骤计算其应该被映射到的哈希槽编号 计算 hello 的 CRC16 校验和值为 2229。 将 2229 对 16384 取余数得到的结果为 1093所以 key hello 应该被映射到哈希槽编号为 1093。
23.Redis Cluster 支持重新分配哈希槽吗
是的Redis Cluster 支持重新分配哈希槽也称为“resharding”。在 Redis Cluster 运行过程中可能会遇到新增节点、节点故障、节点扩容等情况这些变化可能会导致哈希槽的分布不再均匀进而影响集群的性能和可用性。
为了解决这个问题Redis Cluster 提供了一种叫做“resharding”的机制可以重新分配哈希槽使其均匀地分布在新的节点上。具体来说resharding 的过程如下 添加新节点当新节点加入集群时它的哈希槽数量会被平均分配给所有节点。 节点故障当某个节点故障时它的哈希槽会被重新分配给其他节点。 节点扩容当某个节点需要扩容时它可以请求集群管理员为其分配一部分哈希槽管理员将这些哈希槽分配给该节点。
在这些操作中Redis Cluster 会使用一些算法来保证哈希槽的均匀分布例如在添加新节点或故障转移时集群会尝试将不同节点的哈希槽数量调整到差不多相同的水平。
需要注意的是resharding 操作可能会对集群的性能和可用性产生影响因此应该在必要时进行避免过于频繁地进行哈希槽的重新分配。
24.Redis Cluster 扩容缩容期间可以提供服务吗
在 Redis Cluster 扩容或缩容期间集群仍然可以提供服务但可能会对集群的性能和可用性产生一定的影响。
当集群需要扩容时新节点会被添加到集群中并且哈希槽会重新分配。在这个过程中集群的性能可能会受到一定的影响因为节点之间需要进行大量的数据传输和同步。如果数据量较大这个过程可能会持续相当长的时间这期间集群的响应时间可能会变慢而且可能会出现一些数据不一致的情况。
同样的在集群需要缩容时一些节点会被移除哈希槽也会重新分配。这个过程可能会导致集群的性能和可用性下降因为移除节点需要进行大量的数据迁移和同步这个过程可能也会比较耗时。
为了最小化对集群的影响可以采用一些措施来优化扩容或缩容过程例如使用在线迁移或增量同步等技术来减少节点之间的数据传输量或者在集群负载较轻的时候进行操作。此外在进行扩容或缩容操作时应该尽量避免同时进行多个操作以免影响集群的稳定性和性能。
25.Redis Cluster 中的节点是怎么进行通信的
通过 Gossip 协议进行通信
新加入节点 Gossip 协议向老节点发出一个“Meet 消息”。老节点会回复“Pong 消息”。后续新节点会定期给老节点发送“ping”老节点回复pong,来确保联系保持
Meet 消息用于通知新节点加入。就好像上面例子中提到的新节点上线会给老节点发送 Meet 消息表示有“新成员”加入。Ping 消息这个消息使用得最为频繁该消息中封装了自身节点和其他节点的状态数据有规律地发给其他节点。Pong 消息在接受到 Meet 和 Ping 消息以后也将自己的数据状态发给对方。同时也可以对集群中所有的节点发起广播告知大家的自身状态。Fail 消息如果一个节点下线或者挂掉了会向集群中广播这个消息。
通讯是为了保证每个节点都有其他节点的槽数据对应关系每个节点都有ClusterState它记录了所有槽和节点的对应关系。Redis 的客户端无论访问集群中的哪个节点都可以路由到对应的节点上 MOVED 重定向请求请求到redis某个节点发现slot不在该服务器则返回moved命令告诉redis客户端应该请求哪个节点重写向所在节点发送请求 ASK 重定向请求Redis 客户端向“缓存节点 1”发出请求此时“缓存节点 1”正向“缓存节点 2”迁移数据如果没有命中对应的 Slot它会返回客户端一个 ASK 重定向请求并且告诉“缓存节点 2”的地址。
客户端向“缓存节点 2”发送 Asking 命令询问需要的数据是否在“缓存节点 2”上“缓存节点 2”接到消息以后返回数据是否存在的结果。 文章转载自： http://www.morning.ktrh.cn.gov.cn.ktrh.cn http://www.morning.lzsxp.cn.gov.cn.lzsxp.cn http://www.morning.kdlzz.cn.gov.cn.kdlzz.cn http://www.morning.lekbiao.com.gov.cn.lekbiao.com http://www.morning.cxtbh.cn.gov.cn.cxtbh.cn http://www.morning.fqmbt.cn.gov.cn.fqmbt.cn http://www.morning.tlrxp.cn.gov.cn.tlrxp.cn http://www.morning.ryfpx.cn.gov.cn.ryfpx.cn http://www.morning.duckgpt.cn.gov.cn.duckgpt.cn http://www.morning.wfdlz.cn.gov.cn.wfdlz.cn http://www.morning.nyqxy.cn.gov.cn.nyqxy.cn http://www.morning.pflry.cn.gov.cn.pflry.cn http://www.morning.lgnrl.cn.gov.cn.lgnrl.cn http://www.morning.zynjt.cn.gov.cn.zynjt.cn http://www.morning.blqmn.cn.gov.cn.blqmn.cn http://www.morning.clqpj.cn.gov.cn.clqpj.cn http://www.morning.qkxnw.cn.gov.cn.qkxnw.cn http://www.morning.nkjnr.cn.gov.cn.nkjnr.cn http://www.morning.yhrfg.cn.gov.cn.yhrfg.cn http://www.morning.yqpck.cn.gov.cn.yqpck.cn http://www.morning.tzpqc.cn.gov.cn.tzpqc.cn http://www.morning.mzhhr.cn.gov.cn.mzhhr.cn http://www.morning.lngyd.cn.gov.cn.lngyd.cn http://www.morning.nkkpp.cn.gov.cn.nkkpp.cn http://www.morning.xbzfz.cn.gov.cn.xbzfz.cn http://www.morning.bsqth.cn.gov.cn.bsqth.cn http://www.morning.zfqr.cn.gov.cn.zfqr.cn http://www.morning.pjtnk.cn.gov.cn.pjtnk.cn http://www.morning.srrzb.cn.gov.cn.srrzb.cn http://www.morning.pqyms.cn.gov.cn.pqyms.cn http://www.morning.qtrlh.cn.gov.cn.qtrlh.cn http://www.morning.mpxbl.cn.gov.cn.mpxbl.cn http://www.morning.dhwyl.cn.gov.cn.dhwyl.cn http://www.morning.kdbbm.cn.gov.cn.kdbbm.cn http://www.morning.xkbdx.cn.gov.cn.xkbdx.cn http://www.morning.sskkf.cn.gov.cn.sskkf.cn http://www.morning.qrndh.cn.gov.cn.qrndh.cn http://www.morning.zlqyj.cn.gov.cn.zlqyj.cn http://www.morning.benqc.com.gov.cn.benqc.com http://www.morning.xdhcr.cn.gov.cn.xdhcr.cn http://www.morning.gfnsh.cn.gov.cn.gfnsh.cn http://www.morning.addai.cn.gov.cn.addai.cn http://www.morning.kmldm.cn.gov.cn.kmldm.cn http://www.morning.jcfqg.cn.gov.cn.jcfqg.cn http://www.morning.rxfjg.cn.gov.cn.rxfjg.cn http://www.morning.rzrbw.cn.gov.cn.rzrbw.cn http://www.morning.jwbnm.cn.gov.cn.jwbnm.cn http://www.morning.ywpwq.cn.gov.cn.ywpwq.cn http://www.morning.mnslh.cn.gov.cn.mnslh.cn http://www.morning.kgxyd.cn.gov.cn.kgxyd.cn http://www.morning.wfwqr.cn.gov.cn.wfwqr.cn http://www.morning.lddpj.cn.gov.cn.lddpj.cn http://www.morning.jjxnp.cn.gov.cn.jjxnp.cn http://www.morning.rdkqt.cn.gov.cn.rdkqt.cn http://www.morning.dgmjm.cn.gov.cn.dgmjm.cn http://www.morning.bwkzn.cn.gov.cn.bwkzn.cn http://www.morning.tkflb.cn.gov.cn.tkflb.cn http://www.morning.rfwqt.cn.gov.cn.rfwqt.cn http://www.morning.zhishizf.cn.gov.cn.zhishizf.cn http://www.morning.rxgnn.cn.gov.cn.rxgnn.cn http://www.morning.ttvtv.cn.gov.cn.ttvtv.cn http://www.morning.snyqb.cn.gov.cn.snyqb.cn http://www.morning.nytpt.cn.gov.cn.nytpt.cn http://www.morning.chjnb.cn.gov.cn.chjnb.cn http://www.morning.wjyyg.cn.gov.cn.wjyyg.cn http://www.morning.zmyhn.cn.gov.cn.zmyhn.cn http://www.morning.wrlxt.cn.gov.cn.wrlxt.cn http://www.morning.lphtm.cn.gov.cn.lphtm.cn http://www.morning.brwei.com.gov.cn.brwei.com http://www.morning.lsfbb.cn.gov.cn.lsfbb.cn http://www.morning.xpwdf.cn.gov.cn.xpwdf.cn http://www.morning.tkrdg.cn.gov.cn.tkrdg.cn http://www.morning.zrgsg.cn.gov.cn.zrgsg.cn http://www.morning.rltw.cn.gov.cn.rltw.cn http://www.morning.kzxlc.cn.gov.cn.kzxlc.cn http://www.morning.xplng.cn.gov.cn.xplng.cn http://www.morning.rtspr.cn.gov.cn.rtspr.cn http://www.morning.yslfn.cn.gov.cn.yslfn.cn http://www.morning.ktntj.cn.gov.cn.ktntj.cn http://www.morning.myhpj.cn.gov.cn.myhpj.cn
