1、Redis简介Redis是一个高性能的key-value非关系型数据库。由于其高性能特性，支持高可用、持久化、多数据结构、集群等，使其作为常用的非关系型数据库脱颖而出。此外，Redis还有很多使用场景。会话缓存（SessionCache）Redis在缓存会话方面有非常好的优势，因为Redis提供了持久化。在需要长时间保持会话的应用场景，比如购物车场景，可以提供很好的长会话支持。为用户提供良好的购物体验。全页缓存在WordPress中，Pantheon提供了一个不错的插件wp-redis，这个插件可以以最快的速度加载你曾经浏览过的页面。QueueReids提供列表和集合操作，这使得Redis成为一个很好用的消息队列平台。我们经常使用Reids的排队功能来限购。比如在节假日或者促销期间，进行一些限制用户购买行为的活动，限制当天可以购买的数量或者一段时间内只能购买一次。也更适合应用。RankRedis很好地实现了在内存中递增或递减数字的操作。因此，我们会在很多排名场景中使用Redis。例如，某小说网站对小说进行排名，根据排名向用户推荐排名靠前的小说。发布/订阅Redis提供发布和订阅功能。发布和订阅的场景有很多种。例如，我们可以基于发布订阅脚本触发器实现一个利用Redis的发布订阅功能构建的聊天系统。除此之外，还有很多其他的场景，Redis表现不错。2、Redis在使用中出现单点故障的问题正是因为Redis具有多种优秀的特性和丰富的应用场景，使得Redis在各个公司都有它的身影。那么问题和风险也随之而来。尽管Redis拥有丰富的应用场景，但部分企业在实践Redis应用时，仍然相对保守地采用单节点部署，这给以后的维护带来了安全隐患。2015年，我们处理了一个单点故障导致的业务中断问题。当时Redis并没有采用分布式部署，而是单实例部署，没有考虑容灾问题。当时我们使用Redis服务器来控制用户购买打折商品的行为。但由于不明原因，Redis节点服务器宕机，我们无法控制用户的购买行为，导致用户在一段时间内多次购买打折商品。的行为。这种停机事故可以说给公司造成了无法弥补的损失，安全隐患非常严重。作为当时系统的运维人员，我有必要修复这个问题，改进结构。于是开始研究研究解决非分布式应用下的Redis单点故障问题。3、非分布式场景下Redis应用的备份和容灾Redis主从复制现在应该很普遍了。常用的主从复制架构有以下两种架构方案。常用的Redis主从复制方案1这是最常见的架构，有一个Master节点和两个Slave节点。client写数据的时候写到Master节点，读的时候读两个Slave，实现了读的扩展，降低了Master节点的读负载。方案2这种架构也是一个Master和两个Slave。不同的是Master和Slave1使用keepalived进行VIP传输。当Client连接到Master时，它通过VIP连接。这样就避免了方案一换IP的情况。Redis主从复制的优缺点。优势实现了主数据的备份。一旦master发生故障，slave节点可以提升为新的master，取代旧的master继续提供服务，实现读扩展。使用主从复制架构一般是为了实现读扩展。Master主要实现写功能，Slave不能实现读功能。架构上的解决方案是当Master出现故障时，Client会与Master断开连接，无法实现写入功能。同时，Slave不能从Master复制。此时需要进行如下操作（假设Slave1提升为Master）：在Slave1上执行slaveofnoone命令，将Slave1提升为新的Master节点。在Slave1上配置为可写，这是因为在大多数情况下，slave被配置为只读。告诉客户端（也就是连接Redis的程序）新Master节点的连接地址。配置Slave2从新的Master复制数据。架构方案2当master出现故障时，Client可以连接到Slave1进行数据操作，但是Slave1变成了单点，经常需要避免的单点故障（singlepointoffailure）就出现了。之后还需要经过以下操作：在Slave1上执行slaveofnoone命令，将Slave1提升为新的Master节点。将Slave1配置为可写。这是因为在大多数情况下，Slave被配置为只读，而Slave2被配置为从新的Master读取数据。Replication可以发现，不管是哪种架构方案，failover都需要人工干预。需要人工干预，增加了运维的工作量，对业务也产生了巨大的影响。这时候就可以使用Redis的高可用解决方案——Sentinel4.RedisSentinel简介RedisSentinel为Redis提供了一个高可用的解决方案。从实用的角度来看，使用RedisSentinel可以创建一个Redis环境，可以在没有人为干预的情况下防止某些故障。RedisSentinel被设计为分布式架构，运行多个Sentinel进程协同工作。运行多个Sentinel进程进行协作，当给定master的多个Sentinel不能再继续提供服务时，会进行故障检测，减少误报的可能性。5、RedisSentinel功能RedisSentinel在Redis高可用解决方案中主要有以下几个功能：监控Sentinel会不断检查主从是否正常运行通过API通知，Sentinel可以通知系统管理员和Redis实例由程序监控发生自动故障转移。如果master没有按预期正常运行，Sentinel可以启动故障转移过程。其中一个slave将被提升为master，而其他slave将被重新配置以使用新的master。使用Redis服务的应用程序，在连接时，也会通知它使用新的地址。配置提供者Sentinel可以用作客户端服务发现的身份验证源：客户端连接到Sentinel以获取当前负责给定服务的Redismaster的地址。如果发生故障转移，Sentinel将报告新地址。六、RedisSentinel架构七、RedisSentinel实现原理Sentinel集群监控自身和Redis主从复制。当Master节点发现故障后，会经过以下步骤：1）在Sentinels之间进行选举，选出一个leader，选出的leader进行故障转移2）Sentinelleader选择其中一个slave节点作为新的leader主节点。slave选举slave选举的方法如下：a)从master断开连接时间如果从master断开连接时间超过down-after-milliseconds（sentinel配置）*10秒加上从sentinel确定master不可用的时间到哨兵开始执行故障转移之间的时间，从站被认为不适合提升为主站。b)slave优先级每个slave都有一个优先级，保存在redis.conf配置文件中。如果优先级相同，则继续。c)复制偏移位置复制偏移记录从master复制的数据被复制到哪里。copyoffset越大，从master接受的数据越多。如果副本偏移量相同，则继续选举。d)RunID选举有RunID最小的Slave作为新的Master流程图如下：3)Sentinelleader会对上一步选出的新master执行slaveofnoone操作，并提升为master节点4)Sentinelleader向其他slave发送命令，让剩下的slave成为新master节点的slave5)Sentinelleader会将原来的master降级为slave。当它恢复正常工作时，Sentinelleader会发送命令让它从新的master复制。以上故障转移操作都是sentinel自己完成的，完全不需要人为干预。总结使用sentinel实现Redis的高可用，当master出现故障时，无需人工干预即可实现failover。避免了对业务的影响，提高运维效率。部署哨兵时，建议使用奇数个哨兵节点，至少三个哨兵节点。
