redis集群
3主3从;
过半确认;
类似mysql分库分表;
摘要
数据分散存储;
减少一台服务的io操作,提高读取效率;
每个节点一主一备(多备),保证缓存的稳定性;
每个节点都可以跟client连接、每个节点之间相互连接;
投票过半确认;是否确认mater挂机然后选择slave;
A节点的 master在1 机器上 ,然后 B节点的 slave 也在 1机器上,然后2机器上 是A节点的slave + B节点的master,然后两台机器存的数据就一样了;
是怎么实现的
1、
客户端可以与任何一个节点相连接,然后就可以访问集群中的任何一个节点。对其进行
存、取
和其他操作。
2、
在redis的每一个节点上,都有这么两个东西,一个是插槽(slot)可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是:0-16383。
还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。
当我们的存取的key到达的时候,redis会根据crc16的算法得出一个结果,然后把结果对 16384 求余数,这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽,
通过这个值,去找到对应的插槽所对应的节点,然后直接自动跳转到这个对应的节点上进行存取操作。
3、
还有就是因为如果集群的话,是有好多个redis一起工作的,那么,就需要这个集群不是那么容易挂掉,所以呢,理论上就应该给集群中的每个节点至少一个备用的redis服务。
这个备用的redis称为从节点(slave)
4、
那么这个集群是如何判断是否有某个节点挂掉了呢?
首先要说的是,
每一个节点都存有这个集群所有主节点以及从节点的信息
。
它们之间通过互相的ping-pong判断是否节点可以连接上。如果有一半以上的节点去ping一个节点的时候没有回应,集群就认为这个节点宕机了,然后去连接它的备用节点。
这就是redis的投票机制;
5、
如果
某个节点和它的所有从节点全部挂掉
,我们
集群就进入fail状态
。还有就是
如果有一半以上的主节点宕机,那么我们集群同样进入fail状态;
6、
投票过程是
集群中所有
master参与
,如果
半数以上
master节点与该
master节点通信超时
(cluster-node-timeout),认为
当前
master节点挂掉
;
什么时候整个集群不可用(cluster_state:fail)
a:如果集群任意master挂掉,且当前master没有slave.集群进入fail状态,也可以理解成集群的slot映射[0-16383]不完整时进入fail状态. 集群slot映射不完整
ps : redis-3.0.0.rc1加入cluster-require-full-coverage参数,默认关闭,打开集群兼容部分失败.
b:如果集群超过半数以上master挂掉,无论是否有slave,集群进入fail状态. 半数以上master挂调,无法检测某个master挂掉,无法过半确认
主从节点之间消息是怎么同步的
1、写入操作在对应的各个master节点;
2、读取操作在slave节点;
3、
主从结构,一是为了纯粹的冗余备份,二是为了提升读性能,比如很消耗性能的SORT就可以由从服务器来承担;
4、
Redis的主从同步是异步进行的,这意味着主从同步不会影响主逻辑,也不会降低Redis的处理性能;
5、从服务器通常被设置为只读模式,这样可以避免从服务器的数据被误修改;
6、
但是从服务器仍然可以接受CONFIG等(
取得运行中的 Redis 服务器的配置参数
)指令,
所以还是不应该将从服务器直接暴露到不安全的网络环境中。如果必须如此,那可以考虑给重要指令进行重命名,来避免命令被外人误执行。
7、同步原理:
依然会存在延迟
解决方案:强一致性--
主从架构下的强一致性
只需要在主机写入时,确认更新已经同步到备机之后,再返回写操作成功即可。
同步步骤:
https://www.2cto.com/kf/201610/557273.html
初始化同步方案:
1、从服务器会向主服务器发出SYNC指令,当主服务器接到此命令后,就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作;
2、也就是将主服务器的数据写入RDB文件中。在数据持久化期间,主服务器将执行的写指令都缓存在内存中;
3、在BGSAVE指令执行完成后,主服务器会将持久化好的RDB文件发送给从服务器,从服务器接到此文件后会将其存储到磁盘上;
4、然后再将其读取到内存中。这个动作完成后,主服务器会将这段时间缓存的写指令再以Redis协议的格式发送给从服务器;
增量同步方案:
新的写指令以----redis协议的格式直接发送给从服务去;
补充:
1、另外,要说的一点是,即使有多个从服务器同时发来SYNC指令,主服务器也只会执行一次BGSAVE,然后把持久化好的RDB文件发给多个下游;
2、在Redis2.8版本之前,如果从服务器与主服务器因某些原因断开连接的话,都会进行一次主从之间的全量的数据同步;
3、而在2.8版本之后,Redis支持了效率更高的增量同步策略,这大大降低了连接断开的恢复成本;
主服务器会在内存中维护一个缓冲区,缓冲区中存储着将要发给从服务器的内容,
从服务器在与主服务器出现网络瞬断之后,从服务器会尝试再次与主服务器连接,一旦连接成功,从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置(replication offset)”发送出去。
主服务器接收到这样的同步请求后,首先会验证主服务器ID是否和自己的ID匹配,其次会检查“请求的偏移位置”是否存在于自己的缓冲区中,如果两者都满足的话,
主服务器就会向从服务器发送增量内容。
增量同步功能,需要服务器端支持全新的PSYNC指令。这个指令,只有在Redis-2.8之后才具有。
是否强一致性
可以通过配置信息 修改---redis.conf的配置文件配置