网站设计制作合同范本,做应用级网站用什么语言好,app制作教程入门,WordPress可以做大网站吗文章目录 零、写在前面一、水平拆分(sharding/分片)、故障转移(failover)机制介绍水平拆分#xff08;Sharding#xff09;故障转移机制 二、Redis的水平拆分的机制有关的配置1. 环境准备2. 配置文件配置3. 启动所有Redis实例4. 创建集群5. 测试集群读/写6. 集群管理 三、Red… 文章目录 零、写在前面一、水平拆分(sharding/分片)、故障转移(failover)机制介绍水平拆分Sharding故障转移机制 二、Redis的水平拆分的机制有关的配置1. 环境准备2. 配置文件配置3. 启动所有Redis实例4. 创建集群5. 测试集群读/写6. 集群管理 三、Redis的故障转移机制的Sentinel模式问题起源sentinel节点间的相互感知sentinel对master的故障发现的确认sentinel的failover决策从多个sentinel节点中选举出一个failover发起者failover发起后选取一个新的master告知并控制其他slave自动连接新的master 具体配置实例 三、Redis Cluster模式“去中心化”、“proxy/sentinel”的解释去中心化DecentralizationProxy/Sentinel1. 客户端分片Client-side Sharding2. 通过代理服务器实现数据分片Twemproxy配置示例Predixy配置示例 Redis Cluster的拓扑结构Redis Cluster 拓扑结构例图slot的概念什么是Redis Cluster的slot为什么要用slot这个词 Redis Cluster的Bus什么是Redis Cluster BusRedis Cluster Bus的作用 Redis Cluster中每个节点的如何保持集群的拓扑结构的一致Gossip协议的概念 Redis Cluster数据分片和HashTagRedis Cluster客户端路由moved命令和ask命令Redis Cluster提供分片的迁移过程的原语什么是原语Redis Cluster中的原语为什么提供原语 Redis Cluster的failover机制Redis Cluster的读写分离和Master的单点保护机制Redis Cluster的读写分离Redis Cluster的Master的单点保护机制 Redis Cluster模式的具体配置1. 环境准备2. 配置Redis实例3. 启动Redis实例4. 创建Redis Cluster5. 验证集群状态 *拓展概念拓扑结构 零、写在前面
sharding水平拆分的支持replication作为读写分离和故障转移的基础fail-detect和replication配合支撑故障转移cluster(all-in-one)独立完成上面三个的这样的完整的分布式解决方案 Redis集群是一种Redis安装方式提供数据在多个Redis节点间的自动分片和一定程度的高可用性。实现Redis集群的方法包括
手动配置通过配置文件和命令行工具手动设置集群。使用redis-trib.rb一个Ruby脚本用于创建和管理集群。使用create-cluster脚本一个简化的脚本用于快速创建集群 自动分片和一定程度的高可用性这句话的意思是
自动分片Redis集群能够自动将数据分散存储到多个Redis节点上这个过程称为分片。这样可以提高数据存储的容量和访问性能。Redis集群会根据一定的规则如哈希将数据分配到不同的节点上而不需要人工干预。
一定程度的高可用性Redis集群通过数据复制和故障转移机制在某个节点发生故障时能够自动将请求重定向到其他健康的节点从而保证服务的可用性。虽然Redis集群提供了一定程度的高可用性但相比专业的分布式数据库系统其容错能力还是有一定差距的。
总之自动分片和一定程度的高可用性是Redis集群的两个主要特点使其成为一种适合大规模分布式场景的数据存储方案。 Redis Sentinel和Redis Cluster是两种不同的高可用解决方案
Sentinel主要用于监控Redis实例自动进行故障转移和通知。 Cluster提供数据分片和高可用性允许在多个节点上分布数据并在节点故障时进行自动故障转移。 一、水平拆分(sharding/分片)、故障转移(failover)机制介绍
水平拆分Sharding
水平拆分也称为横向拆分是一种数据库架构技术用于将数据分散存储到多个数据库或表中。这种方法通过某种规则如哈希、范围或列表将数据分配到不同的数据库或表中每个分片只包含数据的一部分从而突破单机数据量处理的瓶颈并提高系统的扩展性和负载能力。
优点
提高性能和稳定性通过分散数据到多个数据库或表可以减轻单个数据库的读写和存储压力提升系统稳定性和负载能力。易于扩展可以根据业务需求动态添加或删除数据库节点实现系统的弹性伸缩。
缺点
跨分片事务一致性难以保证在分布式数据库环境中跨多个分片的事务处理变得复杂一致性难以保证。跨库的join关联查询性能较差由于数据被分散到不同的数据库或表中跨分片的关联查询性能会受到影响。
分片规则
根据数值范围例如根据用户ID的范围将数据分配到不同的数据库中。根据数值取模例如根据用户ID取模的结果将数据分配到不同的数据库中。
故障转移机制
故障转移机制是指在数据库或服务出现故障时自动将请求从故障节点转移到健康节点的过程以确保服务的高可用性。
故障发现
主观下线PFAIL指某个节点认为另一个节点不可用这个状态并不是最终的故障判定可能存在误判情况。客观下线Fail指标记一个节点真正的下线集群内多个节点都认为该节点不可用从而达成共识的结果。
故障转移过程
从节点检查每个从节点检查最后与主节点断线时间判断是否有资格替换故障的主节点。故障选举当从节点符合故障转移资格后更新触发故障选举的时间通过对多个从节点使用不同的延迟选举时间来支持优先级问题。收集投票当从节点收集到N/21个持有槽的主节点投票时从节点可以执行替换主节点操作。替换主节点从节点收集到足够的选票之后触发替换主节点操作包括取消复制、变为主节点、接管故障主节点的槽信息等。
故障转移时间
故障转移时间与cluster-node-timeout参数息息相关可以根据业务容忍度做出适当调整。
故障转移机制的目的是确保在主节点发生故障时能够快速、自动地将服务转移到备用节点以最小化服务中断时间提高系统的可用性和可靠性。
二、Redis的水平拆分的机制有关的配置
Redis的水平拆分Sharding配置主要涉及以下几个步骤
1. 环境准备
在搭建Redis分片集群之前需要准备多台服务器或虚拟机每台服务器上可以运行多个Redis实例。例如可以准备三台服务器每台服务器上运行两个Redis实例一个作为主节点Master另一个作为从节点Slave。
2. 配置文件配置
对于每个Redis实例需要配置redis.conf文件。以下是配置文件的一些关键参数
port设置Redis实例的端口号。daemonize yes以守护进程方式运行。pidfile指定pid文件的位置。loglevel设置日志级别。logfile指定日志文件的位置。dbfilename设置RDB持久化文件的名称。dir设置数据文件的目录。protected-mode no关闭保护模式。cluster-enabled yes启用集群模式。cluster-config-file指定集群配置文件。cluster-node-timeout设置节点超时时间。appendonly yes启用AOF持久化。
3. 启动所有Redis实例
根据配置文件启动所有Redis实例。可以使用redis-server命令加上配置文件路径来启动每个实例。
4. 创建集群
使用redis-cli工具创建集群。例如使用以下命令创建一个包含3个主节点和3个从节点的集群
redis-cli --cluster create --cluster-replicas 1 node1_ip:port1 node2_ip:port2 node3_ip:port3 node4_ip:port4 node5_ip:port5 node6_ip:port6其中--cluster-replicas 1表示每个主节点有一个从节点。
5. 测试集群读/写
创建集群后可以测试集群的读写功能确保数据能够正确地存储和检索。
6. 集群管理
Redis集群需要进行管理和监控包括节点的健康状态监测、槽的分配和重新分配、数据的迁移、故障恢复等。Redis提供了一些工具和命令来进行集群管理比如redis-cli、redis-trib.rb、CLUSTER命令等。
以上步骤概述了Redis水平拆分的具体配置过程。在实际操作中可能还需要根据具体的业务需求和环境进行调整和优化。
三、Redis的故障转移机制的Sentinel模式
问题起源
当两台以上Redis实例形成了主备关系它们组成的集群就具备了一定的高可用性当master故障时slave可以成为新的master对外提供读写服务这种运营机制称为failover那么问题在于谁去发现mater的故障做failover的决策 方式是保持一个daemon进程监控着所有的master-slave节点而Redis的sentinel提供了一套多daemon间“多个daemon”的存在是因为不能是只有一个daemon这个的单点故障存在的交互机制解决故障发现、failover决策协商机制等问题这些daemon节点相互间通信、选举、协商在master节点的故障发现、failover决策上表现出一致性
sentinel节点间的相互感知
sentinel节点间因为共同监视了同一个master节点从而相互也关联了起来一个新加入的sentinel节点需要和有相同监视的master的其他sentinel节点相互感知方式如下所有需要相互感知的sentinel都向他们共同的master节点上订阅相同的channel:_sentinel_:hello新加入的sentinel节点向这个channel发布一条消息包含了自己的信息该channel的订阅者们就可以发现这个新的sentinel。随后新sentinel和已有的其他sentinel节点建立长连接。sentinel集群中所有节点两两连接如图所示图中新的sentinel节点加入后它向master节点发布自己加入这个信息此时现有的订阅sentinel节点将会发现这条信息从而感知到了新sentinel节点的存在。 sentinel对master的故障发现的确认
sentinel节点通过定期地向master发送心跳包判断其存活状态称为PING一旦发现master没有正确地响应那么通过和其他sentinel节点对比确认是否将master判定为不可用然后进入failover流程
sentinel的failover决策
从多个sentinel节点中选举出一个failover发起者
当多个sentinel节点之间进行通信已经判定了master为不可用时多个节点想同时发起failover是有问题的要确保最终只有一个sentinel节点作为failover的发起者此时需要开始一个leader选举的过程选择谁来发起failover
failover发起后选取一个新的master告知并控制其他slave自动连接新的master
leader sentinel确定之后从master所有的slave中依据一定的规则选取一个新的master告知其他slave连接这个新的master
在Redis Sentinel系统中当需要从master的所有slave中选取一个新的master时以及通知其他slave连接到新的master这个过程是自动和有序的。以下是详细的步骤和机制 选举新的master 当Sentinel集群确认master客观下线即多个Sentinel节点都认为master不可用后会开始故障转移流程。Sentinel集群会从master的从节点中选择一个作为新的master。选择过程通常基于以下规则 从节点的优先级slave-priority配置项优先级高的从节点更有可能被选为新的master。复制偏移量slave_repl_offset选择与原master复制进度最接近的从节点以确保数据的一致性。runID如果优先级和复制进度都相同那么选择runID最小的从节点作为新的master。 通知机制 一旦新的master被选中Sentinel Leader会执行以下操作 向被选中的从节点发送SLAVEOF NO ONE命令将其提升为新的master。更新剩余从节点的配置让它们开始复制新的master。 Sentinel通过发布订阅功能pub/sub通知其他slave和客户端新的master信息。具体来说 Sentinel会将新的master信息通过switch-master频道发布这样订阅了该频道的客户端和其他系统就能接收到通知。客户端可以通过订阅特定的频道来接收这些通知从而能够及时地更新自己的连接信息。 客户端如何查看通知 客户端可以连接到Sentinel节点并订阅相关的发布订阅频道来接收通知。例如客户端可以订阅switch-master频道来获取master切换的通知。当客户端接收到新的master信息后它们可以自动更新配置将连接指向新的master。 自动完成连接到新的主节点 客户端在接收到Sentinel发布的新master信息后可以根据这些信息自动重新配置连接连接到新的master。这个过程对客户端来说是透明的客户端只需要正确地订阅Sentinel的发布订阅频道并处理接收到的消息即可。
通过上述机制Redis Sentinel确保了在master不可用时能够自动选举新的master并通过通知机制让其他slave和客户端知晓新的master信息从而实现高可用性。
具体配置
Redis的故障转移配置主要依赖于Redis Sentinel以下是具体的配置步骤和关键参数 监控主节点sentinel monitor 使用sentinel monitor命令来监控主节点。该命令的格式为sentinel monitor master-name ip port quorum。master-name是主节点的名称用于在Sentinel之间标识这个主节点。ip和port是主节点的IP地址和端口。quorum是法定人数即需要多少个Sentinel同意主节点下线才能开始故障转移。建议设置为奇数并且大于1。 故障检测时间sentinel down-after-milliseconds 使用sentinel down-after-milliseconds master-name milliseconds来设置主节点被认为是下线的时间阈值。milliseconds是毫秒数超过这个时间没有响应Sentinel会认为主节点宕机。 故障转移超时sentinel failover-timeout 使用sentinel failover-timeout master-name milliseconds来设置故障转移操作的超时时间。milliseconds是毫秒数如果在该时间内故障转移没有完成则认为故障转移失败。 并行同步sentinel parallel-syncs 使用sentinel parallel-syncs master-name num来设置在故障转移时可以有多少个从节点同时对新的主节点进行数据同步。num是数字表示并行同步的从节点数量。 上面说的“并行同步”为什么不说成“并发同步” “并行”和“并发”这两个术语在计算机科学和分布式系统中有着细微的区别尽管在日常对话中它们经常被交替使用。 并行Parallel 并行处理指的是多个计算任务在多个处理器上同时执行。在物理层面上这些任务是真正同时发生的每个处理器可以独立于其他处理器工作。在Redis Sentinel的上下文中当提到“并行同步”它意味着多个从节点可以同时开始对新的主节点进行数据同步。这里的“同时”强调的是多个同步操作在时间上的并行性即它们不需要等待彼此完成就可以开始。 并发Concurrent 并发处理指的是多个计算任务在逻辑上是同时进行的但实际上可能是交替执行的。在单个处理器上任务可能会因为时间片轮转而交替执行给人一种同时进行的错觉。并发更强调的是任务之间的资源共享和时间上的重叠而不是物理上的并行执行。
在Redis Sentinel的故障转移场景中使用“并行同步”而不是“并发同步”的原因可能包括
强调物理并行性在故障转移时多个从节点可以同时开始同步操作每个从节点都在自己的处理器上独立执行同步任务这符合并行处理的定义。区分概念尽管在技术上并发和并行有重叠但在特定的技术领域为了清晰表达开发者和架构师可能会选择一个更精确的术语来描述特定的行为。避免混淆在分布式系统中“并发”可能涉及到更复杂的资源共享和同步问题而“并行”则更直接地描述了多个任务同时进行的情况。
因此Redis Sentinel中使用“并行同步”这个术语是为了更准确地描述在故障转移时多个从节点可以同时对新的主节点进行数据同步的行为。 配置文件示例 sentinel monitor mymaster 127.0.0.1 6379 2
sentinel down-after-milliseconds mymaster 60000
sentinel failover-timeout mymaster 180000
sentinel parallel-syncs mymaster 1这个配置文件监控名为mymaster的主节点IP地址为127.0.0.1端口为6379quorum设置为2。 Sentinel配置文件 Redis源码中包含一个名为sentinel.conf的文件是一个自文档化的示例配置文件可以根据这个文件来配置Sentinel。 启动Sentinel 可以通过redis-sentinel命令启动Sentinel或者使用redis-server命令并加上--sentinel参数来启动。 redis-sentinel sentinel.conf通过以上配置Redis Sentinel可以监控Redis主节点的状态并在主节点发生故障时自动进行故障转移确保Redis服务的高可用性。 要使用redis-cli工具连接到Sentinel并检查其状态以确保Sentinel正常运行并监控Redis主节点你可以按照以下步骤操作
首先你需要连接到运行Sentinel的Redis实例。如果Sentinel在默认端口26379上运行并且Sentinel服务器的IP地址是sentinel_host你可以使用以下命令
redis-cli -h sentinel_host -p 26379如果Sentinel设置了密码通过sentinel auth-pass配置你需要使用-a选项提供密码
redis-cli -h sentinel_host -p 26379 -a sentinel_password连接到Sentinel后你可以使用SENTINEL命令来检查Sentinel的状态和监控的Redis主节点信息。
SENTINEL masters这个命令会列出所有被Sentinel监控的Redis主节点。
SENTINEL slaves mymaster这个命令会列出所有监控到的从节点的信息包括它们的IP地址、端口和与主节点的同步状态。
通过上述命令你可以验证Sentinel是否正常运行并检查它是否正确监控了Redis主节点。如果SENTINEL info命令返回了主节点的详细信息并且SENTINEL slaves命令列出了从节点的信息那么Sentinel应该正常运行并监控Redis主节点。
这些步骤提供了一个基本的框架用于使用redis-cli工具来验证Sentinel的配置和状态。根据你的具体需求你可能需要调整命令和参数。 Redis Sentinel 是一个分布式系统用于监控 Redis 服务的高可用性。它通常不运行在主节点或从节点上而是运行在独立的机器上。以下是关于 redis-sentinel 命令和 sentinel.conf 配置文件的具体说明 redis-sentinel 命令 这个命令是用来启动 Redis Sentinel 实例的。它需要在运行 Sentinel 的机器上存在。这些机器可以是单独的服务器也可以是虚拟机但它们不应该与运行 Redis 主节点或从节点的服务器相同。这样做的目的是为了确保即使主节点或从节点所在的机器发生故障Sentinel 仍然能够正常运行并执行故障转移操作。 sentinel.conf 配置文件 这个配置文件包含了 Sentinel 需要的所有配置信息包括监控的主节点信息、故障转移的参数等。它应该存在于运行 Sentinel 的每台机器上。每台 Sentinel 机器都会有自己的配置文件以便独立监控和处理故障转移。 部署建议 为了确保高可用性Sentinel 应该至少部署在三台不同的机器上。这是因为如果只有两台 Sentinel 机器它们之间可能会出现网络分区的情况导致无法达成法定人数quorum来决定主节点是否下线。Sentinel 机器应该与 Redis 主节点和从节点网络隔离以避免单点故障。在实际部署中Sentinel 机器通常与 Redis 节点位于不同的物理位置或不同的数据中心以减少单点故障的风险。
总结来说redis-sentinel 命令和 sentinel.conf 配置文件需要在专门用于运行 Sentinel 的机器上存在而不是在主节点或从节点上。这样做可以提高整个 Redis 集群的可用性和容错能力。 实例 现有三台Redis服务器redis01、redis02和redis03有三台Redis的sentinel服务器:sentinel01、sentinel02和sentinel03redis02和redis03是redis01的从节点建立了主从复制的关系三台Redis的sentinel服务器负责监控三台Redis服务器并实现故障自动转移如何配置并模拟实现上面的故障自动转移 要配置并模拟实现Redis服务器的故障自动转移可以按照以下步骤进行 配置Redis主从复制 确保redis01作为主节点redis02和redis03作为从节点。在redis02和redis03的配置文件中设置slaveof指令指向redis01的IP和端口例如slaveof redis01_ip 6379重启redis02和redis03使配置生效。 配置Sentinel监控 在三台Sentinel服务器上分别创建配置文件配置监控redis01。以下是一个示例配置port 26379
bind 0.0.0.0
sentinel monitor mymaster redis01_ip 6379 2
sentinel down-after-milliseconds mymaster 5000
sentinel failover-timeout mymaster 15000
sentinel parallel-syncs mymaster 3这里的mymaster是主节点的名称redis01_ip是redis01的IP地址6379是Redis默认端口2是quorum值即认为主节点下线所需的最小Sentinel数量。 启动Sentinel服务 在每台Sentinel服务器上启动Sentinel服务可以使用以下命令redis-sentinel /path/to/sentinel.conf确保Sentinel服务正常运行。 模拟故障转移 可以通过停止redis01服务来模拟主节点故障例如使用命令redis-cli -p 6379 shutdown观察Sentinel的日志确认它们是否检测到主节点故障并开始故障转移流程。故障转移完成后检查新的主节点是否已经由redis02或redis03中的一个担任并确认其他从节点是否已经开始复制新的主节点。 验证故障转移结果 使用redis-cli连接到新的主节点检查其状态redis-cli -p 新的主节点端口
info replication确认role显示为master并且connected_slaves显示了从节点的信息。 客户端更新 更新应用程序的配置使其连接到新的主节点。
通过以上步骤可以配置并模拟实现Redis的故障自动转移。整个过程应该是自动的不需要人工介入Sentinel会负责监控、故障发现、故障转移以及通知客户端新的主节点信息。
三、Redis Cluster模式 Redis 3.0之后节点之间通过去中心化的方式提供了完整的sharding、replication复制机制仍然复用原有机制只是cluster具备感知主备的能力、failover解决方案称为Redis的Cluster。即将proxy/sentinel的工作融合到了普通的Redis节点里
“去中心化”、“proxy/sentinel”的解释
去中心化Decentralization
在计算机科学和网络技术中去中心化是指网络结构或系统不依赖于单一的中心点或节点来控制整个网络的运作。在数据库和分布式系统的上下文中去中心化意味着没有单一的服务器或节点负责管理整个系统的所有操作。相反每个节点都具有自治能力可以独立地处理任务和决策而不需要中央服务器的直接控制。
对于Redis Cluster来说去中心化意味着
数据分片Sharding数据被自动分配到多个节点上没有单一节点控制所有数据。故障转移Failover当一个节点发生故障时其他节点可以自动进行故障转移而不需要中央协调器的干预。复制Replication主节点的数据可以被复制到多个从节点这些从节点可以独立地处理读请求而不需要中央协调器的直接管理。
Proxy/Sentinel
在Redis Cluster出现之前Redis使用两种组件来实现高可用性和故障转移 Sentinel哨兵Sentinel是一个分布式系统用于监控Redis主节点和从节点的运行状态并在主节点发生故障时进行自动故障转移。Sentinel可以监控多个Redis节点并且可以在主节点不可用时自动选举新的主节点。 ProxyProxy是一个中间层它位于客户端和Redis服务器之间。Proxy负责将客户端的请求路由到正确的Redis节点以及处理数据分片和复制。Proxy可以提供额外的功能如负载均衡、缓存、查询重写等。
在Redis Cluster中这些功能被集成到了Redis节点本身不再需要单独的Sentinel和Proxy组件。Redis Cluster节点可以自动处理数据分片、复制和故障转移同时还能感知主从节点的状态从而实现高可用性和自动故障转移。这种集成方式简化了Redis的部署和维护使得Redis的分布式部署更加高效和可靠。 在Redis Cluster出现之前处理sharding逻辑通常是通过客户端分片client-side sharding或者使用代理服务器proxy来实现的。以下是通过代理服务器处理sharding逻辑的具体方法和配置步骤
1. 客户端分片Client-side Sharding
客户端分片是指客户端自己计算数据的key应该在哪个机器上存储和查找。这种方式的好处是降低了服务器集群的复杂度因为服务器之间没有任何关联客户端实现数据分片时服务器是独立的。多数Redis客户端库实现了此功能也叫sharding。这种方式的缺点是客户端需要实时知道当前集群节点的联系信息同时当添加一个新的节点时客户端要支持动态sharding。
2. 通过代理服务器实现数据分片
代理服务器如Twemproxy或Predixy位于客户端和服务器之间将客户端发来的请求进行处理如sharding然后转发给后端真正的Redis服务器。客户端不直接访问Redis服务器而是通过代理中间件间接访问。
Twemproxy配置示例
Twemproxy是一个轻量级的代理中间件用于处理Redis和Memcached的sharding。以下是配置Twemproxy的基本步骤 下载并安装Twemproxy wget https://github.com/twitter/twemproxy/archive/master.zip
unzip master.zip
cd twemproxy-master
make配置Twemproxy 创建配置文件nutcracker.yml配置后端Redis服务器的信息 listens:- address: 0.0.0.0:6379protocol: redistimeout: 300
servers:- 127.0.0.1:7001: 1- 127.0.0.1:7002: 1启动Twemproxy ./nutcracker -c nutcracker.ymlPredixy配置示例
Predixy是另一个代理组件支持Redis单例模式及集群模式。 下载并安装Predixy wget https://github.com/joyieldInc/predixy/releases/tag/1.0.5
tar -xf predixy-1.0.5-bin-amd64-linux.tar.gz -C /usr/local/predixy配置Predixy 编辑predixy.conf全局配置文件并引用cluster.conf配置文件其中定义了Redis Cluster的节点信息 # predixy.conf
Include cluster.conf# cluster.conf
Cluster_001:ClusterServerPool {MasterReadPriority 60StaticSlaveReadPriority 50DynamicSlaveReadPriority 50RefreshInterval 1ServerTimeout 1ServerFailureLimit 10ServerRetryTimeout 1KeepAlive 120Servers { 192.168.98.111:16380 192.168.98.112:16380 192.168.98.113:16380}
}启动Predixy nohup predixy conf/predixy.conf 通过这些配置代理服务器可以接收来自客户端的请求并根据配置的规则将请求转发到正确的Redis节点实现sharding逻辑。这种方式降低了客户端的复杂度需要代理服务器收集集群节点信息。 Redis Cluster的拓扑结构
一个Redis Cluster由多个Redis节点组构成。不同节点组服务的数据无交集即每个节点组对应数据sharding分隔的一个分片。节点组内部分为主备两类节点(master和slave节点)两者数据准实时一致通过异步化主备复制机制保证。一个节点组有且仅有一个master节点同时有0到多个slave节点。只有master节点对用户提供写服务读服可以由master或者slave提供。
Redis Cluster 拓扑结构例图 A和B分别为两个master节点对外提供数据的读写服务分别负责1/2/3三个slot和4/5两个slot。A、A1作为主备关系构成一个节点组A1作为A的slave节点仍然持有1/2/3三个slot的数据。同理B1、B2作为B的slave也构成一个节点组。 上述的5个节点间两两通过Redis Cluster Bus交互相互交换如下关键信息 数据分片slot和节点的对应关系。 集群中每个节点可用状态 集群结构(配置)发生变更时通过一定的协议对配置信息达成一致。数据分片的迁移、故障发生时的主备切换决策、单点master的发现和其发生主备关系的变更等场景均会大致集群结构变化。 publish/subscribe发布/订阅功能在cluster中的内部实现所需要交互的信息。
Reids Cluster Bus通过单独的端口进行连接由于bus是节点间的内部通信机制交互的是字节序列化(二进制)信息而不是client到Redis服务器的字符序列化以提升交互效率。
slot的概念
在Redis Cluster中“slot”哈希槽是一个核心概念用于数据分片和分布式存储。以下是对slot概念的理解和为什么使用slot这个词的解释
什么是Redis Cluster的slot 数据分片Redis Cluster通过分片sharding的方式来保存数据库中的键值对。集群的整个数据库被分为16384个槽slot索引为0到16383。数据库中的每个键都属于这16384个槽中的一个。 键分配每个节点负责处理一部分插槽。通过CRC16(key) % 16384的公式计算键key属于哪个槽其中CRC16(key)用于计算键key的CRC16校验和。 节点责任集群中的每个节点负责处理一部分槽。例如一个节点可能负责处理0号至5500号插槽另一个节点负责5501号至11000号插槽以此类推。
为什么要用slot这个词 概念表达slot这个词在英语中意味着“插槽”或“位置”在Redis Cluster中它用来表示数据可以被分配和存储的位置。每个slot代表一个数据存储的位置使得数据可以在集群中被均匀分配。 管理方便使用slot可以方便地添加或移除节点。当需要增加节点时只需将其他节点的某些哈希槽挪到新节点即可当需要移除节点时只需将移除节点上的哈希槽挪到其他节点上。 数据迁移slot的使用使得数据迁移变得更加简单和直接。以槽为单位移动数据因为槽的数目是固定的处理起来比较容易这样数据移动问题就解决了。 避免数据倾斜slot的使用解决了一致性哈希算法的数据倾斜问题通过引入哈希槽slot在数据和节点之间加入了一层管理使得数据分配更加均匀。 固定数量Redis Cluster将数据划分为16384个槽位这个固定数量简化了集群管理尤其是在实现集群复制和故障转移机制方面。
综上所述slot在Redis Cluster中是一个用于数据分片和节点管理的关键概念它使得数据可以在集群中均匀分布并且方便了节点的添加和移除以及数据的迁移和管理。使用slot这个词是为了清晰地表达这个概念并强调其在集群架构中的重要性。
Redis Cluster的Bus
Redis Cluster中的Bus通常指的是Cluster Bus它是指Redis Cluster节点之间用于通信的内部通道。以下是对Redis Cluster Bus的理解和其作用的说明
什么是Redis Cluster Bus 节点间通信Redis Cluster Bus是集群中各个节点之间进行通信的专用通道。每个节点都会打开两个TCP端口一个是用于客户端连接的标准Redis端口另一个是用于节点间通信的Cluster Bus端口这个端口号比标准端口号高10000。 二进制协议Cluster Bus使用一种二进制协议进行节点间的点对点通信这种协议比文本协议更节省带宽和时间。
Redis Cluster Bus的作用 故障检测Cluster Bus用于节点间的心跳检测节点通过发送PING消息来检测其他节点是否存活这是故障检测机制的一部分。 配置更新当集群配置发生变化时比如有新节点加入或节点故障Cluster Bus负责传播这些变化确保所有节点都能更新它们的配置信息。 故障转移授权在主节点故障时Cluster Bus用于从节点之间的通信以选举新的主节点并进行故障转移。 消息传播Cluster Bus使用流言协议gossip protocol来传播消息包括节点状态、槽(slot)信息变更等这有助于节点间自动发现和保持集群状态的一致性。 Pub/Sub消息传递Cluster Bus还用于节点间的订阅消息(Pub/Sub messages)传递。 手动故障转移系统管理员可以通过Cluster Bus发起手动故障转移操作。
综上所述Redis Cluster Bus是Redis Cluster中节点间通信的关键机制它负责故障检测、配置更新、故障转移等重要功能确保了集群的高可用性和数据一致性。使用Bus这个词可能是因为它像公交车一样在节点之间传递信息连接各个节点并保持它们之间的通信和状态同步。
Redis Cluster中每个节点的如何保持集群的拓扑结构的一致
对于一个去中心化的实现集群的拓扑结构并不保存到单独的配置节点上后者的引入同样会带来新的一致性问题。那么各自为政的节点如何就集群的拓扑结构达成一致是Redis Cluster配置机制解决的问题。Redis Cluster通过引入两个自增的epoch变量来使得集群配置在各个节点间达成最终一致。
Redis Cluster的每个节点都有两种数据结构信息配置数据结构负责保存集群的配置结构信息和交互信息数据结构负责实现Redis Cluster Bus
clusterState 1-----------n cluserNode
clusterState中含有“currentEpoch”、“分片迁移相关状态”、“failover相关状态”等变量
“currentEpoch”表示集群中的最大版本号集群信息每变更一次该版本号都会自增以保证每个信息的版本号唯一 由于去中心化的架构下不存在统一的配置中心各个节点对整个集群状态的认知来自于节点之间的信息交互。在Redis Cluster中这个信息交互通过Redist Cluter Bus来完成后者端口独立。
clusterMsg 1-----------n clusterMsgDataGossin clusterMsg中含有“type”、“gossip或其他消息体”等成员变量
“type”有“PING和”PONG两种类型 每一个节点向其他所有节点较为频繁地周期性发送PING消息同时接收PONG回应。在这些交互信息的Gossip部分包含了发送者节点或者响应节点所知的集群其他节点信息接收节点根据这些Gossip信息更新自己的对于集群结构的认识。
当集群结构不发生变化的时候集群中的各个节点通过gossip协议可以在几轮交互之后得知全集群的结构信息且达到一致的状态。然而故障转移、分片迁移等情况的发生会导致集群结构变更由于无统一的配置服务器变更的信息只能靠各个节点自行协调而变更信息的节点利用epoch变量将自己的最新信息扩散到整个集群达到最终一致。 Gossip协议的概念
Gossip协议又称为流言协议或疫情传播算法是一种在分布式系统中用于节点间状态同步和数据更新的重要工具。它的核心思想是通过节点间的随机信息交换实现整个分布式系统中信息的快速同步和数据的最终一致性。
Gossip协议的工作原理类似于流行病的传播。每个节点以一定的概率随机选择其他节点进行信息交换并将信息传播给它们选择的节点。这种方式使得信息能够在整个网络中快速扩散类似于病毒的传播方式。每个节点只发送固定数量的消息并在一定时间内与其他节点交换信息。通过这种方式Gossip Protocol能够在较短的时间内使得系统内的所有节点数据一致。
Gossip协议具有以下优势
高效性由于采用了类似于流行病传播的方式Gossip协议能够在较短的时间内将信息传播到整个网络中。可靠性由于每个节点都与其他节点进行信息交换因此即使部分节点出现故障信息仍然可以通过其他节点进行传播。灵活性Gossip协议适用于各种不同类型的网络和系统可以根据需要进行定制和扩展。简单性Gossip协议的实现相对简单不需要复杂的配置和参数设置。
Gossip协议在分布式系统中被广泛应用如数据库复制、分布式计算、系统监控、消息传递等。以下是一些具体的应用场景
数据库复制Gossip协议可以用于实现数据库的分布式复制确保所有副本的数据一致性。通过使用Gossip协议可以实现高效的故障转移和数据恢复。分布式计算在分布式计算环境中Gossip协议可以用于实现节点间的数据同步和信息传递提高计算效率和可靠性。系统监控通过使用Gossip协议可以实现对分布式系统的实时监控和故障检测。节点间可以相互交换状态信息和监控数据以便及时发现和解决问题。消息传递在分布式系统中Gossip协议可以用于实现节点间的消息传递。通过将消息随机地传播到整个网络中可以提高消息传递的可靠性和效率。
Gossip协议因其简单、高效和鲁棒性在分布式系统中得到了广泛的应用和研究。 Redis Cluster数据分片和HashTag
简要笔记详细内容略
1、Redis Cluster将所有的数据划分为16384个默认大小可以调整分片(slot每个分片负责其中的一部分。每一天数据(key-value)根据key名通过数据分布算法映射到16384个slot中的一个。 数据分布算法为 slotIdcrcl6(key)%16384
客户端根据slotId决定将请求路由到哪个Redis节点中
2、cluster不支持跨节点的单命令如果涉及的两个key对应的slot分布到到不同的node上则操作失败 例如商品交易摘要记录和商品详情记录即便对同一个商品也会在Redis中以不同的key分成两条记录存储常常需要在同一个命令中操作这两条记录。由于数据分布算法将key的内部组成作为一个黑盒这两条记录有极大可能分散到不同的节点上。
3、Redis引入了HashTag概念例如 某条商品的交易记录的key值为product_trade_{prod123} 这个商品的详情记录的key值为product_detail_{prod123} Redis会根据{}之间的子字符串作为数据分布算法的输入
Redis Cluster客户端路由moved命令和ask命令
简易笔记详细略
1、Redis Cluster的客户端相比单机Redis需要具备路由语义的识别能力且具备一定的路由缓存能力。
2、当一个client访问的key不在对应的Redis节点的slots中Redis返回给client一个moved命令,告知其正确的路由信息从client收到moved响应到再次向moved响应中指向的节点假设为节点B发送请求期间Redis Cluster的数据分布可能又发生了变更使得B仍然不是正确的节点此时B会继续响应moved。client根据moved响应更新其内部的路由缓存信息以便下一次请求时直接能够路由到正确的节点降低交互次数。
3、当cluster处在数据重分布过程中时slot1打算迁移到新节点上可以使用ask命令迁移过程中如果客户端访问已经完成迁移的key节点将响应ask告知客户端向目标节点重试。
4、ask命令和moved命令不同的语义在于后者会更新client数据分布前者只是本条操作重定向到新节点后续的相同slot操作仍路由到旧节点。
Redis Cluster提供分片的迁移过程的原语
简单笔记详细略
在一个稳定的Redis Cluster下每一个slot对应的节点时确定的。但是在某些情况下节点和分片的对应关系需要发生变更 新的节点作为master加入 某个节点分组需要下线 负载不均需要调整slot分布
此时需要进行分片的迁移。分片迁移的触发和过程控制由外部系统完成Redis Cluster只提供迁移过程中需要的原语供外部系统调用。这些原语主要包含两种 节点迁移状态设置迁移前标记源/目标节点 key迁移的原子化命令迁移的具体步骤migrate、cluser seslot命令等
什么是原语
在计算机科学和软件工程中“原语”Primitive通常指的是一些基本的、不可分割的操作或函数它们是构建更复杂系统和应用程序的基础。在不同的上下文中原语可以有不同的含义但在提到“Redis Cluster只提供迁移过程中需要的原语供外部系统调用”时这里的“原语”指的是Redis Cluster提供的一组基本操作接口或命令。
Redis Cluster中的原语 数据迁移操作在Redis Cluster中原语可能包括用于数据迁移的基本操作如MIGRATE命令。这个命令允许将数据从一个节点迁移到另一个节点同时保持数据的一致性和可用性。 槽管理原语也可能包括管理哈希槽slot的操作这些操作允许外部系统查询、分配和重新分配槽以及处理槽的所有权转移。 节点管理原语可能还包括节点的添加、移除和故障转移等操作这些操作是维护Redis Cluster健康和稳定运行的基础。 数据同步原语还可能包括数据同步相关的操作这些操作确保在迁移过程中数据的一致性。
为什么提供原语 灵活性通过提供原语Redis允许外部系统以编程方式控制和自定义数据迁移和集群管理的过程而不是完全依赖于Redis内部的自动机制。 控制外部系统可以根据特定的业务逻辑和需求精确控制迁移过程比如在迁移前进行数据校验或者在迁移后执行特定的清理操作。 集成原语使得Redis可以更好地与其他系统集成例如可以与自动化部署工具、监控系统或者自定义的集群管理工具集成。 扩展性提供原语允许开发者根据需要扩展Redis的功能比如开发自定义的迁移策略或者优化数据分布。
总的来说Redis Cluster中的“原语”是指那些基本的操作和命令它们为外部系统提供了对集群内部操作的直接控制使得数据迁移和集群管理更加灵活和可控。
Redis Cluster的failover机制
和Sentinel的故障发现、故障确认、Master选举过程类似只是多了是Redis Cluster 在集群中的每个节点之间使用了Redis Cluster Bus进行节点间的集群配置同步等过程具体内容略
Redis Cluster的读写分离和Master的单点保护机制
Redis Cluster的读写分离
对于由读写分离需求的场景应用对于某些读的请求允许舍弃一定的数据一致性以换取更高的读吞吐量。此时希望将读的请求交由slave处理以分担master的压力。
默认情况下数据分片映射关系中某个slot对应的节点一定是一个master节点客户端通过MOVED消息得知的集群拓扑结构也只会将请求路由到各个master中即便客户端将读请求直接发送到slave上后者也会回复MOVED到master的响应。
为此Redis Cluster 引入了READONLY命令。客户端向slave发送该命令后slave对于读操作将不再MOVED到master而是直接处理这称为READONLY模式
通过READWRITE命令可将salve的readonly模式重置。
Redis Cluster的Master的单点保护机制
集群只需要保持2*master1个节点就可以在任一节点宕机后仍然能自动地维持高可用状态如果一个主节点A只有一个从节点A1这个从节点A1宕机了那么这个主节点A将很为了单点此时Redis Cluster会将其他主节点假设为B的一个从节点假设为B1进行副本迁移让其变为A的slave。 具体介绍略
Redis Cluster模式的具体配置
要配置Redis Cluster模式你需要遵循以下步骤
1. 环境准备
首先你需要准备多个Redis实例至少需要三个主节点推荐六个节点三个主节点和三个从节点以确保高可用性。
2. 配置Redis实例
对于每个Redis实例你需要修改redis.conf配置文件设置以下参数
port设置Redis实例的端口号。cluster-enabled yes启用Redis的集群模式。cluster-config-file nodes.conf指定集群配置文件的名称这个文件由Redis自动管理不需要手动编辑。cluster-node-timeout 5000设置节点超时时间单位为毫秒这个参数决定了主节点在多长时间内无响应被视为失败。appendonly yes启用AOF持久化确保数据的持久性。
3. 启动Redis实例
在每个配置好的目录中启动Redis实例。例如如果你的配置文件位于7000到7005的目录中你需要在每个目录下启动对应的Redis实例
cd 7000
redis-server ./redis.conf4. 创建Redis Cluster
使用redis-cli工具创建集群。你需要提供所有节点的IP地址和端口号。例如如果你有六个节点你可以使用以下命令创建集群
redis-cli --cluster create [IP_ADDRESS_1]:6379 [IP_ADDRESS_2]:6379 [IP_ADDRESS_3]:6379 [IP_ADDRESS_4]:6379 [IP_ADDRESS_5]:6379 [IP_ADDRESS_6]:6379 --cluster-replicas 1这个命令会将前三个IP地址作为主节点其余的作为从节点。
5. 验证集群状态
创建集群后你可以使用以下命令来验证集群的状态
redis-cli -c -h 192.168.10.101 -p 7000 -a password这个命令会连接到集群并显示集群的状态信息。
以上步骤概述了Redis Cluster模式的具体配置过程。在实际操作中可能还需要根据具体的业务需求和环境进行调整和优化。 *拓展概念拓扑结构
拓扑结构Topological Structure是一个数学概念它描述了空间中各个点之间的邻近关系而不关心这些点的具体位置和距离。在不同的领域拓扑结构有着不同的应用和含义 数学中的拓扑学 在数学的拓扑学分支中拓扑结构指的是一个集合以及其上的一个拓扑这个拓扑定义了集合中元素之间的“邻接性”或“连通性”。拓扑结构关注的是空间的连续性和开放性而不是精确的度量信息如长度、角度等。拓扑结构允许通过连续变换如拉伸、弯曲但不能撕裂或粘合来研究和比较不同的空间形状。 计算机网络中的拓扑结构 在计算机网络领域拓扑结构指的是网络中各个设备如计算机、打印机、路由器等的物理或逻辑连接方式。常见的网络拓扑结构包括总线型、星型、环型、树型和网状型等。网络拓扑结构影响网络的性能、可靠性和成本是网络设计和分析的重要方面。 图论中的拓扑结构 在图论中拓扑结构可以指代图的连通性即节点顶点和边的排列方式它描述了节点之间的连接关系而不关心节点的具体位置。图的拓扑结构是研究图的性质和算法的基础如最短路径、网络流等问题。 地理信息系统GIS中的拓扑结构 在地理信息系统中拓扑结构指的是地理要素如道路、河流、区域等之间的空间关系如邻接、相交、包含等。维护GIS数据的拓扑结构有助于保持数据的一致性和准确性。 软件架构中的拓扑结构 在软件架构中拓扑结构可能指的是系统组件之间的连接和交互模式如服务之间的调用关系、数据流等。
拓扑结构的核心思想是关注元素之间的关系和连接性而不是它们的具体位置或形态。这种抽象的视角使得拓扑结构在多个领域中都有着广泛的应用。
