文章目錄

• 一、特點(diǎn)
• 二、與關(guān)系數(shù)據(jù)庫(kù)的比較
• 三、NoSQL的四大類(lèi)型
• • 1、鍵值數(shù)據(jù)庫(kù)
  • 2、列族數(shù)據(jù)庫(kù)
  • 3、文檔數(shù)據(jù)庫(kù)
  • 4、圖數(shù)據(jù)庫(kù)
• 四、NoSQL的三大基石
• • 1.CAP
  • 2.BASE
• 3.最終一致性 (完)
• 五、數(shù)據(jù)庫(kù)分類(lèi)圖
• redis應(yīng)用場(chǎng)景
• redis安裝
• • Linux redis安裝方法一:Docker安裝
  • Linux redis安裝方法二
  • Windows環(huán)境下安裝Redis
• redis常用命令
• Redis數(shù)據(jù)類(lèi)型
• • String
  • • bitmap
  • list 有點(diǎn)像隊(duì)列
  • set
  • hash
  • zset
  • 應(yīng)用場(chǎng)景腦圖
• Redis持久化
• • RDB(Redis DataBase)
  • AOF(Append Only File)
  • 參考
• Redis事務(wù)
• • 常用命令
  • 悲觀(guān)鎖/樂(lè)觀(guān)鎖/CAS(Check And Set)
  • 三個(gè)特性
• 主從復(fù)制
• • 配置方法
  • 數(shù)據(jù)同步階段：全量復(fù)制和部分復(fù)制
  • 命令傳播階段：心跳機(jī)制
• 哨兵模式
• 緩存穿透，緩存擊穿，緩存雪崩
• 保證緩存(redis)與數(shù)據(jù)庫(kù)(MySQL)的一致性

在線(xiàn)redis
NoSQL是一種不同于關(guān)系數(shù)據(jù)庫(kù)的數(shù)據(jù)庫(kù)管理系統(tǒng)設(shè)計(jì)方式,是對(duì)非關(guān)系數(shù)據(jù)庫(kù)的統(tǒng)稱(chēng).它所采用的是數(shù)據(jù)模型并非傳統(tǒng)關(guān)系數(shù)據(jù)庫(kù)的關(guān)系模型,而是類(lèi)似鍵值、列族、文檔等非關(guān)系模型.

一、特點(diǎn)

通常NoSQL數(shù)據(jù)庫(kù)具有以下3個(gè)特點(diǎn):
1.靈活的可擴(kuò)展行
2.靈活的數(shù)據(jù)模型
3.與云計(jì)算緊密融合

二、與關(guān)系數(shù)據(jù)庫(kù)的比較

• 關(guān)系數(shù)據(jù)庫(kù)的優(yōu)缺點(diǎn)
  優(yōu)勢(shì)在于,以完善的關(guān)系代數(shù)理論為基礎(chǔ),有嚴(yán)格的標(biāo)準(zhǔn),支持事務(wù)ACID四性,借助索引機(jī)制可以實(shí)現(xiàn)高效的查詢(xún),技術(shù)成熟,有專(zhuān)業(yè)公司技術(shù)支持.
  劣勢(shì)在于可擴(kuò)展性差,無(wú)法較好地支持海量數(shù)據(jù)存儲(chǔ),數(shù)據(jù)模型過(guò)于死板,無(wú)法較好地支持Web2.0應(yīng)用,事務(wù)機(jī)制影響了系統(tǒng)的整體性能等.
• NoSQL數(shù)據(jù)庫(kù)的優(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ù)雜查詢(xún)性能不高,一般都不能實(shí)現(xiàn)事務(wù)的強(qiáng)一致性,很難實(shí)現(xiàn)數(shù)據(jù)完整性,技術(shù)尚不成熟,缺乏專(zhuān)業(yè)團(tuán)隊(duì)的技術(shù)支持,維護(hù)較困難等.

