當前位置:首頁 » 硬碟大全 » 網站redis緩存
擴展閱讀
webinf下怎麼引入js 2023-08-31 21:54:13
堡壘機怎麼打開web 2023-08-31 21:54:11

網站redis緩存

發布時間: 2022-10-03 06:26:18

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

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

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

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

這就是緩存雪崩

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

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

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

3. Redis的主要功能

緩存:這應該是 Redis 最主要的功能了,也是大型網站必備機制,合理地使用緩存不僅可以加 快數據的訪問速度,而且能夠有效地降低後端數據源的壓力。共享Session:對於一些依賴 session 功能的服務來說,如果需要從單機變成集群的話,可以選擇 redis 來統一管理 session。消息隊列系統:消息隊列系統可以說是一個大型網站的必備基礎組件,因為其具有業務 解耦、非實時業務削峰等特性。Redis提供了發布訂閱功能和阻塞隊列的功 能,雖然和專業的消息隊列比還不夠足夠強大,但是對於一般的消息隊列功 能基本可以滿足。比如在分布式爬蟲系統中,使用 redis 來統一管理 url隊列。分布式鎖:在分布式服務中。可以利用Redis的setnx功能來編寫分布式的鎖,雖然這個可能不是太常用。 當然還有諸如排行榜、點贊功能都可以使用 Redis 來實現,但是 Redis 也不是什麼都可以做,比如數據量特別大時,不適合 Redis,我們知道 Redis 是基於內存的,雖然內存很便宜,但是如果你每天的數據量特別大,比如幾億條的用戶行為日誌數據,用 Redis 來存儲的話,成本相當的高。

4. 如何查詢redis的緩存文件路徑

1、首先找到redis的安裝目錄,如下圖測試環境目錄,進入到/opt/install/redis-2.8.19/src,如下圖所示。

5. 緩存-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

6. redis的緩存數據在網站中有什麼作用

redis是一個key-value存儲系統。和Memcached類似,它支持存儲的value類型相對更多,包括string(字元串)、list(鏈表)、set(集合)和zset(有序集合)。這些數據類型都支持push/pop、add/remove及取交集並集和差集及更豐富的操作,而且這些操作都是原子性的。在此基礎上,redis支持各種不同方式的排序。與memcached一樣,為了保證效率,數據都是緩存在內存中。區別的是redis會周期性的把更新的數據寫入磁碟或者把修改操作寫入追加的記錄文件,並且在此基礎上實現了master-slave(主從)同步。

7. 高性能高並發網站架構,教你搭建Redis5緩存集群

一、Redis集群介紹

Redis真的是一個優秀的技術,它是一種key-value形式的Nosql內存資料庫,由ANSI C編寫,遵守BSD協議、支持網路、可基於內存亦可持久化的日誌型、Key-Value資料庫,並提供多種語言的API。 Redis最大的特性是它會將所有數據都放在內存中,所以讀寫速度性能非常好。Redis是基於內存進行操作的,性能較高,可以很好的在一定程度上解決網站一瞬間的並發量,例如商品搶購秒殺等活動。

網站承受高並發訪問壓力的同時,還需要從海量數據中查詢出滿足條件的數據,需要快速響應,前端發送請求、後端和mysql資料庫交互,進行sql查詢操作,讀寫比較慢,這時候引入Redis ,把從mysql 的數據緩存到Redis 中,下次讀取時候性能就會提高;當然,它也支持將內存中的數據以快照和日誌的形式持久化到硬碟,這樣即使在斷電、機器故障等異常情況發生時數據也不會丟失,Redis能從硬碟中恢復快照數據到內存中。

Redis 發布了穩定版本的 5.0 版本,放棄 Ruby的集群方式,改用 C語言編寫的 redis-cli的方式,是集群的構建方式復雜度大大降低。Redis-Cluster集群採用無中心結構,每個節點保存數據和整個集群狀態,每個節點都和其他所有節點連接。

為了保證數據的高可用性,加入了主從模式,一個主節點對應一個或多個從節點,主節點提供數據存取,從節點則是從主節點拉取數據備份,當這個主節點掛掉後,就會有這個從節點選取一個來充當主節點,從而保證集群不會掛掉。

redis-cluster投票:容錯,投票過程是集群中所有master參與,如果半數以上master節點與master節點通信超過(cluster-node-timeout),認為當前master節點掛掉。

集群中至少應該有奇數個節點,所以至少有三個節點,每個節點至少有一個備份節點,所以下面使用6節點(主節點、備份節點由redis-cluster集群確定)。6個節點分布在一台機器上,採用三主三從的模式。實際應用中,最好用多台機器,比如說6個節點分布到3台機器上,redis在建立集群時為自動的將主從節點進行不同機器的分配。

