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