文章目錄

• 一、特點(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ù)庫

項(xiàng)目描述

相關(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ù)庫

項(xiàng)目描述

相關(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ù)庫的一個衍生品,而且前者比后者具有更高的查詢效率.

項(xiàng)目描述

相關(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ù)庫

項(xiàng)目描述

相關(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/redis

db0 到 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目錄下

root@user-virtual-machine:/etc/redis# whereis 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所儲存的值的類型

set k1 v1 set k2 v2 set msg aaakeys * 1) "k2" 2) "msg" 3) "k1"> get msg "aaa" > exists k1 (integer) 1 > exists k3 (integer) 0> expire k1 10 (integer) 1 > ttl k1 (integer) 3 > ttl k1 (integer) -2> get k1 (nil) > type k1 "none"> type k2 "string"

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)

> set k1 abcdefg OK > get k1 "abcdefg" > getrange k1 0 3 "abcd"> setrange k1 0 qwe 7 > get k1 "qwedefg"將值 value 關(guān)聯(lián)到 key ，并將 key 的過期時間設(shè)為 seconds (以秒為單位)。 > setex k1 10 qwe OK > get k1 "qwe" > ttl k1 (integer) -2

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) 3

lrem 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)站訪問量

解決方法一:

> sadd iplist 192.168.1.2 # 第一個有用ip (integer) 1 > sadd iplist 192.168.1.3 # 第二個有用ip (integer) 1 > sadd iplist 192.168.1.3 # 重復(fù) (integer) 0 > sadd iplist 192.168.1.3 # 重復(fù) (integer) 0 > scard iplist # 獲取iplist的元素個數(shù) 2

解決方法二: 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)

> hset user name tony 1 > hget user name "tony" > hmset customer id 1 name Tom age 23 OK > hmget customer id name age 1) "1" 2) "Tom" 3) "23"> hgetall customer # 返回多個key, value 1) "id" 2) "1" 3) "name" 4) "Tom" 5) "age" 6) "23"> hkeys customer 1) "id" 2) "name" 3) "age"> hvals customer 1) "1" 2) "Tom" 3) "23"

應(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)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。