Redis中Key中为什么要使用{}

手机软件开发 2024-9-15 07:59:11 56 0 来自 中国
一、Redis集群先容

Redis集群是一个提供在多个Redis间节点间共享数据的步伐集,Redis集群可以大概实现key的分片,分片能使key均匀地分布到集群的呆板上去,能包管数据的同等性。
二、使用Redis集群须要注意的点

从Redis单实例切换到twemproxy集群时,有些须要注意的地方。
1、不支持的方法:
KEYS、MIGRATE、SCAN等
2、支持但需特殊处置惩罚的方法:
MSET、SINTERSTORE、SUNIONSTORE、ZINTERSTORE、ZUNIONSTORE等
对于不支持的方法,在使用时须要探求替换方案。
三、Redis集群的数据分片

Redis集群没有使用同等性hash,而是引入了哈希槽的概念。
Redis集群有16384个哈希槽,每个key通过CRC16校验后对16384取模来决定放置哪个槽。集群的每个节点负责一部分hash槽,举个例子,比如当前集群有3个节点,那么:
节点 A 包罗 0 到 5500号哈希槽。
节点 B 包罗5501 到 11000 号哈希槽。
节点 C 包罗11001 到 16384号哈希槽。
这种结构很轻易添加或者删除节点。比如假如我想新添加个节点D, 我须要从将节点 A、B、C中的部分槽到D上。假如我想移除节点A,须要将A中的槽移到B和C节点上,然后将没有任何槽的A节点从集群中移除即可。 由于从一个节点将哈希槽移动到另一个节点并不会制止服务,以是无论添加删除或者改变某个节点的哈希槽的数量都不会造成集群不可用的状态。
四、MSET

单实例上的MSET是一个原子性(atomic)利用,全部给定key都会在同一时间内被设置,某些给定key被更新而另一些给定key没有改变的环境,不大概发生。
而集群上固然也支持同时设置多个key,但不再是原子性利用。会存在某些给定 key 被更新而另外一些给定key没有改变的环境。其缘故原由是须要设置的多个key大概分配到差别的呆板上。
SINTERSTORE、SUNIONSTORE、ZINTERSTORE、ZUNIONSTORE这四个下令属于同一范例。它们的共同之处是都须要对一组key举行运算或利用,但要求这些key都被分配到雷同呆板上。这就是分片技能的抵牾之处:即要求key尽大概地分散到差别呆板,又要求某些相干联的key分配到雷同呆板。
五、Hash Tags

解铃还需系铃人,办理方法还是从分片技能的原理上找。
分片,就是一个hash的过程:对key做md5,sha1等hash算法,根据hash值分配到差别的呆板上。为了实现将key分到雷同呆板,就须要雷同的hash值,即雷同的key(改变hash算法也行,但不简单)。但key雷同是不现实的,由于key都有差别的用途。比方user:user1:ids生存用户的tweets ID,user:user1:tweets生存tweet的具体内容,两个key不大概同名。
细致观察user:user1:ids和user:user1:tweets,两个key实在有雷同的地方,即user1。能不能拿这一部分去盘算hash呢?
这就是Hash Tag,允许用key的部分字符串来盘算hash。当一个key包罗{} 的时间,就不对整个key做hash,而仅对{} 包罗的字符串做hash。假设hash算法为sha1。对user:{user1}:ids和user:{user1}:tweets,其hash值都等同于sha1(user1)。
HashTag大概会使过多的key分配到同一个slot中,造成数据倾斜影响体系的吞吐量,务必审慎使用。
您需要登录后才可以回帖 登录 | 立即注册

Powered by CangBaoKu v1.0 小黑屋藏宝库It社区( 冀ICP备14008649号 )

GMT+8, 2024-11-22 16:48, Processed in 0.161816 second(s), 32 queries.© 2003-2025 cbk Team.

快速回复 返回顶部 返回列表