标签：+----+ 可用 redis 哨兵 Sentinel master sentinel M1

转：

redis - 哨兵（高可用）

参考官网
redis - 主从（高性能）中，提供了高性能，但是没办法提供高可用。比如master挂了，虽然slave可以提供查询，但是不能提供写入服务，相对于不可用了。虽然可以把slave通过slaveof no one命令变成master，但是手动还是不太方便。
redis可以使用sentinel自动完成故障发现和转移，并提供了以下功能：

1. 监控：监控master和slave是否正常工作。
2. 通知：当发现某个redis异常时，可以通知应用程序或者系统管理员。
3. 故障转移：当master出现异常时，sentinel会选举一个新的master，并让其他slave指向新的master地址，同时通知应用程序使用新的master地址。
4. 配置中心：发生故障转移时，通知新master地址。

为了sentinel的健壮性，sentinel也是分布式的，多个sentinel协同工作的优势如下：

• master是否正常工作，由大部分的sentinel决定的，减少误判的概率。
• 部分sentinel的异常，并不妨碍整体的功能。

部署案例

在部署之前，我们需要了解一下基本信息：

• 为了保证Sentinel服务的健壮性，至少需要三个Sentinel实例。
• 三个示例应该放在不同的虚拟机或物理机上。
• 由于redis的异步复制，所以Sentinel不保证数据的零丢失。

两个实例

+----+         +----+
| M1 |---------| R1 |
| S1 |         | S2 |
+----+         +----+

配置: quorum = 1

这个示例中，一个服务器部署了Mater和Sentinel，一个服务器部署了slave和Sentinel。此时，如果M1挂了，S1和S2只要有一个认为M1挂了，就会选举一个Sentinel让slave升级为master，但是如果M1所在的服务器异常了，则只剩下S2，此时1小于majority(2)是无法做故障转移的。

三个实例

       +----+
       | M1 |
       | S1 |
       +----+
          |
+----+    |    +----+
| R2 |----+----| R3 |
| S2 |         | S3 |
+----+         +----+

配置:  quorum = 2

这个示例中，如果M1所在服务器挂了，此时S2和S3只要有一个认为M1挂了，就就会选举一个Sentinel做故障转移，此时2个Sentinel大于等于majority(2)是可以做故障转移的。
以上两个是比较典型的案例，当然官网还有跟客户端一个服务器的。至于为什么要一起部署，是因为我们服务器的资源是宝贵（要钱）的，一起部署既达到了服务的健壮性，也节约了资源。

简单示例

首先是主从，在redis - 主从（高性能）中也说了如何配置，sentinel的配置也比较简单，如下：

port 26379
sentinel monitor mymaster ip port 2

有三个配置就启动三个sentinel，整体流程图如下：

如果监听多组集群，可以设置多个monitor，比如

port 26379
sentinel monitor mymaster ip port 2
sentinel monitor resque ip port 2

原理部分后面章节讲解

转：

redis - 哨兵（高可用）

标签：+----+,可用,redis,哨兵,Sentinel,master,sentinel,M1
来源： https://www.cnblogs.com/wangtcc/p/14724150.html

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。