Redis持久化實例分析

本篇內(nèi)容介紹了“Redis持久化實例分析”的有關(guān)知識，在實際案例的操作過程中，不少人都會遇到這樣的困境，接下來就讓小編帶領(lǐng)大家學(xué)習(xí)一下如何處理這些情況吧！希望大家仔細(xì)閱讀，能夠?qū)W有所成！

面試官：小伙子，談?wù)剬edis的看法。
我：啊，看法呀，坐著看還是躺著看。Redis很?。亢芸?？但很持久？

面試官：一本正經(jīng)的說，我懷疑你在開車，不僅開開車還搞顏色。
我：。。。

面試官：去去去，我時間有限，別瞎扯淡。回到正題，你對Redis了解有多少。
我：輕量體積小、基于內(nèi)存非?？?、RDB配合AOF持久化讓其一樣堅挺持久。

面試官：說點具體的。
我：請看正文。

正文

簡介
Redis是一個開源的、高性能的、基于鍵值對的緩存與存儲系統(tǒng)，通過提供多種鍵值數(shù)據(jù)類型來適應(yīng)不同場景下的緩存與存儲需求。與此同時，Redis的諸多高層級功能讓其可以勝任消息隊列、任務(wù)隊列等不同的角色。除此之外，Redis還支持外部模塊擴(kuò)展，在某些特定的場景下可以作為主數(shù)據(jù)庫使用。

由于內(nèi)存的讀寫速度遠(yuǎn)快于硬盤，就算現(xiàn)在的固態(tài)盤思維估計也是朝著內(nèi)存那個思維模式發(fā)展的，大概也許我是個外行，但是長久存儲還是使用機(jī)械盤。所以Redis數(shù)據(jù)庫中的所有數(shù)據(jù)都存儲在內(nèi)存中那是相當(dāng)快的。也有一定的風(fēng)險，會導(dǎo)致丟失數(shù)據(jù)，但配合RDB以及AOF持久化會減少風(fēng)險。

一、初識Redis

1、linux下安裝（Redhat7系列）

1.1、安裝

此處準(zhǔn)備的是源碼包，版本不在于最新，在于穩(wěn)定適用。

其余版本在官網(wǎng)獲取，或者在其托管的平臺github上獲取，如下為Redis的官網(wǎng)下載地址。

https://redis.io/download

redis-6.0.8.tar.gz#安裝tar -zxvf redis-6.0.8.tar.gz#編譯make && make install

1.2、排查錯誤

make[1]: *** [server.o] 錯誤 1

1.3、解決方案

1.3.1、安裝依賴環(huán)境

yum -y install centos-release-scl
yum -y install devtoolset-9-gcc devtoolset-9-gcc-c++ devtoolset-9-binutils

1.3.2、加環(huán)境變量并生效

scl enable devtoolset-9 bashecho "/opt/rh/devtoolset-9/enable" >> /etc/profile

重新讀取環(huán)境變量配置文件

source /etc/profile

重新編譯解決問題

#切換到Redis的安裝目錄,一般源碼包安裝會放在/usr/local/下面，看個人使用習(xí)慣cd /opt/redis-6.0.8/
#編譯make && make install

常用基本命令練習(xí)可以參考菜鳥教程

https://www.runoob.com/redis/redis-commands.html

1.4、啟動與登錄

啟動redis-server服務(wù)端

#啟動redis服務(wù)nohup /opt/redis-6.0.8/src/redis-server &

登錄redis-cli客戶端

#登錄redis-cli/opt/redis-6.0.8/src/redis-cli

測試驗證，此時linux下的redis正式啟動成功，下面會帶來基本用法介紹。

pingpong

1.5、設(shè)置密碼

默認(rèn)是沒有開放密碼設(shè)置的，需要手動開啟注釋掉的參數(shù)配置。

#編輯配置文件vim /opt/redis-6.0.8/redis.conf
#原本的被注釋掉,復(fù)制一行改成你設(shè)置的密碼即可
#requirepass foobaredrequirepass 123456

