Redis多机部署，为什么不随便访问一台，而使用这种复杂的机制
2019-08-30 10:10:37   来源：东方头条   

代码的世界只是现实世界的一个延伸，总是充斥着各种各样的bug，这两天，就发生了一个串号的事故，搞得焦头烂额。程序员，特别是架构师，在设计系统的时候，系统的可用性非常的重要，也就是说，容灾，是必须的！

Redis，作为一个常用的缓存，很多人忽略了系统的容灾，试想，如果有一天晚上，突然部署Redis的机器烧坏了，总不能半夜三更把运维人员叫起来，然后重新部署一台机器，开始修改各个机器的Redis地址配置，折腾来折腾去肯定一夜都睡不着觉了。所以，我们常常会选择一定的冗余部署，来让系统更加稳定，也就是我们常说的，分布式部署。

我们常说，分布式部署最少需要2台机器，一主一备，难道两台机器没有同时坏的可能么？当然有，但是假设一台机器1年中有6个小时不可用，那么发生故障的概率为6/8760，两台机器同时发生故障就是66/87608760,这个概率已经非常低了，如果再多一台机器，那么故障的概率就更低了，当然，如果我们增加机器，不同机器之间的数据一致性也会变得更加难以保证，所以我们也说，CAP我们总是很难3个都做到。

Redis Sentinel部署架构

Redis官方，为我们提供了一种高可用的解决 方案，Redis Sentinel。一般我们会部署多台RedisSentinel，由他们选举出Redis主节点，每次客户端都是用主节点进行读写数据。

Redis Sentinel故障迁移

那么，Redis Sentinel是如何发现Redis故障的呢？首先我们要理解两个概念，主观下线跟客观下线。主观下线，每个RedisSentinel服务器都会定时询问主结点的Redis服务，一旦发现连接失败，就会认为主节点已经损坏，我们称之为主动下线。

当发现主节点连接不上的时候，并不意味着Redis主节点已经损坏，有可能是Sentinel自身的网络问题。于是，Sentinel结点机会跟其他Sentinel结点进行协商，按照多数派的原则，看看是否主节点已经损坏。如果集群中的Sentinel节点多数认为Redis主节点已经损坏，就就称之为客观下线。

一旦确定了主节点已经客观下线了了，Sentinel节点便会推选出新的Master节点，尝试将旧的Mater节点标记为Slave节点，并通知所有的客户端逐步切换到新的节点上面读取数据。

总结

可能有些人会问，那么Sentinel节点怎么保证不会挂掉呢？同样有可能，只是我们同时部署了多台，同时挂掉的概率几乎为0。

另外，为什么我们不部署多态Redis实例，然后每次访问都随机访问一台呢？岂不是又省事，又省心。但是，如果两台不同的Redis实例，同时维护1个key,然后又几乎同时修改了，那么是以哪台机器为准呢？在分布式系统中，为了保证数据的一致性问题，我们常常引入第三方的仲裁者，由第三方的仲裁者来决定谁的数据最为准确!