java之Redis 專(zhuān)題 丨【奔跑吧！JAVA】

一、?redis 基本知識(shí)

1.1. redis 概述

Redis 本質(zhì)上是一個(gè) Key-Value 類(lèi)型的內(nèi)存數(shù)據(jù)庫(kù)，很像 memcached，整個(gè) 數(shù)據(jù)庫(kù)統(tǒng)統(tǒng)加載在內(nèi)存當(dāng)中進(jìn)行操作，定期通過(guò)異步操作把數(shù)據(jù)庫(kù)數(shù)據(jù) flush 到硬盤(pán)上進(jìn)行保存。因?yàn)槭羌儍?nèi)存操作，Redis 的性能非常出色，每秒 可以處理超過(guò) 10 萬(wàn)次讀寫(xiě)操作，是已知性能最快的 Key-Value DB。Redis 的出色之處不僅僅是性能，

Redis 最大的魅力是支持保存多種數(shù)據(jù)結(jié)構(gòu)，此外單 個(gè) value 的最大限制是 1GB，不像 memcached 只能保存 1MB 的數(shù)據(jù)，另外 Redis 也可以對(duì)存入的 Key-Value 設(shè)置 expire 時(shí)間。

Redis 的主要缺點(diǎn)是數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制，不能用作海量數(shù)據(jù)的高性能讀寫(xiě)，因此 Redis 適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。

【redis 是什么？】數(shù)據(jù)庫(kù)分為關(guān)系數(shù)據(jù)庫(kù)和鍵值數(shù)據(jù)庫(kù) redis 在本質(zhì)上是鍵值數(shù)據(jù)庫(kù)

1.xml 配置文件中配置 bean（JedisPool/JedisCluster）,再配置屬性注入指定 redis 的 host 和 port，集群的話需 要指定每一個(gè) redis 的 host 和 port，在配置一個(gè) bean（自己寫(xiě)的 JedisClient 接口）

2.【面相接口編程】項(xiàng)目中 JedisClient 接口工具類(lèi)的書(shū)寫(xiě)

【接口】寫(xiě)一個(gè) JedisClient 接口，接口中有 set、get、hset、hget、hdel、expire 等常用方法；

【實(shí)現(xiàn)類(lèi)】分別用集群版的 JedisClientCluster 和單機(jī)版的 JedisClientPool 去實(shí)現(xiàn)，并重寫(xiě)方法，各自用自 己的方式實(shí)現(xiàn)功能；

【調(diào)用】在管理 redis 的時(shí)候，我們只需要@AutoWied（只打開(kāi)一個(gè)得情況下）注入接口，只需要調(diào)用接 口里的方法，不用管調(diào)用的是集群版還是單機(jī)版的，這個(gè)可以在配置文件中控制。

【存值】項(xiàng)目中存的時(shí)候用的是存 hash 值，一個(gè) key，對(duì)應(yīng)一個(gè) map（key，value）；redis 可以存五種類(lèi)型的數(shù)據(jù)（string、list、set、zset(sorted set)、hash）；因?yàn)榧尤氪嫒氲氖?string 的簡(jiǎn)單的 key/value 類(lèi)型，不同表的 id 可能會(huì)重復(fù)， 所以在最前面要添加一個(gè)商品的大的類(lèi)目作為區(qū)分

【應(yīng)用邏輯】在查詢(xún)一個(gè)商品的時(shí)候先查 redis 緩存，如果有取緩存，如果沒(méi)有，查數(shù)據(jù)庫(kù)，同步緩存； 當(dāng)數(shù)據(jù)庫(kù)跟新的時(shí)候，進(jìn)行 redis 緩存的 id 覆蓋/刪除

1.2 java 管理 redis

1)通過(guò) jedis 單機(jī)版的通過(guò) JedisPool 獲取一個(gè) Jedis 對(duì)象來(lái) set、get 管理，用完需要關(guān)閉 Jedis 集群版的通過(guò) JedisCluster 來(lái) set、get 管理

2)通過(guò) spring data redis，項(xiàng)目中這種

1.3 Redis 五種數(shù)據(jù)類(lèi)型（不能存儲(chǔ)對(duì)象）

