正文

redis實例（redis實例化）

發(fā)布時間：2023-04-14 02:44:45 稿源：創(chuàng)意嶺閱讀： 142

大家好！今天讓創(chuàng)意嶺的小編來大家介紹下關(guān)于redis實例的問題，以下是小編對此問題的歸納整理，讓我們一起來看看吧。

開始之前先推薦一個非常厲害的Ai人工智能工具，一鍵生成原創(chuàng)文章、方案、文案、工作計劃、工作報告、論文、代碼、作文、做題和對話答疑等等

只需要輸入關(guān)鍵詞，就能返回你想要的內(nèi)容，越精準(zhǔn)，寫出的就越詳細，有微信小程序端、在線網(wǎng)頁版、PC客戶端

官網(wǎng)：https://ai.de1919.com。

創(chuàng)意嶺作為行業(yè)內(nèi)優(yōu)秀的企業(yè)，服務(wù)客戶遍布全球各地，如需了解SEO相關(guān)業(yè)務(wù)請撥打電話175-8598-2043，或添加微信：1454722008

本文目錄:

1、linux 的環(huán)境搭建（二）--redis單機環(huán)境、生產(chǎn)環(huán)境、集群環(huán)境的搭建
2、Redis 學(xué)習(xí)總結(jié)(3) Redis 哨兵模式
3、Redis哨兵（Sentinel）模式
4、Redis“氣急敗壞”回?fù)簦?3 年來，總有人想替 Redis 換套新架構(gòu)

redis實例（redis實例化）

一、linux 的環(huán)境搭建（二）--redis單機環(huán)境、生產(chǎn)環(huán)境、集群環(huán)境的搭建

一、目錄

1、工具

2、安裝tcl

3、安裝單機版redis

4、把redis設(shè)置為daemon進程，每次系統(tǒng)啟動，redis進程一起啟動

5、安裝redis cluster

二、工具

2.1、tcl8.6.1-src.tar.gz

2.2、ruby-2.3.1.tar.gz

2.3、redis-4.1.1.gem

2.4、redis-3.2.8.tar.gz

2.5、openssl-1.0.2r.tar.gz

三、安裝tcl（安裝redis必須先要安裝tcl）

3.1、把tcl8.6.1-src.tar.gz通過WinSCP上傳到虛擬機中的/usr/local目錄下

四、安裝單機版redis

4.1、把redis-3.2.8.tar.gz通過WinSCP上傳到虛擬機中的/usr/local目錄下

4.2、依次運行如下命令：

tar -zxvf redis-3.2.8.tar.gz 解壓文件

cd redis-3.2.8

make && make test && make install

五、把redis設(shè)置為daemon進程，每次系統(tǒng)啟動，redis進程一起啟動

5.1、將redis的utils目錄下的redis_init_script腳本拷貝到linux的/etc/init.d目錄中，將redis_init_script重命名為redis_6379，6379是我們希望這個redis實例監(jiān)聽的端口號

5.2、修改redis_6379腳本的第6行的REDISPORT，設(shè)置為相同的端口號（默認(rèn)就是6379）

protected-mode no 取消保護模式，保護模式只能127.0.0.1訪問

daemonize yes 讓redis以daemon進程運行

pidfile /var/run/redis_6379.pid 設(shè)置redis的pid文件位置

bind 192.168.3.110

port 6379 設(shè)置redis的監(jiān)聽端口號

dir /var/redis/6379 設(shè)置持久化文件的存儲位置

logfile /var/log/redis/6379.log 設(shè)置日志文件位置

5.6、啟動redis，依次執(zhí)行：

cd /etc/init.d,

chmod 777 redis_6379，賦讀寫執(zhí)行的權(quán)限（chmod -R 777 * 是遞歸把該目錄下的所有文件和其子文件全部賦權(quán)限）

./redis_6379 start 啟動

5.7、確認(rèn)redis進程是否啟動，ps -ef | grep redis

5.8、讓redis跟隨系統(tǒng)啟動自動啟動