2、Windows下安裝

2.1、安裝

Redis-x64-3.2.100.zip

2.1.1、Windows下解壓或者msi直接安裝即可。

2.1.2、設(shè)置服務(wù)命令（注冊為服務(wù)形式，自啟）
安裝服務(wù)

redis-server --service-install redis.windows-service.conf --loglevel verbose

卸載服務(wù)

redis-server --service-uninstall

2.2、啟動與關(guān)閉

redis-server redis.windows.conf

2.2.1、開啟服務(wù)

redis-server --service-start

2.2.2、停止服務(wù)

redis-server --service-stop

2.3、啟動redis服務(wù)

#同樣在redis解壓的或者安裝的目錄以管理員身份運行cmdredis-server --service-start

2.4、cmd下運行測試登錄

#在redis解壓的或者安裝的目錄以管理員身份運行cmdredis-cli.exe -h 127.0.0.1 -p 6379
#或者直接執(zhí)行redis-cli
#執(zhí)行redis-cli
#登錄測試ping

5、Windows下的管理工具rdm，是可視化界面
https://redisdesktop.com/download

二、基礎(chǔ)知識

1、面試常問到

面試官：redis中的數(shù)據(jù)類型有哪些，能聊聊嗎？

我：string（字符串類型）、hash（哈希類型）、list（列表類型）、set（集合類型）、zset（有序集合類型）、stream（流類型）
stream是redis5.0新增的特性支持。

面試官：嚯，小伙子有點東西啊，知道的還不少嘛，連stream流類型都知道。

我：一臉懵逼…

三、進(jìn)階

1、持久化

面試官：Redis的一些高級特性了解嗎？

我：略有了解。

面試官：能具體談?wù)剢幔?/p>

我：飛速在大腦搜索者以前看書總結(jié)的。緩存、持久化迎面而來。

將Redis作為緩存服務(wù)器，但緩存被穿透后會對性能照成較大影響，所有緩存同時失效緩存雪崩，從而使服務(wù)無法響應(yīng)。

我們希望Redis能將數(shù)據(jù)從內(nèi)存中以某種形式同步到磁盤中，使之重啟以后根據(jù)磁盤中的記錄恢復(fù)數(shù)據(jù)。這一過程就是持久化。

面試官：知道Redis有哪幾種常見的持久化方式嗎？

我：Redis默認(rèn)開啟的RDB持久化，AOF持久化方式需要手動開啟。

Redis支持兩種持久化。一種是RDB方式，一種是AOF方式。前者會根據(jù)指定的規(guī)則“定時”將內(nèi)存中的數(shù)據(jù)存儲到硬盤上，而后者在每次執(zhí)行命令后將命令本書記錄下來。對于這兩種持久化方式，你可以單獨使用其中一種，但大多數(shù)情況下是將二者緊密結(jié)合起來。

此時的面試官一臉期待，炯炯有神的看向了我，請繼續(xù)。

2、RDB方式

繼續(xù)介紹，RDB采取的是快照方式，默認(rèn)設(shè)置自定義快照【自動同步】，默認(rèn)配置如下。

同樣可以手動同步

#不推薦在生產(chǎn)環(huán)境中使用SAVE

#異步形式BGSAVE

#基于自定義快照FLASHALL

3、AOF方式

當(dāng)使用Redis存儲非臨時數(shù)據(jù)時，一般需要打開AOF持久化來降低進(jìn)程終止導(dǎo)致數(shù)據(jù)的丟失。AOF可以將Redis執(zhí)行的每一條命令追加到硬盤文件中，著這個過程中顯然會讓Redis的性能打折扣，但大部分情況下這種情況可以接受。這里強(qiáng)調(diào)一點，使用讀寫較快的硬盤可以提高AOF的性能。

默認(rèn)沒有開啟，需要手動開啟AOF，當(dāng)你查看redis.conf文件時也會發(fā)現(xiàn)appendonly配置的是no

appendonly yes

