redis分配槽命令專題及常見問題 - CSDN

2020-12-24 CSDN技術社區

一、槽的遷移

redis 提供redis-trlib 可以讓運維手工調整槽位分配情況，
set key 的時候可以通過在key字符串裡嵌入tag 標記，強制把key 所掛的槽位等於tag 所在的槽位

如圖 所示，Redis 客戶端向「緩存節點 1」發出請求，此時「緩存節點 1」正向「緩存節點 2」遷移數據，如果沒有命中對應的 Slot，它會返回客戶端一個 ASK 重定向請求並且告訴「緩存節點 2」的地址。
客戶端向「緩存節點 2」發送 Asking 命令，詢問需要的數據是否在「緩存節點 2」上，「緩存節點 2」接到消息以後返回數據是否存在的結果。

大致流程：

詳細圖

注意：

redis-cluster 數據遷移是同步的，在目標節點執行restore 指令到源節點刪除key 之間，源節點主線程處於阻塞狀態，直達key 被成功刪除。

所以操作的時候，不能在白天，選擇夜深人靜的時候。

如果遷移過程中遇到網絡故障，整個槽的遷移進行到一半，這市兩個節點依舊處於中間過渡狀態，待下次遷移工具連接，會提示用戶繼續進行遷移。

遷移時的性能：

如果可以都很小 migrate 的指令執行的很快，不會影響正常客戶端訪問，如果可以的內容很大，migrate會阻塞指令，會同時導致源節點和目標節點卡頓，影響集群的穩定性，在集群狀態下業務邏輯儘可能避免產生很大的key

思考：redis 支持的最大key 是

key 最大值 512m
key是按照hash查找的 ,當然越小 ,理論上越快 。 並沒有必然要多長的限制 ，儘量短就可以了！
Redis key值是二進位安全的，這意味著可以用任何二進位序列作為key值，從形如」foo」的簡單字符串到一個JPEG文件的內容都可以。空字符串也是有效key值。
關於key的幾條規則：
太長的鍵值不是個好主意，例如1024位元組的鍵值就不是個好主意，不僅因為消耗內存，而且在數據中查找這類鍵值的計算成本很高。
太短的鍵值通常也不是好主意，如果你要用」u:1000:pwd」來代替」user:1000:password」，這沒有什麼問題，但後者更易閱讀，並且由此增加的空間消耗相對於key
object和value object本身來說很小。當然，沒人阻止您一定要用更短的鍵值節省一丁點兒空間。
最好堅持一種模式。例如：」object-type🆔field」就是個不錯的注意，像這樣」user:1000:password」。我喜歡對多單詞的欄位名中加上一個點，就像這樣：」comment🔢reply.to」。

遷移時客戶端的訪問流程

遷移過程中，兩個節點對應的槽位都存在部分key數據，客戶端首先嘗試訪問舊的節點，如果對應的數據還在舊節點裡，舊節點正常處理。
如果不在舊節點，分兩種情況 1,在新節點 2，不存在

舊節點不清楚，所以向客戶端返回 -ASK targetNodeAddr重定向指令
客戶單去目標節點執行一個ASKING 指令，然後再在新節點執行原先的操作指令

執行ASKING 避免形成重定向循環。
ASKING 告訴新節點，不能不理，當做自己的槽位來處理。

正常情況下:

一個指令 一個ttl

遷移情況下 三個ttl

參考書籍：《Redis 深度歷險》

未經作者同意，本文禁止任何形式的轉載。