5.9、重啟系統(tǒng)，不手動啟動redis，直接連接redis，可以連接上，表示配置成功

此時一個單機版的redis的生產(chǎn)環(huán)境已經(jīng)搭建好了，每次服務(wù)器重啟，redis都會自動的啟動

六、安裝redis cluster

（redis cluster集群，要求至少3個master，去組成一個高可用，健壯的分布式的集群，每個master都建議至少給一個slave，3個master，3個slave）

6.1、前提，我在其它機器上啟動了六個redis（安裝步驟都如下）

2.2、創(chuàng)建三個目錄：

mkdir -p /etc/redis-cluster 存放集群配置信息，自動生成配置

mkdir -p /var/log/redis redis日志

mkdir -p /var/redis/7001 存放redis的rdb文件和aof文件

6.3、將redis的utils目錄下的redis_init_script腳本拷貝到linux的/etc/init.d目錄中，將redis_init_script重命名為redis_7001，7001是我們希望這個redis實例監(jiān)聽的端口號,并修改redis_7001配置文件中的REDISPORT=7001

6.4、修改/etc/redis/7001.conf中的部分配置為生產(chǎn)環(huán)境

6.5、完成了一個redis環(huán)境的配置，依次再配置其余五個，分別為7002、7003、7004、7005、7006，每個啟動腳本內(nèi)，都修改對應(yīng)的端口號

6.6、啟動6個redis實例

6.7、創(chuàng)建集群（需要安裝ruby、rubygems）

上述命令在部分機器上是可以直接運行完成，成功安裝的，但在部分機器上運行第三條命令時會提示ruby版本太低、openssl找不到的問題，下面依次解決這兩個問題：

6.8、再次運行g(shù)em install redis命令，報出兩個錯誤

6.9、再次運行g(shù)em install redis命令，報出一個錯誤

6.10、再次運行g(shù)em install redis命令，報出一個錯誤

6.11、再次運行g(shù)em install redis命令

[root@ceshi01 local]# gem install redis

Successfully installed redis-4.1.1

Parsing documentation for redis-4.1.1

Done installing documentation for redis after 1 seconds

