Redis相關問題怎麼解決

Redis 持久化機制

Redis是一個支援持久化的記憶體資料庫，透過持久化機制把記憶體中的資料同步到硬碟檔案來確保資料持久化。當Redis重啟後透過把硬碟檔案重新載入到內存，就能達到恢復資料的目的。
實作：單獨建立fork()一個子進程，將目前父進程的資料庫資料複製到子程序的記憶體中，然後由子程序寫入到臨時檔中，持久化的過程結束了，再用這個臨時文件取代上次的快照文件，然後子進程退出，記憶體釋放。

RDB是Redis預設的持久化方式。依照一定的時間週期策略把記憶體的資料以快照的形式儲存到硬碟的二進位。即Snapshot快照存儲，對應產生的資料檔為dump.rdb，透過設定檔中的save參數來定義快照的週期。 （ 快照可以是其所表示的資料的一個副本，也可以是資料的一個複製品。）
AOF：Redis會將每一個收到的寫入命令都透過Write函數追加到文件最後，類似於MySQL的binlog。當Redis重啟是會透過重新執行檔案中儲存的寫入命令來在記憶體中重建整個資料庫的內容。
當兩種方式同時開啟時，資料恢復Redis會優先選擇AOF恢復。

快取雪崩、快取穿透、快取預熱、快取更新、快取降級等問題

快取雪崩我們可以簡單的理解為：由於原有快取失效，新快取未到期間
(例如：我們設定快取時採用了相同的過期時間，在同一時刻出現大面積的快取過期)，所有原本應該存取快取的請求都去查詢資料庫了，而對資料庫CPU和記憶體造成巨大壓力，嚴重的會造成資料庫宕機。從而形成一系列連鎖反應，造成整個系統崩潰。
解決方案：
大多數系統設計者考慮用加鎖（ 最多的解決方案）或佇列的方式保證來保證不會有大量的執行緒對資料庫一次進行讀寫，從而避免失效時大量的並發請求落在底層儲存系統上。還有一個簡單方案就時講快取失效時間分散開。

二、快取穿透
快取穿透是指使用者查詢數據，在資料庫沒有，自然在快取中也不會有。這樣就導致用戶查詢的時候，在快取中找不到，每次都要去資料庫再查詢一遍，然後回傳空（相當於進行了兩次無用的查詢）。這樣請求就繞過快取直接查資料庫，這也是常提的快取命中率問題。
解決方案;
最常見的則是採用布隆過濾器，將所有可能存在的資料哈希到一個足夠大的bitmap中，一個一定不存在的資料會被這個bitmap攔截掉，從而避免了對底層儲存系統的查詢壓力。
另外也有一個更為簡單粗暴的方法，如果一個查詢返回的資料為空（不管是資料不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鐘。透過這個直接設定的預設值存放到緩存，這樣第二次到緩衝中取得就有值了，而不會繼續存取資料庫，這種辦法最簡單粗暴。
5TB的硬碟上放滿了數據，請寫一個演算法將這些數據排重。如果這些資料是一些32bit大小的資料該如何解決？如果是64bit的呢？

對於空間的利用到達了一種極致，那就是Bitmap和布隆過濾器(Bloom Filter)。
Bitmap： 典型的就是哈希表
缺點是，Bitmap對於每個元素只能記錄1bit訊息，如果還想完成額外的功能，恐怕只能靠犧牲更多的空間、時間來完成了。

布林過濾器（建議）
就是引入了k(k>1)k(k>1)個相互獨立的雜湊函數，保證在給定的空間、誤判率下，完成元素判重的過程。
它的優點是空間效率和查詢時間都遠遠超過一般的演算法，缺點是有一定的誤辨識率和刪除困難。
Bloom-Filter演算法的核心思想就是利用多個不同的Hash函數來解決「衝突」。
Hash存在一個衝突（碰撞）的問題，而用同一個Hash得到的兩個URL的值有可能相同。為了減少衝突，我們可以多引入幾個Hash，如果透過其中的一個Hash值我們得到某元素不在集合中，那麼該元素肯定不在集合中。只有在所有的Hash函數告訴我們該元素在集合中時，才能確定該元素存在於集合中。這便是Bloom-Filter的基本思想。
Bloom-Filter一般用於在大資料量的集合中判定某元素是否存在。
受提醒補充：快取穿透與快取擊穿的區別
快取擊穿：指一個key非常熱點，大並發集中對這個key進行訪問，當這個key在失效的瞬間，仍然持續的大並發存取就穿破緩存，轉而直接請求資料庫。
解決方案;在訪問key之前，採用SETNX（set if not exists）來設定另一個短期key來鎖住當前key的訪問，訪問結束再刪除該短期key。

