复述,群集部署及原理

  

<强>一、复述,群集架构细节:

  

1,所有的复述,节点彼此互联(乒乓球机制)内部使用二进制协议优先传输速度和带宽。

  

2节点的失效(失败)在群集中超过半数的主(主)节点检测失效时才会生效。

  

3,客户端与复述,节点直连,不需要中间代理(代理)层,客户端不需要连接群集所有节点,连接群集中任何一个可用节点即可。

  

4, redis-cluster把所有的物理节点映射到(0 - 1638)槽上,集群负责维护node<趕lot<?关键。
<强>二,redis-cluster选举:
选举过程是群集中所有主参与,如果半数以上主节点与当前主节点通信超时(cluster-node-timeout)认为当前主节点挂掉。以下两种情况为整个群集不可用(cluster_state:失败),当群集不可用时,所有对群集的操作都不可用,收到((错误)CLUSTERDOWN Thecluster下降)错误:

  
      <李>   

    如果群集中任意主挂掉,且当前主人没有奴隶,则群集进入失败的状态,也可以理解成群集的槽映射(0 - 16383)不完整时进入失败状态。

      李   <李>如果群集中超过半数的主挂掉,无论是否有奴隶,群集都进入失败状态。   
  

默认情况下,每个群集的节点都是用两个TCP端口,一个是6379,一个是16379;6379年服务于客户端的连接,16379年用于群集总线,就是使用二进制协议的节点到节点通信通道。节点使用群集总线进行故障检测,配置更新,故障转移授权等。
<强>复述,群集原理:

  
  

1,复述,集群架构:

  

复述,集群采用虚拟槽分区,将所有的数据根据算法映射到0 ~ 16384整数槽内
复述,集群是一个无中心的结构
每个节点都保存数据和整个集群的状态
2,集群角色:
主:主之间分配槽
奴隶:奴隶向它指定的主人同步数据
3,集群节点使用的TCP端口
6379端口用于客户端的连接
16379端口用于群集总线

     

Redis3.0版本以上开始支持群集,采用的是散列槽(哈希槽),可以将多个复述,实例整合在一起,形成一个群集,也就是将数据分散到群集的多台服务器上。
。集群(
复述,复述,群集)是一个无中心的结构,如下图所示,每个节点都会保存数据和整个群集的状态。每个节点都会保存其他节点的信息,知道其他节点所负责的槽,并且会与其他节点定时发送心跳信息,能够及时感知群集中异常的节点。
复述,群集部署及原理”> <br/>当客户端向群集中任一节点发送与数据库键有关的命令时,接受命令的节点会计算出命令要处理的数据属于哪个槽,并检查这个槽是否指派给了自己,如果键所在的槽正好指派给了当前节点,那么节点直接执这个命令,如果键值所在的槽并没有指派给当前节点,那么节点会向客户端返回一个搬错误,指引客户端转向(重定向)正确的节点,并再次发送之前想要执行的命令。<br/>。<br/>群集角色有大师和slave.master之间分配槽,一共16384个slot.slave向它指定的主人同步数据,实现备份。当其中一个主人无法提供服务时,该主的奴隶将提升为大师,以保证群集间槽的完整性。当其中的某一个主人和它的奴隶都失效,导致了槽不完整,群集失效,这时就需要运维人员去处理了。<br/>。<br/>群集搭建好后,群集中的每个节点都会定期地向其他节点发送平消息,如果接收平消息的节点没有在规定的时间内返回PONG消息,那么发送平消息的节点就会将其标记为疑似下线(PFAIL)。各个节点会通过互相发送消息的方式来交换群集中各个节点的状态信息。如果已经在一个群集里面,半数以上的主节点都将某个主节点x报告为疑似下线,那么这个主节点x将被标记为已下线(失败),同时会向群集广播一条关于主节点x的失败消息,所有收到这条失败的消息的节点都会立即将主节点x标记为已下线。<br/>。<br/>当需要减少或者增加群集中的服务器时,我们需要将已经指派给某个节点(源节点)的槽改为指派给另一个节点(目标节点),并且将相关槽所包含的键值对从源节点移动到目标节点。<br/>。<br/>复述,群集的重新分片操作时由复述的群集管理软件redis-trib负责执行的,不支持自动分片,而且需要自己计算从哪些节点迁移多少槽。在重新分片的过程中,群集无需下线,并且源节点和目标节点都可以继续处理命令请求。<br/> <强>准备工作:</强> <br/> 1,六台服务器,三台为大师,三台为奴隶,这里均为centos 7日IP地址依次为192.168.1.10——60(参与群集的服务器数量最好为偶数,每个主人会自动对应一个奴隶,若为奇数,群集无法实现冗余,因为必定有一个主人没有对应的奴隶,一旦这个大师宕机,整个群集就会丢失一部分数据);<h2 class=复述,群集部署及原理