1.String：key-value（做緩存）

常用命令:

get /set /incr 加一

/decr 減一

2.Hash：key-fields-values（做緩存）

(相當(dāng)于一個(gè) key 對(duì)應(yīng)一個(gè) map,map 中還有 key-value)

常用命令:

hset:從 hash 中添加內(nèi)容/hget:從 hash 中取內(nèi)容

hset hash1 field3 3 /hget hash1 field3

3.List：有順序可重復(fù)

常用命令:

添加:lpush/rpush/

查看:lrange list1 0 -1/

取刪:lpop/ rpop

4.Set：無(wú)順序，不能重復(fù)

常用命令:

添加:sadd set1 a b c c c d

查看:smembers set1

刪除:srem set1 a

5.SortedSet（zset）：有順序，不能重復(fù)

常用命令:

分?jǐn)?shù)添加:zadd zset1 2 a 5 b 1 c 6 d

分?jǐn)?shù)查看:zrange zset1 0 -1

刪除:zrem zset1 a

反過(guò)來(lái)順序查看:zrevrange zset1 0 -1

1.4 key 命令

設(shè)置 10 秒鐘過(guò)期: expire key 秒

查看過(guò)期時(shí)間(s) : ttl key

設(shè)置持久化: persist key , ttl key 值為-1,意思為持久保存,值為-2,意思是不存在/已經(jīng)刪掉了

1.5 Redis 持久化

RDB 持久化（默認(rèn)方式）

該機(jī)制是指在制定的時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)。

優(yōu)點(diǎn)： 1.只有一份 rdb 文件，可隨時(shí)備份

2.比 AOF 文件小，加載效率高

3.只提供 fork 子進(jìn)程，不阻塞主進(jìn)程，IO 操作比較少

AOF 持久化

該機(jī)制將以日志的形式記錄服務(wù)器所處理的每一個(gè)寫(xiě)操作，在 Redis 服務(wù)器啟動(dòng)之初會(huì)讀取該文件來(lái)重新構(gòu)建數(shù)據(jù)庫(kù)，以保證啟動(dòng)后數(shù)據(jù)庫(kù)中的數(shù)據(jù)是完整的。

優(yōu)點(diǎn)： 1.每次改動(dòng)同步數(shù)據(jù)安全性好

2.APPEND 方式追加日志，不會(huì)對(duì)舊日志文件產(chǎn)生影響

無(wú)持久化

我們可以通過(guò)配置的方式禁用 Redis 服務(wù)器的持久化功能，這樣我們就可以將 Redis 視為一個(gè)功能加強(qiáng)版 的 memcached 了

同時(shí)應(yīng)用 AOF 和 RDB（推薦用）

用 AOF 來(lái)保證數(shù)據(jù)不丟失，作為恢復(fù)數(shù)據(jù)的第一選擇；用 RDB 來(lái)做不同程度的冷備，在 AOF 文件都丟失或損壞不可用的時(shí)候，可以使用 RDB 進(jìn)行快速的數(shù)據(jù)恢復(fù)。

二、redis 集群知識(shí)

2.1 redis 集群

集群指的是將幾臺(tái)服務(wù)器集中在一起，實(shí)現(xiàn)同一業(yè)務(wù)

目的：高可用、負(fù)載均衡、易擴(kuò)展、數(shù)據(jù)安全、性能提升

技術(shù)：集群地址（虛擬 IP）、網(wǎng)絡(luò)通信（監(jiān)控消息）

功能：負(fù)載均衡、讀寫(xiě)分離、故障轉(zhuǎn)移

2.2 怎樣判斷 redis 服務(wù)是否正常？

ping-pong 機(jī)制來(lái)判斷節(jié)點(diǎn)是否掛了

啟動(dòng)./redis-service redis.conf(后臺(tái)運(yùn)行)