對(duì)于關(guān)系數(shù)據(jù)庫(kù)而言,在一些特定應(yīng)用領(lǐng)域,其地位和作用仍然無(wú)法被取代,銀行,超市等領(lǐng)域的業(yè)務(wù)依然需要高度依賴(lài)于關(guān)系數(shù)據(jù)庫(kù)來(lái)保證數(shù)據(jù)的一致性

三、NoSQL的四大類(lèi)型

1、鍵值數(shù)據(jù)庫(kù)

項(xiàng)目描述

相關(guān)產(chǎn)品	Redis,Riak
數(shù)據(jù)模型	鍵/值對(duì)
典型應(yīng)用	內(nèi)容緩存,如會(huì)話(huà)、配置文件、參數(shù)、購(gòu)物車(chē)等
優(yōu)點(diǎn)	擴(kuò)展性好靈活性好
缺點(diǎn)	無(wú)法存儲(chǔ)結(jié)構(gòu)化信息,條件查詢(xún)效率較低
使用者	百度云數(shù)據(jù)庫(kù)(Redis)

2、列族數(shù)據(jù)庫(kù)

項(xiàng)目描述

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

在文檔數(shù)據(jù)庫(kù)中,文檔是數(shù)據(jù)庫(kù)的最小單位.雖然每一種文檔數(shù)據(jù)庫(kù)的部署都有所不同,但是大都假定文檔以某種標(biāo)準(zhǔn)化格式封裝并對(duì)數(shù)據(jù)進(jìn)行加密,同時(shí)用多種格式進(jìn)行解碼,包括XML,YAML,JSON,BSON等.
文檔數(shù)據(jù)庫(kù)通過(guò)鍵來(lái)定位一個(gè)文檔,因此可以看成是鍵值數(shù)據(jù)庫(kù)的一個(gè)衍生品,而且前者比后者具有更高的查詢(xún)效率.

項(xiàng)目描述

相關(guān)產(chǎn)品	MongoDB
數(shù)據(jù)模型	版本化的文檔
典型應(yīng)用	存儲(chǔ)、索引并管理面向文檔的數(shù)據(jù)或者類(lèi)似的半結(jié)構(gòu)化數(shù)據(jù)
優(yōu)點(diǎn)	性能好、靈活性高
缺點(diǎn)	缺乏統(tǒng)一的查詢(xún)語(yǔ)句
使用者	百度云數(shù)據(jù)庫(kù)MongoDB

4、圖數(shù)據(jù)庫(kù)

項(xiàng)目描述

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

四、NoSQL的三大基石

NoSQL的三大基石包括CAP、BASE和最終一致性。

1.CAP

指的是:

• C(Consistency):一致性
  它是指任何一個(gè)讀操作總是能夠讀到之前完成的寫(xiě)操作的結(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è)九可以稱(chēng)為高可用。
• P(Tolerance of Network Partition,Partition Tolerance ):分區(qū)容忍性
  它是指當(dāng)出現(xiàn)網(wǎng)絡(luò)分區(qū)的情況時(shí)(即系統(tǒng)中的一部分節(jié)點(diǎn)無(wú)法和其他節(jié)點(diǎn)進(jìn)行通信),分離的系統(tǒng)也能夠正常運(yùn)行。

CAP理論的核心是: 一個(gè)分布式系統(tǒng)不可能同時(shí)很好地的滿(mǎn)足一致性、可用性、分區(qū)容忍性. 最多只能同時(shí)較好的滿(mǎn)足兩個(gè)。

CA：單點(diǎn)集群，滿(mǎn)足一致性，可用性的系統(tǒng)，通常在可擴(kuò)展上不太強(qiáng)大。應(yīng)用：傳統(tǒng)的Oracle數(shù)據(jù)庫(kù).

CP：滿(mǎn)足一致性，分區(qū)容錯(cuò)性的系統(tǒng)，通常性能不是特別高。應(yīng)用：Redis，MongoDB，銀行.