開啟AOF持久化后，每次執(zhí)行一條命令會會更改Redis中的數(shù)據(jù)的目錄，Redis會將該命令寫入磁盤中的AOF文件。AOF文件的保存位置和RDB文件的位置相同，都是通過dir參數(shù)設(shè)置，默認(rèn)的文件名是appendonly.aof，可以通過appendfilename參數(shù)修改。

appendfilename "appendonly.aof

實際上Redis也正是這樣做的，每當(dāng)達(dá)到一定的條件時Redis就會自動重寫AOF文件，這個條件可以通過redis.conf配置文件中設(shè)置：

auto-aof-rewrite-percentage 100auto-aof-rewrite-min-size 64mb

在啟動時Redis會逐行執(zhí)行AOF文件中的命令將硬盤中的數(shù)據(jù)加載到內(nèi)存中，加載的速度相比RDB會慢一些。

雖然每次執(zhí)行更改數(shù)據(jù)庫內(nèi)容的操作時，AOF都將命令記錄在AOF文件中。但事實上，由于操作系統(tǒng)的緩存機(jī)制，數(shù)據(jù)并沒與真正寫入硬盤，而是進(jìn)入了操作系統(tǒng)的硬盤緩存。在默認(rèn)情況下，操作系統(tǒng)每30秒會執(zhí)行一次同步操作，以便將硬盤緩存中的內(nèi)容寫入硬盤。

在Redis中可以通過appendfsync設(shè)置同步的時機(jī)：

# appendfsync always
#默認(rèn)設(shè)置為everysecappendfsync everysec
# appendfsync no

Redis允許同時開啟AOF和RDB。這樣既保證了數(shù)據(jù)的安全，又對進(jìn)行備份等操作比較友好。此時重新啟動Redis后，會使用AOF文件來恢復(fù)數(shù)據(jù)。因為AOF方式的持久化，將會丟失數(shù)據(jù)的概率降至最小化。

4、Redis復(fù)制

通過持久化功能，Redis保證了即使服務(wù)器重啟的情況下也不會丟失（少部分遺失）數(shù)據(jù)。但是數(shù)據(jù)庫是存儲在單臺服務(wù)器上的，難免不會發(fā)生各種突發(fā)情況，比如硬盤故障，服務(wù)器突然宕機(jī)等等，也會導(dǎo)致數(shù)據(jù)遺失。

為了盡可能的避免故障，通常做法是將數(shù)據(jù)庫復(fù)制多個副本以部署在不同的服務(wù)器上。這樣即使有一臺出現(xiàn)故障，其它的服務(wù)器依舊可以提供服務(wù)。為此，Redis提供了復(fù)制（replication）功能。即實現(xiàn)一個數(shù)據(jù)庫中的數(shù)據(jù)更新后，自動將更新的數(shù)據(jù)同步到其它數(shù)據(jù)庫上。

此時熟悉MySQL的同學(xué)，是不是覺得與MySQL的主從復(fù)制很像，以開啟二進(jìn)制日志binlog實現(xiàn)同步復(fù)制。

而Redis中使用復(fù)制功能更為容易，相比MySQL而言。只需要在從庫中啟動時加入slaveof 從數(shù)據(jù)庫地址。

#在從庫中配置slaveof master_database_ip_addr
#測試,加了nohup與&是放入后臺，并且輸出日志到/root/目錄下的nohup.outnohup /opt/redis-6.0.8/src/redis-server --6380 --slaveof 192.168.245.147 6379 &

4.1、原理

復(fù)制初始化。這里主要原理是從庫啟動，會向主庫發(fā)送SYNC命令。同時主庫接收到SYNC命令后會開始在后臺保存快照，即RDB持久化的過程，并將快照期間接收的命令緩存起來。當(dāng)快照完成后，Redis會將快照文件和所有緩存的命令發(fā)送給從數(shù)據(jù)庫。從數(shù)據(jù)庫收到后，會載入快照文件并執(zhí)行收到的緩存命令。

