專案中使用了redis集群，但是生產上發現rediskey 80%都被分配到了同乙個節點，導致該節點磁碟容量報警，其餘節點閒置的情況
專案中為了保持資料的準確性，當系統傳送異常時
單例項上的mset是乙個原子性(atomic)操作，所有給定 key 都會在同一時間內被設定，某些給定 key 被更新而另一些給定 key 沒有改變的情況，不可能發生。
而集群上雖然也支援同時設定多個key，但不再是原子性操作。會存在某些給定 key 被更新而另外一些給定 key 沒有改變的情況。其原因是需要設定的多個key可能分配到不同的機器上。
##sinterstore,sunionstore,zinterstore,zunionstore
這四個命令屬於同一型別。它們的共同之處是都需要對一組key進行運算或操作，但要求這些key都被分配到相同機器上。
這就是分片技術的矛盾之處：
即要求key盡可能地分散到不同機器，又要求某些相關聯的key分配到相同機器。
hashtag機制可以影響key被分配到的slot，從而可以使用那些被限制在slot中操作。
hashtag即是用{}包裹key的乙個子串，如1,2。
在設定了hashtag的情況下，集群會根據hashtag決定key分配到的slot， 兩個key擁有相同的hashtag:, 它們會被分配到同乙個slot，允許我們使用mget命令。
通常情況下，hashtag不支援巢狀，即將第乙個中間的內容作為hashtag。若花括號中不包含任何內容則會對整個key進行雜湊，如{}user:。
hashtag可能會使過多的key分配到同乙個slot中，造成資料傾斜影響系統的吞吐量，務必謹慎使用
redis 集群是乙個提供在多個redis間節點間共享資料的程式集。
redis集群並不支援處理多個keys的命令,因為這需要在不同的節點間移動資料,從而達不到像redis那樣的效能,在高負載的情況下可能會導致不可預料的錯誤.
redis 集群通過分割槽來提供一定程度的可用性,在實際環境中當某個節點宕機或者不可達的情況下繼續處理命令. redis 集群的優勢:
這種結構很容易新增或者刪除節點.比如如果我想新新增個節點d, 我需要從節點 a, b, c中得部分槽到d上. 如果我想移除節點a,需要將a中的槽移到b和c節點上,然後將沒有任何槽的a節點從集群中移除即可. 由於從乙個節點將雜湊槽移動到另乙個節點並不會停止服務,所以無論新增刪除或者改變某個節點的雜湊槽的數量都不會造成集群不可用的狀態
crc16演算法產生的hash值有16bit，該演算法可以產生2^16-=65536個值。換句話說，值是分布在0~65535之間。那作者在做mod運算的時候，為什麼不mod65536，而選擇mod16384
兩個節點之間會定期傳送ping/pong訊息，交換資料資訊，因為每秒鐘，redis節點需要傳送一定數量的ping訊息作為心跳包，如果槽位為65536，這個ping訊息的訊息頭太大了，浪費頻寬
集群節點越多，心跳包的訊息體內攜帶的資料越多。如果節點過1000個，也會導致網路擁堵。因此redis作者，不建議redis cluster節點數量超過1000個。
那麼，對於節點數在1000以內的redis cluster集群，16384個槽位夠用了。沒有必要拓展到65536個
redis集群至少需要3個主節點，因為投票容錯機制要求超過半數節點認為某個節點掛了該節點才是掛了，所以2個節點無法構成集群，另外在加3個從節點，即最少需要6個節點
Redis入門 關於redis key的基本命令
基本的一些命令 127.0.0.1 6379 set name fanmenggang set 乙個 key 的值 ok127.0.0.1 6379 keys 檢視所有的key 1 name 127.0.0.1 6379 get name 通過key獲取值 fanmenggang 127.0.0.1...
redis搭建集群（偽集群）
1 建立6個資料夾 2 複製redis.conf檔案，並修改redis.conf 配置檔案 3 建立集群 4 連線客戶端 5 檢視狀態 建立 6個資料夾來存放redis.conf,因為redis集群最小需要的是，三組三從，每個資料夾代表一台伺服器，6007跟6008可忽略 先複製乙個到6001資料夾...
搭建redis集群
sudo apt get install git python python pip sudo pip install redis sudo pip install e git sudo pip install e git git clone ll binaries total 19m 173582...