客戶(hù)端：./reids-cli -h -p (默認(rèn) 6379）來(lái)連接

還可以通過(guò)哨兵模式監(jiān)控（多了解下哨兵模式）

2.3 架構(gòu)細(xì)節(jié)

(1)所有的 redis 節(jié)點(diǎn)彼此互聯(lián)(PING-PONG 機(jī)制),內(nèi)部使用二進(jìn)制協(xié)議優(yōu)化速度和帶寬.

(2)節(jié)點(diǎn)的 fail 是通過(guò)集群中超過(guò)半數(shù)的節(jié)點(diǎn)檢測(cè)失效時(shí)才生效.

(3)客戶(hù)端與 redis 節(jié)點(diǎn)直連,不需要中間 proxy 層.

客戶(hù)端不需要連接集群所有節(jié)點(diǎn),連接集群中任何一個(gè)可用節(jié)點(diǎn)即可

(4)redis-cluster 把所有的物理節(jié)點(diǎn)映射到[0-16383]slot 上,cluster 負(fù)責(zé)維護(hù)

(5)每個(gè)節(jié)點(diǎn)存儲(chǔ)的數(shù)據(jù)不一樣，但每個(gè)節(jié)點(diǎn)都會(huì)有備份機(jī)，主從機(jī)存儲(chǔ)一樣的數(shù)據(jù)

集群如何存儲(chǔ)數(shù)據(jù)

Redis 集群中內(nèi)置了 16384 個(gè)哈希槽，當(dāng)需要在 Redis 集群中放置一個(gè) key-value 時(shí)，redis 先對(duì) key 使用 crc16 算法算出一個(gè)結(jié)果，然后把結(jié)果對(duì) 16384 求余數(shù)，這樣每個(gè) key 都會(huì)對(duì)應(yīng)一個(gè)編號(hào)在 0- 16383 之間的哈希槽，redis 會(huì)根據(jù)節(jié)點(diǎn)數(shù)量大致均等的將哈希槽映射到不同的節(jié)點(diǎn)

2.4 redis 集群搭建過(guò)程（使用 ruby 腳本搭建集群）

-->刪除 aof 和 rdb 文件

-->安裝 ruby 和 ruby 使用的腳本包 redis-gem

--> 得到 redis-trib.rb，用它來(lái)創(chuàng)建集群

三、常問(wèn)問(wèn)題

1? ?為什么 redis 的查詢(xún)速度比 mysql 數(shù)據(jù)庫(kù)快?

1.存在物理內(nèi)存中

2.是鍵值數(shù)據(jù)庫(kù)，本身具有簡(jiǎn)單快捷的特點(diǎn)

redis 是怎樣存入磁盤(pán)的？

dump.rdb 和 appendonly.aof 兩個(gè)配置文件【rdbaof 熱帶暴風(fēng)】

RDB:在指定時(shí)間間隔內(nèi)將內(nèi)存中的數(shù)據(jù)集快照寫(xiě)入磁盤(pán)（默認(rèn)）

AOF：以日志的形式將記錄服務(wù)器的每一個(gè)操作

2? ?為什么 redis 集群中必須至少有三個(gè)節(jié)點(diǎn)?

一個(gè)節(jié)點(diǎn)掛了,有一半以上的節(jié)點(diǎn)通過(guò) ping-pong 方式的投票機(jī)制認(rèn)為它掛了,那么這個(gè)集群就掛了.

但如果 只有 2 個(gè)節(jié)點(diǎn),有一個(gè)掛了,另一個(gè)確定它掛了但百分比只占到了 50%,沒(méi)有超過(guò)一半,這個(gè)集群也不會(huì)掛,所以至 少需要 3 個(gè)節(jié)點(diǎn)；

3? ?為什么每個(gè) redis 集群需要至少 6 臺(tái)服務(wù)器?

因?yàn)?redis 集群至少需要三個(gè)節(jié)點(diǎn),要保證集群的高可用,每個(gè)節(jié)點(diǎn)都要一個(gè)備份機(jī).理論上也需要 6 臺(tái)虛擬機(jī)

4 redis 優(yōu)缺點(diǎn)

Redis 的優(yōu)點(diǎn)？

性能極高 – Redis 能支持超過(guò) 100K+ 每秒的讀寫(xiě)頻率。

豐富的數(shù)據(jù)類(lèi)型 – Redis 支持二進(jìn)制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 數(shù)據(jù)類(lèi)型操作。

