redis緩存大小設置

A. Redis分布式緩存搭建

花了兩天時間整理了之前記錄的Redis單體與哨兵模式的搭建與使用，又補齊了集群模式的使用和搭建經驗，並對集群的一些個原理做了理解。

筆者安裝中遇到的一些問題：

如果make報錯，可能是沒裝gcc或者gcc++編輯器，安裝之 yum -y install gcc gcc-c++ kernel-devel ，有可能還是提示一些個c文件編譯不過，gcc -v查看下版本，如果不到5.3那麼升級一下gcc：

在 /etc/profile 追加一行 source /opt/rh/devtoolset-9/enable

scl enable devtoolset-9 bash

重新make clean, make

這回編譯通過了，提示讓你最好make test一下/

執行make test ，如果提示 You need tcl 8.5 or newer in order to run the Redis test

那就升級tcl， yum install tcl

重新make test，如果還有error就刪了目錄，重新tar包解壓重新make , make test

o/ All tests passed without errors! ，表示編譯成功。

然後make install即可。

直接運行命令： ./redis-server /usr/redis-6.0.3/redis.conf &

redis.conf 配置文件里 bind 0.0.0.0 設置外部訪問， requirepass xxxx 設置密碼。

redis高可用方案有兩種：

常用搭建方案為1主1從或1主2從+3哨兵監控主節點， 以及3主3從6節點集群。

（1）sentinel哨兵

/usr/redis-6.0.3/src/redis-sentinel /usr/redis-6.0.3/sentinel2.conf &

sentinel2.conf配置：

坑1：master節點也會在故障轉移後成為從節點，也需要配置masterauth

當kill master進程之後，經過sentinel選舉，slave成為了新的master，再次啟動原master，提示如下錯誤：

原因是此時的master再次啟動已經是slave了，需要向現在的新master輸入密碼，所以需要在master.conf
中配置：

坑2：哨兵配置文件要暴露客戶端可以訪問到的master地址

在 sentinel.conf 配置文件的 sentinel monitor mymaster 122.xx.xxx.xxx 6379 2 中，配置該哨兵對應的master名字、master地址和埠，以及達到多少個哨兵選舉通過認為master掛掉。其中master地址要站在redis訪問者（也就是客戶端）的角度、配置訪問者能訪問的地址，例如sentinel與master在一台伺服器（122.xx.xxx.xxx）上，那麼相對sentinel其master在本機也就是127.0.0.1上，這樣 sentinel monitor mymaster 127.0.0.1 6379 2 邏輯上沒有問題，但是如果另外伺服器上的springboot通過lettuce訪問這個redis哨兵，則得到的master地址為127.0.0.1，也就是springboot所在伺服器本機，這顯然就有問題了。

附springboot2.1 redis哨兵配置：

坑3：要注意配置文件.conf會被哨兵修改

redis-cli -h localhost -p 26379 ，可以登到sentinel上用info命令查看一下哨兵的信息。

曾經遇到過這樣一個問題，大致的信息如下

slaves莫名其妙多了一個，master的地址也明明改了真實對外的地址，這里又變成127.0.0.1 !
最後，把5個redis進程都停掉，逐個檢查配置文件，發現redis的配置文件在主從哨兵模式會被修改，master的配置文件最後邊莫名其妙多了一行replicaof 127.0.0.1 7001， 懷疑應該是之前配置錯誤的時候（見坑2）被哨兵動態加上去的！ 總之，實踐中一定要多注意配置文件的變化。

（2）集群

當數據量大到一定程度，比如幾十上百G，哨兵模式不夠用了需要做水平拆分，早些年是使用codis，twemproxy這些第三方中間件來做分片的，即 客戶端 -> 中間件 -> Redis server 這樣的模式，中間件使用一致性Hash演算法來確定key在哪個分片上。後來Redis官方提供了方案，大家就都採用官方的Redis Cluster方案了。

Redis Cluster從邏輯上分16384個hash slot，分片演算法是 CRC16(key) mod 16384 得到key應該對應哪個slot，據此判斷這個slot屬於哪個節點。

每個節點可以設置1或多個從節點，常用的是3主節點3從節點的方案。

reshard，重新分片，可以指定從哪幾個節點移動一些hash槽到另一個節點去。重新分片的過程對客戶端透明，不影響線上業務。

搭建Redis cluster

redis.conf文件關鍵的幾個配置：

啟動6個集群節點

