jquery 网站模板,何炅做的代言网站,网站域名空间一年多少钱,免费做网站的公司本文记述了博主在学习 Redis 在大型项目下的使用方式#xff0c;包括如何设置Redis主从节点#xff0c;应对突发状况如何处理。在了解了Redis的集群搭建和相关的主从复制以及哨兵模式的知识以后#xff0c;进而想要了解 Redis 集群如何使用#xff0c;如何正确使用#xf… 本文记述了博主在学习 Redis 在大型项目下的使用方式包括如何设置Redis主从节点应对突发状况如何处理。在了解了Redis的集群搭建和相关的主从复制以及哨兵模式的知识以后进而想要了解 Redis 集群如何使用如何正确使用在什么场景下使用什么样的集群模式。本文不涉及集群搭建。 文章目录 一、各种 Redis 集群对比二、一主一从1、集群网络配置2、主从复制原理3、故障转移机制哨兵 三、一主多从1、集群网络配置2、主从复制原理并行机制3、故障转移机制哨兵 四、多主多从1、集群网络配置2、主从复制原理异步机制3、故障转移机制哨兵4、多主多从注意事项 一、各种 Redis 集群对比
Redis集群一般有以下三种常见分类一主一从、一主多从和多主多从其对比如下。
架构一主一从一主多从多主多从架构复杂度最简单一个主节点和一个从节点较复杂一个主节点和多个从节点最复杂多个主节点和从节点分片数据冗余最低两份数据较高多份数据最高多份数据分片备份读性能低一个从节点分担读请求高多个从节点分担读请求高多个从节点分担读请求写性能低写操作集中在主节点低写操作集中在主节点高写操作分散到多个主节点高可用性最低依赖哨兵或集群切换较高依赖哨兵或集群切换最高分片和哨兵或集群切换配置与运维最简单部署成本低较复杂运维难度适中最复杂运维难度高适用场景小型应用、开发测试环境读多写少的场景大型生产环境、高并发场景
搭建集群过程中的必备技巧
配置优化合理设置复制延迟参数根据实际业务需求调整 repl-ping-slave-period 和 repl-timeout 等参数以平衡复制的实时性和网络资源占用。优化数据同步方式在从节点首次连接主节点时主节点会进行全量同步可以通过设置 repl-diskless-sync 参数为 yes 启用无磁盘复制减少磁盘 I/O 操作。监控主从状态定期使用 info replication 命令查看主从复制的状态确保从节点与主节点的连接正常数据同步没有异常。设置延迟报警当主从复制延迟过高时可能会对业务产生影响可以通过监控工具设置延迟报警阈值及时发现并解决问题。定期备份主节点数据除了依赖主从复制进行数据备份外还应定期对主节点的数据进行全量备份以便在出现严重故障时能够快速恢复。测试备份恢复流程定期测试备份数据的恢复流程确保在需要时能够顺利恢复数据避免因备份数据损坏或恢复流程不熟悉而导致数据丢失。
二、一主一从
这种集群架构较为简单只有一个主节点和一个从节点。
主节点负责写操作从节点通过复制主节点的数据来保持数据一致性。数据冗余较低只有主节点和从节点两份数据如果主节点和从节点同时出现故障可能会导致数据丢失。适合对数据可靠性要求不高的场景。写性能主要依赖于主节点从节点主要用于读操作可以分担部分读负载在高并发写操作时可能会成为性能瓶颈。如果主节点故障从节点可以通过故障转移机制自动切换为主节点但切换过程可能会有一定读延迟并且在切换过程中可能会出现短暂的服务不可用。资源消耗相对较少只需要两台服务器即可适合资源有限的环境部署和维护成本较低适合小型应用或测试环境。
1、集群网络配置
主节点配置
# redis-master.conf
bind 0.0.0.0
port 6379
daemonize yes从节点配置
# redis-slave.conf
bind 0.0.0.0
port 6380
daemonize yes
replicaof 127.0.0.1 6379 # 指定主节点地址
# 如果使用Redis 5.0及以上版本slaveof 已被替换为 replicaof 。验证主从状态
# 在主节点查看复制信息
redis-cli -p 6379 info replication2、主从复制原理
Redis主从复制通过异步复制实现数据的冗余备份和读写分离
主节点Master负责处理所有写操作并将写命令异步传播给从节点。从节点Slave接收主节点的数据副本处理读请求支持横向扩展读性能。全量同步Full Sync从节点首次连接主节点时主节点生成RDB快照并发送给从节点从节点加载数据。增量同步Partial Sync后续主节点的写操作通过 replication buffer 实时同步到从节点。
3、故障转移机制哨兵
在Redis一主一从集群中故障转移通常需要借助哨兵Sentinel机制来实现。
1、哨兵模式常见的三大步骤
监控哨兵节点定期检查主从节点的健康状态。通知当主节点故障时哨兵节点会通过 Raft 算法选举一个领导者哨兵。故障转移领导者哨兵会选择一个从节点提升为主节点并通知其他从节点切换到新的主节点。
2、哨兵的工作机制
每个哨兵节点会定期向主从节点发送心跳命令PING以检测其健康状态。如果超过配置的 down-after-milliseconds 时间主节点仍未响应则哨兵会认为主节点主观下线。当超过 quorum 数量的哨兵节点都认为主节点下线时会触发故障转移。哨兵节点通过 Raft 算法选举一个领导者哨兵由领导者负责故障转移。
哨兵会监控主从节点的状态当主节点故障时哨兵会触发故障转移即哨兵会根据一定的规则选举一个新的从节点晋升为主节点。
3、哨兵的选举规则
优先选择优先级最高的从节点可通过slave-priority配置。若优先级相同选择复制偏移量最大的从节点数据最完整。若仍相同根据节点的runID选择runID越小说明重启次数越少。最后哨兵会更新所有从节点的配置文件使其指向新的主节点并通知客户端新的主节点地址。
三、一主多从
一主多从集群架构常见于大型网站的缓存服务有一个主节点和多个从节点。这种集群的配置方式和一主一从差不多区别就在于多了些从节点而我们知道从节点主要是用于读操作主节点是用于写操作。所以这种集群方式不难看出适用于读多写少的情境中。
主节点负责写操作多个从节点通过复制主节点的数据来提供读服务可以有效分担读负载所以适用读操作较多、写操作较少的场景。数据冗余较高主节点和多个从节点都有数据副本即使某个从节点故障其他从节点仍然可以提供服务但主节点故障仍可能影响写操作在高并发写操作时可能会成为性能瓶颈但不会影响到读操作。哨兵或集群模式可以自动切换主节点多个从节点提供更好的冗余切换过程可能会有一定读延迟短暂的切换过程可能会影响到写操作但是不影响服务的读操作适合对高可用性有一定要求的场景。配置稍复杂需要配置多个从节点运维难度适中需要监控多个从节点的状态。
1、集群网络配置
主节点配置
# redis-master.conf
port 6379
bind 0.0.0.0
requirepass your_password # 如果需要密码认证设置密码从节点1配置
# redis-slave.conf
port 6380
bind 0.0.0.0
replicaof 127.0.0.1 6379 # 指定主节点地址
masterauth your_password # 如果主节点设置了密码需要配置从节点2配置
# redis-slave.conf
port 6381
bind 0.0.0.0
replicaof 127.0.0.1 6379 # 指定主节点地址
masterauth your_password # 如果主节点设置了密码需要配置2、主从复制原理并行机制
Redis主从复制通过数据同步实现读写分离和数据备份主从复制的主要方式和一主一从集群类似例如全量同步和增量同步有一点不同的是关于主从复制的并行机制主节点要同时向多个从节点发送同步信息。 并行机制当多个从节点连接到主节点时主节点会为每个从节点维护一个独立的复制连接和状态。主节点会将写命令同时发送给所有从节点而不是逐一发送。这种机制确保了主节点可以高效地处理多个从节点的复制请求而不会因为从节点数量的增加而显著降低性能。 过程可以分为以下几个关键步骤这些步骤对每个从节点都是独立进行的。
连接建立从节点启动时会根据配置文件中的 replicaof 指令连接到主节点。主节点会为每个从节点分配一个独立的复制连接。全量同步和增量同步 当从节点首次连接到主节点时主节点会生成一个RDB快照文件并将其发送给从节点。在发送RDB文件期间主节点会将新产生的写命令记录在复制积压缓冲区中。从节点加载RDB文件后主节点会将复制积压缓冲区中的命令发送给从节点。 部分同步 如果从节点与主节点的连接短暂中断后重新连接主节点会检查从节点的复制偏移量。如果从节点的偏移量在复制积压缓冲区的范围内主节点会通过部分同步的方式仅发送从节点缺失的命令而无需重新发送整个RDB文件。 命令同步主节点在处理写命令时会将这些命令实时发送给所有从节点从节点接收到命令后会立即执行这些命令以确保数据的一致性。 这里延伸到主节点如何做到同时处理多个从节点的复制请求 多路复用I/O多路复用Redis 使用 I/O 多路复用技术如epoll、kqueue等能够同时监听和处理多个从节点的连接。主节点通过事件循环机制高效地处理来自多个从节点的复制请求。复制缓冲区主节点为每个从节点维护一个独立的复制缓冲区用于存储发送给从节点的命令。主节点会将写命令写入每个从节点的复制缓冲区然后通过网络发送给从节点。并行发送主节点会将写命令同时发送给所有从节点而不是逐一发送。这种并行机制确保了主从复制的高效性即使有多个从节点也不会显著增加主节点的负载。 主从复制的并行机制使得主节点能够高效地处理多个从节点的复制请求。主节点的性能主要受限于网络带宽和磁盘I/O在全量同步时。主节点可以同时支持多个从节点但随着从节点数量的增加主节点的网络带宽和CPU资源可能会成为瓶颈。 实际场景中的注意事项
网络延迟如果从节点分布在不同的地理位置网络延迟可能会影响复制的实时性。在这种情况下可以考虑使用靠近主节点的从节点作为中间节点进一步扩展从节点。复制积压缓冲区大小复制积压缓冲区的大小需要根据实际场景进行调整。如果缓冲区过小可能会导致部分同步失败从而触发全量同步。故障切换在使用哨兵模式时哨兵会自动处理主节点故障切换。从节点会自动切换到新的主节点继续进行复制。
3、故障转移机制哨兵
Redis哨兵模式是一种高可用解决方案用于监控主从复制集群的健康状态并在主节点故障时自动切换主节点。
哨兵节点配置文件sentinel.conf
# 哨兵节点配置
port 16379
sentinel monitor mymaster 127.0.0.1 6379 2 # 配置监控的主节点
sentinel down-after-milliseconds mymaster 5000 # 主节点无响应时间
sentinel failover-timeout mymaster 180000 # 故障转移超时时间
sentinel parallel-syncs mymaster 1 # 同步新主节点的从节点数量
sentinel auth-pass mymaster your_password # 主节点密码启动哨兵节点
redis-server /path/to/sentinel.conf --sentinel哨兵节点会自动发现其他哨兵节点并通过 Raft 算法进行选举通过监控和故障转移确保集群的高可用性。
四、多主多从
多主多从集群架构常见于大型生产环境、高并发读写场景、对高可用性要求极高的场景。
多个主节点和多个从节点每个主节点有一个或多个对应的从节点。每个主节点独立处理一部分数据通过分片机制实现数据分布从节点作为备份提供高可用性。数据冗余最高每个主节点都有一个从节点备份且主节点之间通过分片机制进一步提升冗余即使某个主节点或从节点故障其他节点仍然可以正常工作整体可靠性最高。多个从节点可以分担读请求读性能高写操作分散到多个主节点适合高并发读写场景。哨兵或集群模式可以自动切换主节点且主节点之间通过分片机制进一步提升高可用性。配置复杂需要配置多个主节点和从节点以及分片策略。运维难度高需要监控多个节点的状态确保数据分片和故障转移的正确性。
1、集群网络配置
主节点配置为每个主节点创建独立的配置文件例如 redis-master1.conf 和 redis-master2.conf 根据需要修改端口、日志路径和数据目录等配置。
port 6379 # 主节点监听端口
daemonize yes # 后台运行
pidfile /var/run/redis-master1.pid # 进程ID文件
logfile /var/log/redis-master1.log # 日志文件
dir /var/lib/redis-master1 # 数据存放目录
requirepass your_password # 设置访问密码可选
masterauth your_password # 设置主从复制时的密码如果需要从节点配置为每个从节点创建独立的配置文件例如 redis-slave1.conf 和 redis-slave2.conf 根据需要修改端口、主节点IP、日志路径和数据目录等配置。
port 6380 # 从节点监听端口
daemonize yes # 后台运行
pidfile /var/run/redis-slave1.pid # 进程ID文件
logfile /var/log/redis-slave1.log # 日志文件
dir /var/lib/redis-slave1 # 数据存放目录
replicaof master_ip 6379 # 指定主节点的IP和端口
requirepass your_password # 设置访问密码如果需要
masterauth your_password # 设置主从复制时的密码如果需要根据配置文件启动主节点和从节点重复命令以启动其他主节点和从节点。
redis-server /path/to/redis-master1.conf
redis-server /path/to/redis-slave1.conf使用 redis-cli 验证主从复制关系是否成功
redis-cli -p 6379 info replication # 查看主节点状态
redis-cli -p 6380 info replication # 查看从节点状态主节点应显示为 master 从节点应显示为 slave 。
2、主从复制原理异步机制
Redis多主多从架构允许多个主节点和多个从节点同时工作。每个主节点可以有多个从节点进行数据备份同时主节点之间也可以通过配置相互同步数据。其中多个主节点master和从节点slave之间的复制机制是实现数据一致性和高可用性的关键。
Redis 的主从复制是异步的主节点将数据同步到从节点从节点可以作为备份或分担读负载。在多主多从架构中每个主节点可以有多个从节点主节点负责写操作从节点通过复制主节点的数据来保持数据一致性。
在多主多从架构中每个主节点独立运行互不干扰。主节点之间的写操作不会直接同步每个主节点只负责将数据同步到自己的从节点。
从节点通过以下步骤进行主从复制
全量同步从节点首次连接主节点时主节点会生成一个 RDB 快照文件并发送给从节点从节点加载快照文件以获取主节点的完整数据。增量同步在全量同步完成后主节点会将后续的写操作命令通过复制缓冲区实时发送给从节点从节点根据这些命令更新本地数据。
在多主多从架构中从节点可以作为主节点的备份。如果主节点故障从节点可以通过哨兵Sentinel或集群Cluster模式自动切换为主节点。哨兵模式可以监控主节点的健康状态并在主节点故障时自动从从节点中选择一个作为新的主节点。
Redis 原生并不支持多主节点之间的直接写操作同步。多主架构通常需要第三方解决方案或自定义逻辑来处理跨主节点的数据同步问题。例如Redis Enterprise 提供了冲突无关的复制数据类型CRDTs允许跨地理分布的多主部署。
注意事项
数据一致性在多主架构中需要特别注意数据一致性问题尤其是在跨主节点同步数据时。冲突处理多主架构中可能会出现写冲突需要通过冲突解决机制如 CRDTs来处理。配置管理确保主从节点的配置正确并定期检查复制状态以确保数据同步正常。
3、故障转移机制哨兵
哨兵模式用于监控主从节点的状态并在主节点故障时自动进行故障转移。
哨兵节点配置文件sentinel.conf
port 16379 # 哨兵节点监听端口
sentinel monitor mymaster master_ip 6379 2 # 监控主节点
sentinel down-after-milliseconds mymaster 5000 # 判定主节点失联的毫秒数
sentinel failover-timeout mymaster 60000 # 故障转移超时时间
sentinel parallel-syncs mymaster 1 # 同步新主节点的从节点数量
sentinel auth-pass mymaster your_password # 主节点密码如果需要根据需要配置多个主节点的监控。
启动哨兵节点
redis-sentinel /path/to/sentinel.conf在多主多从集群中每个主节点都需要一个哨兵监控配置。
4、多主多从注意事项
在大型项目中使用 Redis 多主多从架构时需要注意以下关键点以确保系统的高可用性、性能和可扩展性。
1、数据一致性与冲突管理在多主架构中多个主节点可以同时写入数据这可能导致数据冲突。
分布式锁在写操作前获取分布式锁确保同一时间只有一个主节点可以修改特定数据。数据分片策略通过合理的分片策略如一致性哈希将数据分散到不同的主节点上减少冲突的可能性。
2、故障转移与高可用性
哨兵模式Sentinel使用哨兵监控主节点的健康状态当主节点故障时自动切换到从节点。确保哨兵的配置正确避免脑裂split-brain问题。集群模式Cluster在集群模式下Redis会自动处理故障转移。确保每个主节点至少有一个从节点并且集群的配置正确。
3、性能优化
读写分离将读操作分发到从节点减轻主节点的负载提升整体性能。合理配置TTL为临时数据设置合理的TTL生存时间避免内存浪费。内存管理监控Redis的内存使用情况确保数据集能够完全放入内存中。如果需要可以配置数据淘汰策略。
4、部署与运维
节点数量与配置至少部署三个主节点以防止网络分区问题。每个主节点应配置至少一个从节点。监控与日志使用工具如 Redis INFO 命令、Prometheus 等监控 Redis 实例的性能和健康状态。网络带宽确保网络带宽足以处理 Redis 节点之间的通信特别是在数据同步和故障转移时。
5、数据持久化
根据应用需求选择合适的持久化策略RDB、AOF或两者结合。RDB适合快速恢复但可能丢失部分数据。AOF更安全但占用更多资源。
6、容量规划
了解数据特性分析数据类型、大小和生命周期合理规划内存容量。负载预估评估平均和峰值读写负载选择合适大小的 Redis 实例并预留扩展空间。冗余与备份通过哨兵或集群模式实现数据冗余确保在节点故障时数据安全。
7、安全与访问控制
SSL/TLS 加密在节点间通信时使用 SSL/TLS 加密确保数据传输安全。访问控制限制Redis实例的访问权限仅允许必要的用户和服务访问。
通过遵循这些最佳实践可以有效提升 Redis 多主多从架构在大型项目中的稳定性和性能表现。