WARNING: Unable to pull data from ' https://rubygems.org/' : SSL_connect returned=1 errno=0 state=error: certificate verify failed ( https://api.rubygems.org/specs.4.8.gz )

1 gem installed

運行成功

此時Redis安裝好，此三個工具也安裝好了，這時我們來做一個Redis集群測試，在一臺服務(wù)器中創(chuàng)建了6個Redis實例，開啟6個Redis服務(wù)

redis-trib.rb create --replicas 1 192.168.3.104:7001 192.168.3.104:7002 192.168.3.105:7003 192.168.3.105:7004 192.168.3.106:7005 192.168.3.106:7006

[root@eshop-cache02 init.d]# redis-trib.rb create --replicas 1 192.168.3.104:7001 192.168.3.104:7002 192.168.3.105:7003 192.168.3.105:7004 192.168.3.106:7005 192.168.3.106:7006

此時一個redis集群環(huán)境就已經(jīng)搭建好了，可以通過redis-trib.rb check 192.168.3.105:7003命令查看集群幾點的信息

[root@eshop-cache02 init.d]# redis-trib.rb check 192.168.3.105:7004

redis cluster的優(yōu)點：讀寫分離+高可用+多master

讀寫分離：每個master都有一個slave

高可用：master宕機，slave自動被切換過去

多master：橫向擴容支持更大數(shù)據(jù)量

二、Redis 學(xué)習(xí)總結(jié)(3) Redis 哨兵模式

在實際開發(fā)中不會僅僅部署一個 Redis 服務(wù)器，為了獲得高可用，Redis 哨兵模式則是高可用的一種選擇。

本文先介紹下哨兵模式，再介紹了如何在 springboot 項目中使用。

這意味著使用 Sentinel （哨兵模式），您可以創(chuàng)建一個 Redis 部署，它可抵抗某些類型的故障（進行故障遷移）而無需人工干預(yù)。

它有這些功能：

Sentinel 的分布式特性

Redis Sentinel 是一個分布式系統(tǒng)，多個 Sentinel 進程協(xié)同工作，有這些優(yōu)勢：

部署前需要了解:

三個節(jié)點的基本配置

法定人數(shù)和仲裁

在配置哨兵模式時，要指定一個 quorum，它可理解為“法定人數(shù)”。

假設(shè)有3 個哨兵，法定人數(shù)為2。那么：

哨兵和副本的自動發(fā)現(xiàn)

Sentinel 與其他 Sentinel 保持連接，以便相互檢查彼此的可用性并交換消息。

但是，您不需要在您運行的每個 Sentinel 實例中配置其他 Sentinel 地址的列表，因為 Sentinel 使用 Redis 實例的 Pub/Sub 功能來發(fā)現(xiàn)正在監(jiān)視相同主節(jié)點和副本的其他 Sentinel。

類似地，您不需要配置附加到主服務(wù)器的副本地址在哪里，因為 Sentinel 會通過查詢 Redis 自動發(fā)現(xiàn)它們。

參考我的另一篇文章：

一般需要三個節(jié)點，每個節(jié)點有一個 redis 和一個哨兵。

下面再分別描述。

我這里按三個節(jié)點，先配置 redis 的主從復(fù)制。1個節(jié)點作為 master ，2個副本。

配置節(jié)點1：master

這里的 redis 作為 master 主redis，其他兩個節(jié)點作為從節(jié)點。

我的文件夾名字叫 box1，這里編輯一個 box1/redis.conf 文件，主要配置內(nèi)容如下:

配置節(jié)點2：副本

編輯一個 box2/redis.conf 文件，主要配置內(nèi)容如下:

配置節(jié)點3：副本

編輯一個 box3/redis.conf 文件，主要配置內(nèi)容如下:

分別啟動這三個redis

命令行執(zhí)行 redis-server ，并指定配置文件的路徑參數(shù)。

如何查看“主從復(fù)制”是否配置成功？

使用 info replication 命令，操作如下：

副本節(jié)點設(shè)置為只讀？

從 Redis 2.6 開始，副本已被默認(rèn)設(shè)置為只讀，無需額外配置。.

一般情況下，至少會需要三個哨兵對redis 進行監(jiān)控，我們可以通過修改端口啟動多個sentinel 服務(wù)。

第一個哨兵：

哨兵的默認(rèn)端口是 26379 ，這里不改。

第二個哨兵：

修改哨兵端口。

第三個哨兵：

修改哨兵端口。

啟動哨兵

使用 redis-sentinel 命令，分別啟動這三個哨兵

哨兵的自動發(fā)現(xiàn)

當(dāng)三個哨兵都啟動后，在各個哨兵的打印日志里可以看到，三個哨兵已互相發(fā)現(xiàn)了彼此的存在。

至此，配置完畢了，我們有三個 redis，和三個哨兵，看下截圖。

模擬 master 宕機

按 ctrl+c 停止 master ，其位于 6379 。停止后，從日志可以看到，哨兵和 redis副本先努力繼續(xù)連接 6379，反復(fù)幾次失敗后，開始選舉出新的 master。截圖如下：

至此，配置完畢。

我們看下 springboot 項目的客戶端如何配置以訪問哨兵模式的 redis。

Redis 哨兵支持

對于處理高可用Redis，Spring Data Redis 已經(jīng)支持Redis Sentinel，使用RedisSentinelConfiguration，如下例所示：

Jedis 和 Lettuce 兩種 redis 驅(qū)動都可以支持。

RedisSentinelConfiguration 也可以用可以通過 PropertySource 來設(shè)置，它允許您設(shè)置以下屬性：

配置application.yml

比如我這里修改我的 application.yml 文件如下：

我的配置文件示例： https://github.com/vir56k/java_demo/tree/master/redis-sentinel

我的 springboot 配置實例： https://github.com/vir56k/java_demo/tree/master/redis-sentinel/springboot_redis_demo

Redis官網(wǎng) sentinel 介紹

https://redis.io/topics/sentinel

spring-data/data-redis

https://docs.spring.io/spring-data/data-redis/docs/current/reference/html/#redis:sentinel

https://www.cnblogs.com/jaycekon/p/6237562.html

END

三、Redis哨兵（Sentinel）模式

主從切換技術(shù)的方法是：當(dāng)主服務(wù)器宕機后，需要手動把一臺從服務(wù)器切換為主服務(wù)器，這就需要人工干預(yù)，費事費力，還會造成一段時間內(nèi)服務(wù)不可用。這不是一種推薦的方式，更多時候，我們優(yōu)先考慮 哨兵模式 。

哨兵模式是一種特殊的模式，首先Redis提供了哨兵的命令，哨兵是一個獨立的進程，作為進程，它會獨立運行。其原理是 哨兵通過發(fā)送命令，等待Redis服務(wù)器響應(yīng)，從而監(jiān)控運行的多個Redis實例。

這里的哨兵有兩個作用

然而一個哨兵進程對Redis服務(wù)器進行監(jiān)控，可能會出現(xiàn)問題，為此，我們可以使用多個哨兵進行監(jiān)控。各個哨兵之間還會進行監(jiān)控，這樣就形成了多哨兵模式。

用文字描述一下 故障切換（failover） 的過程。假設(shè)主服務(wù)器宕機，哨兵1先檢測到這個結(jié)果，系統(tǒng)并不會馬上進行failover過程，僅僅是哨兵1主觀的認(rèn)為主服務(wù)器不可用，這個現(xiàn)象成為 主觀下線 。當(dāng)后面的哨兵也檢測到主服務(wù)器不可用，并且數(shù)量達到一定值時，那么哨兵之間就會進行一次投票，投票的結(jié)果由一個哨兵發(fā)起，進行failover操作。切換成功后，就會通過發(fā)布訂閱模式，讓各個哨兵把自己監(jiān)控的從服務(wù)器實現(xiàn)切換主機，這個過程稱為 客觀下線 。這樣對于客戶端而言，一切都是透明的。

配置3個哨兵和1主2從的Redis服務(wù)器來演示這個過程。

首先配置Redis的主從服務(wù)器，修改redis.conf文件如下

上述內(nèi)容主要是配置Redis服務(wù)器，從服務(wù)器比主服務(wù)器多一個slaveof的配置和密碼。

配置3個哨兵，每個哨兵的配置都是一樣的。在Redis安裝目錄下有一個sentinel.conf文件，copy一份進行修改

上述關(guān)閉了保護模式，便于測試。

有了上述的修改，我們可以進入Redis的安裝目錄的src目錄，通過下面的命令啟動服務(wù)器和哨兵

注意啟動的順序。 首先是主機（192.168.11.128）的Redis服務(wù)進程，然后啟動從機的服務(wù)進程，最后啟動3個哨兵的服務(wù)進程。

上面是通過Jedis進行使用的，同樣也可以使用Spring進行配置RedisTemplate使用。

sentinel down-after-milliseconds配置項只是一個哨兵在超過規(guī)定時間依舊沒有得到響應(yīng)后，會自己認(rèn)為主機不可用。對于其他哨兵而言，并不是這樣認(rèn)為。哨兵會記錄這個消息，當(dāng)擁有認(rèn)為主觀下線的哨兵達到sentinel monitor所配置的數(shù)量時，就會發(fā)起一次投票，進行failover，此時哨兵會重寫Redis的哨兵配置文件，以適應(yīng)新場景的需要。

四、Redis“氣急敗壞”回?fù)簦?3 年來，總有人想替 Redis 換套新架構(gòu)