[root@VM_0_11_centos redis-6.0.3]# ps -ef|grep redis
root 5508 1 0 21:25 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7001 [cluster]
root 6903 1 0 21:32 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7002 [cluster]
root 6939 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7003 [cluster]
root 6966 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7004 [cluster]
root 6993 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7005 [cluster]
root 7015 1 0 21:33 ? 00:00:00 /usr/redis-6.0.3/src/redis-server 0.0.0.0:7006 [cluster]

這時候這6個節點還是獨立的，要把他們配置成集群：

說明： -a xxxx 是因為筆者在redis.conf中配置了requirepass xxxx密碼，然後 --cluster-replicas 1 中的1表示每個master節點有1個從節點。

上述命令執行完以後會有一個詢問： Can I set the above configuration? yes同意自動做好的分片即可。

最後 All 16384 slots covered. 表示集群中16384個slot中的每一個都有至少有1個master節點在處理，集群啟動成功。

查看集群狀態：

坑1：暴露給客戶端的節點地址不對

使用lettuce連接發現連不上，查看日誌 Connection refused: no further information: /127.0.0.1:7002 ，跟之前哨兵配置文件sentinel.conf里邊配置master地址犯的錯誤一樣，集群啟動的時候帶的地址應該是提供給客戶端訪問的地址。

我們要重建集群：先把6個redis進程停掉，然後刪除 nodes-7001.conf 這些節點配置文件，刪除持久化文件 mp.rdb 、 appendonly.aof ，重新啟動6個進程，在重新建立集群：

然後，還是連不上，這次報錯 connection timed out: /172.xx.0.xx:7004 ，發現連到企鵝雲伺服器的內網地址上了！

解決辦法，修改每個節點的redis.conf配置文件，找到如下說明：

所以增加配置：

然後再重新構建集群，停進程、改配置、刪除節點文件和持久化文件、啟動進程、配置集群。。。再來一套（累死了）

重新使用Lettuce測試，這次終於連上了！

坑2：Lettuce客戶端在master節點故障時沒有自動切換到從節點

name這個key在7002上，kill這個進程模擬master下線，然後Lettuce一直重連。我們期望的是應該能自動切換到其slave 7006上去，如下圖：

重新啟動7002進程，

7006已成為新master，7002成為它的slave，然後Lettuce也能連接上了。
解決辦法，修改Lettuce的配置：

筆者用的是springboot 2.1 spring-boot-starter-data-redis 默認的Lettuce客戶端，當使用Redis cluster集群模式時，需要配置一下 RedisConnectionFactory 開啟自適應刷新來做故障轉移時的自動切換從節點進行連接。

重新測試：停掉master 7006，這次Lettuce可以正常切換連到7002slave上去了。（仍然會不斷的在日誌里報連接錯誤，因為需要一直嘗試重連7006，但因為有7002從節點頂上了、所以應用是可以正常使用的）

Redis不保證數據的強一致性

Redis並不保證數據的強一致性，也就是取CAP定理中的AP

關於一致性Hash演算法，可以參考 一致性Hash演算法 - (jianshu.com)

Redis cluster使用的是hash slot演算法，跟一致性Hash演算法不太一樣，固定16384個hash槽，然後計算key落在哪個slot里邊（計算key的CRC16值再對16384取模），key找的是slot而不是節點，而slot與節點的對應關系可以通過reshard改變並通過gossip協議擴散到集群中的每一個節點、進而可以為客戶端獲知，這樣key的節點定址就跟具體的節點個數沒關系了。也同樣解決了普通hash取模演算法當節點個數發生變化時，大量key對應的定址都發生改動導致緩存失效的問題。

比如集群增加了1個節點，這時候如果不做任何操作，那麼新增加的這個節點上是沒有slot的，所有slot都在原來的節點上且對應關系不變、所以沒有因為節點個數變動而緩存失效，當reshard一部分slot到新節點後，客戶端獲取到新遷移的這部分slot與新節點的對應關系、定址到新節點，而沒遷移的slot仍然定址到原來的節點。

關於熱遷移，猜想，內部應該是先做復制遷移，等遷移完了，再切換slot與節點的對應關系，復制沒有完成之前仍按照原來的slot與節點對應關系去原節點訪問。復制結束之後，再刪除原節點上已經遷移的slot所對應的key。