三、快取預熱
快取預熱這個應該是比較常見的概念，相信很多小夥伴都應該可以很容易的理解，快取預熱就是系統上線後，將相關的快取資料直接載入到快取系統。這樣就可以避免在用戶請求的時候，先查詢資料庫，然後再將資料快取的問題！使用者直接查詢事先被預熱的快取資料！
解決想法：
1、直接寫個快取刷新頁面，上線時手動操作下；
2、資料量不大，可以在專案啟動的時候自動進行載入；
3、定時刷新快取；

四、快取更新
除了快取伺服器自帶的快取失效策略之外（Redis預設的有6中策略可供選擇），我們也可以根據具體的業務需求進行自訂的快取淘汰，常見的策略有兩種：
（1）定時去清理過期的快取；
（2）當有用戶請求過來時，再判斷這個請求所用到的快取是否過期，過期的話就去底層系統得到新資料並更新快取。
兩者各有優劣，第一種的缺點是維護大量快取的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷快取失效，邏輯相對比較複雜！具體用哪一種方案，大家可以根據自己的應用場景來權衡。
五、快取降級
當訪問量劇增、服務出現問題（如回應時間慢或不回應）或非核心服務影響核心流程的效能時，仍需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵資料進行自動降級，也可以配置開關來實現人工降級。
降級的最終目的是確保核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。
以參考日誌等級設定預案：
（1）一般：例如有些服務偶爾因為網路抖動或服務正在上線而逾時，可以自動降級；
（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並發送警告；
（3）錯誤：例如可用率低於90%，或者資料庫連接池被打爆了，或是訪問量突然激增到系統能承受的最大閥值，此時可以根據情況自動降級或人工降級；
（4）嚴重錯誤：例如因為特殊原因資料錯誤了，此時需要緊急人工降級。

服務降級的目的在於避免Redis服務故障，進而引發資料庫雪崩問題。因此，對於不重要的快取數據，可以採取服務降級策略，例如一個比較常見的做法就是，Redis出現問題，不去資料庫查詢，而是直接傳回預設值給使用者。

熱點數據和冷數據是什麼

熱點數據，緩存才有價值
對於冷數據而言，大部分數據可能還沒有再次訪問到就已經被擠出內存，不僅佔用內存，而且價值不大。頻繁修改的數據，看情況考慮使用快取
對於上面兩個例子，壽星列表、導航資訊都存在一個特點，就是資訊修改頻率不高，讀取通常非常高的場景。
對於熱點數據，例如我們的某IM產品，生日祝福模組，當天的壽星列表，快取以後可能讀取數十萬次。再舉個例子，某導航產品，我們將導航訊息，快取以後可能讀取數百萬次。
**資料更新前至少讀取兩次，**快取才有意義。這個是最基本的策略，如果快取還沒起作用就失效了，那就沒有太大價值了。
那存不存在，修改頻率很高，但又得考慮快取的場景呢？有！例如，這個讀取介面對資料庫的壓力很大，但是又是熱點數據，這個時候就需要考慮透過快取手段，減少資料庫的壓力，例如我們的某助手產品的，點讚數，收藏數，分享數等是非常典型的熱點數據，但又不斷變化，此時就需要將數據同步保存到Redis緩存，減少資料庫壓力。

Memcache與Redis的差別有哪些？

1)、儲存方式 Memecache把資料全部存在記憶體之中，斷電後會掛掉，資料不能超過記憶體大小。 Redis有部份存在硬碟上，redis可以持久化其資料
2)、資料支援型別memcached所有的值都是簡單的字串，redis作為其替代者，支援更為豐富的資料型別，提供list ，set，zset，hash等資料結構的儲存
3)、使用底層模型不同它們之間底層實作方式以及與客戶端之間通訊的應用協定不一樣。 Redis直接自己建構了VM 機制 ，因為一般的系統呼叫系統函數的話，會浪費一定的時間去移動和請求。
4). value 值大小不同：Redis 最大可以達到 512M；memcache 只有 1mb。
5）redis的速度比memcached快很多
6）Redis支援資料的備份，即master-slave模式的資料備份。