AP：滿(mǎn)足可用性，分區(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ù)庫(kù)強(qiáng)一致性引起的問(wèn)題而引起的可用性降低而提出的解決方案。

BASE的基本含義是基本可用(Basically Availble)、軟狀態(tài)(Soft-state)、最終一致性(Eventual-consistendy)。下面分別介紹:
(1)基本可用
指一個(gè)分布式系統(tǒng)的一部分發(fā)生問(wèn)題變得不可用時(shí),其他部分仍然可以正常使用,也就是允許分區(qū)失敗的情形出現(xiàn).

(2)軟狀態(tài)

• 軟狀態(tài) Soft-state
  指狀態(tài)可以有一段時(shí)間不同步,具有一定的滯后性.

• 硬狀態(tài) Hard-state
  數(shù)據(jù)庫(kù)的狀態(tài)必須一直保持?jǐn)?shù)據(jù)庫(kù)一致性,就是任意時(shí)刻數(shù)據(jù)必須是正確的.

(3)最終一致性
舉例:雙十一某個(gè)商品本來(lái)有100萬(wàn)人點(diǎn)贊,結(jié)果只顯示了80萬(wàn),但等高峰過(guò)后工程師要保證這個(gè)點(diǎn)贊數(shù)最終是正確的,這就是最終一致性.

3.最終一致性 (完)

五、數(shù)據(jù)庫(kù)分類(lèi)圖

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/redis

db0 到 db15 共16個(gè)庫(kù):

Linux redis安裝方法二

sudo apt-get install redis-server

執(zhí)行service redis status 可以查看redis服務(wù)的狀態(tài)為running，說(shuō)明安裝完成系統(tǒng)自動(dòng)啟動(dòng)了服務(wù).

執(zhí)行redis-cli命令打開(kāi)redis客戶(hù)端:

select 0 切換庫(kù)
keys * 顯示所有的鍵值對(duì)
set "key" "value" 設(shè)置鍵值對(duì)
FLUSHALL 清空所有鍵值對(duì)(所有庫(kù)中的)

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ù)類(lèi)型

Redis以鍵值對(duì)存儲(chǔ)數(shù)據(jù):

• Key只有String類(lèi)型
• Value包括五種數(shù)據(jù)類(lèi)型：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è)定過(guò)期時(shí)間,以秒計(jì)算,可以不寫(xiě)second，默認(rèn)為秒
ttl key：返回key剩余時(shí)間,-1為永久,-2為失效
type key：返回key所儲(chǔ)存的值的類(lèi)型

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的使用場(chǎng)景：
1、限時(shí)的優(yōu)惠活動(dòng)
2、網(wǎng)站數(shù)據(jù)緩存
3、手機(jī)驗(yàn)證碼
4、限制網(wǎng)站訪(fǎng)客頻率

key的命名建議:

1.key不要太長(zhǎng)，盡量不要超過(guò)1024字節(jié)。不僅消耗內(nèi)存，也會(huì)降低查找的效率
2.key不要太短，太短可讀性會(huì)降低
3.在一個(gè)項(xiàng)目中，key最好使用統(tǒng)一的命名模式，如user:123:password
4.key區(qū)分大小寫(xiě)

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 的過(guò)期時(shí)間設(shè)為 seconds (以秒為單位)。 > setex k1 10 qwe OK > get k1 "qwe" > ttl k1 (integer) -2

bitmap

主要用來(lái)做活躍用戶(hù)在線(xiàn)狀態(tài)、活躍用戶(hù)統(tǒng)計(jì)、用戶(hù)簽到等場(chǎng)景

Redis數(shù)據(jù)類(lèi)型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) 3

lrem 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 開(kāi)始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)站訪(fǎng)問(wèn)量

解決方法一:

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

解決方法二: bitset