原子 –

Redis 的所有操作都是原子性的，同時(shí) Redis 還支持對(duì)幾個(gè)操作全并后的原子性執(zhí)行。

豐富的特性 – Redis 還支持 publish/subscribe, 通知, key 過(guò)期等等特性。

Redis 相比其它緩存，他有兩種持久化機(jī)制，RDB 和 AOF，數(shù)據(jù)更安全。

Redis 的缺點(diǎn)？

是數(shù)據(jù)庫(kù)容量受到物理內(nèi)存的限制,不能用作海量數(shù)據(jù)的高性能讀寫(xiě),因此 Redis 適合的場(chǎng)景主要局限在較小數(shù)據(jù)量的高性能操作和運(yùn)算上。

5 一致性哈希算法 一

致性哈希算法(Consistent Hashing Algorithm)是一種分布式算法，常用于負(fù)載均衡。twemproxy 也選擇這種 算法，解決將 key-value 均勻分配到眾多 server 上的問(wèn)題。它可以取代傳統(tǒng)的取模操作，解決了取模操作應(yīng)對(duì) 增刪 Server 的問(wèn)題。

**

步驟

**

1. 先用 hash 算法將對(duì)應(yīng)的節(jié)點(diǎn) ip 哈希到一個(gè)具有 2^32 次方個(gè)桶的空間中，即 0~（2^32）-1 的數(shù)字空間。

現(xiàn)在我們可以將這些數(shù)字頭尾相連，連接成一個(gè)閉合的環(huán)形

2. 當(dāng)用戶(hù)在客戶(hù)端進(jìn)行請(qǐng)求時(shí)候，首先根據(jù) key 計(jì)算路由 hash 值，然后看 hash 值落到了 hash 環(huán)的哪個(gè)地方，根據(jù) hash 值在 hash 環(huán)上的位置順時(shí)針找距離最近的節(jié)點(diǎn)

3. 當(dāng)新增節(jié)點(diǎn)的時(shí)候，和之前的做法一樣，只需要把受到影響的數(shù)據(jù)遷移到新節(jié)點(diǎn)即可新增 Master4 節(jié)點(diǎn)：

4. 當(dāng)移除節(jié)點(diǎn)的時(shí)候，和之前的做法一樣，把移除節(jié)點(diǎn)的數(shù)據(jù)，遷移到順時(shí)針距離最近的節(jié)點(diǎn)移除 Master2 節(jié)點(diǎn)：

當(dāng)節(jié)點(diǎn)個(gè)數(shù)變動(dòng)時(shí)，使用哈希一致性映射關(guān)系失效的對(duì)象非常少，遷移成本也非 常小。那么判斷一個(gè)哈希算法好壞的指標(biāo)有哪些呢？以下列出了 3 個(gè)指標(biāo)：

* 平衡性（Balance）：

平衡性是指哈希的結(jié)果能夠盡可能分散到不同的緩存服務(wù)器上去，這樣可以使得所有的服務(wù)器得到利用。 一致性 hash 可以做到每個(gè)服務(wù)器都進(jìn)行處理理請(qǐng)求，但是不能保證每個(gè)服務(wù)器處理的請(qǐng)求的數(shù)量大致相同

* 單調(diào)性（Monotonicity）：

單調(diào)性是指如果已經(jīng)有一些請(qǐng)求通過(guò)哈希分派到了相應(yīng)的服務(wù)?進(jìn)行處理，又有新的服務(wù)器加入到系統(tǒng)中時(shí)候，哈希的結(jié)果應(yīng)保證原有的請(qǐng)求可以被映射到原有的或者新的服務(wù)?中去，而不會(huì)被映射到原來(lái)的其它服務(wù)?上去。

* 分散性（Spread）：

分布式環(huán)境中，客戶(hù)端請(qǐng)求時(shí)候可能不知道所有服務(wù)器的存在，可能只知道其中一部分服務(wù)器，在客戶(hù)端 看來(lái)他看到的部分服務(wù)?會(huì)形成一個(gè)完整的 hash 環(huán)。如果多個(gè)客戶(hù)端都把部分服務(wù)器作為一個(gè)完整 hash 環(huán)，那么可能會(huì)導(dǎo)致，同一個(gè)用戶(hù)的請(qǐng)求被路由到不同的服務(wù)器進(jìn)行處理。這種情況顯然是應(yīng)該避免的，因?yàn)樗?/p>

