一、搭建配置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
- 监控master 和slave是否正常运行
- 如果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。