怎么快速掌握Redis數(shù)據(jù)庫

本篇內(nèi)容主要講解“怎么快速掌握redis數(shù)據(jù)庫”，感興趣的朋友不妨來看看。本文介紹的方法操作簡單快捷，實(shí)用性強(qiáng)。下面就讓小編來帶大家學(xué)習(xí)“怎么快速掌握Redis數(shù)據(jù)庫”吧!

創(chuàng)新互聯(lián)于2013年開始，是專業(yè)互聯(lián)網(wǎng)技術(shù)服務(wù)公司，擁有項(xiàng)目成都做網(wǎng)站、成都網(wǎng)站建設(shè)網(wǎng)站策劃，項(xiàng)目實(shí)施與項(xiàng)目整合能力。我們以讓每一個夢想脫穎而出為使命，1280元管城做網(wǎng)站,已為上家服務(wù),為管城各地企業(yè)和個人服務(wù),聯(lián)系電話:18982081108

Redis基本數(shù)據(jù)類型

  1.  字符串：redis沒有直接使用C語言傳統(tǒng)的字符串表示，而是自己實(shí)現(xiàn)的叫做簡單動態(tài)字符串SDS的抽象類型。C語言的字符串不記錄自身的長度信息，而SDS則保存了長度信息，這樣將獲取字符串長度的時間由O(N)降低到了O(1)，同時可以避免緩沖區(qū)溢出和減少修改字符串長度時所需的內(nèi)存重分配次數(shù)。

  2.  鏈表linkedlist：redis鏈表是一個雙向無環(huán)鏈表結(jié)構(gòu)，很多發(fā)布訂閱、慢查詢、監(jiān)視器功能都是使用到了鏈表來實(shí)現(xiàn)，每個鏈表的節(jié)點(diǎn)由一個listNode結(jié)構(gòu)來表示，每個節(jié)點(diǎn)都有指向前置節(jié)點(diǎn)和后置節(jié)點(diǎn)的指針，同時表頭節(jié)點(diǎn)的前置和后置節(jié)點(diǎn)都指向NULL。

  3.  字典hashtable：用于保存鍵值對的抽象數(shù)據(jù)結(jié)構(gòu)。redis使用hash表作為底層實(shí)現(xiàn)，每個字典帶有兩個hash表，供平時使用和rehash時使用，hash表使用鏈地址法來解決鍵沖突，被分配到同一個索引位置的多個鍵值對會形成一個單向鏈表，在對hash表進(jìn)行擴(kuò)容或者縮容的時候，為了服務(wù)的可用性，rehash的過程不是一次性完成的，而是漸進(jìn)式的。

  4.  跳躍表skiplist：跳躍表是有序集合的底層實(shí)現(xiàn)之一，redis中在實(shí)現(xiàn)有序集合鍵和集群節(jié)點(diǎn)的內(nèi)部結(jié)構(gòu)中都是用到了跳躍表。redis跳躍表由zskiplist和zskiplistNode組成，zskiplist用于保存跳躍表信息（表頭、表尾節(jié)點(diǎn)、長度等），zskiplistNode用于表示表跳躍節(jié)點(diǎn)，每個跳躍表的層高都是1-32的隨機(jī)數(shù)，在同一個跳躍表中，多個節(jié)點(diǎn)可以包含相同的分值，但是每個節(jié)點(diǎn)的成員對象必須是唯一的，節(jié)點(diǎn)按照分值大小排序，如果分值相同，則按照成員對象的大小排序。

  5.  整數(shù)集合intset：用于保存整數(shù)值的集合抽象數(shù)據(jù)結(jié)構(gòu)，不會出現(xiàn)重復(fù)元素，底層實(shí)現(xiàn)為數(shù)組。

  6.  壓縮列表ziplist：壓縮列表是為節(jié)約內(nèi)存而開發(fā)的順序性數(shù)據(jù)結(jié)構(gòu)，他可以包含多個節(jié)點(diǎn)，每個節(jié)點(diǎn)可以保存一個字節(jié)數(shù)組或者整數(shù)值。

基于這些基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，redis封裝了自己的對象系統(tǒng)，包含字符串對象string、列表對象list、哈希對象hash、集合對象set、有序集合對象zset，每種對象都用到了至少一種基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)。

redis通過encoding屬性設(shè)置對象的編碼形式來提升靈活性和效率，基于不同的場景redis會自動做出優(yōu)化。不同對象的編碼如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  字符串對象string：int整數(shù)、embstr編碼的簡單動態(tài)字符串、raw簡單動態(tài)字符串

