NoSQL数据库_Redis
文章目錄
- 一、特點(diǎn)
- 二、與關(guān)系數(shù)據(jù)庫的比較
- 三、NoSQL的四大類型
- 1、鍵值數(shù)據(jù)庫
- 2、列族數(shù)據(jù)庫
- 3、文檔數(shù)據(jù)庫
- 4、圖數(shù)據(jù)庫
- 四、NoSQL的三大基石
- 1.CAP
- 2.BASE
- 3.最終一致性 (完)
- 五、數(shù)據(jù)庫分類圖
- redis應(yīng)用場景
- redis安裝
- Linux redis安裝方法一:Docker安裝
- Linux redis安裝方法二
- Windows環(huán)境下安裝Redis
- redis常用命令
- Redis數(shù)據(jù)類型
- String
- bitmap
- list 有點(diǎn)像隊(duì)列
- set
- hash
- zset
- 應(yīng)用場景腦圖
- Redis持久化
- RDB(Redis DataBase)
- AOF(Append Only File)
- 參考
- Redis事務(wù)
- 常用命令
- 悲觀鎖/樂觀鎖/CAS(Check And Set)
- 三個特性
- 主從復(fù)制
- 配置方法
- 數(shù)據(jù)同步階段:全量復(fù)制和部分復(fù)制
- 命令傳播階段:心跳機(jī)制
- 哨兵模式
- 緩存穿透,緩存擊穿,緩存雪崩
- 保證緩存(redis)與數(shù)據(jù)庫(MySQL)的一致性
在線redis
NoSQL是一種不同于關(guān)系數(shù)據(jù)庫的數(shù)據(jù)庫管理系統(tǒng)設(shè)計(jì)方式,是對非關(guān)系數(shù)據(jù)庫的統(tǒng)稱.它所采用的是數(shù)據(jù)模型并非傳統(tǒng)關(guān)系數(shù)據(jù)庫的關(guān)系模型,而是類似鍵值、列族、文檔等非關(guān)系模型.
一、特點(diǎn)
通常NoSQL數(shù)據(jù)庫具有以下3個特點(diǎn):
1.靈活的可擴(kuò)展行
2.靈活的數(shù)據(jù)模型
3.與云計(jì)算緊密融合
二、與關(guān)系數(shù)據(jù)庫的比較
- 關(guān)系數(shù)據(jù)庫的優(yōu)缺點(diǎn)
優(yōu)勢在于,以完善的關(guān)系代數(shù)理論為基礎(chǔ),有嚴(yán)格的標(biāo)準(zhǔn),支持事務(wù)ACID四性,借助索引機(jī)制可以實(shí)現(xiàn)高效的查詢,技術(shù)成熟,有專業(yè)公司技術(shù)支持.
劣勢在于可擴(kuò)展性差,無法較好地支持海量數(shù)據(jù)存儲,數(shù)據(jù)模型過于死板,無法較好地支持Web2.0應(yīng)用,事務(wù)機(jī)制影響了系統(tǒng)的整體性能等. - NoSQL數(shù)據(jù)庫的優(yōu)缺點(diǎn)
優(yōu)勢在于,可以支持超大數(shù)據(jù)規(guī)模存儲,靈活的數(shù)據(jù)模型可以很好地支持Web2.0應(yīng)用,具有強(qiáng)大的橫向擴(kuò)展能力等.
劣勢在于,缺乏數(shù)學(xué)理論基礎(chǔ),復(fù)雜查詢性能不高,一般都不能實(shí)現(xiàn)事務(wù)的強(qiáng)一致性,很難實(shí)現(xiàn)數(shù)據(jù)完整性,技術(shù)尚不成熟,缺乏專業(yè)團(tuán)隊(duì)的技術(shù)支持,維護(hù)較困難等.
對于關(guān)系數(shù)據(jù)庫而言,在一些特定應(yīng)用領(lǐng)域,其地位和作用仍然無法被取代,銀行,超市等領(lǐng)域的業(yè)務(wù)依然需要高度依賴于關(guān)系數(shù)據(jù)庫來保證數(shù)據(jù)的一致性
三、NoSQL的四大類型
1、鍵值數(shù)據(jù)庫
| 相關(guān)產(chǎn)品 | Redis,Riak |
| 數(shù)據(jù)模型 | 鍵/值對 |
| 典型應(yīng)用 | 內(nèi)容緩存,如會話、配置文件、參數(shù)、購物車等 |
| 優(yōu)點(diǎn) | 擴(kuò)展性好靈活性好 |
| 缺點(diǎn) | 無法存儲結(jié)構(gòu)化信息,條件查詢效率較低 |
| 使用者 | 百度云數(shù)據(jù)庫(Redis) |
2、列族數(shù)據(jù)庫
| 相關(guān)產(chǎn)品 | BigTable, HBase, Cassandra |
| 數(shù)據(jù)模型 | 列族 |
| 典型應(yīng)用 | 分布式數(shù)據(jù)存儲與管理 |
| 優(yōu)點(diǎn) | 查找速度快 可擴(kuò)展性強(qiáng) 容易分布式擴(kuò)展 |
| 缺點(diǎn) | 功能較少 大都不支持強(qiáng)事務(wù)一致性 |
| 使用者 | Ebay(Cassandra) Facebook(HBase) |
3、文檔數(shù)據(jù)庫
在文檔數(shù)據(jù)庫中,文檔是數(shù)據(jù)庫的最小單位.雖然每一種文檔數(shù)據(jù)庫的部署都有所不同,但是大都假定文檔以某種標(biāo)準(zhǔn)化格式封裝并對數(shù)據(jù)進(jìn)行加密,同時用多種格式進(jìn)行解碼,包括XML,YAML,JSON,BSON等.
文檔數(shù)據(jù)庫通過鍵來定位一個文檔,因此可以看成是鍵值數(shù)據(jù)庫的一個衍生品,而且前者比后者具有更高的查詢效率.
| 相關(guān)產(chǎn)品 | MongoDB |
| 數(shù)據(jù)模型 | 版本化的文檔 |
| 典型應(yīng)用 | 存儲、索引并管理面向文檔的數(shù)據(jù)或者類似的半結(jié)構(gòu)化數(shù)據(jù) |
| 優(yōu)點(diǎn) | 性能好、靈活性高 |
| 缺點(diǎn) | 缺乏統(tǒng)一的查詢語句 |
| 使用者 | 百度云數(shù)據(jù)庫MongoDB |
4、圖數(shù)據(jù)庫
| 相關(guān)產(chǎn)品 | Neo4J |
| 數(shù)據(jù)模型 | 圖結(jié)構(gòu) |
| 典型應(yīng)用 | 應(yīng)用于大量復(fù)雜、互連接低結(jié)構(gòu)化的場合,如社交網(wǎng)絡(luò)、推薦系統(tǒng) |
| 優(yōu)點(diǎn) | 靈活性高、支持復(fù)雜的圖算法 |
| 缺點(diǎn) | 復(fù)雜性高、只能支持一定的數(shù)據(jù)規(guī)模 |
| 使用者 | Adobe(Neo4J),Cisco,T-Mobile |
最后用一張圖形象描述一下上面提到的數(shù)據(jù)庫
四、NoSQL的三大基石
NoSQL的三大基石包括CAP、BASE和最終一致性。
1.CAP
指的是:
- C(Consistency):一致性
它是指任何一個讀操作總是能夠讀到之前完成的寫操作的結(jié)果,也就是在分布式環(huán)境中,多點(diǎn)的數(shù)據(jù)是一致的。數(shù)據(jù)在多個副本中能保持一致的狀態(tài)。 - A(Availability):可用性
它是指快速獲取數(shù)據(jù),可以在確定的時間內(nèi)返回操作結(jié)果。整個系統(tǒng)在任何時刻都能提供可用的服務(wù),通常達(dá)到99.99%四個九可以稱為高可用。 - P(Tolerance of Network Partition,Partition Tolerance ):分區(qū)容忍性
它是指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(即系統(tǒng)中的一部分節(jié)點(diǎn)無法和其他節(jié)點(diǎn)進(jìn)行通信),分離的系統(tǒng)也能夠正常運(yùn)行。
CAP理論的核心是: 一個分布式系統(tǒng)不可能同時很好地的滿足一致性、可用性、分區(qū)容忍性. 最多只能同時較好的滿足兩個。
CA:單點(diǎn)集群,滿足一致性,可用性的系統(tǒng),通常在可擴(kuò)展上不太強(qiáng)大。應(yīng)用:傳統(tǒng)的Oracle數(shù)據(jù)庫.
CP:滿足一致性,分區(qū)容錯性的系統(tǒng),通常性能不是特別高。應(yīng)用:Redis,MongoDB,銀行.
AP:滿足可用性,分區(qū)容錯性,通常可能對一致性要求低一些。應(yīng)用:大多數(shù)網(wǎng)站架構(gòu)的選擇.一般弱一致性即可.
為何CAP三者不可兼得
http://codekiller.top/2020/03/30/redis2/
2.BASE
Base就是為了解決關(guān)系型數(shù)據(jù)庫強(qiáng)一致性引起的問題而引起的可用性降低而提出的解決方案。
BASE的基本含義是基本可用(Basically Availble)、軟狀態(tài)(Soft-state)、最終一致性(Eventual-consistendy)。下面分別介紹:
(1)基本可用
指一個分布式系統(tǒng)的一部分發(fā)生問題變得不可用時,其他部分仍然可以正常使用,也就是允許分區(qū)失敗的情形出現(xiàn).
(2)軟狀態(tài)
-
軟狀態(tài) Soft-state
指狀態(tài)可以有一段時間不同步,具有一定的滯后性. -
硬狀態(tài) Hard-state
數(shù)據(jù)庫的狀態(tài)必須一直保持?jǐn)?shù)據(jù)庫一致性,就是任意時刻數(shù)據(jù)必須是正確的.
(3)最終一致性
舉例:雙十一某個商品本來有100萬人點(diǎn)贊,結(jié)果只顯示了80萬,但等高峰過后工程師要保證這個點(diǎn)贊數(shù)最終是正確的,這就是最終一致性.
3.最終一致性 (完)
五、數(shù)據(jù)庫分類圖
redis應(yīng)用場景
https://www.bilibili.com/video/BV1J4411x7U1?p=3
redis安裝
REmote DIctionary Server(遠(yuǎn)程字典服務(wù)器)
Linux redis安裝方法一:Docker安裝
docker pull redis docker run -d -p 6379:6379 --name myredis docker.io/redisdb0 到 db15 共16個庫:
Linux redis安裝方法二
sudo apt-get install redis-server執(zhí)行service redis status 可以查看redis服務(wù)的狀態(tài)為running,說明安裝完成系統(tǒng)自動啟動了服務(wù).
執(zhí)行redis-cli命令打開redis客戶端:
select 0 切換庫
keys * 顯示所有的鍵值對
set "key" "value" 設(shè)置鍵值對
FLUSHALL 清空所有鍵值對(所有庫中的)
redis配置文件
首先查看redis安裝位置,可以看到在/etc/redis目錄下
Windows環(huán)境下安裝Redis
https://www.cnblogs.com/zxtceq/p/14002736.html
redis常用命令
http://www.redis.cn/commands.html#string
Redis數(shù)據(jù)類型
Redis以鍵值對存儲數(shù)據(jù):
- Key只有String類型
- Value包括五種數(shù)據(jù)類型:string、hash、list、set、zset(sorted set).
zset(sorted set)應(yīng)用: 英雄戰(zhàn)力排行榜(60分以上的, 90分以上的).
首先看一下key
keys *
exists "key的名字":檢查key是否存在
expire key的名字 second:為key設(shè)定過期時間,以秒計(jì)算,可以不寫second,默認(rèn)為秒
ttl key:返回key剩余時間,-1為永久,-2為失效
type key:返回key所儲存的值的類型
expirekey second的使用場景:
1、限時的優(yōu)惠活動
2、網(wǎng)站數(shù)據(jù)緩存
3、手機(jī)驗(yàn)證碼
4、限制網(wǎng)站訪客頻率
key的命名建議:
1.key不要太長,盡量不要超過1024字節(jié)。不僅消耗內(nèi)存,也會降低查找的效率
2.key不要太短,太短可讀性會降低
3.在一個項(xiàng)目中,key最好使用統(tǒng)一的命名模式,如user:123:password
4.key區(qū)分大小寫
String
set/get/del/append/strlen
getrange/setrange 返回 key 中字符串值的子字符
setex(set with expire)鍵秒值/setnx(set if not exist)
bitmap
主要用來做活躍用戶在線狀態(tài)、活躍用戶統(tǒng)計(jì)、用戶簽到等場景
Redis數(shù)據(jù)類型String之bitmap
https://blog.csdn.net/qq_36804603/article/details/111599199
Redis BitMap簡介(一)
https://www.bilibili.com/video/BV1Vv411s799
list 有點(diǎn)像隊(duì)列
底層采用雙向鏈表 左進(jìn)左出 右進(jìn)右出
lpush/rpush/lrange
> lpush list0 1 2 3 4 5 (integer) 5> llen list0 (integer) 5> lrange list0 0 -1 1) "5" 2) "4" 3) "3" 4) "2" 5) "1"lpop/rpop
> lpop list0 # 左邊彈出一個 "5" > lrange list0 0 -1 1) "4" 2) "3" 3) "2" 4) "1"> rpop list0 # 右邊彈出一個 "1" > lrange list0 0 -1 1) "4" 2) "3" 3) "2"lindex
> lindex list0 0 "4"llen
> llen list0 (integer) 3lrem key 刪除N個value(刪除指定位置的值)
> lrange list1 0 -1 1) "5" 2) "4" 3) "3" 4) "2" 5) "2" 6) "2" 7) "1" > lrem list1 2 2 # 刪除兩個2 (integer) 2 > lrange list1 0 -1 1) "5" 2) "4" 3) "3" 4) "2" 5) "1"ltrim key 開始index 結(jié)束index,截取指定范圍的值后再賦值給key
> lrange list1 0 -1 1) "5" 2) "4" 3) "3" 4) "1" > ltrim list1 0 2 # 去除索引0-2的值, 再賦給list1 OK > lrange list1 0 -1 1) "5" 2) "4" 3) "3"應(yīng)用場景
set
應(yīng)用場景一: 網(wǎng)站訪問量
解決方法一:
解決方法二: bitset
拼多多面試:如何用 Redis 統(tǒng)計(jì)獨(dú)立用戶訪問量? - 動力節(jié)點(diǎn)Java學(xué)院的文章 - 知乎
https://zhuanlan.zhihu.com/p/88995241
Redis getbit和setbit 用法理解https://blog.csdn.net/sinat_38740436/article/details/88599751
hash
平時Java中寫的Bean, User有id跟name屬性,這里user是一個key,它的value也是一個鍵值對(key:name,value:tony)
應(yīng)用場景一
應(yīng)用場景二
zset
# 60分以上v1個, 70分以上v2個 > zadd zset0 60 v1 70 v2 80 v3 90 v4 100 v5 (integer) 5 > zrange zset0 0 -1 1) "v1" 2) "v2" 3) "v3" 4) "v4" 5) "v5" > zrangebyscore zset0 60 90 1) "v1" 2) "v2" 3) "v3" 4) "v4" > zrangebyscore zset0 60 (90 # 小于90, 不包含90 1) "v1" 2) "v2" 3) "v3" > zrangebyscore zset0 (60 (90 # 大于60, 小于90, 都不包含 1) "v2" 2) "v3" > zrem zset0 v5 1 > zrange zset0 0 -1 1) "v1" 2) "v2" 3) "v3" 4) "v4"應(yīng)用場景腦圖
Redis持久化
Redis 為了保證效率,數(shù)據(jù)緩存在了內(nèi)存中,但是會周期性的把更新的數(shù)據(jù)寫入磁盤或者把修改操作寫入追加的記錄文件中,以保證數(shù)據(jù)的持久化。
Redis 的持久化策略有兩種:
RDB(Redis DataBase)
在指定的時間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫入磁盤,也就是行話講的Snapshot快照,它恢復(fù)時是將快照文件直接讀到內(nèi)存里.
Redis會單獨(dú)創(chuàng)建(fork)一個子進(jìn)程來進(jìn)行持久化,會先將數(shù)據(jù)寫入到一個臨時文件中 dump.rdb,待持久化過程都結(jié)束了,再用這個臨時文件替換上次持久化好的文件。
優(yōu)缺點(diǎn):
- 整個過程中,主進(jìn)程是不進(jìn)行任何IO操作的,這就確保了極高的性能如果需要進(jìn)行大規(guī)模數(shù)據(jù)的恢復(fù),且對于數(shù)據(jù)恢復(fù)的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。
- RDB的缺點(diǎn)是最后一次持久化后的數(shù)據(jù)可能丟失。(假如5min一次, 剛備份完后的 1 分鐘系統(tǒng)掛掉了, 這就導(dǎo)致最后數(shù)據(jù)丟失)
fork的作用是復(fù)制一個與當(dāng)前進(jìn)程一樣的進(jìn)程。新進(jìn)程的所有數(shù)據(jù)(變量、環(huán)境變量、程序計(jì)數(shù)器等). 數(shù)值都和原進(jìn)程一致,但是是一個全新的進(jìn)程,并作為原進(jìn)程的子進(jìn)程.
AOF(Append Only File)
RDB持久化是用進(jìn)程將數(shù)據(jù)寫入文件,而AOF持久化則是將每次執(zhí)行的寫命令記錄到單獨(dú)的日志文件中(有點(diǎn)像MySQL的binlog);當(dāng)Redis重啟時再次執(zhí)行AOF文件中的命令來恢復(fù)數(shù)據(jù)。
與RDB相比,AOF的實(shí)時性更好,因此已成為主流的持久化方案。
參考
https://www.cnblogs.com/kismetv/p/9137897.html
Redis事務(wù)
常用命令
可以一次執(zhí)行多個命令,本質(zhì)是一組命令的集合。一個事務(wù)中的所有命令都會序列化,按順序地串行化執(zhí)行而不會被其它命令插入,不許加塞. 即批處理, 一次性執(zhí)行一堆命令.
> multi # 標(biāo)記事務(wù)開始 OK > incr user_id # 多條命令按順序入隊(duì) QUEUED > incr user_id QUEUED > incr user_id QUEUED > get user_id QUEUED > exec # 執(zhí)行 1) 1 2) 2 3) 3 4) "3"悲觀鎖/樂觀鎖/CAS(Check And Set)
悲觀鎖(Pessimistic Lock)
顧名思義,就是很悲觀,每次去拿數(shù)據(jù)的時候都認(rèn)為別人會修改,所以每次在拿數(shù)據(jù)的時候都會上鎖,這樣別人想拿這個數(shù)據(jù)就會block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫里邊就用到了很多這種鎖機(jī)制,比如行鎖,表鎖等,讀鎖,寫鎖等,都是在做操作之前先上鎖.
樂觀鎖(Optimistic Lock)
顧名思義,就是很樂觀,每次去拿數(shù)據(jù)的時候都認(rèn)為別人不會修改,所以不會上鎖,但是在更新的時候會判斷一下在此期間別人有沒有去更新這個數(shù)據(jù),可以使用版本號等機(jī)制。樂觀鎖適用于多讀的應(yīng)用類型,這樣可以提高吞吐量,樂觀鎖策略:提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新.
1 DISCARD
取消事務(wù),放棄執(zhí)行事務(wù)塊內(nèi)的所有命令。
2 EXEC
執(zhí)行所有事務(wù)塊內(nèi)的命令。
3 MULTI
標(biāo)記一個事務(wù)塊的開始。
4 UNWATCH
取消 WATCH 命令對所有 key 的監(jiān)視。
5 WATCH key [key …]
監(jiān)視一個(或多個) key ,如果在事務(wù)執(zhí)行之前這個(或這些) key 被其他命令所改動,那么事務(wù)將被打斷。
三個特性
單獨(dú)的隔離操作:
事務(wù)中的所有命令都會序列化、按順序地執(zhí)行。事務(wù)在執(zhí)行的過程中,不會被其他客戶端發(fā)送來的命令請求所打斷。
沒有隔離級別的概念:
隊(duì)列中的命令沒有提交之前都不會實(shí)際的被執(zhí)行,因?yàn)槭聞?wù)提交前任何指令都不會被實(shí)際執(zhí)行,也就不存在”事務(wù)內(nèi)的查詢要看到事務(wù)里的更新,在事務(wù)外查詢不能看到”這個讓人萬分頭痛的問題.
不保證原子性:
redis同一個事務(wù)中如果有一條命令執(zhí)行失敗,其后的命令仍然會被執(zhí)行,沒有回滾.
主從復(fù)制
配置方法
配從(庫)不配主(庫): 只需配置從服務(wù)器, 主從復(fù)制的開啟,完全是在從節(jié)點(diǎn)發(fā)起的;不需要我們在主節(jié)點(diǎn)做任何事情。
從節(jié)點(diǎn)開啟主從復(fù)制,有3種方式:
(1)配置文件
在從服務(wù)器的配置文件中加入:slaveof
(2)啟動命令
redis-server啟動命令后加入 --slaveof
(3)客戶端命令
Redis服務(wù)器啟動后,直接通過客戶端執(zhí)行命令:slaveof ,則該Redis實(shí)例成為從節(jié)點(diǎn)。
主從復(fù)制過程大體可以分為3個階段:連接建立階段(即準(zhǔn)備階段)、數(shù)據(jù)同步階段、命令傳播階段;
數(shù)據(jù)同步階段:全量復(fù)制和部分復(fù)制
在Redis2.8以前,從節(jié)點(diǎn)向主節(jié)點(diǎn)發(fā)送sync命令請求同步數(shù)據(jù),此時的同步方式是全量復(fù)制;在Redis2.8及以后,從節(jié)點(diǎn)可以發(fā)送psync命令請求同步數(shù)據(jù),此時根據(jù)主從節(jié)點(diǎn)當(dāng)前狀態(tài)的不同,同步方式可能是全量復(fù)制或部分復(fù)制。后文介紹以Redis2.8及以后版本為例。
- 全量復(fù)制:用于初次復(fù)制或其他無法進(jìn)行部分復(fù)制的情況,將主節(jié)點(diǎn)中的所有數(shù)據(jù)都發(fā)送給從節(jié)點(diǎn),是一個非常重型的操作。
- 部分復(fù)制:用于網(wǎng)絡(luò)中斷等情況后的復(fù)制,只將中斷期間主節(jié)點(diǎn)執(zhí)行的寫命令發(fā)送給從節(jié)點(diǎn),與全量復(fù)制相比更加高效。需要注意的是,如果網(wǎng)絡(luò)中斷時間過長,導(dǎo)致主節(jié)點(diǎn)沒有能夠完整地保存中斷期間執(zhí)行的寫命令,則無法進(jìn)行部分復(fù)制,仍使用全量復(fù)制。
命令傳播階段:心跳機(jī)制
在命令傳播階段,除了發(fā)送寫命令,主從節(jié)點(diǎn)還維持著心跳機(jī)制:PING和REPLCONF ACK。心跳機(jī)制對于主從復(fù)制的超時判斷、數(shù)據(jù)安全等有作用。
主從復(fù)制雖然解決或緩解了數(shù)據(jù)冗余、故障恢復(fù)、讀負(fù)載均衡等問題,但其缺陷仍很明顯:
- 故障恢復(fù)無法自動化;
- 寫操作無法負(fù)載均衡;
- 存儲能力受到單機(jī)的限制;
這些問題的解決,需要哨兵和集群的幫助.
更多參考
★★★★★ https://www.cnblogs.com/kismetv/category/1186633.html
哨兵模式
Redis Sentinel,即Redis哨兵,在Redis 2.8版本開始引入。哨兵的核心功能是主節(jié)點(diǎn)的自動故障轉(zhuǎn)移。下面是Redis官方文檔對于哨兵功能的描述:
- 監(jiān)控(Monitoring):哨兵會不斷地檢查主節(jié)點(diǎn)和從節(jié)點(diǎn)是否運(yùn)作正常。
- 自動故障轉(zhuǎn)移(Automatic failover):當(dāng)主節(jié)點(diǎn)不能正常工作時,哨兵會開始自動故障轉(zhuǎn)移操作,它會將失效主節(jié)點(diǎn)的其中一個從節(jié)點(diǎn)升級為新的主節(jié)點(diǎn),并讓其他從節(jié)點(diǎn)改為復(fù)制新的主節(jié)點(diǎn)。
- 配置提供者(Configuration provider):客戶端在初始化時,通過連接哨兵來獲得當(dāng)前Redis服務(wù)的主節(jié)點(diǎn)地址。
- 通知(Notification):哨兵可以將故障轉(zhuǎn)移的結(jié)果發(fā)送給客戶端。
深入學(xué)習(xí)Redis(4):哨兵
https://www.cnblogs.com/kismetv/p/9609938.html
簡書: 多哨兵模式
https://www.jianshu.com/p/06ab9daf921d
緩存穿透,緩存擊穿,緩存雪崩
《進(jìn)大廠系列》系列-Redis緩存雪崩、擊穿、穿透
https://zhuanlan.zhihu.com/p/89961333
REDIS緩存穿透,緩存擊穿,緩存雪崩原因+解決方案
https://www.cnblogs.com/midoujava/p/11277096.html
保證緩存(redis)與數(shù)據(jù)庫(MySQL)的一致性
https://blog.csdn.net/wwd0501/article/details/106902856/
總結(jié)
以上是生活随笔為你收集整理的NoSQL数据库_Redis的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 开始使用vue.js
- 下一篇: 微信小程序-豆瓣电影TOP250