但是我们有没有更优的算法来查找呢？
在数据结构的书中我们可以找到“哨兵查找法”，但是什么又是“哨兵查找法”呢？什么又是“哨兵”呢？
所谓“哨兵”就是用一个特殊的值来作为数组的边界key，可以少用一条判断语句，目的在于免去查找过程中每一步都要检测整个表是否查找完毕，以达到提高程序的效率。
相对于一层遍历，没有使用”哨兵“的，是有两个判断条件的i<array.count和if(array[i] == item)；但是使用了”哨兵“只有一个判断条件if(array[i] == item)！
如果你的数据量非常小的话，相对于一层遍历来说，差别微乎其微，但是当数据达到十万或者更多的时候，函数的执行时间就会有明显差距了！
我们可以将数组的第一个值作为”哨兵“，数据存储下标index从1开始，则list的0号位表示暂无元素，位”哨兵“Key。
比如数组中有一千个元素，我查找中间那个元素，运行结果如下：
欢迎各位大神提出宝贵的意见和建议，也欢迎大家进群交流365152048！
哨兵模式是一种自动选择老大的模式，即在老大宕机之后，哨兵模式会根据哨兵们的内部投票，自动的重新选出一个新的老大。哨兵模式是一种特殊的模式，首先Redis提供了哨兵的命令，哨兵是一个独立的进程，作为进程，它会独立运行。其原理是哨兵通过发送命令，等待Redis服务器响应，如果Redis服务器一直没有响应，说明这个Redis服务器可能已经宕机了，从而监控运行的多个Redis实例。
这里的哨兵有两个作用
1、通过发送命令，让Redis服务器返回监控其运行状态，包括主服务器和从服务器。
2、当哨兵监测到master宕机，会自动将slave切换成master，然后通过发布订阅模式通知其他的从服务器，修改配置文件，让它们切换主机。
然而一个哨兵进程对Redis服务器进行监控，可能会出现问题，为此，我们可以使用多个哨兵进行监控。各个哨兵之间还会进行监控，这样就形成了多哨兵模式。
用文字描述一下故障切换(failover)的过程。假设主服务器宕机，哨兵1先检测到这个结果，系统并不会马上进行failover过程，仅仅是哨兵1主观的认为主服务器不可用，这个现象成为主观下线。当后面的哨兵也检测到主服务器不可用，并且数量达到一定值时，那么哨兵之间就会进行一次投票，投票的结果由一个哨兵发起，进行failover操作。切换成功后，就会通过发布订阅模式，让各个哨兵把自己监控的从服务器实现切换主机，这个过程称为客观下线。这样对于客户端而言，一切都是透明的。如果有三个哨兵，不仅每个哨兵会监视主机和从机，而且哨兵之间也会互相监视，如下图：
配置哨兵配置文件sentinel.conf，如下
当哨兵模式的配置文件配置好之后，就可以启动哨兵模式了，如下图
测试在哨兵模式下如果主机崩了的话会不会从从机中自动选出一个老大，先关闭主机，让主机宕机，如下图：
看看主机宕机之后，哨兵模式中输出日志的新的内容是什么，如下图：
哨兵模式自动选举一个主机这个过程是怎样实现自动化的？哨兵自动选举之前的某个从机为老大，所有的从机都会称新选出的从机为老大，以及原本的老大也会称新选出的老大为老大，这个过程是怎么自动化实现的呢？是通过在对应的redis服务器的配置文件中写内容来实现的，比方说，让我们看一下新老大也即是端口号是6381的redis服务器的配置文件中是怎样改写的，如下图：
再来看一下从机即端口号是6380的redis服务器对应的配置文件是怎样改写的，如下图：
最后看一下原本的主机即端口号是6379的redis服务器的配置文件是怎样改写的。我检查了一下，发现在重新启动原本的老大即重启已经宕机的端口号是6379的redis服务器之前，它对应的配置文件中没有发生任何改变，但是一旦重新启动原本的老大，它对应的配置文件就会发生变化，如下图：
哨兵模式中的主机关闭之后需要特别注意的一个易错点：就是因为现在老大已经换了，所以老大的认证密码也换了，因此需要在现任老大的所有从机里面配置主机的认证密码，这个哨兵模式是不会帮我们自动配置的，需要我们自动配置，如下图：
测试哨兵模式结果，如下图：
1、哨兵集群，基于主从复制模式，所有的主从配置优点，它全有。
2、主从可以切换，故障可以转移，系统的可用性就会更好。
3、哨兵模式就是主从模式的升级，手动到自动，更加健壮。
1、集群容量一旦到达上限，在线扩容十分麻烦。
2、实现哨兵模式的配置其实是很麻烦的，里面有很多选择。
当Redis集群的主节点故障时，Sentinel集群将从剩余的从节点中选举一个新的主节点，有以下步骤：
Sentinel集群的每一个Sentinel节点会定时对Redis集群的所有节点发心跳包检测节点是否正常。如果一个节点在down-after-milliseconds时间内没有回复Sentinel节点的心跳包，则该Redis节点被该Sentinel节点主观下线。
当节点被一个Sentinel节点记为主观下线时，并不意味着该节点肯定故障了，还需要Sentinel集群的其他Sentinel节点共同判断为主观下线才行。
该Sentinel节点会询问其他Sentinel节点，如果Sentinel集群中超过quorum数量的Sentinel节点认为该Redis节点主观下线，则该redis客观下线。
如果客观下线的redis节点是从节点或者是Sentinel节点，则操作到此为止，没有后续的操作了；如果客观下线的Redis节点为主节点，则开始故障转移，从从节点中选举一个节点升级为主节点。
如果需要从redis集群选举一个节点为主节点，首先需要从Sentinel集群中选举一个Sentinel节点作为Leader。
每一个Sentinel节点都可以成为Leader，当一个Sentinel节点确认redis集群的主节点主观下线后，会请求其他Sentinel节点要求将自己选举为Leader。被请求的Sentinel节点如果没有同意过其他Sentinel节点的选举请求，则同意该请求(选举票数+1)，否则不同意。
如果一个Sentinel节点获得的选举票数达到Leader最低票数(quorum和Sentinel节点数/2+1的最大值)，则该Sentinel节点选举为Leader；否则重新进行选举。
当Sentinel集群选举出Sentinel Leader后，由Sentinel Leader从redis从节点中选择一个redis节点作为主节点：
详解redis集群选举机制