與哨兵模式比較類似，當1個節點發現某個master節點故障了、會對這個故障節點進行pfail主觀宕機，然後會通過gossip協議通知到集群中的其他節點、其他節點也執行判斷pfail並gossip擴散廣播這一過程，當超過半數節點pfail時那麼故障節點就是fail客觀宕機。接下來所有的master節點會在故障節點的從節點中選出一個新的主節點，此時所有的master節點中超過半數的都投票選舉了故障節點的某個從節點，那麼這個從節點當選新的master節點。

所有節點都持有元數據，節點之間通過gossip這種二進制協議進行通信、發送自己的元數據信息給其他節點、故障檢測、集群配置更新、故障轉移授權等等。

這種去中心化的分布式節點之間內部協調，包括故障識別、故障轉移、選主等等，核心在於gossip擴散協議，能夠支撐這樣的廣播協議在於所有的節點都持有一份完整的集群元數據，即所有的節點都知悉當前集群全局的情況。

Redis高可用方案 - (jianshu.com)

面試題:Redis 集群模式的工作原理能說一下么 - 雲+社區 - 騰訊雲 (tencent.com)

深度圖解Redis Cluster原理 - detectiveHLH - 博客園 (cnblogs.com)

Redis學習筆記之集群重啟和遇到的坑-阿里雲開發者社區 (aliyun.com)

雲伺服器Redis集群部署及客戶端通過公網IP連接問題

B. window下配置redis 能夠緩存多少數據

Redis在分布式應用中占據著越來越重要的地位，短短的幾萬行代碼，實現了一個高性能的數據存儲服務。最近mp中心的cm8集群出現過幾次redis超時的情況，但是查看redis機器的相關內存都沒有發現內存不夠，或者內存發生交換的情況，查看redis源碼之後，發現在某些情況下redis會出現超時的狀況，相關細節如下。1. 網路。Redis的處理與網路息息相關，如果網路出現閃斷則容易發生redis超時的狀況。如果出現這種狀況首先應查看redis機器網路帶寬信息，判斷是否有閃斷情況發生。
2. 內存。redis所有的數據都放在內存里，當物理內存不夠時，linux os會使用swap內存，導致內存交換發生，這時如果有redis調用命令就會產生redis超時。這里可以通過調整/proc/sys/vm/swappiness參數，來設置物理內存使用超過多少就會進行swap。

C. redis緩存怎麼弄

redis是類似Key_Value形式的快速緩存服務。類型較豐富，可以保存對象、列表等，支持的操作也很豐富，屬於內存資料庫，且可以把內存中的數據及時或定時的寫入到磁碟。可設置過期自動刪除，速度快，易於使用。

D. 我用redis緩存了一些數據，我想查看redis緩存多KB的數據，占內存多少

1，增加內存； 2，數據分流，即分散到多個電腦上面。可以按一致性哈稀演算法分布。 3，設置緩存數據的有效期，對於不重要的數據盡量不要緩存。或緩存時間可以短一些。

E. 緩存-redis 三種模式搭建和運行原理

標簽： redis 緩存 主從 哨兵 集群

本文簡單的介紹redis三種模式在linux的安裝部署和數據存儲的總結，希望可以相互交流相互提升。

對於Centos7在安裝redis之前需要進行一些常用工具的安裝：

關閉防火牆

正式安裝redis

在redis進行maketest時候會出現一系列的異常，有如下解決方案：

用redis-server啟動一下redis，做一些實驗沒什麼意義。

要把redis作為一個系統的daemon進程去運行的，每次系統啟動，redis進程一起啟動，操作不走如下：

RDB和AOF是redis的一種數據持久化的機制。 持久化 是為了避免系統在發生災難性的系統故障時導致的系統數據丟失。我們一般會將數據存放在本地磁碟，還會定期的將數據上傳到雲伺服器。
RDB 是redis的snapshotting，通過redis.conf中的save配置進行設置，如 save 60 1000:

AOF 是以appendonly方式進行數據的儲存的，開啟AOF模式後，所有存進redis內存的數據都會進入os cache中,然後默認1秒執行一次fsync寫入追加到appendonly.aof文件中。一般我們配置redis.conf中的一下指令：

AOF和RDB模式我們一般在生產環境都會打開，一般而言，redis服務掛掉後進行重啟會優先家在aof中的文件。

