redis哨兵和集群区别是什么?

redis哨兵和集群区别是：

监控主数据库和从数据库是否正常运行。

主数据库出现故障时自动将从数据库转换为主数据库。sentinel发现master挂了后，就会从slave中重新选举一个master。哨兵模式强调高可用。

Sentinel会不断地检查你的主服务器和从服务器是否运作正常。

提醒（Notification）：当被监控的某个Redis服务器出现问题时，Sentinel可以通过API向管理员或者其他应用程序发送通知。

自动故障迁移（Automatic failover）：当一个主服务器不能正常工作时，Sentinel会开始一次自动故障迁移操作。

它会将失效主服务器的其中一个从服务器升级为新的主服务器，并让失效主服务器的其他从服务器改为复制新的主服务器。

当客户端试图连接失效的主服务器时，集群也会向客户端返回新主服务器的地址，使得集群可以使用新主服务器代替失效服务器。

客户端中不会记录redis的地址（某个IP），而是记录sentinel的地址，这样我们可以直接从sentinel获取的redis地址。

因为sentinel会对所有的master、slave进行监控，它是知道到底谁才是真正的master的，例如我们故障转移，这时候对于sentinel来说，master是变了的，然后通知客户端。

而客户端根本不用关心到底谁才是真正的master，只关心sentinel告知的master。

集群即使使用哨兵，redis每个实例也是全量存储，每个redis存储的内容都是完整的数据，浪费内存且有木桶效应。

为了最大化利用内存，可以采用集群，就是分布式存储。即每台redis存储不同的内容，共有16384个slot。

每个redis分得一些slot，hash_slot = crc16(key) mod 16384找到对应slot，键是可用键，如果有｛｝则取｛｝内的作为可用键，否则整个键是可用键。

集群至少需要3主3从，且每个实例使用不同的配置文件，主从不用配置，集群会自己选。cluster是为了解决单机Redis容量有限的问题，将数据按一定的规则分配到多台机器。

集群模式提高并发量。

Redis：Remote Dictionary Server ，即远程字典服务，是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。

很精辟的一段话,"未曾清贫难做人,不经打击永天真；成熟不过是善于隐藏,沧桑不过是无泪有伤。"

redis的主从配置比较容易，主从配置后，主主要进行写的操作,从主要进行读的操作,那么如果主挂了,是不是就没法进行写了？所以redis中可以进行哨兵的配置,具有高可用性，即是在主挂了之后,哨兵检测到后，会在从中进行投票,投票数多的晋升为主。这个配置可折腾我了，按照找的资料进行了哨兵的配置，可是当我把主服务停掉之后，从还在一致尝试连接主

启动哨兵日志

停掉主后从的日志

停掉后哨兵中,日志情况

就是这个问题我一直尝试找到解决办法，看了其中" sentinel-16379conf"中的配置差不多，跟网上的一样。但是就是不行。

sentinel-16379conf配置如下

这是我把这个配置文件的注释和空格都去掉后的结果

实际中我修改了如下几个配置

其他的可能都是自动生成的。当然你也可以自己指定日志位置。

auth-pass是因为我的主中做了配置密码了。

官网的配置说明： https://redisio/topics/sentinel

所以那为什么我的哨兵没有起作用了,最后我找了公司运维一起看,问题的原因就是我的从中的bind的这个属性没有做配置。

加上了这个，all done!!!

如果你直接使用

报错如下

因为bind只配置了101039105所以连接如下

哨兵启动结果

干掉主进程

哨兵的日志打印状况

从服务器的日志情况：

连接39105设置数据如下

哨兵监控如下：

测试从是否可以设置数据

在主上设置数据

在从上get数据

三：问题说明

上面也说了，第一次没有成功的原因是因为bind问题

我尝试翻译下如下

Redis的Sentinel文档

概述：Redis的Sentinel系统用于管理多个Redis服务器，该系统执行以下三个任务：

如何使用？

启动Sentinel

    对于 redis-sentinel 程序，你可以用一下命令来启动Sentinel系统：

    对于 redis-server 程序，你可以用下面的命令来启动一个运行在Sentinel模式下的Redis服务器

    两种方式都可以启动一个sentinel实例，启动sentinel实例必须指定相应的配置文件，系统会使用配置文件来保存sentinel的当前状态，并在Sentinel重启时通过载入配置文件来进行状态还原。

    注意：如果启动Sentinel时没有指定相应的配置文件，或者指定的配置文件不可用（not writabel），那么Sentinel会拒绝启动。

    如何配置Sentinel？

    Redis 源码中包含了一个名为 sentinelconf 的文件， 这个文件是一个带有详细注释的 Sentinel 配置文件示例。

运行一个 Sentinel 所需的最少配置如下所示：

    解读一下第一条指令的意思：

    其他选项的基本格式如下

学到这里我们进行实操一下，感受一下哨兵的威力！

    我们先在test目录下，新建三个配置文件：26379conf、26380conf、26381conf（Sentinel服务器端口号默认是在redis服务器前拼个2），用 vi 命令创建这三个配置文件，然后我们在配置文件中写入一些简单的配置：

端口号：26379，哨兵名称：mymaster，主机地址：127001，监控的redis端口号：6379，必须要2台从Sentinel服务器同意才会切换master，并进行故障迁移。（注意，这三个配置文件监控的redis服务器端口都是6379）

用相同的方法，创建了另外两个sentinel配置文件

我们先启动一个6379作为master

再启动6380、6381，作为两个slave

接下来正菜上场了！启动Sentinel！

可以发现，有两个slave正在跟随master，我们只要拿哨兵监控master，就可以看到有几个slave

我们继续启动，再接着启动两个Sentinel服务器

现在我们做一个小实验：如果我们将master服务器（6379）关闭，两个slave之间会发生什么？

当把master关闭之后，两个slave直接会有一段时间提示主服务器拒绝访问：

而哨兵开始也没有立马进行选举投票，选出新master，因为redis选举默认配的时间是有些长的，要过一点时间才开始选举投票，经过重新选举之后，sentinel选择了6381作为新的master。

那既然6381作为新秀，它应该有了很大的指导权，我们现在看看：

我们可以看到，在6381中设置的数据，确实在6380中可以查的到！说明6380在跟随6381，说明哨兵自动帮我们实现了故障转移。

我们再查看一下配置文件，看看有何变化？

可以发现，和原来我们写进去的2句配置完全不一样了，也就是说哨兵会自己改动配置文件。现在的master是6381。

接下来探讨一个问题：哨兵是如何发现其他哨兵的？

答案是：发布订阅机制。活着的master会去查看slave是谁，然后会去订阅其他的slave

我们可以用 psubscribe 去查看相关的发布订阅情况