3.  列表對象list：ziplist、linkedlist

4.  哈希對象hash：ziplist、hashtable

5.  集合對象set：intset、hashtable

6.  有序集合對象zset：ziplist、skiplist

Redis為什么快呢？

redis的速度非常的快，單機(jī)的redis就可以支撐每秒10幾萬的并發(fā)，相對于MySQL來說，性能是mysql的幾十倍。速度快的原因主要有幾點(diǎn)：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  完全基于內(nèi)存操作

3.  C語言實(shí)現(xiàn)，優(yōu)化過的數(shù)據(jù)結(jié)構(gòu)，基于幾種基礎(chǔ)的數(shù)據(jù)結(jié)構(gòu)，redis做了大量的優(yōu)化，性能極高

4.  使用單線程，無上下文的切換成本

5.  基于非阻塞的IO多路復(fù)用機(jī)制

那為什么Redis6.0之后又改用多線程呢?

redis使用多線程并非是完全摒棄單線程，redis還是使用單線程模型來處理客戶端的請求，只是使用多線程來處理數(shù)據(jù)的讀寫和協(xié)議解析，執(zhí)行命令還是使用單線程。

這樣做的目的是因?yàn)閞edis的性能瓶頸在于網(wǎng)絡(luò)IO而非CPU，使用多線程能提升IO讀寫的效率，從而整體提高redis的性能。

知道什么是熱key嗎？熱key問題怎么解決？

所謂熱key問題就是，突然有幾十萬的請求去訪問redis上的某個特定key，那么這樣會造成流量過于集中，達(dá)到物理網(wǎng)卡上限，從而導(dǎo)致這臺redis的服務(wù)器宕機(jī)引發(fā)雪崩。

針對熱key的解決方案：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  提前把熱key打散到不同的服務(wù)器，降低壓力

3.  加入二級緩存，提前加載熱key數(shù)據(jù)到內(nèi)存中，如果redis宕機(jī)，走內(nèi)存查詢

什么是緩存擊穿、緩存穿透、緩存雪崩？

緩存擊穿

緩存擊穿的概念就是單個key并發(fā)訪問過高，過期時導(dǎo)致所有請求直接打到db上，這個和熱key的問題比較類似，只是說的點(diǎn)在于過期導(dǎo)致請求全部打到DB上而已。

解決方案：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  加鎖更新，比如請求查詢A，發(fā)現(xiàn)緩存中沒有，對A這個key加鎖，同時去數(shù)據(jù)庫查詢數(shù)據(jù)，寫入緩存，再返回給用戶，這樣后面的請求就可以從緩存中拿到數(shù)據(jù)了。

3.  將過期時間組合寫在value中，通過異步的方式不斷的刷新過期時間，防止此類現(xiàn)象。

https://tva

緩存穿透

緩存穿透是指查詢不存在緩存中的數(shù)據(jù)，每次請求都會打到DB，就像緩存不存在一樣。

針對這個問題，加一層布隆過濾器。布隆過濾器的原理是在你存入數(shù)據(jù)的時候，會通過散列函數(shù)將它映射為一個位數(shù)組中的K個點(diǎn)，同時把他們置為1。

這樣當(dāng)用戶再次來查詢A，而A在布隆過濾器值為0，直接返回，就不會產(chǎn)生擊穿請求打到DB了。

顯然，使用布隆過濾器之后會有一個問題就是誤判，因?yàn)樗旧硎且粋€數(shù)組，可能會有多個值落到同一個位置，那么理論上來說只要我們的數(shù)組長度夠長，誤判的概率就會越低，這種問題就根據(jù)實(shí)際情況來就好了。

緩存雪崩

當(dāng)某一時刻發(fā)生大規(guī)模的緩存失效的情況，比如你的緩存服務(wù)宕機(jī)了，會有大量的請求進(jìn)來直接打到DB上，這樣可能導(dǎo)致整個系統(tǒng)的崩潰，稱為雪崩。雪崩和擊穿、熱key的問題不太一樣的是，他是指大規(guī)模的緩存都過期失效了。

針對雪崩幾個解決方案：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  針對不同key設(shè)置不同的過期時間，避免同時過期

3.  限流，如果redis宕機(jī)，可以限流，避免同時刻大量請求打崩DB

4.  二級緩存，同熱key的方案。

Redis的過期策略有哪些？

redis主要有2種過期刪除策略

惰性刪除