復(fù)制同步階段會貫穿整個主從同步過程，直到主從關(guān)系終止為止。在復(fù)制的過程中快照起到了至關(guān)重要的作用，只要執(zhí)行復(fù)制就會進(jìn)行快照，即使關(guān)閉了RDB方式的持久化，通過刪除所有save參數(shù)。

4.2、樂觀復(fù)制

Redis采用了樂觀復(fù)制（optimistic replication）的復(fù)制策略。容忍在一定時間內(nèi)主從數(shù)據(jù)庫的內(nèi)容是不同的，但是兩者的數(shù)據(jù)最終是會同步的。具體來講，Redis在主從數(shù)據(jù)庫之間復(fù)制數(shù)據(jù)的過程本身是異步的，這就意味著，主數(shù)據(jù)庫執(zhí)行完客戶端請求的命令會立即將命令在主數(shù)據(jù)庫的執(zhí)行結(jié)果反饋給客戶端，并異步的將數(shù)據(jù)同步給從庫，不會等待從數(shù)據(jù)庫接收到該命令在返回給客戶端。

當(dāng)數(shù)據(jù)至少同步給指定數(shù)量的從庫時，才是可寫，通過參數(shù)指定：

#設(shè)置最少限制3min-slaves-to-write 3
#設(shè)置允許從數(shù)據(jù)最長失去連接時間min-slaves-max-lag 10

4.3、增量復(fù)制

基于以下三點實現(xiàn)

• 從庫會存儲主庫的運行ID（run id）。每個Redis運行實例均會擁有一個唯一運行ID，每當(dāng)實例重啟后，就會自動生成一個新的運行ID。類似于MySQL的從節(jié)點配置的唯一ID去識別。

• 在復(fù)制同步階段，主庫一條命令被傳送到從庫時，會同時把該命令存放到一個積壓隊列（backlog）中，記錄當(dāng)前積壓隊列中存放的命令的偏移量范圍。

• 從庫接收到主庫傳來的命令時，會記錄該命令的偏移量。

4.4、注意

當(dāng)主數(shù)據(jù)庫崩潰時，情況略微復(fù)雜。手動通過從數(shù)據(jù)庫數(shù)據(jù)庫恢復(fù)主庫數(shù)據(jù)時，需要嚴(yán)格遵循以下原則：

• 在從數(shù)據(jù)庫中使用SLAVEOF NO ONE命令將從庫提升為主庫繼續(xù)服務(wù)。

• 啟動之前崩潰的主庫，然后使用SLAVEOF命令將其設(shè)置為新的主庫的從庫。

注意：當(dāng)開啟復(fù)制且數(shù)據(jù)庫關(guān)閉持久化功能時，一定不要使用supervisor以及類似的進(jìn)程管理工具令主庫崩潰后重啟。同樣當(dāng)主庫所在的服務(wù)器因故障關(guān)閉時，也要避免直接重新啟動。因為當(dāng)主庫重啟后，沒有開啟持久化功能，數(shù)據(jù)庫中所有數(shù)據(jù)都被清空。此時從庫依然會從主庫中接收數(shù)據(jù)，從而導(dǎo)致所有從庫也被清空，導(dǎo)致數(shù)據(jù)庫的持久化開了個寂寞。

手動維護(hù)確實很麻煩，好在Redis提供了一種自動化方案：哨兵去實現(xiàn)這一過程，避免手動維護(hù)易出錯的問題。

5、哨兵（sentinel）

從Redis的復(fù)制歷中，我們了解到在一個典型的一主多從的Redis系統(tǒng)中，從庫在整個系統(tǒng)中起到了冗余備份以及讀寫分離的作用。當(dāng)主庫遇到異常中斷服務(wù)后，開發(fā)人員手動將從升主時，使系統(tǒng)繼續(xù)服務(wù)。過程相對復(fù)雜，不好實現(xiàn)自動化。此時可借助哨兵工具。

哨兵的作用

• 監(jiān)控Redis系統(tǒng)運行情況

• 監(jiān)控主庫和從庫是否正常運行