二、單機redis模式

下載源碼redis5.0並解壓編譯

wget http://download.redis.io/releases/redis-5.0.0.tar.gz

tar xzf redis-5.0.0.tar.gz

cd redis-5.0.0

make

redis前端啟動需要改成後台啟動.

修改redis.conf文件,將daemonize no -> daemonize yes

vim redis.conf

啟動redis

/www/server/redis/src/redis-server /www/server/redis/redis.conf

查看redis是否在運行

ps aux|grep redis

現在是單機redis模式完成。

三、redis集群模式:

1.創建6個Redis配置文件

cd /usr/local/

mkdir redis_cluster //創建集群目錄

cd redis_cluster

mkdir 7000 7001 7002 7003 7004 7005//分別代表6個節點

其對應埠 7000 7001 7002 70037004 7005

2.復制配置文件到各個目錄

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7000/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7001/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7002/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7003/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7004/

cp /www/server/redis/redis.conf /usr/local/redis_cluster/7005/

3.分別修改配置文件

vim /usr/local/redis_cluster/7000/redis.conf

vim /usr/local/redis_cluster/7001/redis.conf

vim /usr/local/redis_cluster/7002/redis.conf

vim /usr/local/redis_cluster/7003/redis.conf

vim /usr/local/redis_cluster/7004/redis.conf

vim /usr/local/redis_cluster/7005/redis.conf

如下

port 7000 #埠

cluster-enabled yes #啟用集群模式

cluster-config-file nodes_7000.conf #集群的配置 配置文件首次啟動自動生成

cluster-node-timeout 5000 #超時時間 5秒

appendonly yes #aof日誌開啟 它會每次寫操作都記錄一條日誌

daemonize yes #後台運行

protected-mode no #非保護模式

pidfile /var/run/redis_7000.pid

//下面可以不寫

#若設置密碼,master和slave需同時配置下面兩個參數:

masterauth "jijiji" #連接master的密碼

requirepass "jijiji" #自己的密碼

cluster-config-file,port,pidfile對應數字

4.啟動節點

cd /www/server/redis/src/

./redis-server /usr/local/redis_cluster/7000/redis.conf

./redis-server /usr/local/redis_cluster/7001/redis.conf

./redis-server /usr/local/redis_cluster/7002/redis.conf

./redis-server /usr/local/redis_cluster/7003/redis.conf

./redis-server /usr/local/redis_cluster/7004/redis.conf

./redis-server /usr/local/redis_cluster/7005/redis.conf

查看redis運行

ps aux|grep redis

5.啟動集群

/www/server/redis/src/redis-cli --cluster create 127.0.0.1:7000 127.0.0.1:7001 127.0.0.1:7002 127.0.0.1:7003 127.0.0.1:7004 127.0.0.1:7005 --cluster-replicas 1

這里使用的命令是create,因為我們要創建一個新的集群。 該選項--cluster-replicas 1意味著我們希望每個創建的主伺服器都有一個從服。

輸入yes

至此,Reids5 集群搭建完成。

6.檢查Reids5集群狀態

可以執行redis-cli --cluster check host:port檢查集群狀態slots詳細分配。

redis-cli --cluster info 127.0.0.1:7000

7.停止Reids5集群

(1).因為Redis可以妥善處理SIGTERM信號,所以直接kill -9也是可以的,可以同時kill多個,然後再依次啟動。

kill -9 PID PID PID

(2).redis5 提供了關閉集群的工具,修改文件: /www/server/redis/utils/create-cluster/create-cluster

埠PROT設置為6999,NODES為6,工具會生成 7000-7005 六個節點 用於操作。

修改後,執行如下命令關閉集群:

/www/server/redis/utils/create-cluster/create-cluster stop

重新啟動集群:

/www/server/redis/utils/create-cluster/create-cluster start

8.幫助信息

執行redis-cli --cluster help,查看更多幫助信息

redis-cli --cluster help

吉海波

8. 怎麼實現redis的資料庫的緩存

大致為兩種措施:

一、腳本同步:
1、自己寫腳本將資料庫數據寫入到redis/memcached。
2、這就涉及到實時數據變更的問題(mysql row binlog的實時分析),binlog增量訂閱Alibaba 的canal ,以及緩存層數據 丟失/失效 後的數據同步恢復問題。

二、業務層實現:
1、先讀取nosql緩存層,沒有數據再讀取mysql層,並寫入數據到nosql。
2、nosql層做好多節點分布式(一致性hash),以及節點失效後替代方案(多層hash尋找相鄰替代節點),和數據震盪恢復了。

9. 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 分頁插件的使用 ,下期不見不散, 關注我,不迷路~