部分开发人员工作当中只是在应用中使用redis，比如用来做数据结果的缓存。而且现在有很多不错的redis客户端工具(redisson)，基本上可以不用关注redis命令就可以完成相当部分的功能。所以可能会对如下这些问题关注点不够：

redis提供了主从热备机制，主服务器的数据同步到从服务器，通过哨兵实时监控主服务器状态并负责选举主服务器。当发现主服务器异常时根据一定的算法重新选举主服务器并将问题服务器从可用列表中去除，最后通知客户端。主从是一对多的树型结构，如下图：

哨兵是sentinel的中文名称，是redis出的一个高可用架构的工具，自身是一个独立的进程，可以同时监控一个以上的redis集群。

基于高可用的考虑，哨兵自身也是需要支持集群的，如果只有一个哨兵就会存在单点问题。

哨兵有一个数量配置，当多少个哨兵同时认为某个主服务不可用时才进行主从切换，比如总共有5个哨兵，当3个哨兵认为服务不可用时才决定做主从切换。这么做可以避免一些误切换，降低切换成本，比如瞬时的网络异常等。

无论是redis还是其它一些数据库之类的产品，当单节点的数据容量达到一定上限后，服务对外提供的能力会越来越弱。redis在高版本中提供了redis-trib.rb来实现集群功能，也可以使用第三方的工具twemproxy。

redis集群从设计上没有考虑中心化，这样可以避免中心节点的单点等问题。每个节点都能掌握整个集群的状态，连接任意的节点都可以访问到所有的key，就像单节点的redis一样。

自己理解画的，如有理解不对的地方可以指出。

引入了hasy solt，中文理解为哈希槽。总共16384个，我们操作的key通过取模算法确认key落在哪个槽上。

哈希槽与节点之间有一定关系，所以我们就可以将key分配到某个具体的redis节点上了。

执行过程中会遇到提示需要安装ruby，安装完成之后又会提示安装 gem redis。

再次执行创建集群的脚本,出现如下提示：

输入yes，继续

连接成功后，增加一个key

有一行提示语，指向到端口7002，这说明虽然我们连接的是7000的实例，但通过hash算法最终会将key分配到7002的实例上。

再连接7005端口查询下key，测试下是否任意一个实例都可以查询到key

显示指向到端口7002

真实环境的部署与单机部署还是差异比较大的，但也不复杂，尽管部分开发人员可能一辈子都不会有机会在线上搭建redis集群，但了解redis的高可用可扩展的方案对设计大型系统还是有比较大的帮助的，也有助于分析解决线上问题。看了上面的这些，对于本文开头提到的问题就不难理解了。

下面关于Redis的文章您也可能喜欢，不妨参考下：