今年年中，一位前谷歌、前亞馬遜的工程師推出了他創(chuàng)作的開源內(nèi)存數(shù)據(jù)緩存系統(tǒng) Dragonfly，用 C/C++ 編寫，基于 BSL 許可（Business Source License）分發(fā)。

根據(jù)過往的基準(zhǔn)測試結(jié)果來看， Dragonfly 可能是世界上最快的內(nèi)存存儲系統(tǒng)，它提供了對 Memcached 和 Redis 協(xié)議的支持，但能夠以更高的性能進行查詢，運行時內(nèi)存消耗也更少。與 Redis 相比，Dragonfly 在典型工作負(fù)載下實現(xiàn)了 25 倍的性能提升；單個 Dragonfly 服務(wù)器每秒可以處理數(shù)百萬個請求；在 5GB 存儲測試中，Dragonfly 所需的內(nèi)存比 Redis 少 30%。

作為一個開源軟件，Dragonfly 在短短兩個月獲得了 9.2K GitHub 星，177 個 fork 分支。雖然這些年，涌現(xiàn)了不少類似的 Redis 兼容型內(nèi)存數(shù)據(jù)存儲系統(tǒng)，例如 KeyDB、Skytable，但是都沒能像這次這么“轟動”。畢竟 Redis 誕生了十多年，這時從頭開始設(shè)計一個緩存系統(tǒng)，可以拋棄歷史包袱，更好地利用資源。