能保證同一個(gè)用戶(hù)的請(qǐng)求落到同一個(gè)服務(wù)?。所謂分散性是指上述情況發(fā)生的嚴(yán)重程度。好的哈希算法應(yīng)盡量避免盡量降低分散性。 而一致性 hash 具有很低的分散性。

6 使用過(guò) Redis 做異步隊(duì)列么，你是怎么用的？有什么缺點(diǎn)？

一般使用 list 結(jié)構(gòu)作為隊(duì)列，rpush 生產(chǎn)消息，lpop 消費(fèi)消息。當(dāng) lpop 沒(méi)有消息的時(shí)候，要適當(dāng) sleep 一會(huì)再重試。

缺點(diǎn)：

在消費(fèi)者下線的情況下，生產(chǎn)的消息會(huì)丟失，得使用專(zhuān)業(yè)的消息隊(duì)列如 rabbitmq 等。

7 什么是緩存穿透？如何避免？什么是緩存雪崩？何如避免？

緩存穿透

一般的緩存系統(tǒng)，都是按照 key 去緩存查詢(xún)，如果不存在對(duì)應(yīng)的 value，就應(yīng)該去后端系統(tǒng)查找（比如 DB）。

一些惡意的請(qǐng)求會(huì)故意查詢(xún)不存在的 key,請(qǐng)求量很大，就會(huì)對(duì)后端系統(tǒng)造成很大的壓力。這就叫做緩存穿透。

如何避免？

1：對(duì)查詢(xún)結(jié)果為空的情況也進(jìn)行緩存，緩存時(shí)間設(shè)置短一點(diǎn)，或者該 key 對(duì)應(yīng)的數(shù)據(jù) insert 了之后清理緩存。

2：對(duì)一定不存在的 key 進(jìn)行過(guò)濾。可以把所有的可能存在的 key 放到一個(gè)大的 Bitmap 中，查詢(xún)時(shí)通過(guò)該 bitmap 過(guò)濾。

緩存雪崩

當(dāng)緩存服務(wù)器重啟或者大量緩存集中在某一個(gè)時(shí)間段失效，這樣在失效的時(shí)候，會(huì)給后端系統(tǒng)帶來(lái)很大壓力。 導(dǎo)致系統(tǒng)崩潰。

如何避免？

1：在緩存失效后，通過(guò)加鎖或者隊(duì)列來(lái)控制讀數(shù)據(jù)庫(kù)寫(xiě)緩存的線程數(shù)量。比如對(duì)某個(gè) key 只允許一個(gè)線程查詢(xún)數(shù)據(jù)和寫(xiě)緩存，其他線程等待。

2：做二級(jí)緩存，A1 為原始緩存，A2 為拷貝緩存，A1 失效時(shí)，可以訪問(wèn) A2，A1 緩存失效時(shí)間設(shè)置為短期，A2 設(shè)置為長(zhǎng)期

3：不同的 key，設(shè)置不同的過(guò)期時(shí)間，讓緩存失效的時(shí)間點(diǎn)盡量均勻。

8 Redis 為什么是單線程的?

