用户密码找回网站,即时通讯app开发,上海网站设计与开发公司,做网站公司郑州汉狮Redis集群一般有5种#xff1a;1#xff0c;主从复制2#xff0c;哨兵模式3#xff0c;Redis官方提供的Cluster集群模式(服务端)4#xff0c;Jedis sharding集群(客户端sharding)5,利用中间件代理#xff0c;比如豌豆荚的codis等介绍完他们的模式#xff0c;现在来分析一…Redis集群一般有5种1主从复制2哨兵模式3Redis官方提供的Cluster集群模式(服务端)4Jedis sharding集群(客户端sharding)5,利用中间件代理比如豌豆荚的codis等介绍完他们的模式现在来分析一下他们的原理主从复制(Master-Slave Replication):实现主从复制(Master-Slave Replication)的工作原理Slave从节点服务启动并连接到Master之后它将主动发送一个SYNC命令。Master服务主节点收到同步命令后将启动后台存盘进程同时收集所有接收到的用于修改数据集的命令在后台进程执行完毕后Master将传送整个数据库文件到Slave以完成一次完全同步。而Slave从节点服务在接收到数据库文件数据之后将其存盘并加载到内存中。此后Master主节点继续将所有已经收集到的修改命令和新的修改命令依次传送给SlavesSlave将在本次执行这些数据修改命令从而达到最终的数据同步。如果Master和Slave之间的链接出现断连现象Slave可以自动重连Master但是在连接成功之后一次完全同步将被自动执行。主从复制配置修改从节点的配置文件slaveof masterip masterport如果设置了密码就要设置masterauth master-password哨兵模式:该模式是从Redis的2.6版本开始提供的但是当时这个版本的模式是不稳定的直到Redis的2.8版本以后这个哨兵模式才稳定下来无论是主从模式还是哨兵模式这两个模式都有一个问题不能水平扩容并且这两个模式的高可用特性都会受到Master主节点内存的限制。Sentinel(哨兵)进程是用于监控redis集群中Master主服务器工作的状态在Master主服务器发生故障的时候可以实现Master和Slave服务器的切换保证系统的高可用。Sentinel(哨兵)进程的作用监控(Monitoring): 哨兵(sentinel) 会不断地检查你的Master和Slave是否运作正常。提醒(Notification)当被监控的某个Redis节点出现问题时, 哨兵(sentinel) 可以通过 API 向管理员或者其他应用程序发送通知。自动故障迁移(Automatic failover)当一个Master不能正常工作时哨兵(sentinel) 会开始一次自动故障迁移操作它会将失效Master的其中一个Slave升级为新的Master, 并让失效Master的其他Slave改为复制新的Master当客户端试图连接失效的Master时集群也会向客户端返回新Master的地址使得集群可以使用现在的Master替换失效Master。Master和Slave服务器切换后Master的redis.conf、Slave的redis.conf和sentinel.conf的配置文件的内容都会发生相应的改变即Master主服务器的redis.conf配置文件中会多一行slaveof的配置sentinel.conf的监控目标会随之调换。Sentinel(哨兵)进程的工作方式每个Sentinel(哨兵)进程以每秒钟一次的频率向整个集群中的Master主服务器Slave从服务器以及其他Sentinel(哨兵)进程发送一个 PING 命令。如果一个实例(instance)距离最后一次有效回复 PING 命令的时间超过 down-after-milliseconds 选项所指定的值 则这个实例会被 Sentinel(哨兵)进程标记为主观下线(SDOWN)如果一个Master主服务器被标记为主观下线(SDOWN)则正在监视这个Master主服务器的所有 Sentinel(哨兵)进程要以每秒一次的频率确认Master主服务器的确进入了主观下线状态当有足够数量的 Sentinel(哨兵)进程(大于等于配置文件指定的值)在指定的时间范围内确认Master主服务器进入了主观下线状态(SDOWN) 则Master主服务器会被标记为客观下线(ODOWN)在一般情况下 每个 Sentinel(哨兵)进程会以每 10 秒一次的频率向集群中的所有Master主服务器、Slave从服务器发送 INFO 命令。当Master主服务器被 Sentinel(哨兵)进程标记为客观下线(ODOWN)时Sentinel(哨兵)进程向下线的 Master主服务器的所有 Slave从服务器发送 INFO 命令的频率会从 10 秒一次改为每秒一次。若没有足够数量的 Sentinel(哨兵)进程同意 Master主服务器下线 Master主服务器的客观下线状态就会被移除。若 Master主服务器重新向 Sentinel(哨兵)进程发送 PING 命令返回有效回复Master主服务器的主观下线状态就会被移除。Redis官方 Cluster集群模式Redis Cluster是一种服务器Sharding技术3.0版本开始正式提供。在这个图中每一个蓝色的圈都代表着一个redis的服务器节点。它们任何两个节点之间都是相互连通的。客户端可以与任何一个节点相连接然后就可以访问集群中的任何一个节点。对其进行存取和其他操作。Redis集群数据分片在redis的每一个节点上都有这么两个东西一个是插槽(slot)可以理解为是一个可以存储两个数值的一个变量这个变量的取值范围是0-16383。还有一个就是cluster我个人把这个cluster理解为是一个集群管理的插件。当我们的存取的key到达的时候redis会根据crc16的算法得出一个结果然后把结果对 16384 求余数这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽通过这个值去找到对应的插槽所对应的节点然后直接自动跳转到这个对应的节点上进行存取操作。Jedis sharding集群Redis Sharding可以说是在Redis cluster出来之前业界普遍的采用方式其主要思想是采用hash算法将存储数据的key进行hash散列这样特定的key会被定为到特定的节点上。庆幸的是Java Redis客户端驱动Jedis已支持Redis Sharding功能即ShardedJedis以及结合缓存池的ShardedJedisPoolJedis的Redis Sharding实现具有如下特点采用一致性哈希算法将key和节点name同时hashing然后进行映射匹配采用的算法是MURMUR_HASH。采用一致性哈希而不是采用简单类似哈希求模映射的主要原因是当增加或减少节点时不会产生由于重新匹配造成的rehashing。一致性哈希只影响相邻节点key分配影响量小。为了避免一致性哈希只影响相邻节点造成节点分配压力ShardedJedis会对每个Redis节点根据名字(没有Jedis会赋予缺省名字)会虚拟化出160个虚拟节点进行散列。根据权重weight也可虚拟化出160倍数的虚拟节点。用虚拟节点做映射匹配可以在增加或减少Redis节点时key在各Redis节点移动再分配更均匀而不是只有相邻节点受影响。ShardedJedis支持keyTagPattern模式即抽取key的一部分keyTag做sharding这样通过合理命名key可以将一组相关联的key放入同一个Redis节点这在避免跨节点访问相关数据时很重要。利用中间件代理中间件的作用是将我们需要存入redis中的数据的key通过一套算法计算得出一个值。然后根据这个值找到对应的redis节点将这些数据存在这个redis的节点中。常用的中间件有这几种TwemproxyCodisnginx