惰性刪除指的是當(dāng)我們查詢key的時候才對key進(jìn)行檢測，如果已經(jīng)達(dá)到過期時間，則刪除。顯然，他有一個缺點(diǎn)就是如果這些過期的key沒有被訪問，那么他就一直無法被刪除，而且一直占用內(nèi)存。

定期刪除

定期刪除指的是redis每隔一段時間對數(shù)據(jù)庫做一次檢查，刪除里面的過期key。由于不可能對所有key去做輪詢來刪除，所以redis會每次隨機(jī)取一些key去做檢查和刪除。

那么定期+惰性都沒有刪除過期的key怎么辦？

假設(shè)redis每次定期隨機(jī)查詢key的時候沒有刪掉，這些key也沒有做查詢的話，就會導(dǎo)致這些key一直保存在redis里面無法被刪除，這時候就會走到redis的內(nèi)存淘汰機(jī)制。

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  volatile-lru：從已設(shè)置過期時間的key中，移出最近最少使用的key進(jìn)行淘汰

3.  volatile-ttl：從已設(shè)置過期時間的key中，移出將要過期的key

4.  volatile-random：從已設(shè)置過期時間的key中隨機(jī)選擇key淘汰

5.  allkeys-lru：從key中選擇最近最少使用的進(jìn)行淘汰

6.  allkeys-random：從key中隨機(jī)選擇key進(jìn)行淘汰

7.  noeviction：當(dāng)內(nèi)存達(dá)到閾值的時候，新寫入操作報(bào)錯

持久化方式有哪些？有什么區(qū)別？

redis持久化方案分為RDB和AOF兩種。

RDB

RDB持久化可以手動執(zhí)行也可以根據(jù)配置定期執(zhí)行，它的作用是將某個時間點(diǎn)上的數(shù)據(jù)庫狀態(tài)保存到RDB文件中，RDB文件是一個壓縮的二進(jìn)制文件，通過它可以還原某個時刻數(shù)據(jù)庫的狀態(tài)。由于RDB文件是保存在硬盤上的，所以即使redis崩潰或者退出，只要RDB文件存在，就可以用它來恢復(fù)還原數(shù)據(jù)庫的狀態(tài)。

可以通過SAVE或者BGSAVE來生成RDB文件。

SAVE命令會阻塞redis進(jìn)程，直到RDB文件生成完畢，在進(jìn)程阻塞期間，redis不能處理任何命令請求，這顯然是不合適的。

BGSAVE則是會fork出一個子進(jìn)程，然后由子進(jìn)程去負(fù)責(zé)生成RDB文件，父進(jìn)程還可以繼續(xù)處理命令請求，不會阻塞進(jìn)程。

AOF

AOF和RDB不同，AOF是通過保存redis服務(wù)器所執(zhí)行的寫命令來記錄數(shù)據(jù)庫狀態(tài)的。

AOF通過追加、寫入、同步三個步驟來實(shí)現(xiàn)持久化機(jī)制。

•  當(dāng)AOF持久化處于激活狀態(tài)，服務(wù)器執(zhí)行完寫命令之后，寫命令將會被追加append到aof_buf緩沖區(qū)的末尾

•  在服務(wù)器每結(jié)束一個事件循環(huán)之前，將會調(diào)用flushAppendOnlyFile函數(shù)決定是否要將aof_buf的內(nèi)容保存到AOF文件中，可以通過配置appendfsync來決定。 

always ##aof_buf內(nèi)容寫入并同步到AOF文件  everysec ##將aof_buf中內(nèi)容寫入到AOF文件，如果上次同步AOF文件時間距離現(xiàn)在超過1秒，則再次對AOF文件進(jìn)行同步  no ##將aof_buf內(nèi)容寫入AOF文件，但是并不對AOF文件進(jìn)行同步，同步時間由操作系統(tǒng)決定

如果不設(shè)置，默認(rèn)選項(xiàng)將會是everysec，因?yàn)閍lways來說雖然最安全（只會丟失一次事件循環(huán)的寫命令），但是性能較差，而everysec模式只不過會可能丟失1秒鐘的數(shù)據(jù)，而no模式的效率和everysec相仿，但是會丟失上次同步AOF文件之后的所有寫命令數(shù)據(jù)。

怎么實(shí)現(xiàn)Redis的高可用？

要想實(shí)現(xiàn)高可用，一臺機(jī)器肯定是不夠的，而redis要保證高可用，有2個可選方案。

主從架構(gòu)

主從模式是最簡單的實(shí)現(xiàn)高可用的方案，核心就是主從同步。主從同步的原理如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  slave發(fā)送sync命令到master

3.  master收到sync之后，執(zhí)行bgsave，生成RDB全量文件