當啟動一個slave node的時候，它會發送一個PSYNC命令給master node,如果這是slave node重新連接master node，那麼master node僅僅會復制給slave部分缺少的數據;否則如果是slave node第一次連接master node，那麼會觸發一次full resynchronization;
開始full resynchronization的時候，master會啟動一個後台線程，開始生成一份RDB快照文件，同時還會將從客戶端收到的所有寫命令緩存在內存中。RDB文件生成完畢之後，master會將這個RDB發送給slave，slave會先寫入本地磁碟，然後再從本地磁碟載入到內存中。然後master會將內存中緩存的寫命令發送給slave，slave也會同步這些數據。
slave node如果跟master node有網路故障，斷開了連接，會自動重連。master如果發現有多個slave node都來重新連接，僅僅會啟動一個rdb save操作，用一份數據服務所有slave node。

從redis 2.8開始，就支持主從復制的斷點續傳，如果主從復制過程中，網路連接斷掉了，那麼可以接著上次復制的地方，繼續復制下去，而不是從頭開始復制一份。

master node會在內存中常見一個backlog，master和slave都會保存一個replica offset還有一個master id，offset就是保存在backlog中的。如果master和slave網路連接斷掉了，slave會讓master從上次的replica offset開始繼續復制,但是如果沒有找到對應的offset，那麼就會執行一次resynchronization。

master在內存中直接創建rdb，然後發送給slave，不會在自己本地落地磁碟了，可以有如下配置：

slave不會過期key，只會等待master過期key。如果master過期了一個key，或者通過LRU淘汰了一個key，那麼會模擬一條del命令發送給slave。

在redis.conf配置文件中，上面的參數代表至少需要3個slaves節點與master節點進行連接，並且master和每個slave的數據同步延遲不能超過10秒。一旦上面的設定沒有匹配上，則master不在提供相應的服務。

sdown達成的條件很簡單，如果一個哨兵ping一個master，超過了 is-master-down-after-milliseconds 指定的毫秒數之後，就主觀認為master宕機
sdown到odown轉換的條件很簡單，如果一個哨兵在指定時間內，收到了 quorum 指定數量的其他哨兵也認為那個master是sdown了，那麼就認為是odown了，客觀認為master宕機

如果一個slave跟master斷開連接已經超過了down-after-milliseconds的10倍，外加master宕機的時長，那麼slave就被認為不適合選舉為master

(down-after-milliseconds * 10) + milliseconds_since_master_is_in_SDOWN_state

每次一個哨兵要做主備切換，首先需要quorum數量的哨兵認為odown，然後選舉出一個slave來做切換，這個slave還得得到majority哨兵的授權，才能正式執行切換；

（2）SENTINEL RESET *，在所有sentinal上執行，清理所有的master狀態
（3）SENTINEL MASTER mastername，在所有sentinal上執行，查看所有sentinal對數量是否達成了一致

4.3.2 slave的永久下線

讓master摘除某個已經下線的slave：SENTINEL RESET mastername，在所有的哨兵上面執行.

redis的集群模式為了解決系統的橫向擴展以及海量數據的存儲問題，如果你的數據量很大，那麼就可以用redis cluster。
redis cluster可以支撐N個redis master,一個master上面可以掛載多個slave，一般情況我門掛載一個到兩個slave，master在掛掉以後會主動切換到slave上面，或者當一個master上面的slave都掛掉後，集群會從其他master上面找到冗餘的slave掛載到這個master上面，達到了系統的高可用性。

2.1 redis cluster的重要配置

2.2 在三台機器上啟動6個redis實例

將上面的配置文件，在/etc/redis下放6個，分別為: 7001.conf，7002.conf，7003.conf，7004.conf，7005.conf，7006.conf

每個啟動腳本內，都修改對應的埠號

2.3 創建集群

解決辦法是 先安裝rvm，再把ruby版本提升至2.3.3

使用redis-trib.rb命令創建集群

--replicas: 表示每個master有幾個slave

redis-trib.rb check 192.168.31.187:7001 查看狀體

3.1 加入新master

以上相同配置完成後，設置啟動腳本進行啟動；然後用如下命令進行node節點添加：

3.2 reshard一些數據過去

3.3 添加node作為slave

3.4 刪除node

F. redis緩存數據，內存占滿，怎麼解決

1，增加內存；
2，數據分流，即分散到多個電腦上面。可以按一致性哈稀演算法分布。
3，設置緩存數據的有效期，對於不重要的數據盡量不要緩存。或緩存時間可以短一些。

G. redis緩存怎麼在spring中配置

首先可以在多台伺服器裝memcached，啟動時分別指定容量和埠
訪問時採用集群方式訪問，只需要spring配置文件裡面配置即可
value可以放任何對象，包括集合
每個鍵值的生命周期可以在放入時獨立設置
類庫可以用spymemcached

數據更新方式可以在後台的定時任務中執行

