Redis集群

一.节点

cluster meet <ip> <port> //向节点握手
cluster nodes //查看集群节点

进行节点握手,握手成够后,node节点会将该节点加入到node节点的集群中。
节点启动:cluster-enabled 为yes则为集群模式启动
节点的数据结构:

struct clusterNode{
    //创建节点时间
    mstime_t ctime;
    //节点的名称,由40个16进制的字符组成
    char name[REDIS_CLISTER_NAMELEN]
    //节点标识
    //使用不同的标识来表示节点的不同角色
    //以及标识节点的不同状态
    int flags;
    //节点当前的配置纪元,用于故障转移
    unint64_t configEpoch;
    //节点的ip地址
    char ip[REDIS_IP_STR_LEN]
    //节点的端口号
    int port;
    //保存连接点的有关信息
    clusterLink *link;
};

cluster meet 命令的实现:

  1. 节点A会给节点B创建一个clusterNode结构,将该结构添加到自己的clusterState.nodes字典里面。
  2. 之后节点A会根据命令中的地址与端口向节点B发送一个meet消息。
  3. 如果节点B接受到节点A的消息,会为节点A创建一个clusterNode结构,并将该结构添加到自己的clusterState.nodes中。
  4. 之后节点B向节点A返回一个pong消息
  5. 节点A接受到节点B的pong消息,通过pong消息节点A知道自己的meet消息被节点B接受
  6. 之后节点A向节点B发送一条ping命令
  7. 节点B接收到节点A的ping命令,通过该命令节点B知道节点A接受到自己的Pong命令。握手完成。

在这里插入图片描述

二.槽指派

Redis集群通过分片的方式来保存数据库中的键值对:集群的整个数据库被分为16834个槽,数据库中的每一个键都属于这16834中的一个,集群中的每个节点都能处理0到16834个槽。
当数据库中的16834个槽都有节点处理时,整个集群属于上线状态,有且仅当一个槽没有被节点处理时,该集群属于下线状态。

cluster addslots 0 1 2 3 4 ... 5000 //给该节点分配5000个槽

记录节点中槽的指派信息:

struct clusterNode{
        unsinged char slots[16384/8]
        int numslots;
}

slots时一个二进制的数组,这个数组的长度时16384/8=2048个字节,共包含16384个二进制位。
在这里插入图片描述
一个节点除了会将自己处理的槽记录到自己的cluterNode中,还会将自己的slots数组通过消息发送到集群的其他节点,告诉其他节点自己负责的那些槽。
例如当节点A接受到节点B发送的slots数组时,会在自己的cluterState.nodes中找到节点B的cluterNode结构,并对结构中的slots进行保存或更新。

三.在集群中执行命令

执行命令判断流程:
在这里插入图片描述
计算键属于那个槽:
节点使用算法来计算键属于那个在0~16383之间的那个槽。所以从一个方面来说,每个建位的槽都是固定的。

四.AKS错误

在进行重新分片时,源节点在向目标节点迁移的过程中,可能会出现这样一种情况:属于被迁移的一部分键保存在源节点中,而另一部分保存在目标节点中。这时就会返回AKS错误。

五.复制与故障转移

Redis集群中的节点分为主节点和从节点,其中主节点用于处理槽,而从节点则用于复制某个主节点,并在其复制的主节点下线时,代替主节点继续处理命令请求。
在这里插入图片描述
故障检测:如果在集群中半数以上负责处理槽的主节点都将某个主节点标记为疑似下线。那么这个主节点就会被标记为已下线,将主节点标记为已下线的节点会向集群广播一条该节点已下线的消息。收到该消息的主节点会将该节点标记为已下线。
故障转移:

  1. 复制主节点中的所有到从节点里面,会有一个从节点被选中。
  2. 被选中的从节点会执行SLAVEOF on one命令,成为主节点。
  3. 新的主节点会撤销所有已下线主节点的槽指派,并将这些槽指派给自己。
  4. 新的主节点会在集群中广播一个PONG命令,告诉其他的主节点这个节点已经变为主节点,并也继承了该下线节点的所有的槽。

六.消息

集群中各个节点通过messgae来进行通信,发送消息的节点被称位sender,接受消息的节点被称位receiver.
消息分为五种:

  1. MEET消息:当发送者接收到客户端的CLUSTER MEET命令时,发送者会向接收者发送meet消息,请求接收者加入到当前的集权中。
  2. PING消息:集群中的每个节点默认每隔一秒就会从已知节点中选出5个。然后对这五个节点中最长时间没有发送ping消息的节点发送ping节点,以来检测该节点是否在线。
  3. PONG消息:当节点接受到MEET消息和PING消息时,为了向发送端表示已接受到该消息,会返回一个PONG消息,表示自己已经接受到该消息。
  4. FAIL消息:当一个主节点A判断另一个主节点B进入FAIL状态时,节点A会在集权中广播一个关于节点B的FAIL的消息,接受到该消息的节点会将节点B更新位FAIL(下线)状态。
  5. PUBLISH消息:当一个节点接受到PUBLSH消息时,会在集群中广播PUBLSH消息,接受到该消息的节点会执行相同的PUBLISH命令。
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
本火锅店点餐系统采用Java语言和Vue技术,框架采用SSM,搭配Mysql数据库,运行在Idea里,采用小程序模式。本火锅店点餐系统提供管理员、用户两种角色的服务。总的功能包括菜品的查询、菜品的购买、餐桌预定和订单管理。本系统可以帮助管理员更新菜品信息和管理订单信息,帮助用户实现在线的点餐方式,并可以实现餐桌预定。本系统采用成熟技术开发可以完成点餐管理的相关工作。 本系统的功能围绕用户、管理员两种权限设计。根据不同权限的不同需求设计出更符合用户要求的功能。本系统中管理员要负责审核管理用户,发布分享新的菜品,审核用户的订餐信息和餐桌预定信息等,用户可以对需要的菜品进行购买、预定餐桌等。用户可以管理个人资料、查询菜品、在线点餐和预定餐桌、管理订单等,用户的个人资料是由管理员添加用户资料时产生,用户的订单内容由用户在购买菜品时产生,用户预定信息由用户在预定餐桌操作时产生。 本系统的功能设计为管理员、用户两部分。管理员为菜品管理、菜品分类管理、用户管理、订单管理等,用户的功能为查询菜品,在线点餐、预定餐桌、管理个人信息等。 管理员负责用户信息的删除和管理,用户的姓名和手机号都可以由管理员在此功能里看到。管理员可以对菜品的信息进行管理、审核。本功能可以实现菜品的定时更新和审核管理。本功能包括查询餐桌,也可以发布新的餐桌信息。管理员可以查询已预定的餐桌,并进行审核。管理员可以管理公告和系统的轮播图,可以安排活动。管理员可以对个人的资料进行修改和管理,管理员还可以在本功能里修改密码。管理员可以查询用户的订单,并完成菜品的安排。 当用户登录进系统后可以修改自己的资料,可以使自己信息的保持正确性。还可以修改密码。用户可以浏览所有的菜品,可以查看详细的菜品内容,也可以进行菜品的点餐。在本功能里用户可以进行点餐。用户可以浏览没有预定出去的餐桌,选择合适的餐桌可以进行预定。用户可以管理购物车里的菜品。用户可以管理自己的订单,在订单管理界面里也可以进行查询操作。

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值