相關焦點

  • redis 虛擬槽分區專題及常見問題 - CSDN
    但哈希分布其實是有個問題的，當我們要擴容機器的時候，專業上稱之為「節點伸縮」，這個時候，因為是哈希算法，會導致數據遷移。哈希分區方式1、節點取餘分區使用特定的數據（包括redis的鍵或用戶ID），再根據節點數量N，使用公式：hash(key)%N計算出一個0~（N-1）值，用來決定數據映射到哪一個節點上。即哈希值對節點總數取餘。
  • 計算redis的槽 - CSDN
    集群節點的槽分配信息槽（slots）數據結構實際上是一個二進位數組，數組長度為2048個字節，16384個二進位位。Redis集群通過分片的方式來保存資料庫中的鍵值對。集群的整個資料庫被分為16384個槽，即資料庫中的所有鍵都屬於這16384個槽中的一個。集群中每個節點可以處理0~16384個槽。
  • cluster redis 槽位專題及常見問題 - CSDN
    這個槽是一個虛擬的槽，並不是真正存在的。正常工作的時候，Redis Cluster中的每個Master節點都會負責一部分的槽，當有某個key被映射到某個Master負責的槽，那麼這個Master負責為這個key提供服務，至於哪個Master節點負責哪個槽，這是可以由用戶指定的，也可以在初始化的時候自動生成（redis-trib.rb腳本）。
  • java 異步保存資料庫專題及常見問題 - CSDN
    redis-cluster架構圖Redis Cluster中，Sharding採用slot(槽)的概念，一共分成16384個槽，這有點兒類pre sharding思路。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。使用的hash算法也比較簡單，就是CRC16後16384取模。
  • 16384 redis slot專題及常見問題 - CSDN
    0-16383 之間的哈希槽，redis 會根據節點數量大致均等的將哈希槽映射到不同的節點。Redis 集群有16384個哈希槽,每個key通過CRC16校驗後對16384取模來決定放置哪個槽.集群的每個節點負責一部分hash槽。這種結構很容易添加或者刪除節點，並且無論是添加刪除或者修改某一個節點，都不會造成集群不可用的狀態。使用哈希槽的好處就在於可以方便的添加或移除節點。
  • redis集群原理 兩臺 - CSDN
    <b>}命令，將<a>~<b>範圍的槽都分配給當前客戶端所連接的節點。將所有的槽都分配給master節點後，執行cluster nodes命令，查看各個節點負責的槽，以及節點的ID。接下來還需要分配slave節點。
  • 電商項目的redis集群專題及常見問題 - CSDN
    如果redis伺服器內存不夠用,怎麼辦?Redis內存淘汰指的是用戶存儲的一些鍵被可以被Redis主動地從實例中刪除，從而產生讀miss的情況，那麼Redis為什麼要有這種功能？這就是我們需要探究的設計初衷。
  • c++信號與槽專題及常見問題 - CSDN
    開源庫下載：包含說明文檔，源碼，實例：https://download.csdn.net/download/u012372584/131624962、直接編譯會有錯誤，需要對源碼中的一句進行更改：將第419行 ：typedef sender_set::const_iterator const_iterator; 更改為：typedef typename sender_set
  • redis集群組建 - CSDN
    redis-trib 對集群的單個槽進行重新分片的步驟如下：redis-trib 對目標節點發送 cluster setslot <slot> importing <sorce_id> 命令讓目標節點準備好從源節點導入(import)屬於槽slot的鍵值對redis-trib 對源節點發送 cluster setslot <slot
  • redis 槽是什麼專題及常見問題 - CSDN
    有些同學私信了我但是我沒回，不是不願意交流，而是打算先答完問題，如果你有疑問再針對性問我，不然直接一個一個私信談效率太低。先說17校招吧。階段：面試小白到面試新人。經歷過校招的同學都知道，17校招應該是16秋季開始的。但是我並沒有參加這個秋季招聘，因為當時在準備考研中。學校是211，秋季來的企業普遍質量還不錯，這裡是第一個需要注意的地方，對於還沒畢業的孩子，秋招很重要，請務必重視。
  • docker鏡像重啟專題及常見問題 - CSDN
    二、串聯 Dockerfile 指令大家在定義Dockerfile時，如果太多的使用RUN指令，經常會導致鏡像有特別多的層，鏡像很臃腫，而且甚至會碰到超出最大層數(127層)限制的問題，遵循 Dockerfile 最佳實踐，我們應該把多個命令串聯合併為一個 RUN(通過運算符&&和/ 來實現)，每一個 RUN 要精心設計，確保安裝構建最後進行清理，這樣才可以降低鏡像體積
  • github覆蓋本地專題及常見問題 - CSDN
    參考文獻[1] Github進行fork後如何與原倉庫同步 https://blog.csdn.net/matrix_google/article/details/80676034[2] git分支查看及切換 https://blog.csdn.net/qq_26710805/article/details/80674006[3] git 放棄本地修改 https://
  • 深入Redis集群
    cluster info命令可以查看集群狀態，分配槽之前狀態為fail：分配槽使用cluster addslots命令，執行下面的命令將槽（編號0-16383）全部分配完畢：redis-cli -p 7000 cluster addslots {0..5461}redis-cli -p 7001 cluster addslots
  • redis16個分片 - CSDN
    1.redis cluster介紹redis cluster在3.0版本或者以上版本提供，採用sharding技術。Sharding採用slot(槽)的概念，一共分成16384個槽。對於每個進入Redis的鍵值對，根據key進行散列，分配到這16384個slot中的某一個中。
  • java 信號與槽專題及常見問題 - CSDN
    QT信號/槽在我的理解中,QT和Android都是類似的開發框架,都是由開發團隊封裝了各式各樣的接口和數據結構.將一些問題的解決方法簡單化 比如QT中將線程封裝為QThread,派生類通過重寫run方法來將代碼投入到新的線程執行,而同樣的Android中的線程是Java自帶的Thread
  • c使用sql server專題及常見問題 - CSDN
    ，在本地測試是好的，但是部署到測試環境、生產環境時就出這樣那樣的問題，同時，因為本地與測試環境、生產環境之間存在差異，我們可能無法在本地復現這些問題，那麼，有沒有一種工具可以很好的解決這一問題呢？Docker，同時，也可以使用 docker --version 命令查看我們安裝的 Docker CE 版本。
  • c++ 槽函數專題及常見問題 - CSDN
    它是一種函數回調機制，當一個信號關聯了多個槽時，信號發出，這些槽將會被調用,當然,也可以僅僅關聯一個槽函數。;第二個模板參數Combiner是一個函數對象，它被稱為『合併器』，用於組合所有槽的返回值，默認是boost::signals2::optional_last_value<R>，返回最後一個被調用的槽的返回值；第三個模板參數Group是槽編組的類型，你可以為你的槽設置不同的組，默認組的類型是int，通常情況下，不需要更改；
  • Redis的各項功能解決了哪些問題
    而redis官方給出的cluster方案則是把分布式的這部分事情做到了每一個redis伺服器中，使其不再需要其他的組件就可以獨立的完成分布式的要求。我們這裡不關心這些方案的優略，我們關注一下這裡的分布式到底是要處理那些事情?也就是twemproxy和codis獨立處理的處理分布式的這部分邏輯和cluster集成到redis服務的這部分邏輯到底在解決什麼問題？
  • Redis常見的面試題，確實厲害
    C語言的字符串不記錄自身的長度信息，而SDS則保存了長度信息，這樣將獲取字符串長度的時間由O(N)降低到了O(1)，同時可以避免緩衝區溢出和減少修改字符串長度時所需的內存重分配次數。redis使用hash表作為底層實現，每個字典帶有兩個hash表，供平時使用和rehash時使用，hash表使用鏈地址法來解決鍵衝突，被分配到同一個索引位置的多個鍵值對會形成一個單向鍊表，在對hash表進行擴容或者縮容的時候，為了服務的可用性，rehash的過程不是一次性完成的，而是漸進式的。
  • Redis的那些最常見面試問題
    6.redis常見性能問題和解決方案： 1).Master寫內存快照，save命令調度rdbSave函數，會阻塞主線程的工作，當快照比較大時對性能影響是非常大的，會間斷性暫停服務，所以Master最好不要寫內存快照。