單執行緒的redis為什麼這麼快

(一)純記憶體運算
(二)單執行緒操作，避免了頻繁的上下文切換
(三)採用了非阻塞I/O多路復用機制

redis的資料類型，以及每種資料類型的使用場景

回答：一共五種
(一)String
這個其實沒啥好說的，最常規的set/get操作，value可以是String也可以是數字。一般做一些複雜的計數功能的快取。
(二)hash
這裡value存放的是結構化的對象，比較方便的就是操作其中的某個欄位。部落客在做單一登入的時候，就是用這種資料結構儲存使用者訊息，以cookieId作為key，設定30分鐘為快取過期時間，能很好的模擬出類似session的效果。
(三)list
使用List的資料結構，可以做簡單的訊息佇列的功能。另外還有一個就是，可以利用lrange指令，做基於redis的分頁功能，效能極佳，使用者體驗好。本人還用一個場景，很適合—取行情資訊。就也是個生產者和消費者的場景。 LIST可以很好的完成排隊，先進先出的原則。
(四)set
因為set堆疊的是一堆不重複值的集合。所以可以做全域去重的功能。為什麼不用JVM自帶的Set進行去重？因為我們的系統通常都是叢集部署，使用JVM自帶的Set，比較麻煩，難道為了一個做一個全域去重，再起一個公共服務，太麻煩了。
另外，就是利用交集、並集、差集等操作，可以計算共同喜好，全部的喜好，自己獨有的喜好等功能。
(五)sorted set
sorted set多了一個權重參數score,集合中的元素能夠按score進行排列。可以做排行榜應用，取TOP N操作。

Redis 內部結構

• dict 基本上是為了解決演算法中的查找問題（Searching）是一個用於維護key和value映射關係的資料結構，與很多語言中的Map或dictionary類似。基本上是為了解決演算法中的查找問題（Searching）

• sds sds就等同於char * 它可以儲存任意二進位數據，不能像C語言字串那樣以字元'\ 0'來標識字串的結束，因此它必然有個長度欄位。

• skiplist （跳躍表） 跳錶是一種實現起來很簡單，單層多指標的鍊錶，它找到效率很高，堪比優化過的二元平衡樹，且比平衡樹的實現，

• quicklist

• #ziplist 壓縮表ziplist是編碼後的列表，是由一系列特殊編碼的由連續記憶體區塊組成的順序型資料結構，

redis的過期策略以及記憶體淘汰機制

redis採用的是定期刪除 惰性刪除策略。
為什麼不用定時刪除策略?
定時刪除,用一個計時器來負責監視key,過期則自動刪除。雖然記憶體及時釋放，但是十分消耗CPU資源。在大並發請求下，CPU要將時間應用在處理請求，而不是刪除key,因此沒有採用這一策略.
定期刪除惰性刪除是如何工作的呢?
# 定期刪除，redis預設每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。
於是，惰性刪除派上用場。也就是說在你取得某個key的時候，redis會檢查一下，這個key如果設定了過期時間那麼是否過期了？如果過期了此時就會刪除。
採用定期刪除 惰性刪除就沒其他問題了麼?
不是的，如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的記憶體會越來越高。那就應該採用記憶體淘汰機制。
在redis.conf中有一行配置

maxmemory-policy volatile-lru

該配置就是配內存淘汰策略的(什麼，你沒配過？好好反省一下自己)

volatile- lru：從已設定過期時間的資料集（server.db[i].expires）中挑選最近最少使用的資料淘汰
volatile-ttl：從已設定過期時間的資料集（server.db[i].expires）中挑選將要過期的資料淘汰
volatile-random：從已設定過期時間的資料集（server.db[i].expires）中任意選擇資料淘汰
allkeys-lru：從資料集（server.db[i].dict）中挑選最近最少使用的資料淘汰
allkeys-random：從資料集（server.db[i].dict）中任意選擇資料淘汰
no-enviction（驅逐）：禁止驅逐數據，新寫入操作會報錯
ps ：如果沒有設定expire 的key, 不滿足先決條件(prerequisites); 那麼volatile-lru, volatile-random 和volatile-ttl 策略的行為, 和noeviction(不刪除) 基本上一致。

