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-06
Redis為什么快如何實(shí)現(xiàn)高可用及持久化
這篇文章主要介紹了Redis為什么快如何實(shí)現(xiàn)高可用及持久化,本文給大家介紹的非常詳細(xì)，對大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-12-12
Redis存儲(chǔ)的列表分頁和檢索的實(shí)現(xiàn)方法
在 Redis 中,列表（List）是一種有序的數(shù)據(jù)結(jié)構(gòu),通常用于存儲(chǔ)一系列元素,由于列表是有序的,可以通過索引來訪問元素,因此可以很方便地實(shí)現(xiàn)分頁和檢索功能,以下是 Redis 列表的分頁和檢索的實(shí)現(xiàn)方法,需要的朋友可以參考下2025-02-02
Redis sentinel節(jié)點(diǎn)如何修改密碼
這篇文章主要介紹了Redis sentinel節(jié)點(diǎn)如何修改密碼問題,具有很好的參考價(jià)值,希望對大家有所幫助,如有錯(cuò)誤或未考慮完全的地方,望不吝賜教2024-01-01
Redis實(shí)現(xiàn)分布式事務(wù)的示例
Redis雖不支持傳統(tǒng)SQL數(shù)據(jù)庫ACID特性的事務(wù),但提供了事務(wù)特性,允許多命令捆綁執(zhí)行,通過命令MULTI、EXEC、DISCARD、WATCH實(shí)現(xiàn),感興趣的可以了解一下2024-10-10
Redis 對比 Memcached 并在 CentOS 下進(jìn)行安裝配置詳解
Redis 是一個(gè)開源、支持網(wǎng)絡(luò)、基于內(nèi)存、鍵值對的 Key-Value 數(shù)據(jù)庫，本篇文章主要介紹了Redis 對比 Memcached 并在 CentOS 下進(jìn)行安裝配置詳解，有興趣的可以了解一下。2016-11-11
Redis 緩存使用內(nèi)存來保存數(shù)據(jù),隨著需要緩存的數(shù)據(jù)量越來越大,有限的緩存空間不可避免地會(huì)被寫滿,本文主要介紹了Redis 緩存滿了如何解決,感興趣的可以了解一下2023-08-08
緩存擊穿問題也叫熱點(diǎn)Key問題,就是?個(gè)被高并發(fā)訪問并且緩存重建業(yè)務(wù)較復(fù)雜的key突然失效了,無數(shù)的請求訪問會(huì)在瞬間給數(shù)據(jù)庫帶來巨大的沖擊,本文給大家介紹了Redis解決緩存擊穿問題的兩種方法,需要的朋友可以參考下2025-03-03
本文主要介紹了IDEA中的Redis插件連接Redis服務(wù)器，文中通過示例代碼介紹的非常詳細(xì)，對大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2023-02-02
redis的list數(shù)據(jù)類型相關(guān)命令介紹及使用
本文主要介紹了redis的list數(shù)據(jù)類型相關(guān)命令介紹及使用，文中通過示例代碼介紹的非常詳細(xì)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2022-01-01