Redis?Key使用{}原因分析
Redis集群介紹
Redis集群是一個(gè)提供在多個(gè)Redis間節(jié)點(diǎn)間共享數(shù)據(jù)的程序集,Redis集群能夠?qū)崿F(xiàn)key的分片,分片能使key均勻地分布到集群的機(jī)器上去,能保證數(shù)據(jù)的一致性。
使用Redis集群需要注意的點(diǎn)
從Redis單實(shí)例切換到twemproxy集群時(shí),有些需要注意的地方。
1、不支持的方法:
KEYS、MIGRATE、SCAN等
2、支持但需特殊處理的方法:
MSET、SINTERSTORE、SUNIONSTORE、ZINTERSTORE、ZUNIONSTORE等
對于不支持的方法,在使用時(shí)需要尋找替代方案。
Redis集群的數(shù)據(jù)分片
Redis集群沒有使用一致性hash,而是引入了哈希槽的概念。
Redis集群有16384個(gè)哈希槽,每個(gè)key通過CRC16校驗(yàn)后對16384取模來決定放置哪個(gè)槽。集群的每個(gè)節(jié)點(diǎn)負(fù)責(zé)一部分hash槽,舉個(gè)例子,比如當(dāng)前集群有3個(gè)節(jié)點(diǎn),那么:
節(jié)點(diǎn) A 包含 0 到 5500號(hào)哈希槽。
節(jié)點(diǎn) B 包含5501 到 11000 號(hào)哈希槽。
節(jié)點(diǎn) C 包含11001 到 16384號(hào)哈希槽。
這種結(jié)構(gòu)很容易添加或者刪除節(jié)點(diǎn)。比如如果我想新添加個(gè)節(jié)點(diǎn)D, 我需要從將節(jié)點(diǎn) A、B、C中的部分槽到D上。如果我想移除節(jié)點(diǎn)A,需要將A中的槽移到B和C節(jié)點(diǎn)上,然后將沒有任何槽的A節(jié)點(diǎn)從集群中移除即可。 由于從一個(gè)節(jié)點(diǎn)將哈希槽移動(dòng)到另一個(gè)節(jié)點(diǎn)并不會(huì)停止服務(wù),所以無論添加刪除或者改變某個(gè)節(jié)點(diǎn)的哈希槽的數(shù)量都不會(huì)造成集群不可用的狀態(tài)。
MSET
單實(shí)例上的MSET是一個(gè)原子性(atomic)操作,所有給定key都會(huì)在同一時(shí)間內(nèi)被設(shè)置,某些給定key被更新而另一些給定key沒有改變的情況,不可能發(fā)生。
而集群上雖然也支持同時(shí)設(shè)置多個(gè)key,但不再是原子性操作。會(huì)存在某些給定 key 被更新而另外一些給定key沒有改變的情況。其原因是需要設(shè)置的多個(gè)key可能分配到不同的機(jī)器上。
SINTERSTORE、SUNIONSTORE、ZINTERSTORE、ZUNIONSTORE
這四個(gè)命令屬于同一類型。它們的共同之處是都需要對一組key進(jìn)行運(yùn)算或操作,但要求這些key都被分配到相同機(jī)器上。這就是分片技術(shù)的矛盾之處:即要求key盡可能地分散到不同機(jī)器,又要求某些相關(guān)聯(lián)的key分配到相同機(jī)器。
Hash Tags
解鈴還需系鈴人,解決方法還是從分片技術(shù)的原理上找。
分片,就是一個(gè)hash的過程:對key做md5,sha1等hash算法,根據(jù)hash值分配到不同的機(jī)器上。為了實(shí)現(xiàn)將key分到相同機(jī)器,就需要相同的hash值,即相同的key(改變hash算法也行,但不簡單)。但key相同是不現(xiàn)實(shí)的,因?yàn)閗ey都有不同的用途。例如user:user1:ids
保存用戶的tweets ID,user:user1:tweets
保存tweet的具體內(nèi)容,兩個(gè)key不可能同名。
仔細(xì)觀察user:user1:ids
和user:user1:tweets
,兩個(gè)key其實(shí)有相同的地方,即user1。能不能拿這一部分去計(jì)算hash呢?
這就是Hash Tag,允許用key的部分字符串來計(jì)算hash。當(dāng)一個(gè)key包含{}
的時(shí)候,就不對整個(gè)key做hash,而僅對{}
包括的字符串做hash。假設(shè)hash算法為sha1。對user:{user1}:ids
和user:{user1}:tweets
,其hash值都等同于sha1(user1)。
HashTag可能會(huì)使過多的key分配到同一個(gè)slot中,造成數(shù)據(jù)傾斜影響系統(tǒng)的吞吐量,務(wù)必謹(jǐn)慎使用。
以上就是Redis Key使用{}原原因分析的詳細(xì)內(nèi)容,更多關(guān)于Redis Key使用{}的資料請關(guān)注腳本之家其它相關(guān)文章!
相關(guān)文章
Redis報(bào)錯(cuò):Could not create server TCP 
這篇文章主要介紹了Redis報(bào)錯(cuò):Could not create server TCP listening socket 127.0.0.1:6379: bind:解決方法,是安裝與啟動(dòng)Redis過程中比較常見的問題,需要的朋友可以參考下2023-06-06Redis為什么快如何實(shí)現(xiàn)高可用及持久化
這篇文章主要介紹了Redis為什么快如何實(shí)現(xiàn)高可用及持久化,本文給大家介紹的非常詳細(xì),對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-12-12Redis存儲(chǔ)的列表分頁和檢索的實(shí)現(xiàn)方法
在 Redis 中,列表(List)是一種有序的數(shù)據(jù)結(jié)構(gòu),通常用于存儲(chǔ)一系列元素,由于列表是有序的,可以通過索引來訪問元素,因此可以很方便地實(shí)現(xiàn)分頁和檢索功能,以下是 Redis 列表的分頁和檢索的實(shí)現(xiàn)方法,需要的朋友可以參考下2025-02-02Redis sentinel節(jié)點(diǎn)如何修改密碼
這篇文章主要介紹了Redis sentinel節(jié)點(diǎn)如何修改密碼問題,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-01-01Redis實(shí)現(xiàn)分布式事務(wù)的示例
Redis雖不支持傳統(tǒng)SQL數(shù)據(jù)庫ACID特性的事務(wù),但提供了事務(wù)特性,允許多命令捆綁執(zhí)行,通過命令MULTI、EXEC、DISCARD、WATCH實(shí)現(xiàn),感興趣的可以了解一下2024-10-10Redis 對比 Memcached 并在 CentOS 下進(jìn)行安裝配置詳解
Redis 是一個(gè)開源、支持網(wǎng)絡(luò)、基于內(nèi)存、鍵值對的 Key-Value 數(shù)據(jù)庫,本篇文章主要介紹了Redis 對比 Memcached 并在 CentOS 下進(jìn)行安裝配置詳解,有興趣的可以了解一下。2016-11-11redis的list數(shù)據(jù)類型相關(guān)命令介紹及使用
本文主要介紹了redis的list數(shù)據(jù)類型相關(guān)命令介紹及使用,文中通過示例代碼介紹的非常詳細(xì),具有一定的參考價(jià)值,感興趣的小伙伴們可以參考一下2022-01-01