缓存之Redis学习（五）

一、搭建配置redis主从环境：
1、首先我们需要去redis.conf 注释掉bind 127.0.0.1 这样我们才可以远程连接
因为开启bind 表示只允许这个ip访问。
vim 文本编辑模式 搜索是按 / 下一个 是 n。

还有将daemonize 的 no 改为yes 表示 redis 在后台启动


然后我们先去配置选为从服务器的两台机器：

这里有个小插曲 之前版本应该是slaveof、有人认为 Redis 中的术语 master/slave （主人 / 奴隶）冒犯到了别人，要求 Redis 作者 ANTIREZ 修改这个术语
配置完成之后我们就先重启redis服务

启动slave之后可以通过命令 info replication 查看

可以看到本机的角色 role ： slave
查看master机器的话能看到：

可以看到连接的有两个slaves ip分别是多少。
我们设置一个值试试同步效果。


master slave 实现原理：
1、slave连接到master上以后，会向master 发送一个SYNC的命令。
2、master收到SYNC的时候，会做两件事：
a) 执行bgsave（master将内存中的数据以后台方式同步到快照）（会生成rdb的快照文件）
b) master会把新收到的修改命令存入缓冲区
ps：如果主从同步不成功 可以将这个快照文件直接复制过去恢复数据
我们可以通过replconf 命令 监听 6379端口来看下一下master slave 同步的过程

再发送一个sync命令 就会将同步过来的数据输出到控制台

我们在master 机器上面 set 一个值

slave会输出如下内容：

但是也有会有一个问题，但我们master挂掉的时候：

我们再去查看slave的信息：

并不会像zookeeper 的 leader的动态选举操作，挂了就是挂了。
哨兵机制：
sentinel

1. 监控master 和slave是否正常运行
2. 如果master出现故障，那么会把其中一台salve数据升级为master
   第一步，我们先配置下哨兵的配置文件：
   
   
   第一个参数表示名称，第二个参数当前master ip 端口 最后一个 数字 表示最低投票数（如果我们当前哨兵集群有三个的话，表示最少要两台机器投票决定）
   
   这个参数表示在多少秒之内master没有响应就认为down，保存配置。
   然后照常开启我们的redis主从，通过info replication查看是否开启成功，为了方便查看哨兵监听的效果。
   我们单独给master开一个会话开启哨兵。
   
   可以看到 监控了master，因为有重试机制，所以当我们master down了之后，不会马上选举出来 而是会等一会。
   
   通过这里的信息，我们可以先是master down之后 try 失败 最后重新选出作为master结束。
   就算现在之前down的master重新启动了 也只会以slave的身份进入。
   而且哨兵这个选举还会去修改配置文件的 slaveof 也就是现在的 replicaof。
   ip会指向现在的master。
   
   总结： master-slave 模式 要加上哨兵模式才能算高可用的配置。但并不是高性能的配置。
   因为数据存在一个节点上，操作开销也会比较大。
   所以我们需要将数据进行分片。

不然master挂掉了就没法对请求做出处理。
数据存储量受限于配置里面内存最小的一个节点，有点像木桶效应。

集群（redis3.0之后的版本才会有）：
简单点来说就是根据key的hash值除于当前集群中服务器的数量。
每个hash值固定访问某个节点。
集群的原理
Redis Cluster中，Sharding采用slot(槽)的概念，一共分成16384个槽，这有点儿类似前面讲的pre sharding思路。对于每个进入Redis的键值对，根据key进行散列，分配到这16384个slot中的某一个中。使用的hash算法也比较简单，就是CRC16后16384取模。Redis集群中的每个node(节点)负责分摊这16384个slot中的一部分，也就是说，每个slot都对应一个node负责处理。当动态添加或减少node节点时，需要将16384个槽做个再分配，槽中的键值也要迁移。当然，这一过程，在目前实现中，还处于半自动状态，需要人工介入。Redis集群，要保证16384个槽对应的node都正常工作，如果某个node发生故障，那它负责的slots也就失效，整个集群将不能工作。为了增加集群的可访问性，官方推荐的方案是将node配置成主从结构，即一个master主节点，挂n个slave从节点。这时，如果主节点失效，Redis Cluster会根据选举算法从slave节点中选择一个上升为主节点，整个集群继续对外提供服务。这非常类似服务器节点通过Sentinel监控架构成主从结构，只是Redis Cluster本身提供了故障转移容错的能力。

slot（哈希槽）的概念：
在redis集群中 一共有16384个槽，根据key的CRC16算法，得到的结果再对16834进行取模。
假如现在集群有3个节点
node1 0 5460
node2 5461 10922
node3 10923 16383
类似这样去推算对应访问的节点。
当需要新增节点的时候，只需要平均将每个节点的数据取一些出来。
删除节点的话：
先将节点的数据移动到其他节点上，然后才能执行删除。
比较成熟的集群方案：
twemproxy： 相当于代理吧，你调用twemproxy，他负责访问那个reids。