拼多多面試：如何用 Redis 統(tǒng)計(jì)獨(dú)立用戶(hù)訪(fǎng)問(wèn)量？ - 動(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中寫(xiě)的Bean, User有id跟name屬性,這里user是一個(gè)key,它的value也是一個(gè)鍵值對(duì)(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 # 返回多個(gè)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)用場(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ù)寫(xiě)入磁盤(pán)或者把修改操作寫(xiě)入追加的記錄文件中，以保證數(shù)據(jù)的持久化。
Redis 的持久化策略有兩種：

RDB(Redis DataBase)

在指定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)，也就是行話(huà)講的Snapshot快照，它恢復(fù)時(shí)是將快照文件直接讀到內(nèi)存里.

Redis會(huì)單獨(dú)創(chuàng)建（fork）一個(gè)子進(jìn)程來(lái)進(jìn)行持久化，會(huì)先將數(shù)據(jù)寫(xiě)入到一個(gè)臨時(shí)文件中 dump.rdb，待持久化過(guò)程都結(jié)束了，再用這個(gè)臨時(shí)文件替換上次持久化好的文件。

優(yōu)缺點(diǎn):

• 整個(gè)過(guò)程中，主進(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ù)寫(xiě)入文件，而AOF持久化則是將每次執(zhí)行的寫(xiě)命令記錄到單獨(dú)的日志文件中（有點(diǎn)像MySQL的binlog）；當(dāng)Redis重啟時(shí)再次執(zhí)行AOF文件中的命令來(lái)恢復(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ù)開(kāi)始 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"

悲觀(guān)鎖/樂(lè)觀(guān)鎖/CAS(Check And Set)

悲觀(guān)鎖(Pessimistic Lock)
顧名思義，就是很悲觀(guān)，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人會(huì)修改，所以每次在拿數(shù)據(jù)的時(shí)候都會(huì)上鎖，這樣別人想拿這個(gè)數(shù)據(jù)就會(huì)block直到它拿到鎖。傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)里邊就用到了很多這種鎖機(jī)制，比如行鎖，表鎖等，讀鎖，寫(xiě)鎖等，都是在做操作之前先上鎖.

樂(lè)觀(guān)鎖(Optimistic Lock)
顧名思義，就是很樂(lè)觀(guān)，每次去拿數(shù)據(jù)的時(shí)候都認(rèn)為別人不會(huì)修改，所以不會(huì)上鎖，但是在更新的時(shí)候會(huì)判斷一下在此期間別人有沒(méi)有去更新這個(gè)數(shù)據(jù)，可以使用版本號(hào)等機(jī)制。樂(lè)觀(guān)鎖適用于多讀的應(yīng)用類(lèi)型，這樣可以提高吞吐量，樂(lè)觀(guān)鎖策略:提交版本必須大于記錄當(dāng)前版本才能執(zhí)行更新.

1 DISCARD
取消事務(wù)，放棄執(zhí)行事務(wù)塊內(nèi)的所有命令。

2 EXEC
執(zhí)行所有事務(wù)塊內(nèi)的命令。

3 MULTI
標(biāo)記一個(gè)事務(wù)塊的開(kāi)始。

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í)行的過(guò)程中，不會(huì)被其他客戶(hù)端發(fā)送來(lái)的命令請(qǐng)求所打斷。

沒(méi)有隔離級(jí)別的概念：
隊(duì)列中的命令沒(méi)有提交之前都不會(huì)實(shí)際的被執(zhí)行，因?yàn)槭聞?wù)提交前任何指令都不會(huì)被實(shí)際執(zhí)行，也就不存在”事務(wù)內(nèi)的查詢(xún)要看到事務(wù)里的更新，在事務(wù)外查詢(xún)不能看到”這個(gè)讓人萬(wàn)分頭痛的問(wèn)題.

不保證原子性：
redis同一個(gè)事務(wù)中如果有一條命令執(zhí)行失敗，其后的命令仍然會(huì)被執(zhí)行，沒(méi)有回滾.

主從復(fù)制

配置方法

