Recomendados
Más contenido relacionado
La actualidad más candente
La actualidad más candente (20)
Similar a Redis 多机特性工作原理简介v2
Similar a Redis 多机特性工作原理简介v2 (20)
Redis 多机特性工作原理简介v2
- 2. Redis 的三个多机特性 1. 复制（replication） 2. Sentinel 3. 集群（cluster）
- 3. SLAVEOF 、SYNC 和 PSYNC、一致性问题 复制
- 6. 复制的执行步骤（4/5）：同步 1. 从服务器向主服务器发送 SYNC 命 令。 2. 接到 SYNC 命令的主服务器会调用 BGSAVE 命令，创建一个 RDB 文 件，并使用缓冲区记录接下来执行的 所有写命令。 3. 当主服务器执行完 BGSAVE 命令 时，它会向从服务器发送 RDB 文件， 而从服务器则会接收并载入这个文 件。 4. 主服务器将缓冲区储存的所有写命令 发送给从服务器执行。 在同步操作执行期间，主从服务 器进行的数据交互。
- 9. 不一致性出现的例子 1）完成同步之后 2）主服务器执行 SET k6 v6 之后 主服务器 从服务器 k1 k1 k2 k2 k3 k3 k4 k4 k5 k5 k6 N/A 主服务器 从服务器 k1 k1 k2 k2 k3 k3 k4 k4 k5 k5
- 11. 命令传播示例 执行并发送 SET k6 v6 之后 主服务器 从服务器 k1 k1 k2 k2 k3 k3 k4 k4 k5 k5 k6 k6 之后每当有什么新的写命令被 执行了，比如 SET k7 v7、 SET k8 v8 ，等等，主服务器也会继续将命令传播给从服务器 执行。
- 12. SYNC 命令和 PSYNC 命令的区别 复制
- 13. 从 Redis 2.8 开始，Redis 使用 PSYNC 命令代替 SYNC 命令。 PSYNC 比起 SYNC 的最大改进在于 PSYNC 实 现了部分重同步（partial resync）特性： 在主从服务器断线并且重新连接的时候，只要条 件允许，PSYNC 可以让主服务器只向从服务器 同步断线期间缺失的数据，而不用重新向从服务 器同步整个数据库。
- 14. SYNC 处理断线重连示例 如果我们仔细地观察整 个断线并重连的过程， 就会发现： 从服务器在断线之前已 经拥有主服务器的绝大 部分数据，要让主从服 务器重新回到一致状 态，从服务器真正需要 的是 k10087 、 k10088 和 k10089 这三个键的 数据，而不是主服务器 整个数据库的数据。 SYNC 命令在处理断线 并重连时的做法 —— 将主服务器的整个数据 库重新同步给从服务 器，是极度浪费的！
- 15. PSYNC 处理断线重连示例 PSYNC 只会将 从服务器断线期 间缺失的数据发 送给从服务器。 两个例子的情况 是相同的，但 SYNC 需要发送 包含整个数据库 的 RDB 文件，而 PSYNC 只需要 发送三个命令。
- 16. 结论 如果主从服务器所处的网络环境并不那么好的话 （经常断线），那么请尽量使用 Redis 2.8 或以上 版本：通过使用 PSYNC 而不是 SYNC 来处理断 线重连接，可以避免因为重复创建和传输 RDB 文件而浪费大量的网络资源、计算资源和内存资 源。
- 17. 一致性问题 复制
- 18. 命令传播需要花费一段时间来完成 在主服务器执行完写命令 W ，直到从服务器也 执行完写命令 W 之间的这段时间里面，主从服 务器的数据并不一致。
- 19. 现在，考虑这样一种情况…… ● 客户端向主服务器发送写命令 SET n 10086，主服务器在执行这个写命令之后，向客 户端返回回 复，并将这个写命令传播给从服务器。 ● 接到回复的客户端继续向从服务器发送读命令 GET n ，并且因为网络状态的原因，客户端的 GET 命令比主服务器传播的 SET 命令更快到达了从服 务器。 ● 因为从服务器键 n 的值还未被更新，所以客户端在从服务器读取到的将是一个错误（过期）的 n 值。
- 20. 结论 ● Redis 目前的复制实现只保证最终一致性，而不 是强一致性。 ● 如果程序不能够容忍过期数据，那么就应该读取 主服务器，而不是从服务器。 ● Redis 目前在 unstable 分支有一个 WAIT 命令， 它可以确保命令已经被传播到了指定数量的从服 务器里面，从而减少不一致问题发生的可能。 http://antirez.com/news/66
- 21. 回顾 ● Redis 的复制主要由两个操作实现：第一个是同步 —— 将 主服务器的数据库通过 RDB 文件的形式发送给从服务 器；第二个是命令传播 —— 主服务器每执行一个写命令， 它就将该命令发送给从服务器执行。 ● PSYNC 命令在处理主从服务器断线重连接时的效率比 SYNC 命令要高很多，所以要尽量使用 Redis 2.8 或者以 后的版本。 ● Redis 目前的复制实现可能会导致程序出现一致性问题， 所以写程序的时候需要格外小心，如果有必要的话，读主 服务器而不是从服务器。
- 23. Sentinel 的构造 Sentinel 是一个监视器，它可以根据被监视 实例的身份和状态来判断应该执行何种动 作。 DEF sentinel(): WHILE sentinel_is_running(): # 循环 LOOP FOR instance IN all_instances: # 遍历所有被监视实例 instance.check_status() # 检查实例的当前状态 IF instance.role == MASTER: # 实例是一个主服务器 IF instance.status == FAIL: handle_master_down() IF instance.status == OK: ... IF instance.role == SLAVE: # 实例是一个从服务器 … IF instance.role == SENTINEL: # 实例是一个 Sentinel ... 被 Sentinel 监视的主服务器和从服务器
- 24. 发现并连接主服务器 Sentinel 通过用户给定的配 置文件来发现主服务器。 $ redis-sentinel sentinel.conf ############ master1 configure ############## sentinel monitor master1 127.0.0.1 6379 2 sentinel down-after-milliseconds master1 30000 sentinel parallel-syncs master1 1 sentinel failover-timeout master1 900000 ############ master2 configure ############## sentinel monitor master2 127.0.0.1 12345 5 sentinel down-after-milliseconds master2 50000 sentinel parallel-syncs master2 5 sentinel failover-timeout master2 450000 Sentinel 会与被监视的主服务器创建两个网络连接： 命令连接用于向主服务器发送命令。 订阅连接用于订阅指定的频道，从而发现监视同一主服务 器的其他 Sentinel （细节马上会介绍）。
- 25. 发现并连接从服务器 Sentinel 通过向主服务器发 送 INFO 命令来自动获得所 有从服务器的地址。 redis>INFO # other section ... # Replication role:master ... slave0:ip=127.0.0.1,port=11111,state=online,offset=43,lag=0 slave1:ip=127.0.0.1,port=22222,state=online,offset=43,lag=0 slave2:ip=127.0.0.1,port=33333,state=online,offset=43,lag=0 … # other section ... 跟主服务器一样，Sentinel 会与每个被发现的从 服务器创建命令连接和订阅连接。
- 26. 发现其他 Sentinel Sentinel 会通过命令连接向被监 视的主从服务器发送 HELLO 信 息，该消息包含 Sentinel 的 IP、 端口号、ID 等内容，以此来向其 他 Sentinel 宣告自己的存在。 与此同时，Sentinel 会通过订阅 连接接收其他 Sentinel 的 HELLO 信息，以此来发现监视同 一个主服务器的其他 Sentinel 。 Sentinel 向服务器发送和接收 HELLO 信息的示意图。
- 27. 例子：发现其他 Sentinel sentinel1 通过发送 HELLO 信息来让 sentinel2 和 sentinel3 发现自己，其他两个 sentinel 也会进行类似 的操作。
- 28. 连接其他 Sentienl ● Sentinel 之间会互相创建 命令连接，用于进行通信。 ● 因为已经有主从服务器作 为发送和接收 HELLO 信 息的中介，所以 Sentinel 之间不会创建订阅连接。 三个 Sentinel 之间互 相创建命令连接。
- 29. 检测实例的状态 Sentinel 使用 PING 命 令来检测实例的状态：如 果实例在指定的时间内 没有返回回复，或者返 回错误的回复，那么该 实例会被 Sentinel 判断 为下线。 箭头指示了 Sentinel 是怎样发送 PING 命令的。
- 30. Sentinel 和从服务器的下线状态 如果 Sentinel 把一个从服务器或者另一个 Sentinel 标记为下线，那么： ● Sentinel 不会与下线的 Sentinel 交换信息。 ● Sentinel 也不会将下线的从服务器选为新的主 服务器。
- 31. 主服务器的下线状态 主服务器的下线状态分为 PFAIL 和 FAIL 两级： ● PFAIL 状态：单个或者少量 Sentinel 认为主服务器 已下线。 ● FAIL 状态：有 <quorum> 个 Sentinel 认为主服务 器已经进入 PFAIL 状态。 ● sentinel monitor <name> <ip> <port> <quorum> ● 换言之，对于主服务器来说， FAIL 才是真正的下线 状态。
- 32. 示例：检测主服务器下线 如果 sentinel1 、 sentinel2 和 sentinel3 对于主服务器的 <quorum> 为 3 ，那么就 必须三个 Sentinel 都同意这个主服务器已经 PFAIL 时，Sentinel 才会将主服务器 标记为 FAIL 状态。 三个 Sentinel 在监视 同一个主服务器。
- 33. 一旦主服务器被判断为 FAIL ，Sentinel 就会对下线主服务器进行故障转移。 步骤： 1. 在下线主服务器的所有从服务器中，选出一个数据状态最接近 主服务器的从服务器，选择的条件包括：从服务器未下线、主从 之间的连接断开时间最短，等等。 2. Sentinel 向被选中的从服务器发送 SLAVEOF NO ONE ，将它 升级为主服务器。 3. 向其他从服务器发送 SLAVEOF 命令，让它们复制新的主服务 器。 完成了故障转移之后，新的主服务器就可以代替已下线的主服务 器，继续执行客户端发送的写命令了。
- 35. 回顾 ● Sentinel 是一个状态机，它监视着多个实例，并 根据实例的身份和状态，对实例进行操作。 ● Sentinel 使用 PING 命令来检测实例是否在线。 ● Sentinel 会对下线的主服务器进行故障转移，步 骤主要有三个：1）选出一个从服务器；2）将被选 中的从服务器升级为主服务器；3）让其他从服务 器复制这个新的主服务器。
- 38. 分片（sharding） ● 集群将整个数据库分为 16384（2 的 14 次方）个槽 （slot）。 ● 每个主节点可以负责处理 0 个至 16384 个槽。 ● 当 16384 个槽都有主节点 负责处理时，集群进入上 线状态，可以开始处理数 据命令。 将 16384 个槽分别指派给 7000 、 7001 和 7002 这三个主节点。
- 39. 槽的计算公式 集群使用公式 CRC16(key) & 16383 计算键 key 属于哪个槽。 通过计算得知， 键 date 属于槽 2022 。
- 40. 在集群里面执行命令的两种情况 1. 命令发送到了正确的节点：命令要处理的键所在 的槽正好是由接收命令的节点负责，那么该节点 执行命令，就像单机 Redis 服务器一样。 2. 命令发送到了错误的节点：接收到命令的节点并 非处理键所在槽的节点，那么节点将向客户端返 回一个转向（redirection）错误，告知客户端应该 到哪个节点去执行这个命令，客户端会根据错误 提示的信息，重新向正确的节点发送命令。
- 41. 情况一：命令发送给正确的节点 键 date 位于 2022 槽，该槽由节点 7000 负责， 命令会直接执行。 7000：槽 0 ～ 5000 7001：槽 5001 ～ 10000 7002：槽 10001 ～ 16383
- 42. 情况二：命令发送给了错误的节点 键 date 所在的槽 2022 并 非由节点 7001 负责，7001 向客户端返回转向错误。 客户端根据转向错误的指 引，转向至节点 7000，并 重新发送命令。
- 44. 转向错误的实现（2/2） ● 集群中的每个节点都会记录 16384 个槽 分别由哪个节点负责，从而形成一个“槽 表”（slot table）。 ● 节点在接收到命令请求时，会通过槽表 检查键所在的槽是否由本节点处理： - 如果是的话，那么节点直接执行命令； - 如果不是的话，那么节点就从槽表里面 提取出正确节点的地址信息，然后返回 转向错误。 槽表示例
- 45. 集群节点的复制 集群的复制特性重用了 SLAVEOF 命令的代码，所 以集群节点的复制行为和 SLAVEOF 命令的复制行 为完全相同。
- 46. 集群主节点的故障转移 ● 在集群里面，节点会对其他节点进行下线检测。 ● 当一个主节点下线时，集群里面的其他主节点负责对下 线主节点进行故障转移。 ● 换句话说，集群的节点集成了下线检测和故障转移等类 似 Sentinel 的功能。 ● 因为 Sentinel 是一个独立运行的监控程序，而集群的下 线检测和故障转移等功能是集成在节点里面的，它们的 运行模式非常地不同，所以尽管这两者的功能很相似， 但集群的实现没有重用 Sentinel 的代码。
- 47. 回顾 1. 一个集群由主节点和从节点组成，主节点负责储存键值对数 据，而从节点负责复制主节点。 2. 集群将整个数据库被分为 16384 个槽，集群里面的每个主节点 处理一部分槽。 3. 集群里面的每个节点会互相通知其他节点自己在处理哪些槽， 并且维持一个槽表。 4. 节点执行命令前需要查看槽表，判断命令是否由该节点来执 行，如果不是的话，就向客户端返回转向错误。 5. 集群的复制实现重用了 SLAVEOF 代码。 6. 集群中的每个节点都可以检测其他节点是否已经下线，而在线 的主节点可以对下线的主节点进行故障转移。
- 48. 通过 www.huangz.me 联系我 谢谢观看！ ：）