Redis中redis-cluster需要注意哪些地方

本篇內(nèi)容主要講解“Redis中redis-cluster需要注意哪些地方”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實用性強。下面就讓小編來帶大家學習“Redis中redis-cluster需要注意哪些地方”吧!

1.收到150告警，rdb持久化失敗

15011:M 17 Sep 08:54:43.037 # Can't save in background: fork: Cannot allocate memory
15011:M 17 Sep 08:54:49.043 * 1 changes in 900 seconds. Saving...
15011:M 17 Sep 08:54:49.043 # Can't save in background: fork: Cannot allocate memory

2 查看主機內(nèi)存（內(nèi)心os：尼瑪還有這么多內(nèi)存呢）

[root@ip-172-31-43-150 ~]# free -g
              total        used        free      shared  buff/cache   available
Mem:             29          14          10           0           4          14
Swap:             0           0           0

3 查看redis-cluster集群狀態(tài)，顯示150已down機，心慌慌

[root@ip-172-31-39-42 ~]# /usr/local/src/redis-4.0.8/src/redis-trib.rb  check 172.31.39.42:6379
[ERR] Sorry, can't connect to node 172.31.43.150:6379
*** WARNING: 172.31.39.54:6379 claims to be slave of unknown node ID 6d2b67b9745a8d4bedb70d480645e3651fddaf3f.
>>> Performing Cluster Check (using node 172.31.39.42:6379)
M: 00f7bd511046438af2d1b41666a69ff77b6f176f 172.31.39.42:6379
   slots:11258-11832,13655-16383 (3304 slots) master
   1 additional replica(s)
S: e771e70f580ec2799af50268865444cf425e000e 172.31.33.17:6379
   slots: (0 slots) slave
   replicates 00f7bd511046438af2d1b41666a69ff77b6f176f
S: 8bb99c5b9585269b66684400f036fca1d30e72cb 172.31.47.157:6379
   slots: (0 slots) slave
   replicates 148697f75e9b4f84ad893f4d5377e96fdde7664d
M: 148697f75e9b4f84ad893f4d5377e96fdde7664d 172.31.34.25:6379
   slots:28,4799-5462,6375-7282,8194-9106,11833-12744 (3398 slots) master
   1 additional replica(s)
M: 40b766b505c54066de5b5d8eb214ea78c7df8c4b 172.31.36.10:6379
   slots:7542-8193,9107-10922,12745-13654 (3378 slots) master
   1 additional replica(s)
S: f6a625cc2d6fb66d267b15c8d668ea150be262bc 172.31.37.68:6379
   slots: (0 slots) slave
   replicates 792ab7473fa447d07582817eb2f489633001d831
M: 792ab7473fa447d07582817eb2f489633001d831 172.31.33.182:6379
   slots:0-27,29-1145,1822-2105,3406-4798,7283-7541 (3081 slots) master
   1 additional replica(s)
S: 92a5541964fc3e4bfb90f1750b9105d5705beb93 172.31.39.54:6379
   slots: (0 slots) slave
   replicates 6d2b67b9745a8d4bedb70d480645e3651fddaf3f
S: 7e5e1e341f33ebd7a3c20480b66a76bbd0922a4f 172.31.32.254:6379
   slots: (0 slots) slave
   replicates 40b766b505c54066de5b5d8eb214ea78c7df8c4b
[OK] All nodes agree about slots configuration.
>>> Check for open slots...
>>> Check slots coverage...
[ERR] Not all 16384 slots are covered by nodes.

登上150檢查redis的狀態(tài)，發(fā)現(xiàn)好好的！

先解決持久化失敗的問題：

