redis hash key数量 redis hash_tag

转载

mob64ca14061c9e 2023-08-15 09:50:18

文章标签 redis hash key数量 redis 客户端数据 文章分类 Redis 数据库

redis cluster 是Redis官方退出的集群方案，采用主从加选举方案保证高可用，采用类似一致性哈希（哈希槽）的方式保证数据容量可以横向拓展，只移动部分元素就可以实现动态添加删除节点，是比较常用的redis集群方案。

这里总结一些使用过程中容易忽视的的问题，或者是比较有用的技巧。

1. redis cluster 每个节点都需要开启两个TCP端口

一个是redis服务端和客户端通信的端口，比如配置端口6379，响应的redis会使用 6379+10000=16379端口，作为集群总线，用于集群间数据交互。10000 这个数字是固定的。所以搭建redis集群的时候要确保防火墙放开了客户端端口和集群总线端口。否则客户端功能或者集群功能将无法正常使用。

2. hash Tag

hash Tag是redis集群比较好用的特性。当然这个功能我们也可以再客户端这边自己去实现。简单来讲hash tag就是可以标记key中用hash算法生成hash槽的部分。从而控制特定的key被分配到特定的hash槽中，从而可使用redis的批量命令（mget,mset等），这个功能的问题也比较明显，就是有可能会导致数据分配不均。使用方式就是把key中需要用来做hash的部分用{}括起来，比如 {englishClass}_zhangsan, {englishClass}_lisi。这两个key会被分配到一个hash槽中，从而可以用mget批量获取一个班级的所有学生。

3. redis集群数据一致性问题。redis集群不保证数据强一致性，有两种会导致丢失数据的情况。

（1）主节点同步数据到从节点之前宕机，从节点升级为主节点，导致数据丢失。

例如主节点A，有一个从节点B，主节点A收到set name zhangsan的命令后，处理结束后返回客户端成功，然后再异步去通知从节点B set命令。如果主节点A在返回客户端之后，通知从节点之前宕机，过一段时间之后会由集群的选举机制选举从节点B为新的主节点，但是B节点是没有name zhangsan这条数据的，即便过一会主节点A恢复，也会同步节点B的数据，name 这条数据就丢失了。

解决方案：wait命令，将客户端阻塞，异步变同步。wait命令使用方式：wait 1 意思是等待主节点之前的所有写操作成功通知一个从节点之后返回。也可以加上超时时间，wait 1 1000 最长不能超过1秒返回，1秒后超时返回成功同步的从节点个数。

（2）脑裂

比如有集群：A a B b C c 主节点：A B C 从节点 a1 b1 c1 。如果出现网络问题，集群脑裂成两个子集群 A B a1 b1 c1和 C，在多数节点的集群中，检测到C主节点宕机，c1从节点升级为主节点，网络恢复之后，C节点加入成为c1的从节点。就会导致网络分裂时期对C节点的数据写入丢失。

解决方案：节点超时时间（node timeout）。主节点宕机超过node timeout后，从节点C1升级为主节点。如果主节点C在超过node timeout后，还是无法感知大多数的主节点，则变为error状态并拒绝写入操作。

4. manual failover

因为redis集群不保证强一致性，存在数据丢失风险，所以如果想要主动下掉某个主节点的话，其实是有数据丢失风险的。这个时候，manual failover 就可以起到作用。如果某个主节点出现问题，想要重启，或者迁移之类的操作的话，可以使用redis 的CLUSTER FAILOVER 命令。从想要下线的主节点的从节点发起命令，主节点和从节点会调换身份。期间会阻塞客户端请求一段时间，保证数据一致后，开始转换，从而保证数据一致性。