Redis集群架构概述
- 单实例Redis问题分析
首先Redis是一个缓存数据库，而且可以承受每秒10w的访问量，同时Redis数据库还可以将数据进行持久化存储，这样即使在Redis关闭之后数据也可以被保存下来。
但是除了这些基本知识之外，在整个系统的开发架构之中，Redis也有着非常重要的地位。
应用场景：
在进行web项目开发的时候，为了保证性能高效，往往会使用大量的web服务器来一起共同承担起用户的高并发访问，而在这种处理环境之中就会产生一个Session跨域的问题。
在你去X东或者X宝购买商品的时候会推荐同类商品，或者你去看一些X条的新闻信息，会发现它也会自动推荐你感兴趣的内容，所以这样的操作都是基于大数据的分析统计结果来得来的。
秒杀活动等
那么有了Redis之后，这些Web服务器上的Session的内存数据将不再单独保存，而是集中保存在了Redis数据库里面，这样即便有了再多的web容器，也可以区分唯一的的用户的Session。
或者
另外的核心就在于大数据的一个分析框架，Strom。
总结：在很多的开发之中Redis很重要，也就是说如果项目里没有了Redis，那么对于整个项目而言就会出现一个瘫痪。那么现在一个最为明确的问题出现了，如果在项目运行之中，Redis突然损坏了。
对于Redis的集群不一定是主机的当机，也可能是因为网络问题、机房断电等问题。所以单实例的Redis开发操作是不能够被简单应用的，尤其是在一些高可用的环境下，比如：你是一个跨国公司的架构师，你必须保证及时你的某一台网络节点主机出现了问题之后，可以在很短的时间内进行有效的切换，以保证服务的持续提供。
所以本次的内容就是围绕如何搭建高可用的Redis集群服务为主，以避免由于某一个节点出现问题而导致整体的项目的瘫痪。实现Redis集群，以保证整个程序的高可用性。
- Redis集群设计方案
集群的核心意义：实际上所谓集群的核心意义就是：保证一个节点出现了问题之后，其它的节点可以可以继续供服务使用。那么在Redis基础部分讲解过主从配置 ，一共有两类：一主二仆，层级关系，不过从实际开发的角度来讲，一主二仆是一种比较常用的手段。
一主二仆的配置的核心意义在于：一个Master节点，而后配置两个Slave节点，并且这个两个slave节点的数据与Master节点的数据同步，及时master节点出现了问题之后，slave节点也可以保证数据的存在。
Redis主从配置是所有Redis集群的基础。但是只是依靠主从依然无法实现高可用配置。
Redis虽然提供有简单的主从配置，但是这样给我们带来的自动的帮助是非常少的，我们更多的情况下是希望：如果某一个Redis出现了问题，那么对于项目可以自动进行可用的Redis恢复，那么这个时候就需要在主从的基础上使用更多的集群配置。
对于Redis集群而言，首先在主从的基础上发展出了一个哨兵的处理机制，所谓的哨兵的处理机制指的是:当三台主机之中的master节点出现了问题之后，会自动的在两个slave节点里面重新选举出新的master节点。这样就可以保证原始的Master节点出现问题之后，Redis数据依然存在有主从的配置。
但是哨兵机制也只是针对于单主机的一种配置形式。你现在如果只有一台Redis主机，那么即使你的电脑性能再好，面对广大人民群众的力量也可能招架不住，所以很明显不可能只使用一台主机来实现Redis配置。
而推特网站发布了一个代理机制，而已有效的实现数据的分片存储，即根据不同的算法实现不同主机的分片存储，以保证负载均衡，同时可以结合keepalived组件实现twemproxy的高可用。
Redis在后来的版本发展之中也推出了一个redis-cluster集群配置，利用这样的配置可以不用自己来通过配置文件实现主从关系的实现，而直接通过命令完成。但是它有一个问题，所有的主机不能够动态扩充。
集群之中最好的方案：codis
如果从可扩展的角度来讲，codis是整个Redis实现集群最好的一套方案。因为它的可扩展性非常强悍。（动态）
国内开源组件。
Redis哨兵机制
- 哨兵机制简介
只要是进行高可用的架构部署，那么就必须保证多节点，在Redis里面使用了主从模式可以可以实现多节点配置，传统的主从模式设计有一个缺陷：一旦Master主机出现了问题之后，两台slave主机将无法提供正常的工作支持，例如：slave主机为只读主机，而且如果要想继续提供支持，那么你至少应该通过剩余的slave里面去推选出一个新的master，并且最为重要的是，这个新的Master还必须能被用户的程序找到。
通过以上的解释实际上就可以发现，如果先要进行哨兵机制的实现，一定需要具备有如下的几个特点：
- *哨兵机制实现
1.如果想要进行哨兵机制配置及使用，请确保你的主机上已经准备好了Redis服务，本次将在一台主机上模拟哨兵机制，
原则：一台主机运行三个哨兵，并且该哨兵运行端口不同，但是这三个哨兵都要去监控同一个master的地址。
启动三台redis服务：
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6379.conf
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6380.conf
/usr/local/redis/bin/redis-server /usr/local/redis/conf/redis-6381.conf
2.通过Redis源代码拷贝出哨兵的运行程序。
cp /usr/local/src/redis-4.0.9/src/redis-sentinel /usr/local/redis/bin/
3.所有的哨兵如果要想运行一定要准备出一个配置文件：
sentinel.conf
sentinel的默认端口——-26379
对于此配置文件已经给出了一个参考模板/usr/local/src/redis-4.0.9/sentinel.conf
4.建立sentinel-26379的配置文件：
建立一个哨兵的配置文件目录
mkdir -p /usr/data/redis/{sentinel-26379,sentinel-26380,sentinel-26381} 做一个数据目录
vim /usr/local/redis/conf/sentinel-26379.conf
配置哨兵监听端口：port 26379
配置哨兵的工作目录：dir /usr/data/redis/sentinel-26379
设置监控的master：sentinel monitor mymaster 192.168.231.128 6379 2
设置的mymaster只是一个代表名称，如果你配置了多个哨兵，一个哨兵监控多个master，则这个名称一定要有所不同，而后的2表示如果有两个哨兵认为你出现了问题，则你应该下线，选举出新的master。
设置master的认证信息：sentinel auth-pass mymaster wanghaoxin
设置master不活跃的时间：sentinel down-after-milliseconds mymaster 30000
选举新的master失败时间：sentinel failover-timeout mymaster 180000
只有一个master同步：sentinel parallel-syncs mymaster 1
撤销Redis的保护模式：redis.conf中有一个属性：
protected-mode yes
在sentinel-26379.conf配置中添加：
protected-mode no
如果不设置最后一项：则哨兵不会做所谓的选举操作，哨兵不具备操作redis的能力。
随后按照这样的配置创建sentinel-26380.conf和sentinel-26381.conf两个配置文件。
cp /usr/local/redis/conf/sentinel-26379.conf /usr/local/redis/conf/sentinel-26380.conf
cp /usr/local/redis/conf/sentinel-26379.conf /usr/local/redis/conf/sentinel-26381.conf
强烈建议将此时的配置做一个副本
mkdir /usr/local/redis/backup/
cp /usr/local/redis/conf/* /usr/local/redis/backup/
5.启动三个哨兵进程。
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26379.conf
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26380.conf
/usr/local/redis/bin/redis-sentinel /usr/local/redis/conf/sentinel-26381.conf
通过哨兵的信息输出可以发现如下特点：
1.+slave 当一个哨兵启动之后已经确定了可以连接到master节点，则自动追加所有节点
2.+sentinel 每当启动一个新的哨兵进程后会自动进行哨兵增加的信息提示。
三个哨兵都会监控master和它对应的子结点。但是如果master一旦挂掉。
6.直接kill掉当前监控的master主机：
随后会发现有如下提示信息：
23：30之后的信息：
“+sdown master 192.168.231.128 6379 ”：当前master主机下线了
“+vote-for-leader”：进行了重新的投票选举，
“+slave-reconf-sent slave 192.168.231.128 6381”:从主机会自动修改redis.conf配置文件，
“switch-master mymaster 192.168.231.128 6379 192.168.231.128 6380”:切换新的master 为6380
6381变成6380的从主机
8.如果此时6379的进程又重新启动成功了：那么这个时候可以考虑通过命令做一个从的设置，一定要求设置好redis-6379.conf文件中的master-auth属性，如果不进行此项配置则无法连接到msater主机，6380 下的master只有一个节点，6381 而没有6379
同时发现哨兵文件对应的配置内容已经发生了改变，证明在整个哨兵运行机制里面，所有的配置文件都有可能出现更改。
—-配置文件更改可能导致风险，会导致配置文件维护起来比较麻烦。
- Jedis访问哨兵机制
现在为止已经成功的实现了哨兵处理机制，但是对于程序的编写依然需要注意一点：如果要进行哨兵的处理操作，那么一定要求通过哨兵来取得可用的master的地址。
此处采用6379作为master主机来操作
范例：使用jredis进行数据操作。
如果要通过哨兵机制进行Redis访问，那么必须要明确设置出所有可以使用的哨兵的地址与端口
取消
不是直接连接redis的。而是通过哨兵连接的
如果这个时候主机的master被干掉了，那么也可以通过同样的模式获取一个可用的master的地址。
自动切换主机