Redis 為什麼是單線程的

官方FAQ表示，因為Redis是基於記憶體的操作，CPU不是Redis的瓶頸，Redis的瓶頸最有可能是機器記憶體的大小或網路頻寬。既然單線程容易實現，而且CPU不會成為瓶頸，那就順理成章地採用單線程的方案了（畢竟採用多線程會有很多麻煩！）Redis利用隊列技術將並發訪問變為串行訪問
1 ）絕大部分請求是純粹的內存操作（非常快速）2）採用單線程,避免了不必要的上下文切換和競爭條件
3）非阻塞IO優點：
1.速度快，因為數據存在記憶體中，類似HashMap，HashMap的優點就是尋找和操作的時間複雜度都是O(1)
2. 支援豐富資料型，支援string，list，set，sorted set，hash
3 .支援事務，操作都是原子性，所謂的原子性就是對資料的變更要麼全部執行，要麼全部不執行
4. 豐富的特性：可用於緩存，訊息，按key設定過期時間，過期後將會自動刪除如何解決redis的並發競爭key問題

同時有多個子系統去set一個key。這個時候要注意什麼呢？不建議使用redis的事務機制。因為我們的生產環境，基本上都是redis叢集環境，做了資料分片作業。你一個事務中有牽涉到多個key操作的時候，這多個key不一定都儲存在同一個redis-server上。因此，redis的事務機制，十分雞肋。
(1)如果對這個key操作，不要求順序： 準備一個分散式鎖，大家去搶鎖，搶到鎖就做set操作即可
(2)如果對這個key操作，要求順序： 分散式鎖定時間戳記。假設這會系統B先搶到鎖，將key1設定為{valueB 3:05}。接下來系統A搶到鎖，發現自己的valueA的時間戳早於快取中的時間戳，那就不做set操作了。以此類推。
(3) 利用佇列，將set方法變成串列存取也可以redis遇到高並發，如果保證讀寫key的一致性
對redis的操作都是具有原子性的,是執行緒安全的操作,你不用考慮並發問題,redis內部已經幫你處理好並發的問題了。

Redis 叢集方案該怎麼做？都有哪些方案？

1.twemproxy，大概概念是，它類似於一個代理方式， 使用時在本需要連接redis 的地方改為連接twemproxy， 它會以一個代理的身份接收請求並使用一致性hash 演算法，將請求轉接到具體redis，將結果再回傳twemproxy。
缺點： twemproxy 自身單一連接埠實例的壓力，使用一致性 hash 後，對 redis 節點數量改變時候的計算值的改變，資料無法自動移動到新的節點。

2.codis，目前用的最多的叢集方案，基本和twemproxy 一致的效果，但它支援在節點數量改變情況下，舊節點資料可恢復到新hash 節點

# 3.redis cluster3.0 自帶的集群，特點在於他的分佈式演算法不是一致性hash，而是hash 槽的概念，以及自身支援節點設定從節點。具體看官方文件介紹。

有沒有嘗試進行多機redis 的部署？如何保證數據一致的？

主從複製，讀寫分離
一類是主資料庫（master）一類是從資料庫（slave），主資料庫可以進行讀寫操作，當發生寫入操作的時候自動將數據同步到從資料庫，而從資料庫一般是唯讀的，並接收主資料庫同步過來的數據，一個主資料庫可以有多個從資料庫，而一個從資料庫只能有一個主資料庫。

對於大量的請求怎麼樣處理

redis是一個單線程程序，也就說同一時刻它只能處理一個客戶端請求；
redis是透過IO多路復用（select，epoll, kqueue，依據不同的平台，採取不同的實作）來處理多個客戶端請求的

Redis 常見效能問題和解決方案？

(1) Master 最好不要做任何持久化工作，如RDB 記憶體快照和AOF 日誌檔案
(2) 如果資料比較重要，某個Slave 開啟AOF 備份數據，策略設定為每秒同步一次
(3) 為了主從複製的速度和連接的穩定性， Master 和Slave 最好在同一個區域網路內
(4) 盡量避免在壓力很大的主庫上增加從庫
(5) 主從複製不要用圖狀結構，用單向鍊錶結構更為穩定，即： Master Slave3…