單純的網(wǎng)絡(luò) IO 來(lái)說(shuō)，量大到一定程度之后，多線程的確有優(yōu)勢(shì)——但并不是單純的多線程，而是每個(gè)線程自 己有自己的 epoll 這樣的模型，也就是多線程和 multiplexing 混合。一般這個(gè)開(kāi)頭我們都會(huì)跟一個(gè)“但是”。但是。還要考慮 Redis 操作的對(duì)象。它操作的對(duì)象是內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)。如果在多線程中操作，那就需要為這些 對(duì)象加鎖。最終來(lái)說(shuō)，多線程性能有提高，但是每個(gè)線程的效率嚴(yán)重下降了。而且程序的邏輯嚴(yán)重復(fù)雜化。要知道 Redis 的數(shù)據(jù)結(jié)構(gòu)并不全是簡(jiǎn)單KeyValue，還有列表，hash，map 等等復(fù)雜的結(jié)構(gòu)，這些結(jié)構(gòu)有可能會(huì) 進(jìn)行很細(xì)粒度的操作，比如在很長(zhǎng)的列表后面添加一個(gè)元素，在 hash 當(dāng)中添加或者刪除一個(gè)對(duì)象，等等。一些操作還可以合成 MULTI/EXEC 的組。這樣一個(gè)操作中可能就需要加非常多的鎖，導(dǎo)致的結(jié)果是同步開(kāi)銷(xiāo)大大增加。這還帶來(lái)一個(gè)惡果就是吞吐量雖然增大，但是響應(yīng)延遲可能會(huì)增加。

Redis 在權(quán)衡之后的選擇是用單線程，突出自己功能的靈活性。在單線程基礎(chǔ)上任何原子操作都可以幾乎無(wú)代 價(jià)地實(shí)現(xiàn)，多么復(fù)雜的數(shù)據(jù)結(jié)構(gòu)都可以輕松運(yùn)用，甚至可以使用 Lua 腳本這樣的功能。對(duì)于多線程來(lái)說(shuō)這需要 高得多的代價(jià)。

并不是所有的 KV 數(shù)據(jù)庫(kù)或者內(nèi)存數(shù)據(jù)庫(kù)都應(yīng)該用單線程，比如 ZooKeeper 就是多線程的，最終還是看自己的意愿和取舍。單線程的威力實(shí)際上非常強(qiáng)大，每核心效率也非常高，在今天的虛擬化環(huán)境當(dāng)中可以充分利 用云化環(huán)境來(lái)提高資源利用率。多線程自然是可以比單線程有更高的性能上限，但是在今天的計(jì)算環(huán)境中，即使是單機(jī)多線程的上限也往往不能滿足需要了，需要進(jìn)一步摸索的是多服務(wù)器集群化的方案，這些方案中多線程的技術(shù)照樣是用不上的，所以單線程、多進(jìn)程的集群不失為一個(gè)時(shí)髦的解決方案。

9 redis 的通信協(xié)議是什么？

我們不需要一個(gè)特殊的 Redis客戶(hù)端僅靠Telnet或者是文本流就可以跟Redis進(jìn)行通訊。客戶(hù)端的命令格式:

簡(jiǎn)單字符串Simple Strings，以“+"加號(hào)開(kāi)頭。錯(cuò)誤Errors，以"-"減號(hào)開(kāi)頭。

整數(shù)型Integer，以“”冒號(hào)開(kāi)頭。

大字符串類(lèi)型Bulk Strings，以"$美元符號(hào)開(kāi)頭。

數(shù)組類(lèi)型Arrays，以“*"星號(hào)開(kāi)頭。

set hello abc 一個(gè)簡(jiǎn)單的文本流就可以是redis的客戶(hù)端

簡(jiǎn)單總結(jié)：具體可以見(jiàn)：

https://redis.io/topics/protocol ，

Redis 文檔認(rèn)為簡(jiǎn)單的實(shí)現(xiàn)，快速的解析，直觀理解是采用 RESP 文本協(xié)議最重要的地方，有可能文本協(xié)議會(huì)造成一定量的流量浪費(fèi)，但卻在性能上和操作上快速簡(jiǎn)單，這中間也是一個(gè)權(quán)衡和協(xié)調(diào)的過(guò)程。

10 redis 使用場(chǎng)景

（1）、會(huì)話緩存（Session Cache）

（2）、全頁(yè)緩存（FPC）

（3）、隊(duì)列

（4）、排行榜/計(jì)數(shù)器

（5）、發(fā)布/訂閱

11 如何提高緩存的利用率？

做數(shù)據(jù)的緩存時(shí)，因?yàn)閿?shù)據(jù)量很大，而且緩存是把數(shù)據(jù)保存到內(nèi)存中，此時(shí)不可能把所有的數(shù)據(jù)都放到緩存中。