4.  master把slave的寫命令記錄到緩存

5.  bgsave執(zhí)行完畢之后，發(fā)送RDB文件到slave，slave執(zhí)行

6.  master發(fā)送緩存中的寫命令到slave，slave執(zhí)行

這里我寫的這個命令是sync，但是在redis2.8版本之后已經(jīng)使用psync來替代sync了，原因是sync命令非常消耗系統(tǒng)資源，而psync的效率更高。

哨兵

基于主從方案的缺點(diǎn)還是很明顯的，假設(shè)master宕機(jī)，那么就不能寫入數(shù)據(jù)，那么slave也就失去了作用，整個架構(gòu)就不可用了，除非你手動切換，主要原因就是因?yàn)闆]有自動故障轉(zhuǎn)移機(jī)制。而哨兵(sentinel)的功能比單純的主從架構(gòu)全面的多了，它具備自動故障轉(zhuǎn)移、集群監(jiān)控、消息通知等功能。

哨兵可以同時監(jiān)視多個主從服務(wù)器，并且在被監(jiān)視的master下線時，自動將某個slave提升為master，然后由新的master繼續(xù)接收命令。整個過程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  初始化sentinel，將普通的redis代碼替換成sentinel專用代碼

3.  初始化masters字典和服務(wù)器信息，服務(wù)器信息主要保存ip:port，并記錄實(shí)例的地址和ID

4.  創(chuàng)建和master的兩個連接，命令連接和訂閱連接，并且訂閱sentinel:hello頻道

5.  每隔10秒向master發(fā)送info命令，獲取master和它下面所有slave的當(dāng)前信息

6.  當(dāng)發(fā)現(xiàn)master有新的slave之后，sentinel和新的slave同樣建立兩個連接，同時每個10秒發(fā)送info命令，更新master信息

7.  sentinel每隔1秒向所有服務(wù)器發(fā)送ping命令，如果某臺服務(wù)器在配置的響應(yīng)時間內(nèi)連續(xù)返回?zé)o效回復(fù)，將會被標(biāo)記為下線狀態(tài)

8.  選舉出領(lǐng)頭sentinel，領(lǐng)頭sentinel需要半數(shù)以上的sentinel同意

9.  領(lǐng)頭sentinel從已下線的的master所有slave中挑選一個，將其轉(zhuǎn)換為master

10.  讓所有的slave改為從新的master復(fù)制數(shù)據(jù)

11.  將原來的master設(shè)置為新的master的從服務(wù)器，當(dāng)原來master重新回復(fù)連接時，就變成了新master的從服務(wù)器

sentinel會每隔1秒向所有實(shí)例（包括主從服務(wù)器和其他sentinel）發(fā)送ping命令，并且根據(jù)回復(fù)判斷是否已經(jīng)下線，這種方式叫做主觀下線。當(dāng)判斷為主觀下線時，就會向其他監(jiān)視的sentinel詢問，如果超過半數(shù)的投票認(rèn)為已經(jīng)是下線狀態(tài)，則會標(biāo)記為客觀下線狀態(tài)，同時觸發(fā)故障轉(zhuǎn)移。

能說說redis集群的原理嗎？

如果說依靠哨兵可以實(shí)現(xiàn)redis的高可用，如果還想在支持高并發(fā)同時容納海量的數(shù)據(jù)，那就需要redis集群。redis集群是redis提供的分布式數(shù)據(jù)存儲方案，集群通過數(shù)據(jù)分片sharding來進(jìn)行數(shù)據(jù)的共享，同時提供復(fù)制和故障轉(zhuǎn)移的功能。

節(jié)點(diǎn)

一個redis集群由多個節(jié)點(diǎn)node組成，而多個node之間通過cluster meet命令來進(jìn)行連接，節(jié)點(diǎn)的握手過程：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  節(jié)點(diǎn)A收到客戶端的cluster meet命令

3.  A根據(jù)收到的IP地址和端口號，向B發(fā)送一條meet消息

4.  節(jié)點(diǎn)B收到meet消息返回pong

5.  A知道B收到了meet消息，返回一條ping消息，握手成功

6.  最后，節(jié)點(diǎn)A將會通過gossip協(xié)議把節(jié)點(diǎn)B的信息傳播給集群中的其他節(jié)點(diǎn)，其他節(jié)點(diǎn)也將和B進(jìn)行握手

槽slot