為回?fù)粜旅邦^的 Dragonfly，Redis 的聯(lián)合創(chuàng)始人兼 CTO Yiftach Shoolman 和 Redis Labs 的首席架構(gòu)師 Yossi Gottlieb、Redis Labs 的性能工程師 Filipe Oliveira 聯(lián)合發(fā)布了一篇名為《13 年后，Redis 是否需要新的架構(gòu)》的文章。

在文章中，他們特地給出了自認(rèn)更加公平的 Redis 7.0 vs. Dragonfly 基準(zhǔn)測試結(jié)果：Redis 的吞吐量比 Dragonfly 高 18% - 40%，以及一些有關(guān) Redis 架構(gòu)的觀點和思考，以證明 “為什么 Redis 的架構(gòu)仍然是內(nèi)存實時數(shù)據(jù)存儲（緩存、數(shù)據(jù)庫，以及介于兩者之間的所有內(nèi)容）的最佳架構(gòu)”。

雖然他們強調(diào) Redis 架構(gòu)仍然是同類最佳，但也沒法忽視 Dragonfly 這些新軟件提供的一些新鮮、有趣的想法和技術(shù)，Redis 表示其中的一些甚至有可能在未來進入 Redis（比如已經(jīng)開始研究的 io_uring 、更現(xiàn)代的 dictionaries、更有策略地使用線程等）。

另外，Redis 指出 Dragonfly 基準(zhǔn)測試的比較方法 “不能代表 Redis 在現(xiàn)實世界中的運行方式” 。對此，Reddit 上有網(wǎng)友反駁稱：

還有人表示，這篇文章是 Redis 團隊在有禮貌地否認(rèn)“Dragonfly 是最快的緩存系統(tǒng)”，但更多網(wǎng)友表示，Redis 發(fā)文章進行“回?fù)簟?，就已?jīng)代表他們的營銷部門輸了：

我們當(dāng)然一直在尋求為 Redis 提升性能、擴充功能的創(chuàng)新方向，但這里我們想聊聊自己的觀點和思考，闡釋 Redis 時至今日為何仍是最出色的實時內(nèi)存數(shù)據(jù)存儲（包括緩存、數(shù)據(jù)庫以及介于二者之間的一切）方案之一。

接下來，我們將重點介紹 Redis 對于速度和架構(gòu)差異的觀點，再以此為基礎(chǔ)做出比較。在文章的最后，我們還會提供基準(zhǔn)測試結(jié)果、與 Dragonfly 項目的詳盡性能比較信息，歡迎大家自行對比參考。

Dragonfly 基準(zhǔn)測試其實是將獨立單進程 Redis 實例（只能使用單一核心）與多線程 Dragonfly 實例（可以使用虛擬機 / 服務(wù)器上的全部可用核心）進行比較。很明顯，這樣的粗暴比較并不能代表 Redis 在現(xiàn)實場景下的運行狀態(tài)。作為技術(shù)構(gòu)建者，我們希望更確切地把握自有技術(shù)同其他方案間的差異，所以這里我們做了一點公平性調(diào)整：將具有 40 個分片的 Redis 7.0 集群（可使用其中的大部分實例核心）與 Dragonfly 團隊在基準(zhǔn)測試中使用的最大實例類型（AWS c4gn.16xlarge）進行性能比較。