所以需要設(shè)置數(shù)據(jù)緩存的有效期，當(dāng)用戶(hù)訪問(wèn)到非熱點(diǎn)數(shù)據(jù)后，此數(shù)據(jù)放到緩存中，當(dāng)緩存到期后就從緩 存中刪除，而且長(zhǎng)時(shí)間不會(huì)添加到緩存。而熱點(diǎn)數(shù)據(jù)一旦從緩存中刪除會(huì)馬上又添加到緩存。這樣可以提 高緩存的利用率，同時(shí)也減輕了數(shù)據(jù)庫(kù)的壓力。

12 項(xiàng)目中使用到了緩存，那么如何實(shí)現(xiàn)緩存同步的？

只要使用了緩存就涉及到緩存同步的問(wèn)題。緩存同步其實(shí)就是當(dāng)緩存的信息發(fā)生變化，也就是對(duì)后臺(tái)對(duì)緩存的 數(shù)據(jù)進(jìn)行增、刪、改操作后，數(shù)據(jù)庫(kù)中的數(shù)據(jù)發(fā)生了化同時(shí)要把緩存中的數(shù)據(jù)對(duì)應(yīng)刪除即可。當(dāng)頁(yè)面再次請(qǐng)求數(shù)據(jù)時(shí)，緩存中不能命中就會(huì)從數(shù)據(jù)庫(kù)中查詢(xún)并且添加到緩存中，即實(shí)現(xiàn)了緩存同步。

13 redis 事物，了解 CAS(check-and-set 操作實(shí)現(xiàn)樂(lè)觀鎖 )?

和 眾 多 其 它 數(shù) 據(jù) 庫(kù) 一 樣 ， Redis 作 為 NoSQL 數(shù) 據(jù) 庫(kù) 也 同 樣 提 供 了 事 務(wù) 機(jī) 制 。 在 Redis 中 ， MULTI/EXEC/DISCARD/WATCH 這四個(gè)命令是我們實(shí)現(xiàn)事務(wù)的基石。相信對(duì)有關(guān)系型數(shù)據(jù)庫(kù)開(kāi)發(fā)經(jīng)驗(yàn)的開(kāi)發(fā)者 而言這一概念并不陌生，即便如此，我們還是會(huì)簡(jiǎn)要的列出

Redis 中

事務(wù)的實(shí)現(xiàn)特征：

1). 在事務(wù)中的所有命令都將會(huì)被串行化的順序執(zhí)行，事務(wù)執(zhí)行期間，Redis 不會(huì)再為其它客戶(hù)端的請(qǐng)求提供任

何服務(wù)，從而保證了事物中的所有命令被原子的執(zhí)行。

2). 和關(guān)系型數(shù)據(jù)庫(kù)中的事務(wù)相比，在 Redis 事務(wù)中如果有某一條命令執(zhí)行失敗，其后的命令仍然會(huì)被繼續(xù)執(zhí)行。

3). 我們可以通過(guò) MULTI 命令開(kāi)啟一個(gè)事務(wù)，有關(guān)系型數(shù)據(jù)庫(kù)開(kāi)發(fā)經(jīng)驗(yàn)的人可以將其理解為"BEGIN TRANSACTION"語(yǔ)句。在該語(yǔ)句之后執(zhí)行的命令都將被視為事務(wù)之內(nèi)的操作，最后我們可以通過(guò)執(zhí)行 EXEC/DISCARD 命令來(lái)提交/回滾該事務(wù)內(nèi)的所有操作。這兩個(gè) Redis 命令可被視為等同于關(guān)系型數(shù)據(jù)庫(kù)中的 COMMIT/ROLLBACK 語(yǔ)句。

4). 在事務(wù)開(kāi)啟之前，如果客戶(hù)端與服務(wù)器之間出現(xiàn)通訊故障并導(dǎo)致網(wǎng)絡(luò)斷開(kāi)，其后所有待執(zhí)行的語(yǔ)句都將不

會(huì)被服務(wù)器執(zhí)行。然而如果網(wǎng)絡(luò)中斷事件是發(fā)生在客戶(hù)端執(zhí)行 EXEC 命令之后，那么該事務(wù)中的所有命令都會(huì)

