网站开发主流框架删除WordPress的404页面
目录
问题：
经典主从模式：
主从复制的细节：
主从切换的问题：
哨兵是什么？
哨兵模式：
前言
在分布式系统架构中，数据的高可用性与容灾能力是保障业务连续性的核心要素。Redis作为高性能的内存数据库，其主从复制（Master-Slave Replication）和哨兵模式（Sentinel）是实现数据冗余、故障恢复与高可用的关键机制。主从模式通过数据复制实现读写分离与负载均衡，而哨兵模式则在主从架构基础上，进一步提供自动化的故障检测与主节点切换能力，从而避免单点故障引发的服务中断。本文旨在深入探讨Redis主从模式与哨兵模式的设计原理、工作流程及其在实际场景中的应用价值，为构建稳定可靠的Redis服务提供理论支撑与实践指导。
问题：
虽然redis的性能很高，但是读写的受限于单个服务器的cpu和内存上限，并且这玩意要是挂了，外部就没法用了，高可用是一点没看到。
如果是你，你会如何把这样的一个单进程服务器变得高可用呢？这就要聊聊主从模式和哨兵模式了。
经典主从模式：
既然单个redis怕跪，那我们就简单粗暴的方式就是多添加几个副本，让他们变成主从关系，主节点主要的任务是读写操作，并且把数据同步给从节点，从节点也不能闲着，对外提供读操作。
加的从节点越多，那么我们支持的读请求量就越高。
如果说主节点跪了，我们就将从节点变成新的主节点，并且同样支持读写操作。
我们将主从redis分别的部署在不同的服务器上，这样既能提升redis的可用性，也提升redis的读性能。
主从复制的细节：
问题来了：
如果我们的主节点已经跑了很久，里面已经存了非常多的缓存数据，此时我们新增加了一个从节点，新增加的从节点里面是没有数据的，我们如何将主节点的数据同步到从节点呢？
redis为了尽可能的保证数据的持久性，会定期的将全量数据持久化到磁盘文件中，也就是著名的RDB文件。
主节点会把RDB文件传给从节点，让从节点去完成大部分的数据同步。不过同步的过程中还会有一些写操作，那么我们此时该如何将这些写操作也传递给从节点呢？
我们可以将它存放在主节点的复制积压缓冲区的地方，然后等RDB同步结束以后，再将里面的内容也同步给从节点。
说白了，复制积压缓冲区他就是个固定大小的内存数组，他的数组下标就是所谓的复制偏移量。
我们可以通过偏移量来记录同步写操作给从节点的进度，就算在同步的过程中从节点挂了，我们也可以通过偏移量来判断出同步进度，然后等从节点恢复过来，根据同步进度接着同步就可以了。
主从切换的问题：
问题又来了：
我们传统的主从节点的切换是要手动切换的，我们人工处理肯定是会有一些慢的，如果在高并发的场景下，那么造成的数据损失将会很大，那么此时应该就要准备领取专属于你的N+1了，哈哈哈。
那么我们就要引入自动化脚本工具，来解决人工处理慢的情况，这次引入的自动化脚本工具是Keepalived，他能帮助你进行节点之间的自动切换。
这玩意他能粗糙地检测redis是否存活，比如redis进程是否存在，redis端口是否响应。
注意：他不能感知redis内部的数据一致性和复制偏移量。
正因为他不能感知redis内部的数据一致性和复制偏移量，所以它选出来的新的主节点并不是最适合的，怎么办呢？这个时候就要引入哨兵了。
哨兵是什么？
我们可以在多个主从节点上面添加一个监控redis内部的监控进程，这个监控进程会先连接主节点，并且从主节点这里获得有哪些从节点，并且连接从节点。然后每秒ping一下从节点，看主节点有没有挂，主节点一挂，我们就把健康的从节点顶上。
可是问题就来了：
不想当主节点的从节点不是好节点。那么多的从节点，监控进程该如何判断哪个从节点最适合当主节点呢？
答：
- 优先考虑：配置中优先级最高的从节点，比如服务器的内存越大，优先级会越高
- 其次考虑：复制偏移量最大的从节点，因为他的数据最接近原主节点
- 最后考虑：选择运行id最小的从节点
这个监控进程其实就是所谓的哨兵：Sentinel
Sentinel功能不多，而且需要和redis通信，也就是需要复用一些redis底层的通信协议，所以可以直接将他放在redis的代码仓库中，也就是说redis和Sentinel本质上是同一套代码，通过不同的启动参数部署出来的两个不同服务进程而已。
哨兵模式：
如果只有一个哨兵，那就会出现如果哨兵挂了，那就没有协调主从切换了，依然是存在单点问题。并且如果哨兵和redis之间存在网络问题，还会造成误判，整个服务都会受到影响。
那我们可以多加几个哨兵，哨兵之间互相通信，单个哨兵认为redis下线了，那就主观下线，此时他会和多个哨兵进行确认，只有在大多数的哨兵都认为这个redis下线了，我们才会认为他是真的下线了，这就是客观下线，这样一个使用了主从模式和哨兵集群的redis架构，我们就叫他哨兵模式，它可以极大地提升redis的高可用，特别适合电商和金融这类可用性非常强的项目。
结语
Redis的主从模式与哨兵模式共同构成了其高可用架构的基石。主从模式通过数据复制与读写分离提升了系统的吞吐量与容灾能力，而哨兵模式则以自动化的监控与故障转移机制确保了服务的持续可用性。两者结合使用，不仅能有效应对节点故障、网络波动等异常场景，还能为业务系统提供近乎无缝的故障恢复体验。随着分布式系统复杂性的增加，深入理解并合理应用Redis的高可用机制，将成为保障数据安全与服务质量的关键。未来，结合集群模式与更智能的运维策略，Redis的高可用架构还将持续演进，为更多场景提供坚实的技术支持。