常州网站建设网站wordpress设置横向菜单

常州网站建设网站,wordpress设置横向菜单,网站建设公司有哪些方面,搜索引擎推广效果前言Redis作为高性能的内存数据存储#xff0c;其核心数据驻留于易失性内存中。为了在保障卓越性能的同时#xff0c;满足实际生产环境对数据可靠性和服务高可用性的严苛要求#xff0c;Redis提供了相辅相成的三大核心机制#xff1a;持久化、主从复制和哨兵模式。这三者构…前言Redis作为高性能的内存数据存储其核心数据驻留于易失性内存中。为了在保障卓越性能的同时满足实际生产环境对数据可靠性和服务高可用性的严苛要求Redis提供了相辅相成的三大核心机制持久化、主从复制和哨兵模式。这三者构成了Redis从单点数据存储迈向健壮、可靠分布式系统的基石持久化解决了数据的持久存储问题。它通过将内存数据定期或实时保存至磁盘RDB快照与AOF日志确保在Redis进程重启后数据得以恢复是数据安全的最后防线。主从复制解决了数据的多副本备份与读写分离问题。它允许将一台主节点Master的数据异步复制到多个从节点Slave实现了数据冗余、负载分流并为故障转移提供了数据基础。哨兵模式解决了服务的高可用性与自动故障转移问题。哨兵是一个独立的分布式监控系统它能自动监测主从节点的健康状态并在主节点故障时通过投票机制自动选举并提升一个从节点为新的主节点通知客户端连接新的主节点从而实现服务不间断。简而言之三者协同工作构建了一个稳固的Redis服务体系持久化保障数据不丢主从复制保障数据多备并扩展读能力哨兵模式则保障服务在故障时能自动切换、永不中断。理解这三者的原理与配置是设计和运维一个可用于生产环境的Redis集群的关键前提。持久化什么是持久化持久化是最简单的高可用方法主要作用是数据备份即将数据存储在硬盘保证数据不会因进程退出而丢失。rdb持久化rdb快照定期把数据快照保存到磁盘优点文件小恢复快。缺点可能丢几分钟数据。触发条件手动触发使用bgsave在redis交互页面输入bgsave或者save即可触发快照生成rdb文件save命令会阻塞Redis服务器进程直到RDB文件创建完毕为止在Redis服务器阻塞期间服务器不能处理任何命令请求。而bgsave命令会创建一个子进程由子进程来负责创建RDB文件父进程(即Redis主进程)则继续处理请求。总结因此save已基本被废弃线上环境要杜绝save的使用。自动触发vim /etc/redis/6379.confsave m n --219行--以下三个save条件满足任意一个时都会引起bgsave的调用 save 900 1 当时间到900秒时如果redis数据发生了至少1次变化则执行bgsave save 300 10 当时间到300秒时如果redis数据发生了至少10次变化则执行bgsave save 60 10000 当时间到60秒时如果redis数据发生了至少10000次变化则执行bgsave --254行--指定RDB文件名 dbfilename dump.rdb --264行--指定RDB文件和AOF文件所在目录 dir /var/lib/redis/6379 --242行--是否开启RDB文件压缩 rdbcompression yes自动触发最常见的情况是在配置文件中通过save m n指定当m秒内发生n次变化时会触发bgsave。其他触发快照的场景shutdown # redis服务优雅退出,会触发快照 stop # redis被关闭可能会触发快照不稳定 exit # 退出redis-cli服务没关闭 quit # 退出redis-cli服务没关闭bgsave流程原理Redis父进程首先判断当前是否在执行save或bgsave/bgrewriteaof的子进程如果在执行则bgsave命令直接返回。 bgsave/bgrewriteaof的子进程不能同时执行主要是基于性能方面的考虑两个并发的子进程同时执行大量的磁盘写操作可能引起严重的性能问题。父进程执行fork操作创建子进程这个过程中父进程是阻塞的Redis不能执行来自客户端的任何命令父进程fork后bgsave命令返回”Background saving started”信息并不再阻塞父进程并可以响应其他命令子进程创建RDB文件根据父进程内存快照生成临时快照文件完成后对原有文件进行原子替换子进程发送信号给父进程表示完成父进程更新统计信息2.4、rdb文件加载RDB文件的载入工作是在服务器启动时自动执行的并没有专门的命令。但是由于AOF的优先级更高因此当AOF开启时Redis会优先载入 AOF文件来恢复数据只有当AOF关闭时才会在Redis服务器启动时检测RDB文件并自动载入。服务器载入RDB文件期间处于阻塞状态直到载入完成为止。Redis载入RDB文件时会对RDB文件进行校验如果文件损坏则日志中会打印错误Redis启动失败。AOF持久化aof介绍RDB持久化是将进程数据写入文件而AOF持久化则是将Redis执行的每次写、删除命令记录到单独的日志文件中查询操作不会记录 当Redis重启时再次执行AOF文件中的命令来恢复数据。 与RDB相比AOF的实时性更好因此已成为主流的持久化方案。开启AOF# Redis服务器默认开启RDB关闭AOF要开启AOF需要在配置文件中配置 vim /etc/redis/6379.conf --700行--修改开启AOF appendonly yes --704行--指定AOF文件名称 appendfilename appendonly.aof --796行--是否忽略最后一条可能存在问题的指令 aof-load-truncated yes /etc/init.d/redis_6379 restartbgrewriteaof工作原理AOF的执行流程包括命令追加(append)将Redis的写命令追加到缓冲区aof_buf文件写入(write)和文件同步(sync)根据不同的同步策略将aof_buf中的内容同步到硬盘文件重写(rewrite)定期重写AOF文件达到压缩的目的。文件重写流程文件重写流程1Redis父进程首先判断当前是否存在正在执行bgsave/bgrewriteaof的子进程如果存在则 bgrewriteaof命令直接返回如果存在 bgsave命令则等bgsave执行完成后再执行。 2父进程执行fork操作创建子进程这个过程中父进程是阻塞的。 3.1父进程fork后bgrewriteaof命令返回”Background append only file rewrite started”信息并不再阻塞父进程 并可以响应其他命令。Redis的所有写命令依然写入AOF缓冲区并根据 appendfsync策略同步到硬盘保证原有AOF机制的正确。 3.2由于fork操作使用写时复制技术子进程只能共享fork操作时的内存数据。由于父进程依然在响应命 令因此Redis使用AOF重写缓冲区(aof_rewrite_buf)保存这部分数据防止新AOF文件生成期间丢失这 部分数据。也就是说bgrewriteaof执行期间Redis的写命令同时追加到aof_buf和aof_rewirte_buf 两个缓冲区。 4子进程根据内存快照按照命令合并规则写入到新的AOF文件。 5.1子进程写完新的AOF文件后向父进程发信号父进程更新统计信息具体可以通过info persistence查看。 5.2父进程把AOF重写缓冲区的数据写入到新的AOF文件这样就保证了新AOF文件所保存的数据库状态和 服务器当前状态一致。 5.3使用新的AOF文件替换老文件完成AOF重写aof文件加载当AOF开启时Redis启动时会优先载入AOF文件来恢复数据只有当AOF关闭时才会载入RDB文件恢复数据。当AOF开启但AOF文件不存在时即使RDB文件存在也不会加载。Redis载入AOF文件时会对AOF文件进行校验如果文件损坏则日志中会打印错误Redis启动失败。但如果是AOF文件结尾不完整(机器突然宕机等容易导致文件尾部不完整)且aof-load-truncated参数开启则日志中会输出警告Redis忽略掉AOF文件的尾部启动成功。aof-load-truncated参数默认是开启的。rdb和aof的比较rdb类似完全备份优点RDB文件紧凑体积小网络传输快适合全量复制恢复速度比AOF快很多。当然与AOF相比RDB最重要的优点之一是对性能的影响相对较小。 缺点RDB文件的致命缺点在于其数据快照的持久化方式决定了必然做不到实时持久化而在数据越来越重要的今天数据的大量丢失很多时候是无法接受的因此AOF持久化成为主流。此外RDB文件需要满足特定格式兼容性差如老版本的Redis不兼容新版本的RDB文件。 对于RDB持久化一方面是bgsave在进行fork操作时Redis主进程会阻塞另一方面子进程向硬盘写数据也会带来IO压力aof:与RDB持久化相对应AOF的优点在于支持秒级持久化、兼容性好缺点是文件大、恢复速度慢、对性能影响大。 对于AOF持久化向硬盘写数据的频率大大提高(everysec策略下为秒级)IO压力更大甚至可能造成AOF追加阻塞问题。 AOF文件的重写与RDB的bgsave类似会有fork时的阻塞和子进程的IO压力问题。相对来说由于AOF向硬盘中写数据的频率更高因此对 Redis主进程性能的影响会更大。主从复制介绍一主多从主写从读。主从复制是高可用Redis的基础哨兵和集群都是在主从复制基础上实现高可用的。主从复制主要实现了数据的多机备份以及对于读操作的负载均衡和简单的故障恢复。缺陷故障恢复无法自动化写操作无法负载均衡存储能力受到单机的限制。作用数据冗余主从复制实现了数据的热备份是持久化之外的一种数据冗余方式。故障恢复当主节点出现问题时可以由从节点提供服务实现快速的故障恢复实际上是一种服务的冗余。负载均衡在主从复制的基础上配合读写分离可以由主节点提供写服务由从节点提供读服务 即写Redis数据时应用连接主节点读Redis数据时应用连接从节点分担服务器负载尤其是在写少读多的场景下通过多个从节点分担读负载可以大大提高Redis服务器的并发量。高可用基石除了上述作用以外主从复制还是哨兵和集群能够实施的基础因此说主从复制是Redis高可用的基础。流程重点1若启动一个Slave机器进程则它会向Master机器发送一个“sync command”命令请求同步连 接。 2无论是第一次连接还是重新连接Master机器都会启动一个后台进程将数据快照保存到数据文 件中执行rdb操作同时Master还会记录修改数据的所有命令并缓存在数据文件中。 3后台进程完成缓存操作之后Master机器就会向Slave机器发送数据文件Slave端机器将数据文 件保存到硬盘上然后将其加载到内存中接着Master机器就会将修改数据的所有操作一并发送给 Slave端机器。若Slave出现故障导致宕机则恢复正常后会自动重新连接。 4Master机器收到Slave端机器的连接后将其完整的数据文件发送给Slave端机器如果Mater同时 收到多个Slave发来的同步请求则Master会在后台启动一个进程以保存数据文件然后将其发送给所 有的Slave端机器确保所有的Slave端机器都正常。哨兵模式介绍主机宕机自动切换到从机。原理哨兵(sentinel):是一个分布式系统用于对主从结构中的每台服务器进行监控当出现故障时通过投票机制选择新的 Master并将所有slave连接到新的 Master。所以整个运行哨兵的集群的数量不得少于3个节点。作用哨兵结构由两部分组成哨兵节点和数据节点节点不存储数据。监控哨兵会不断地检查主节点和从节点是否运作正常。自动故障转移当主节点不能正常工作时哨兵会开始自动故障转移操作它会将失效主节点的其中一个从节点升级为新的主节点并让其它从节点改为复制新的主节点。通知提醒哨兵可以将故障转移的结果发送给客户端。哨兵节点哨兵系统由一个或多个哨兵节点组成哨兵节点是特殊的redis数据节点主节点和从节点都是数据节点。故障转移机制由哨兵节点定期监控发现主节点是否出现了故障每个哨兵节点每隔1秒会向主节点、从节点及其它哨兵节点发送一次ping命令做一次心跳检测。如果主节点在一定时间范围内不回复或者是回复一个错误消息那么这个哨兵就会认为这个主节点主观下线了单方面的。当超过半数哨兵节点认为该主节点主观下线了这样就客观下线了。当主节点出现故障此时哨兵节点会通过Raft算法选举算法实现选举机制共同选举出一个哨兵节点为leader来负责处理主节点的故障转移和通知。所以整个运行哨兵的集群的数量不得少于3个节点。由leader哨兵节点执行故障转移过程如下将某一个从节点升级为新的主节点让其它从节点指向新的主节点若原主节点恢复也变成从节点并指向新的主节点通知客户端主节点已经更换。需要特别注意的是客观下线是主节点才有的概念如果从节点和哨兵节点发生故障被哨兵主观下线后不会再有后续的客观下线和故障转移操作。主节点的选举过滤掉不健康的已下线的没有回复哨兵 ping 响应的从节点。选择配置文件中从节点优先级配置最高的。replica-priority默认值为100选择复制偏移量最大也就是复制最完整的从节点。哨兵的启动依赖于主从模式所以须把主从模式安装好的情况下再去做哨兵模式总结Redis数据可靠性与高可用性三大支柱为实现生产环境所需的健壮性Redis的核心架构围绕三大支柱构建它们环环相扣层层递进持久化数据的“保险箱核心目的将内存中的数据保存到磁盘防止进程重启导致数据完全丢失。实现方式RDB定时快照恢复快与AOF记录每步操作数据更安全通常结合使用。主从复制服务的“后备军核心目的创建数据的多个实时副本实现数据冗余、读写分离和读扩展。实现方式一主多从数据从主节点异步复制到所有从节点为高可用奠定基础。哨兵模式系统的“监护人与调度员”核心目的提供自动故障转移实现服务高可用。实现方式独立的哨兵集群监控所有节点主节点故障时能自动选举新主并通知客户端实现服务不间断。三者关系精炼持久化为数据存底是基础。主从复制利用副本扩展服务能力与可靠性是骨架。哨兵模式在上述骨架之上实现了自动化的故障恢复是保障持续服务的大脑。最终目标三者协同将Redis从一个高性能的内存缓存转变为一个具备数据持久化、负载分担和自动容灾能力的生产级数据存储服务。这个总结突出了每个组件的核心角色和它们如何协同工作便于快速理解和记忆。