被服務(wù)器執(zhí)行。

5). 當(dāng)使用 Append-Only 模式時(shí)，Redis 會(huì)通過(guò)調(diào)用系統(tǒng)函數(shù) write 將該事務(wù)內(nèi)的所有寫(xiě)操作在本次調(diào)用中全部 寫(xiě)入磁盤(pán)。然而如果在寫(xiě)入的過(guò)程中出現(xiàn)系統(tǒng)崩潰，如電源故障導(dǎo)致的宕機(jī)，那么此時(shí)也許只有部分?jǐn)?shù)據(jù)被寫(xiě) 入到磁盤(pán)，而另外一部分?jǐn)?shù)據(jù)卻已經(jīng)丟失。

Redis 服務(wù)器會(huì)在重新啟動(dòng)時(shí)執(zhí)行一系列必要的一致性檢測(cè)，一旦發(fā)現(xiàn)類(lèi)似問(wèn)題，就會(huì)立即退出并給出相應(yīng)的 錯(cuò)誤提示。此時(shí)，我們就要充分利用 Redis 工具包中提供的 redis-check-aof 工具，該工具可以幫助我們定位到 數(shù)據(jù)不一致的錯(cuò)誤，并將已經(jīng)寫(xiě)入的部分?jǐn)?shù)據(jù)進(jìn)行回滾。修復(fù)之后我們就可以再次重新啟動(dòng) Redis 服務(wù)器了。

14? Redis 有哪幾種數(shù)據(jù)結(jié)構(gòu)？

Redis 的數(shù)據(jù)結(jié)構(gòu)有五種，分別是：

String——字符串

String 數(shù)據(jù)結(jié)構(gòu)是簡(jiǎn)單的 key-value 類(lèi)型，value 不僅可以是 String，也可以是數(shù)字（當(dāng)數(shù)字類(lèi)型用 Long 可以表示的時(shí)候 encoding 就是整型，其他都存儲(chǔ)在 sdshdr 當(dāng)做字符串）。

Hash——字典

在 Memcached 中，我們經(jīng)常將一些結(jié)構(gòu)化的信息打包成 hashmap，在客戶(hù)端序列化后存儲(chǔ)為一個(gè)字符串的值 （一般是 JSON 格式），比如用戶(hù)的昵稱(chēng)、年齡、性別、積分等。

List——列表

List 說(shuō)白了就是鏈表（redis 使用雙端鏈表實(shí)現(xiàn)的 List），相信學(xué)過(guò)數(shù)據(jù)結(jié)構(gòu)知識(shí)的人都應(yīng)該能理解其結(jié)構(gòu)。

Set——集合

Set 就是一個(gè)集合，集合的概念就是一堆不重復(fù)值的組合。利用 Redis 提供的 Set 數(shù)據(jù)結(jié)構(gòu)，可以存儲(chǔ)一些集合性的數(shù)據(jù)。

Sorted Set——有序集合

和 Sets 相比，Sorted Sets 是將 Set 中的元素增加了一個(gè)權(quán)重參數(shù) score，使得集合中的元素能夠按 score 進(jìn)行有序排列，

1. 帶有權(quán)重的元素，比如一個(gè)游戲的用戶(hù)得分排行榜

2.比較復(fù)雜的數(shù)據(jù)結(jié)構(gòu)，一般用到的場(chǎng)景不算太多

【奔跑吧！JAVA】有獎(jiǎng)?wù)魑幕馃徇M(jìn)行中：https://bbs.huaweicloud.com/blogs/265241

Java Redis Spring

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。

版權(quán)聲明：本文內(nèi)容由網(wǎng)絡(luò)用戶(hù)投稿，版權(quán)歸原作者所有，本站不擁有其著作權(quán)，亦不承擔(dān)相應(yīng)法律責(zé)任。如果您發(fā)現(xiàn)本站中有涉嫌抄襲或描述失實(shí)的內(nèi)容，請(qǐng)聯(lián)系我們jiasou666@gmail.com 處理，核實(shí)后本網(wǎng)站將在24小時(shí)內(nèi)刪除侵權(quán)內(nèi)容。