#講解下Redis執行緒模型

檔案事件處理器包含分別是 套接字、 I/O 多重化程式、 檔案事件分派器（dispatcher）、 以及事件處理器。使用 I/O 多重化程式來同時監聽多個套接字， 並根據套接字目前執行的任務來為套接字關聯不同的事件處理器。當被監聽的套接字準備好執行連接應答（accept）、讀取（read）、寫入（write）、關閉（close）等操作時， 與操作相對應的文件事件就會產生， 此時文件事件處理器就會呼叫套接字之前關聯好的事件處理器來處理這些事件。
I/O 多重化程式負責監聽多個套接字， 並向檔案事件分派器傳送那些產生了事件的套接字。
工作原理：
1)I/O 多重化程式負責監聽多個套接字， 並向檔案事件分派器傳送那些產生了事件的套接字。
儘管多個文件事件可能會並發地出現， 但I/O 多路復用程序總是會將所有產生事件的套接字都入隊到一個隊列裡面， 然後通過這個隊列， 以有序（sequentially）、同步（synchronously）、每次一個套接字的方式向文件事件分派器傳送套接字： 當上一個套接字產生的事件被處理完畢之後（該套接字為事件所關聯的事件處理器執行完畢）， I/O 多重化程式才會繼續傳送下一個套接字到檔案事件分派器。如果一個套接字又可讀又可寫的話， 那麼伺服器將先讀套接字， 後寫套接字.

為什麼Redis的操作是原子性的，怎麼保證原子性的？

對於Redis而言，命令的原子性指的是：一個操作的不可以再分，操作要麼執行，要麼不執行。
Redis的操作之所以是原子性的，是因為Redis是單線程的。
Redis本身提供的所有API都是原子操作，Redis中的事務其實是要確保批次操作的原子性。
多個指令在並發中也是原子性的嗎？
不一定， 將get和set改成單一指令操作，incr 。使用Redis的事務，或使用Redis Lua==的方式實現.

Redis交易

Redis交易功能是透過MULTI、EXEC、DISCARD和WATCH 四個原語實現的
Redis會將一個交易中的所有命令序列化，然後按順序執行。
1.redis 不支援回滾“Redis 在交易失敗時不進行回滾，而是繼續執行餘下的命令”， 所以 Redis 的內部可以保持簡單且快速。
2.如果在一個交易中的命令出現錯誤，那麼所有的命令都不會執行；
3.如果在一個事務中出現運行錯誤，那麼正確的指令就會被執行。
註：redis的discard只是結束本次事務,正確命令造成的影響仍然存在.

#1）MULTI命令用於開啟一個事務，它總是返回OK。 MULTI執行之後，客戶端可以繼續向伺服器發送任意多條命令，這些命令不會立即被執行，而是被放到一個佇列中，當EXEC命令被呼叫時，所有佇列中的命令才會被執行。
2）EXEC：執行所有事務區塊內的命令。傳回事務區塊內所有指令的回傳值，依指令執行的先後順序排列。當操作被打斷時，傳回空值 nil 。
3）透過呼叫DISCARD，客戶端可以清空事務佇列，並放棄執行事務， 且客戶端會從事務狀態中退出。
4）WATCH 指令可以為 Redis 交易提供 check-and-set （CAS）行為。可以監控一個或多個鍵，一旦其中有一個鍵被修改（或刪除），之後的事務就不會執行，監控一直持續到EXEC指令。

Redis實作分散式鎖定

Redis為單進程單執行緒模式，採用佇列模式將並發存取變成串列訪問，且多客戶端對Redis的連線並不存在競爭關係Redis中可以使用SETNX指令實現分散式鎖定。
將 key 的值設為 value ，當且僅當 key 不存在。若給定的key 已經存在，則SETNX 不做任何動作
 

解鎖：使用del key 指令就能釋放鎖定
解決死鎖：
1）透過Redis中expire()給鎖設定最大持有時間，如果超過，則Redis來幫我們釋放鎖。
2） 使用 setnx key 「目前系統時間 鎖定持有的時間」和getset key 「目前系統時間 鎖定持有的時間」組合的指令就可以實現。

以上是Redis相關問題怎麼解決的詳細內容。更多資訊請關注PHP中文網其他相關文章！