下面是spring mvc中配置：

<beanid="memcachedClient"class="net.spy.memcached.spring.MemcachedClientFactoryBean">
<propertyname="servers"value="伺服器A：埠，伺服器B：埠，伺服器C：埠"/>
<propertyname="protocol"value="BINARY"/>
<propertyname="transcoder">
<beanclass="net.spy.memcached.transcoders.SerializingTranscoder">
<propertyname="compressionThreshold"value="1024"/>
</bean>
</property>
<propertyname="opTimeout"value="2000"/>
<propertyname="timeoutExceptionThreshold"value="1998"/>
<propertyname="locatorType"value="CONSISTENT"/>
<propertyname="hashAlg">
<valuetype="net.spy.memcached.DefaultHashAlgorithm">KETAMA_HASH</value>
</property>
<propertyname="failureMode"value="Redistribute"/>
<propertyname="useNagleAlgorithm"value="false"/>
</bean>

H. 如何設置資料庫緩存

內存資料庫有現成的redis，高效存取鍵值對，鍵設為你的查詢條件，值設為你的查詢結果轉為字元串
查詢時先從redis取，沒有再查資料庫，並且設置redis的過期時間，這種方式需要項目對實時性要求不高，這樣你才能用緩存，而且如果你的項目沒有明顯的熱點，即沒有某些內容確定會多次被查到，那你緩存就不會命中，添加緩存反而影響你得速度
redis是一種nosql的內存資料庫，感興趣你可以了解一下，優點就是性能強勁
數據查詢請求多就把結果緩存下來，你查資料庫再快也沒有直接把結果從內存讀出來快
同樣的sql請求只有第一次查資料庫，之後通通讀內存
或者你乾脆藉助這種思想，創建一個全局的map對象，然後查詢條件作key
，結果作value，就省去了了解redis的過程，把整個資料庫裝內存不太科學，你有多少條數據啊

I. Redis緩存雪崩就這么簡單

在實際項目開發中，我們都知道Redis不可能把所有的數據都緩存起來( 內存昂貴且有限 )，所以Redis需要對數據設置過期時間，並採用的是惰性刪除+定期刪除兩種策略對過期鍵刪除。

如果緩存數據 設置的過期時間是相同 的，並且Redis恰好將這部分數據全部刪光了。這就會導致在這段時間內，這些緩存 同時失效 ，全部請求到資料庫中。

這就是緩存雪崩 ：

緩存雪崩如果發生了，很可能就把我們的資料庫 搞垮 ，導致整個服務癱瘓，造成的後果很嚴重。

對緩存數據設置相同的過期時間，導致某段時間內緩存失效。」

對於「Redis掛掉了」，我們可以有以下的思路：

J. java怎樣配置redis佔用多大內存

Redis的配置
daemonize 如果需要在後台運行，把該項改為yes
pidfile 配置多個pid的地址，默認在/var/run/redis.pid
bind 綁定ip，設置後只接受自該ip的請求
port 監聽埠，默認為6379
timeout 設置客戶端連接時的超時時間，單位為秒
loglevel 分為4級，debug、verbose、notice、warning
logfile 配置log文件地址
databases 設置資料庫的個數，默認使用的資料庫為0
save 設置redis進行資料庫鏡像的頻率，保存快照的頻率，第一個*表示多長時間， 第三個*表示執行多少次寫操作。在一定時間內執行一定數量的寫操作時，自動保存快照。可設置多個條件。
rdbcompression 在進行鏡像備份時，是否進行壓縮
Dbfilename 鏡像備份文件的文件名
Dir 資料庫鏡像備份的文件放置路徑
Slaveof 設置資料庫為其他資料庫的從資料庫
Masterauth 主資料庫連接需要的密碼驗證
Requirepass 設置登錄時需要使用的密碼
Maxclients 限制同時連接的客戶數量
Maxmemory 設置redis能夠使用的最大內存
Appendonly 開啟append only模式
appendfsync 設置對appendonly.aof文件同步的頻率
vm-enabled 是否虛擬內存的支持
vm-swap-file 設置虛擬內存的交換文件路徑
vm-max-memory 設置redis使用的最大物理內存大小
vm-page-size 設置虛擬內存的頁大小
vm-pages 設置交換文件的總page數量
vm-max-threads 設置VMIO同時使用的線程數量
glueoutputbuf 把小的輸出緩存存放在一起
hash-max-zipmap-entries 設置hash的臨界值
activerehashing 重新has