配從(庫(kù))不配主(庫(kù)): 只需配置從服務(wù)器, 主從復(fù)制的開(kāi)啟，完全是在從節(jié)點(diǎn)發(fā)起的；不需要我們?cè)谥鞴?jié)點(diǎn)做任何事情。

從節(jié)點(diǎn)開(kāi)啟主從復(fù)制，有3種方式：

（1）配置文件
在從服務(wù)器的配置文件中加入：slaveof

（2）啟動(dòng)命令
redis-server啟動(dòng)命令后加入 --slaveof

（3）客戶(hù)端命令
Redis服務(wù)器啟動(dòng)后，直接通過(guò)客戶(hù)端執(zhí)行命令：slaveof ，則該Redis實(shí)例成為從節(jié)點(diǎn)。

主從復(fù)制過(guò)程大體可以分為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ù)制或其他無(wú)法進(jìn)行部分復(fù)制的情況，將主節(jié)點(diǎn)中的所有數(shù)據(jù)都發(fā)送給從節(jié)點(diǎn)，是一個(gè)非常重型的操作。
• 部分復(fù)制：用于網(wǎng)絡(luò)中斷等情況后的復(fù)制，只將中斷期間主節(jié)點(diǎn)執(zhí)行的寫(xiě)命令發(fā)送給從節(jié)點(diǎn)，與全量復(fù)制相比更加高效。需要注意的是，如果網(wǎng)絡(luò)中斷時(shí)間過(guò)長(zhǎng)，導(dǎo)致主節(jié)點(diǎn)沒(méi)有能夠完整地保存中斷期間執(zhí)行的寫(xiě)命令，則無(wú)法進(jìn)行部分復(fù)制，仍使用全量復(fù)制。

命令傳播階段：心跳機(jī)制

在命令傳播階段，除了發(fā)送寫(xiě)命令，主從節(jié)點(diǎn)還維持著心跳機(jī)制：PING和REPLCONF ACK。心跳機(jī)制對(duì)于主從復(fù)制的超時(shí)判斷、數(shù)據(jù)安全等有作用。

主從復(fù)制雖然解決或緩解了數(shù)據(jù)冗余、故障恢復(fù)、讀負(fù)載均衡等問(wèn)題，但其缺陷仍很明顯：

• 故障恢復(fù)無(wú)法自動(dòng)化；
• 寫(xiě)操作無(wú)法負(fù)載均衡；
• 存儲(chǔ)能力受到單機(jī)的限制；

這些問(wèn)題的解決，需要哨兵和集群的幫助.

更多參考

★★★★★ https://www.cnblogs.com/kismetv/category/1186633.html

哨兵模式

Redis Sentinel，即Redis哨兵，在Redis 2.8版本開(kāi)始引入。哨兵的核心功能是主節(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ì)開(kāi)始自動(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）：客戶(hù)端在初始化時(shí)，通過(guò)連接哨兵來(lái)獲得當(dāng)前Redis服務(wù)的主節(jié)點(diǎn)地址。
• 通知（Notification）：哨兵可以將故障轉(zhuǎn)移的結(jié)果發(fā)送給客戶(hù)端。

深入學(xué)習(xí)Redis（4）：哨兵
https://www.cnblogs.com/kismetv/p/9609938.html

簡(jiǎn)書(shū): 多哨兵模式
https://www.jianshu.com/p/06ab9daf921d

緩存穿透，緩存擊穿，緩存雪崩

《進(jìn)大廠(chǎng)系列》系列-Redis緩存雪崩、擊穿、穿透
https://zhuanlan.zhihu.com/p/89961333

REDIS緩存穿透，緩存擊穿，緩存雪崩原因+解決方案
https://www.cnblogs.com/midoujava/p/11277096.html

保證緩存(redis)與數(shù)據(jù)庫(kù)(MySQL)的一致性

https://blog.csdn.net/wwd0501/article/details/106902856/

總結(jié)

以上是生活随笔為你收集整理的NoSQL数据库_Redis的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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