1.
172.31.39.54:6379> config set stop-writes-on-bgsave-error no  ---解決應(yīng)用端拋異常的問題
OK
172.31.39.54:6379> config rewrite
OK
172.31.39.54:6379> 
2.開啟內(nèi)核參數(shù)，解決bgsave失敗的問題
[root@ip-172-31-33-182 ~]# sudo echo 'vm.overcommit_memory = 1' >> /etc/sysctl.conf
[root@ip-172-31-33-182 ~]# sysctl -p
vm.overcommit_memory = 1

再次查看日志，已經(jīng)持久化成功，check集群也發(fā)現(xiàn)集群恢復(fù)正常

關(guān)于redis的內(nèi)存分配學習：

Redis有自己的內(nèi)存分配器，當key-value對象被移除時，Redis不會馬上向操作系統(tǒng)釋放其占用內(nèi)存（例如，當用戶往一個實例填充了5G的數(shù)據(jù)，移除其中2G數(shù)據(jù)，但占用內(nèi)存可能仍會保持在5G左右）。為什么Redis要這樣處理？有兩個原因：
1、OS可能會將釋放內(nèi)存交換到VM，但OS的VM又是物理文件，其IO讀寫效率較低，從而影響Redis性能表現(xiàn)；
2、OS的VM換入換出是基于Page機制，同一Page內(nèi)的部分數(shù)據(jù)對象被釋放，但其他數(shù)據(jù)對象依然被其他應(yīng)用使用中，導(dǎo)致在該Page內(nèi)的Redis對象沒有被釋放。
而Redis作者應(yīng)該是考慮到以上問題，不希望Redis由此降低性能，所以在設(shè)計上Redis更傾向于自己掌控VM換入的粒度。(https://segmentfault.com/a/1190000004708270)

持久化的問題

Redis持久化磁盤IO方式及其帶來的問題
有Redis線上運維經(jīng)驗的人會發(fā)現(xiàn)Redis在物理內(nèi)存使用比較多，但還沒有超過實際物理內(nèi)存總?cè)萘繒r就會發(fā)生不穩(wěn)定甚至崩潰的問題，有人認為是基于快照方式持久化的fork系統(tǒng)調(diào)用造成內(nèi)存占用加倍而導(dǎo)致的，這種觀點是不準確的，因為fork 調(diào)用的copy-on-write機制是基于操作系統(tǒng)頁這個單位的，也就是只有有寫入的臟頁會被復(fù)制，但是一般你的系統(tǒng)不會在短時間內(nèi)所有的頁都發(fā)生了寫入而導(dǎo)致復(fù)制，那么是什么原因?qū)е翿edis崩潰的呢？
答案是Redis的持久化使用了Buffer IO造成的，所謂Buffer IO是指Redis對持久化文件的寫入和讀取操作都會使用物理內(nèi)存的Page Cache,而大多數(shù)數(shù)據(jù)庫系統(tǒng)會使用Direct IO來繞過這層Page Cache并自行維護一個數(shù)據(jù)的Cache，而當Redis的持久化文件過大(尤其是快照文件)，并對其進行讀寫時，磁盤文件中的數(shù)據(jù)都會被加載到物理內(nèi)存中作為操作系統(tǒng)對該文件的一層Cache,而這層Cache的數(shù)據(jù)與Redis內(nèi)存中管理的數(shù)據(jù)實際是重復(fù)存儲的，雖然內(nèi)核在物理內(nèi)存緊張時會做Page Cache的剔除工作，但內(nèi)核很可能認為某塊Page Cache更重要，而讓你的進程開始Swap ,這時你的系統(tǒng)就會開始出現(xiàn)不穩(wěn)定或者崩潰了。我們的經(jīng)驗是當你的Redis物理內(nèi)存使用超過內(nèi)存總?cè)萘康?/5時就會開始比較危險了。

到此，相信大家對“Redis中redis-cluster需要注意哪些地方”有了更深的了解，不妨來實際操作一番吧！這里是億速云網(wǎng)站，更多相關(guān)內(nèi)容可以進入相關(guān)頻道進行查詢，關(guān)注我們，繼續(xù)學習！