本地和redis緩存框架

❶ SpringBoot進階之緩存中間件Redis

大家好，一直以來我都本著 用最通俗的話理解核心的知識點， 我認為所有的難點都離不開 「基礎知識」 的鋪墊

「大佬可以繞過 ~」

本節給大家講講 「java的SpringBoot框架」 , 之前我們學習的都是java的基礎知識和底層提供的一些能力，我們日常工作都是在寫介面。在我們在產品開發中，一般我們都會選擇比較穩定的框架來幫我們加速開發，不會自己去造輪子，而在java眾多框架中，spring框架表現的非常好，大部分公司都會首選它作為開發框架，而至今，大部分企業都是以 springboot 來構建項目了,一個穩健的系統需要引入穩定的技術~

如果你是一路看過來的，很高興你能夠耐心看完。前幾期都是帶大家學習了 SpringBoot 的基礎使用以及集成 mybatis 開發，這也是我們寫業務的基礎，如果你還不熟悉這些，請先看完它們。接下來的幾期內容將會帶大家進階使用，會先講解基礎 中間件 的使用和一些場景的應用，或許這些技術你聽說過，沒看過也沒關系，我會帶大家一步一步的入門，耐心看完你一定會有 收獲 ,本期將會給大家講解最熱門的緩存中間件技術 Redis ,同樣的，我們集成到 Springboot 中。最近github可能會被牆，所以我把源碼放到了國內gitee上,本節我們依然使用上期的代碼

Redis 是由義大利人Salvatore Sanfilippo（網名：antirez）開發的一款內存高速緩存資料庫。全稱叫 Remote Dictionary Server（遠程數據服務） 是由 C語言 編寫的，Redis是一個 key-value 存儲系統，它支持豐富的數據類型，如： string、list、set、zset(sorted set)、hash 。

它本質上是一種鍵值對資料庫，我們之前學習的 mysql 它是持久層的關系型資料庫,而 redis 它的存儲主要存在 內存 中。我們都知道在 內存 中的數據讀取是非常快的，就好比你把一個變數存到磁碟讀取和直接放到代碼中運行，肯定是在代碼中拿到的速度快，因為運行時期，都是直接存到內存的。

給大家總結一下：

有了基本的概念之後，我們下面進行環境搭建,在學習階段，安裝 redis 很簡單,生產環境一般我們也會選擇雲產品，一切為了服務保障,雖說它只是做緩存用，但也是系統的一把 保護傘

如果你是 mac 用戶，你可以運行如下命令:

安裝完成後會提示你運行命令，運行即可。

win 用戶也很簡單，直接下載 redis 軟體，雙擊運行即可，運行之後它會有一個小方塊的圖案，和 locahost:6379 的log,說明運行成功了。初始階段沒有配置的 redis 默認 host 就是本地, port 就是 6379 , 而且是 沒有密碼 就可以訪問的。

推薦一個客戶端軟體 Redis Desktop Manager ，它是 redis 的客戶端界面軟體,方便麵我們學習的時候 清理緩存 使用,生產慎連。

我們不給大家講它的基本命令使用，它也有語法，可以通過類似命令執行,如果想學習的小夥伴，可以自行搜索。本期重點內容是在 sprinboot 中的使用,我們平時開發不可能是去命令行里敲的，都是代碼里執行，而目前市面上有很多封裝好的庫，我們可以直接調用它的方法，很方便的就可以操作它了，不用記一些繁瑣的命令,下面我們就實際操作一下:

修改 pom.xml

修改 application.yml :

redis 默認是有 16 個庫,不是 15 個啊，從 0 開始算的,我們隨便連一個

通過代碼很好理解, 首先需要引入 StringRedisTemplate ,然後需要設置一個 key ,那麼思考一下，這個 key 允許重復嗎

我們進客戶端看一下，發現 key 還是只有一個,但是值變成了新的值了，所以可以得知 key 是唯一的，我們重新設置的時候相當於刷新了它。

在 redis 中刪除緩存有兩種方式，一種是自我消亡，也就是 過期 銷毀,還有有一種是 主動 銷毀，我們先看一下，過期時間如何設置