在這輪測試中，我們看到 Redis 的吞吐量比 Dragonfly 要高出 18% 至 40%，而這還僅僅只用到全部 64 個 vCore 中的 40 個。

在我們看來，每一位多線程項目的開發(fā)者在立項之前，都會根據(jù)以往工作中經(jīng)歷過的痛點來指導(dǎo)架構(gòu)決策。我們也承認(rèn)，在多核設(shè)備上運行單一 Redis 進程（這類設(shè)備往往提供幾十個核心和數(shù)百 GB 內(nèi)存）確實存在資源無法充分利用的問題。但 Redis 在設(shè)計之初也確實沒有考慮到這一點，而且眾多 Redis 服務(wù)商已經(jīng)拿出了相應(yīng)的解決方案，借此在市場上占得一席之地。

Redis 通過運行多個進程（使用 Redis 集群）實現(xiàn)橫向擴展，包括在單一云實例背景下也是如此。在 Redis 公司，我們進一步拓展這個概念并建立起 Redis Enterprise。Redis Enterprise 提供管理層，允許用戶大規(guī)模運行 Redis，并默認(rèn)啟用高可用性、即時故障轉(zhuǎn)移、數(shù)據(jù)持久與備份等功能。

下面，我們打算分享幕后使用的一些原則，向大家介紹我們?nèi)绾螢?Redis 的生產(chǎn)應(yīng)用設(shè)計良好的工程實踐。

通過在每個虛擬機上運行多個 Redis 實例，我們可以：

我們不允許單一 Redis 進程的大小超過 25 GB（運行 Redis on Flash 時上限為 50 GB）。如此一來，我們就能：

以橫向擴展的方式靈活運行內(nèi)存數(shù)據(jù)存儲，是 Redis 獲得成功的關(guān)鍵。下面來看具體原因：

我們?nèi)匀恍蕾p由社區(qū)提出的種種有趣思路和技術(shù)方案。其中一部分有望在未來進入 Redis（我們已經(jīng)開始研究 io_uring、更現(xiàn)代的字典、更豐富的線程使用策略等）。但在可預(yù)見的未來，我們不會放棄 Redis 所堅守的無共享、多進程等基本架構(gòu)原則。這種設(shè)計不僅具備最佳性能、可擴展性和彈性，同時也能夠支持內(nèi)存內(nèi)實時數(shù)據(jù)平臺所需要的各類部署架構(gòu)。

附錄：Redis 7.0 對 Draonfly 基準(zhǔn)測試細節(jié)

版本：

目標(biāo)：

客戶端配置：

資源利用與配置優(yōu)化：

最后，我們還發(fā)現(xiàn) Redis 和 Dragonfly 都不受網(wǎng)絡(luò)每秒數(shù)據(jù)包或傳輸帶寬的限制。我們已經(jīng)確認(rèn)在 2 個虛擬機間（分別作為客戶端和服務(wù)器，且均使用 c6gn.16xlarge 實例）使用 TCP 傳遞約 300 B 大小的數(shù)據(jù)包負(fù)載時，可以讓每秒數(shù)據(jù)包傳輸量達到 1000 萬以上、傳輸帶寬超過 30 Gbps。

單 GET 通道延遲低于 1 毫秒：

30 條 GET 通道：

單 SET 通道延遲低于 1 毫秒：

30 條 SET 通道:

用于各變體的 memtier_benchmark 命令：

單 GET 通道延遲低于 1 毫秒

30 條 GET 通道

單 SET 通道延遲低于 1 毫秒

30 條 SET 通道

在本次比較測試中，我們在客戶端（用于運行 memtier_benchmark）和服務(wù)器（用于運行 Redis 和 Dragonfly）使用了相同的虛擬機類型，具體規(guī)格為：

參考鏈接：

https://redis.com/blog/redis-architecture-13-years-later/