redis通過集群分片的形式來保存數(shù)據(jù)，整個集群數(shù)據(jù)庫被分為16384個slot，集群中的每個節(jié)點(diǎn)可以處理0-16384個slot，當(dāng)數(shù)據(jù)庫16384個slot都有節(jié)點(diǎn)在處理時，集群處于上線狀態(tài)，反之只要有一個slot沒有得到處理都會處理下線狀態(tài)。通過cluster addslots命令可以將slot指派給對應(yīng)節(jié)點(diǎn)處理。

slot是一個位數(shù)組，數(shù)組的長度是16384/8=2048，而數(shù)組的每一位用1表示被節(jié)點(diǎn)處理，0表示不處理，如圖所示的話表示A節(jié)點(diǎn)處理0-7的slot。

當(dāng)客戶端向節(jié)點(diǎn)發(fā)送命令，如果剛好找到slot屬于當(dāng)前節(jié)點(diǎn)，那么節(jié)點(diǎn)就執(zhí)行命令，反之，則會返回一個MOVED命令到客戶端指引客戶端轉(zhuǎn)向正確的節(jié)點(diǎn)。（MOVED過程是自動的）

如果增加或者移出節(jié)點(diǎn)，對于slot的重新分配也是非常方便的，redis提供了工具幫助實(shí)現(xiàn)slot的遷移，整個過程是完全在線的，不需要停止服務(wù)。

故障轉(zhuǎn)移

如果節(jié)點(diǎn)A向節(jié)點(diǎn)B發(fā)送ping消息，節(jié)點(diǎn)B沒有在規(guī)定的時間內(nèi)響應(yīng)pong，那么節(jié)點(diǎn)A會標(biāo)記節(jié)點(diǎn)B為pfail疑似下線狀態(tài)，同時把B的狀態(tài)通過消息的形式發(fā)送給其他節(jié)點(diǎn)，如果超過半數(shù)以上的節(jié)點(diǎn)都標(biāo)記B為pfail狀態(tài)，B就會被標(biāo)記為fail下線狀態(tài)，此時將會發(fā)生故障轉(zhuǎn)移，優(yōu)先從復(fù)制數(shù)據(jù)較多的從節(jié)點(diǎn)選擇一個成為主節(jié)點(diǎn)，并且接管下線節(jié)點(diǎn)的slot，整個過程和哨兵非常類似，都是基于Raft協(xié)議做選舉。

了解Redis事務(wù)機(jī)制嗎？

redis通過MULTI、EXEC、WATCH等命令來實(shí)現(xiàn)事務(wù)機(jī)制，事務(wù)執(zhí)行過程將一系列多個命令按照順序一次性執(zhí)行，并且在執(zhí)行期間，事務(wù)不會被中斷，也不會去執(zhí)行客戶端的其他請求，直到所有命令執(zhí)行完畢。事務(wù)的執(zhí)行過程如下：

1. 鴻蒙官方戰(zhàn)略合作共建——HarmonyOS技術(shù)社區(qū)

2.  服務(wù)端收到客戶端請求，事務(wù)以MULTI開始

3.  如果客戶端正處于事務(wù)狀態(tài)，則會把事務(wù)放入隊(duì)列同時返回給客戶端QUEUED，反之則直接執(zhí)行這個命令

4.  當(dāng)收到客戶端EXEC命令時，WATCH命令監(jiān)視整個事務(wù)中的key是否有被修改，如果有則返回空回復(fù)到客戶端表示失敗，否則redis會遍歷整個事務(wù)隊(duì)列，執(zhí)行隊(duì)列中保存的所有命令，最后返回結(jié)果給客戶端

WATCH的機(jī)制本身是一個CAS的機(jī)制，被監(jiān)視的key會被保存到一個鏈表中，如果某個key被修改，那么REDIS_DIRTY_CAS標(biāo)志將會被打開，這時服務(wù)器會拒絕執(zhí)行事務(wù)。

到此，相信大家對“怎么快速掌握Redis數(shù)據(jù)庫”有了更深的了解，不妨來實(shí)際操作一番吧！這里是創(chuàng)新互聯(lián)網(wǎng)站，更多相關(guān)內(nèi)容可以進(jìn)入相關(guān)頻道進(jìn)行查詢，關(guān)注我們，繼續(xù)學(xué)習(xí)！

網(wǎng)頁題目：怎么快速掌握Redis數(shù)據(jù)庫
轉(zhuǎn)載源于：http://muchs.cn/article18/pdghgp.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供域名注冊、網(wǎng)站設(shè)計(jì)、營銷型網(wǎng)站建設(shè)、App設(shè)計(jì)、移動網(wǎng)站建設(shè)、全網(wǎng)營銷推廣

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)