• 主庫gg思密達(dá)，自動將從庫升為主庫，美滋滋

當(dāng)然也有多個哨兵監(jiān)控主從數(shù)據(jù)庫模式，哨兵之間也會互相監(jiān)控，如下圖：

首先需要建立起一主多從的模型，然后開啟配置哨兵。

#主庫sentinel monitor master 127.0.0.1 6379 1
#建立配置文件，例如sentinel.confredis-sentinel /opt/path/to/sentinel.conf

關(guān)于哨兵就介紹這么多，現(xiàn)在大腦中有印象。至少知道有那么回事，可以和美女面試官多掰扯掰扯。

6、集群（cluster）

從Redis3.0開始加入了集群這一特性。

即使使用哨兵，此時的Redis集群的每個數(shù)據(jù)庫依然存有集群中的所有數(shù)據(jù)，從而導(dǎo)致集群的總數(shù)據(jù)存儲量受限于可用內(nèi)存最小的數(shù)據(jù)庫節(jié)點，繼而出現(xiàn)木桶效應(yīng)。正因為Redis所有數(shù)據(jù)都是基于內(nèi)存存儲，問題已經(jīng)很突出，尤其是當(dāng)Redis作為持久化存儲服務(wù)時。

有這樣一種場景。就擴(kuò)容來說，在客戶端分片后，如果像增加更多的節(jié)點，需要對數(shù)據(jù)庫進(jìn)行手動遷移。遷移的過程中，為了保證數(shù)據(jù)的一致性，需要將進(jìn)群暫時下線，相對比較復(fù)雜。

此時考慮到Redis很小，啊不口誤，是輕量的特點。可以采用預(yù)分片（presharding）在一定程度上避免問題的出現(xiàn)。換句話說，就是在部署的初期，提前考慮日后的存儲規(guī)模，建立足夠多的實例。

從上面的理論知識來看，哨兵和集群類似，但哨兵和集群是兩個獨立的功能。如果要進(jìn)行水平擴(kuò)容，集群是不錯的選擇。

配置集群，開啟配置文件redis.conf中的cluster-enabled

cluster-enabled yes

配置集群每個節(jié)點配置不同工作目錄，或者修改持久化文件

cluster-config-file nodes-6379.conf

集群測試大家可以執(zhí)行配置，參考其他書籍亦可，實現(xiàn)并不難。只要是知其原理。

四、Redis for Java

示例

package com.jedis;import redis.clients.jedis.Jedis;import redis.clients.jedis.JedisPool;import redis.clients.jedis.JedisPoolConfig;public class Test {

	@org.junit.Test
	public void demo() {
		Jedis jedis = new Jedis("127.0.0.1", 6379);
		jedis.set("name", "sky");
		String params = jedis.get("jedis");
		System.out.println(params);
		jedis.close();
	}
	
	@org.junit.Test
	public void config() {
		// 獲取連接池的配置對象
		JedisPoolConfig config = new JedisPoolConfig();
		// 設(shè)置最大連接數(shù)
		config.setMaxTotal(30);
		// 設(shè)置最大空閑連接數(shù)
		config.setMaxIdle(10);
		// 獲取連接池
		JedisPool pool = new JedisPool(config, "127.0.0.1", 6379);
		// 獲得核心對象
		Jedis jedis = null;
		try {
			//通過連接池獲取連接
			jedis = pool.getResource();
			//設(shè)置對象
			jedis.set("poolname", "pool");
			//獲取對象
			String pools = jedis.get("poolname");
			System.out.println("values:"+pools);
		} catch (Exception e) {
			e.printStackTrace();
		}finally{
			//釋放資源
			if(jedis != null){
				jedis.close();
			}
			if(pool != null){
				pool.close();
			}
		}	
	}}

“Redis持久化實例分析”的內(nèi)容就介紹到這里了，感謝大家的閱讀。如果想了解更多行業(yè)相關(guān)的知識可以關(guān)注億速云網(wǎng)站，小編將為大家輸出更多高質(zhì)量的實用文章！