我們設置了 10s 後過期,過完10s後發現，這個```key data``消失了。我們在看看如何主動刪除

我們可以利用 Redis 做一個計數器，實現自增功能,你可以用它做網站訪問統計

通常做法，我們會把它封裝一下，後續使用直接引入封裝好的即可，把它直接交給 Springboot容器 管理

其實這個類，你還可以繼續進一步封裝，比如約束 key 的規范，約束過期時間，約束數據類型等等，這一切也都是為了規范和後期維護，防止濫用緩存

緩存的主要場景是用於解決熱點數據問題，因為這些數據是訪問頻率比較高的，當大量的請求進來, mysql 可能壓力很大，這樣一來，數據查詢效率就很慢，用戶肯不高興等了，這樣用戶體驗很不好。所以我們一般做法，都是把這些熱點數據放到緩存里，因為緩存讀取速度很快。當有新數據的時候，我們再及時更新它，一般流程是先查詢緩存，查到了直接返回緩存數據，查不到再走資料庫，然後再刷回緩存。

但是並發足夠大的時候，還是會暴露出很多問題，比如面試常問的一些高頻問題 緩存雪崩、緩存穿透、緩存雪崩 ,這些問題後邊會給大家專門講，和如何去防範。所以總的來說，引入任何一門技術並不是萬事大吉，還需我們不斷的在實踐中積累經驗

本期到這里就結束了，總結一下，我們了解了什麼是 redis ，以及在 springboot 中如何去使用它們，很簡單，沒什麼復雜的東西。但這里想多說一點的是，緩存的設計卻是很復雜的，因為工具是死的，人是活的，我們如何正確設計，需要我們在項目中不斷的積累。

我們之前教大家查詢列表數據，都是所有數據返回，還沒有教大家如何去做分頁，下期將帶大家學習一下 mybatis 分頁插件的使用 ，下期不見不散, 關注我，不迷路~

❷ Redis詳解——概述/下載安裝

互聯網需求的3高： 高並發，高可擴，高性能。

Redis 是一種運行速度很快，並發性能很強，並且運行在內存上的NoSql（not only sql）資料庫

NoSQL資料庫 和 傳統資料庫 相比的優勢：

NoSQL資料庫無需事先為要存儲的數據建立欄位，隨時可以存儲自定義的數據格式。

而在關系資料庫里，增刪欄位是一件非常麻煩的事情。如果是非常大數據量的表，增加欄位 簡直就是一個噩夢。

Redis的常用使用場景：

緩存 ，毫無疑問這是Redis當今最為人熟知的使用場景。在提升伺服器性能方面非常有效；一 些頻繁被訪問的數據，經常被訪問的數據如果放在關系型資料庫，每次查詢的開銷都會很 大，而放在redis中，因為redis 是放在內存中的可以很高效的訪問

排行榜 ，在使用傳統的關系型資料庫（mysql oracle 等）來做這個事兒，非常的麻煩，而利 用Redis的SortSet(有序集合)數據結構能夠簡單的搞定；

好友關系 ，利用集合的一些命令，比如求交集、並集、差集等。可以方便搞定一些共同好 友、共同愛好之類的功能；

Session共享 ，以jsp為例，默認Session是保存在伺服器的文件中，如果是集群服務，同一個 用戶過來可能落在不同機器上，這就會導致用戶頻繁登陸；採用Redis保存Session後，無論 用戶落在那台機器上都能夠獲取到對應的Session信息。

下載： redis：http://www.redis.net.cn/ 圖形工具：https://redisdesktop.com/download

安裝（linux）

上傳tar.gz包，並解壓：tar -zxvf redis-5.0.4.tar.gz

安裝gcc：yum -y install gcc （忘記是否安裝過，可以使用 gcc -v 命令查看gcc版本，如果沒有安裝過，會提示命令不存在）

進入redis目錄，進行編譯：make

編譯之後，開始安裝：make install

後台運行方式—— redis默認不會使用後台運行，如果你需要，修改配置文件daemonize=yes，當你後台服務啟動的 時候，會寫成一個進程文件運行

vim /opt/redis-5.0.4/redis.conf

以配置文件的方式啟動:

cd /usr/local/bin

redis-server /opt/redis-5.0.4/redis.conf

關閉資料庫:

單實例關閉 ——redis-cli shutdown

多實例關閉 ——dis-cli -p 6379 shutdown 默認的埠6379，如改過，更換埠

❸ redis源碼解讀：單線程的redis是如何實現高速緩存的

redis可能是最近幾年最火的緩存資料庫方案了，在各個高並發領域都有應用。

這篇文章，我們將從源代碼的角度來分析一下，為何如此一個高性能，高應用的緩存，會是單線程的方案，當然一個方案的高性能，高並發是多方面的綜合因素，其它的因素我們將在後續解讀。後續分析主要以LINUX操作系統為基礎，這也是redis應用最廣的平台。

單線程最大的受限是什麼？就是CPU，現在伺服器一般已經是多CPU，而單線程只能使用到其中的一個核。

redis作為一個網路內存緩存資料庫，在實現高性能時，主要有4個點。

1.網路高並發，高流量的數據處理。

一個非同步，高效，且對CPU要求不高的網路模型，這個模型主要是由OS來提供的，目前在LINUX最主流使用的是EPOLL，這個網上介紹很多，主要是基於事件驅動的一個非同步模型。

2.程序內部的合理構架，調用邏輯，內存管理。

redis在採用純C實現時，整體調用邏輯很短，但在內存方面，適當的合並了一些對象和對齊，比如sds等，在底層使用了內存池，在不同情況下使用的不太一樣。

但整體處理上沒有NGINX的內池設計巧妙，當然二者不太一樣，NGINX是基於請求釋放的邏輯來設計的，因此針對請求，可以一次申請大塊，分量使用，再最後統一釋放。

3.數據復制的代價，不管是讀取數據或是寫入數據，一般都是需要有數據復制的過程。

數據復制其實就是一次內存，真正的代價是在於存在大VALUE，當value值長度超過16KB時，性能會開始下降。因為單線程的原因，如果存在一個超大VALUE，比如20MB，則會因為這個請求卡住整個線程，導致後續的請求進不來，雖然後面的請求是能快速處理的小請求。

4.redis中數據結構中演算法的代價，有些結構在大數據量時，代價是很高的。

很多時間，大家忽略了演算法的運算代碼，因為像memcached等這類是完全的KV緩存，不存在什麼演算法，除了一個KEY的查找定位HASH演算法。

而redis不一樣，提供了不少高階的數據對象，這些對象具有上層的一些演算法能力，而這些能力是需要比如GEO模塊。

❹ 常用的緩存技術

第一章 常用的緩存技術
1、常見的兩種緩存

本地緩存：不需要序列化，速度快，緩存的數量與大小受限於本機內存
分布式緩存：需要序列化，速度相較於本地緩存較慢，但是理論上緩存的數量與大小無限（因為緩存機器可以不斷擴展）
2、本地緩存

Google guava cache：當下最好用的本地緩存
Ehcache：spring默認集成的一個緩存，以spring cache的底層緩存實現類形式去操作緩存的話，非常方便，但是欠缺靈活，如果想要靈活使用，還是要單獨使用Ehcache
Oscache：最經典簡單的頁面緩存
3、分布式緩存

memcached：分布式緩存的標配
Redis：新一代的分布式緩存，有替代memcached的趨勢
3.1、memcached

經典的一致性hash演算法
基於slab的內存模型有效防止內存碎片的產生（但同時也需要估計好啟動參數，否則會浪費很多的內存）
集群中機器之間互不通信（相較於Jboss cache等集群中機器之間的相互通信的緩存，速度更快<--因為少了同步更新緩存的開銷，且更適合於大型分布式系統中使用）
使用方便（這一點是相較於Redis在構建客戶端的時候而言的，盡管redis的使用也不困難）
很專一（專做緩存，這一點也是相較於Redis而言的）
3.2、Redis

可以存儲復雜的數據結構（5種）
strings-->即簡單的key-value，就是memcached可以存儲的唯一的一種形式，接下來的四種是memcached不能直接存儲的四種格式（當然理論上可以先將下面的一些數據結構中的東西封裝成對象，然後存入memcached，但是不推薦將大對象存入memcached，因為memcached的單一value的最大存儲為1M，可能即使採用了壓縮演算法也不夠，即使夠，可能存取的效率也不高，而redis的value最大為1G）
hashs-->看做hashTable
lists-->看做LinkedList
sets-->看做hashSet，事實上底層是一個hashTable
sorted sets-->底層是一個skipList
有兩種方式可以對緩存數據進行持久化
RDB
AOF
事件調度
發布訂閱等
4、集成緩存

專指spring cache，spring cache自己繼承了ehcache作為了緩存的實現類，我們也可以使用guava cache、memcached、redis自己來實現spring cache的底層。當然，spring cache可以根據實現類來將緩存存在本地還是存在遠程機器上。

5、頁面緩存

在使用jsp的時候，我們會將一些復雜的頁面使用Oscache進行頁面緩存，使用非常簡單，就是幾個標簽的事兒；但是，現在一般的企業，前台都會使用velocity、freemaker這兩種模板引擎，本身速度就已經很快了，頁面緩存使用的也就很少了。

總結：

在實際生產中，我們通常會使用guava cache做本地緩存+redis做分布式緩存+spring cache就集成緩存（底層使用redis來實現）的形式
guava cache使用在更快的獲取緩存數據，同時緩存的數據量並不大的情況
spring cache集成緩存是為了簡單便捷的去使用緩存（以註解的方式即可），使用redis做其實現類是為了可以存更多的數據在機器上
redis緩存單獨使用是為了彌補spring cache集成緩存的不靈活
就我個人而言，如果需要使用分布式緩存，那麼首先redis是必選的，因為在實際開發中，我們會緩存各種各樣的數據類型，在使用了redis的同時，memcached就完全可以舍棄了，但是現在還有很多公司在同時使用memcached和redis兩種緩存。

❺ 緩存-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

❻ SpringBoot整合SpringSeesion實現Redis緩存

使用Spring Boot開發項目時我們經常需要存儲Session，因為Session中會存一些用戶信息或者登錄信息。傳統的web服務是將session存儲在內存中的，一旦服務掛了，session也就消失了，這時候我們就需要將session存儲起來，而Redis就是用來緩存seesion的一種非關系型資料庫，我們可以通過配置或者註解的方式將Spring Boot和Redis整合。而在分布式系統中又會涉及到session共享的問題，多個服務同時部署時session需要共享，Spring Session可以幫助我們實現這一功能。將Spring Session集成到Spring Boot框架中並使用Redis進行緩存是目前非常流行的解決方案，接下來就跟著我一起學習吧。

工具/材料

IntelliJ IDEA

首先我們創建一個Spring Boot 2.x的項目，在application.properties配置文件中添加Redis的配置，Spring和Redis的整合可以參考我其他的文章，此處不再詳解。我們設置服務埠server.port為8080埠用於啟動第一個服務。

接下來我們需要在pom文件中添加spring-boot-starter-data-redis和spring-session-data-redis這兩個依賴，spring-boot-starter-data-redis用於整合Spring Boot和Redis，spring-session-data-redis集成了spring-session和spring-data-redis，提供了session與redis的整合方案。

接下來我們創建一個配置類RedisSessionConfig，這個類使用@Configuration註解表明這是一個配置類。在這個類上我們同時添加註解@EnableRedisHttpSession，表示開啟Redis的Session管理。如果需要設置失效時間可以使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds = 3600)表示一小時後失效。若同時需要設置Redis的命名空間則使用@EnableRedisHttpSession(maxInactiveIntervalInSeconds=3600, redisNamespace="{spring.session.redis.namespace}") ，其中{spring.session.redis.namespace}表示從配置文件中讀取這個命名空間。

配置完成後我們寫一個測試類SessionController，在這個類中我們寫兩個方法，一個方法用於往session中存數據，一個用於從session中取數據，代碼如下圖所示，我們存取請求的url。啟動類非常簡單，一般都是通用的，我們創建一個名為SpringbootApplication的啟動類，使用main方法啟動。

接下來我們使用Postman分別請求上面兩個介面，先請求存數據介面，再請求取數據介面，結果如下圖所示，我們可以看到數據已從redis中取出。另外需要注意sessionId的值，這是session共享的關鍵。

為了驗證兩個服務是否共享了session，我們修改項目的配置文件，將服務埠server.port改為8090，然後再啟動服務。此時我們不必在請求存數據的介面，只需要修改請求埠號再一次請求取數據的介面即可。由下圖可以看到兩次請求的sessionId值相同，實現了session的共享。

以上我們完成了SpringBoot整合SpringSeesion實現Redis緩存的功能，在此我們還要推薦一個Redis的可視化工具RedisDesktopManager，我們可以配置Redis資料庫的連接，然後便可以非常直觀地查看到存儲到Redis中的session了，如下圖所示，session的命名空間是share，正是從配置文件中讀取到的。

特別提示

如果Redis伺服器是很多項目共用的，非常建議配置命名空間，否則同時打開多個項目的瀏覽器頁面可能會導致session錯亂的現象。

❼ 面試官要求我研究一個Java緩存框架，哪個比較好

緩存框架有ehcache、redis、memcached
現在大公司用的比較多的是memcached和redis，這也是分布式系統開發中常用的緩存中間件
個人比較推薦用redis，因為redis對於可支持的數據類型比memcached要多，而且redis是一個可持久化的緩存框架，在使用的時候還可以嘗試搭建redis集群環境。
如果你對redis深入研究，相信你的面試官會很樂意要你的。

❽ redis緩存什麼情況下用怎末使用

redis是一個key-value存儲系統。和Memcached類似，它支持存儲的value類型相對更多，包括string(字元串)、list(鏈表)、set(集合)、zset(sorted set --有序集合)和hash（哈希類型）。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作，而且這些操作都是原子性的。在此基礎上，redis支持各種不同方式的排序。與memcached一樣，為了保證效率，數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件，並且在此基礎上實現了master-slave(主從)同步。
Redis 是一個高性能的key-value資料庫。 redis的出現，很大程度補償了memcached這類key/value存儲的不足，在部 分場合可以對關系資料庫起到很好的補充作用。它提供了Java，C/C++，C#，PHP，JavaScript，Perl，Object-C，Python，Ruby，Erlang等客戶端，使用很方便。
Redis支持主從同步。數據可以從主伺服器向任意數量的從伺服器上同步，從伺服器可以是關聯其他從伺服器的主伺服器。這使得Redis可執行單層樹復制。存檔可以有意無意的對數據進行寫操作。由於完全實現了發布/訂閱機制，使得從資料庫在任何地方同步樹時，可訂閱一個頻道並接收主伺服器完整的消息發布記錄。同步對讀取操作的可擴展性和數據冗餘很有幫助。

❾ 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連接問題

❿ Spring本地緩存的使用方法

我們現在在用的Spring Cache，可以直接看Spring Boot提供的緩存枚舉類，有如下這些：

EhCache：一個純Java的進程內緩存框架，所以也是基於本地緩存的。(注意EhCache2.x和EhCache3.x相互不兼容)。
Redis：分布式緩存，只有Client-Server(CS)模式，Java一般使用Jedis/Luttuce來操縱。
Hazelcast：基於內存的數據網格。雖然它基於內存，但是分布式應用程序可以使用Hazelcast進行分布式緩存、同步、集群、處理、發布/訂閱消息等。
Guava：它是Google Guava工具包中的一個非常方便易用的本地化緩存實現，基於LRU（最近最少使用）演算法實現，支持多種緩存過期策略。在Spring5.X以後的版本已經將他標記為過期了。
Caffeine：是使用Java8對Guava緩存的重寫版本，在Spring5中將取代了Guava，支持多種緩存過期策略。
SIMPLE：使用ConcurrentMapCacheManager，因為不支持緩存過期時間，所以做本地緩存基本不考慮該方式。

關於分布式緩存，我們需要後面會專門討論Redis的用法，這里只看本地緩存。性能從高到低，依次是Caffeine，Guava，ConcurrentMapCacheManager，其中Caffeine在讀寫上都快了Guava近一倍。

這里我們只討論在Spring Boot裡面怎麼整合使用Caffeine和EhCache。

主要有以下幾個步驟：

1)加依賴包：

2)配置緩存：
這里有兩種方法，通過文件配置或者在配置類裡面配置，先看一下文件配置，我們可以寫一個properties文件，內容像這樣：

然後還要在主類中加上@EnableCaching註解：

另外一種更靈活的方法是在配置類中配置：

應用類：

測試類：

導入依賴包，分為2.x版本和3.x版本。
其中2.x版本做如下導入：

3.x版本做如下導入：

導包完成後，我們使用JCacheManagerFactoryBean + ehcache.xml的方式配置：

參考資料：

https://blog.csdn.net/f641385712/article/details/94982916

http://www.360doc.com/content/17/1017/20/16915_695800687.shtml