一、持久化資料庫的缺點：

1、平常我們使用的關係型資料庫有Mysql、Oracle以及SqlServer等，在開發的過程中，資料庫通常都是通過web提供的資料庫驅動來連線資料庫進行curd操作。那麼我們 日常使用的資料庫的資料都儲存儲存在哪裡呢？

以mysql為例子：開啟mysql所在資料夾目錄下的的data資料夾，如下所示：

也就是說，我們日常使用的關係型資料中的資料，全部儲存在我們部署資料庫的機器的硬碟中。一般我們的網站開發完成，上線之後，伺服器的讀寫效率是網站執行速度的重要條件，當然還有伺服器的頻寬等，但是這些東西都可以通過硬體的更新升級來解決。其實與網站執行效率息息相關的東西，就是我們的------資料庫。

2、提高資料庫的效率的辦法：

（1）sql語句的優化技術，sql語句寫的處理效率比較高，資料庫處理能力就會上去，而網站的資料處理能力也會快些。

（2）使用高併發處理、負載均衡和分散式資料庫。

（3）降低資料庫的讀寫次數，引入快取技術。

3、使用快取減輕資料庫的負載：快取就是在記憶體中儲存的資料備份，當資料沒有發生本質改變的時候，我們就不讓資料的查詢去資料庫進行操作，而去記憶體中取資料，這樣就大大降低了資料庫的讀寫次數，而且從記憶體中讀資料的速度比去資料庫查詢要快一些，這樣同時又提高了效率。

二、redis

1、百度百科給出的定義：Redis是一個開源的使用ANSI C語言編寫、支援網路、可基於

語言編寫的，所以在linux安裝的時候就很不友好、使用者體驗 差評哈哈哈哈哈哈）

2、使用redis作快取的好處：

（1）效能：我們在碰到需要執行耗時特別久，且結果不頻繁變動的SQL，就特別適合將執行結果放入快取。這樣，後面的請求就去快取中讀取，使得請求能夠迅速響應。

（2）併發：在高併發的情況下，所有的請求直接訪問資料庫，資料庫會出現連線異常。這個時候，就需要使用redis做一個緩衝操作，讓請求先訪問到redis，而不是直接訪問資料庫。

3、使用redis作快取需要考慮的幾個問題：

快取和資料庫雙寫一致性問題、快取雪崩、快取擊穿、快取穿透、熱點key重建

（1）快取雪崩：在同一時間大量快取失效，導致資料庫壓力激增從而崩潰。

解決辦法：將快取失效時間分散開，比如我們可以在原有的失效時間基礎上增加一個隨機值，比如1-5分鐘隨機，這樣每一個快取的過期時間的重複率就會降低，就很難引發集體失效的事件。

（2）快取擊穿：針對某一個非常“熱點”的key，在它即將過期的那一個瞬間恰巧有大量的併發請求過來，這些請求發現快取過期一般都會從DB載入資料並回到快取，這個時候大併發的請求可能會瞬間把DB壓垮。

（3）快取穿透：快取穿透是指查詢一個根本不存在的資料，快取層和儲存層都不會命中。通常處於容錯的考慮，如果從儲存層查詢不到資料則不會寫入快取層。快取穿透將導致請求不存在的資料每次都要到儲存層去在找，就失去了快取保護後端儲存的意義。 造成快取穿透的原因主要有兩個：自身業務程式碼或者資料出現問題和一些惡意攻擊或爬蟲造成大量空命中 

解決辦法：對於快取穿透，可以給不存在的資料快取一個空物件，同時設定超時時間。如果在此期間快取層和儲存層的資料不一致，可使用訊息系統或者其他操作剔除快取中的空物件。

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

純記憶體操作、單執行緒操作，避免了頻繁的上下文切換、採用了非阻塞I/O多路複用機制

說一下非阻塞I/O多路複用機制：只有單個執行緒，通過跟蹤每個I/O流的狀態，來管理多個I/O流。我們的redis-client在操作的時候，會產生具有不同事件型別的socket。在服務端，有一段I/0多路複用程式，將其置入佇列之中。然後，檔案事件分派器，依次去佇列中取，轉發到不同的事件處理器中。

5、redis的持久化

RDB：當資料庫中的key-value值有進行相應的增刪改時，每經過一段時間，對資料庫進行一次快照，儲存為dump.rdb檔案，伺服器每次重啟時都會將dump.rdb裡的資料讀到redis中

配置RDB的方法：redis.conf檔案

save 900 1              #在900秒(15分鐘)之後，如果至少有1個key發生變化，則dump記憶體快照。

save 300 10            #在300秒(5分鐘)之後，如果至少有10個key發生變化，則dump記憶體快照。

save 60 10000        #在60秒(1分鐘)之後，如果至少有10000個key發生變化，則dump記憶體快照。

AOF：使用日誌功能儲存資料，預設AOF是關閉的

在Redis的配置檔案中存在三種同步方式，它們分別是：

appendfsync always     #每次有資料修改發生時都會寫入AOF檔案。

appendfsync everysec  #每秒鐘同步一次，該策略為AOF的預設策略。（預設，但可修改）

appendfsync no          #從不同步。高效但是資料不會被持久化。

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

定期刪除，redis預設每個100ms檢查，是否有過期的key,有過期key則刪除。需要說明的是，redis不是每個100ms將所有的key檢查一次，而是隨機抽取進行檢查(如果每隔100ms,全部key進行檢查，redis豈不是卡死)。因此，如果只採用定期刪除策略，會導致很多key到時間沒有刪除。於是，惰性刪除派上用場。也就是說當你每次獲取某個key的時候，redis會檢查一下，這個key如果設定了過期時間那麼是否過期了？如果過期了此時就會刪除。

如果定期刪除沒刪除key。然後你也沒即時去請求key，也就是說惰性刪除也沒生效。這樣，redis的記憶體會越來越高。那麼就應該採用記憶體淘汰機制。

# maxmemory-policy allkeys-lru

1）noeviction：當記憶體不足以容納新寫入資料時，新寫入操作會報錯。
2）allkeys-lru：當記憶體不足以容納新寫入資料時，在鍵空間中，移除最近最少使用的key。
3）allkeys-random：當記憶體不足以容納新寫入資料時，在鍵空間中，隨機移除某個key。
4）volatile-lru：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，移除最近最少使用的key。
5）volatile-random：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，隨機移除某個key。
6）volatile-ttl：當記憶體不足以容納新寫入資料時，在設定了過期時間的鍵空間中，有更早過期時間的key優先移除。

7、redis叢集（3.0之後的版本才可以搭建叢集）

即使使用哨兵，此時的redis叢集中的每個資料庫依然存有叢集中的所有資料，從而導致叢集的總資料儲存量受限於記憶體最小的資料庫節點，形成木桶效應。

Redis3.0版的一大特性就是支援叢集功能。叢集的特點在於擁有和單機例項同樣的效能，同時在網路分割槽後能夠提供一定的可訪問性以及對主資料庫故障恢復的支援。另外叢集支援幾乎所有的單機例項支援的命令，對於設計多鍵的命令，如果每個鍵都在同一個節點中，則可以正常支援，否則會提示錯誤。除此之外叢集還有一個限制是只能使用預設的0號資料庫，如果執行select切換資料庫會發生錯誤。

哨兵和叢集是兩個獨立的功能，但從特性來看哨兵可以是叢集的子集，當不需要資料分片或者已經在客戶端進行分片的場景下哨兵就已經足夠用了。

（1）redis-cluster架構圖

（2）redis-cluster投票容錯：

（3）redis叢集裡面沒有一個統一的入口，也就是說叢集中每個節點都可以被客戶端連線。叢集內部的每個節點之間都是相互通訊的（ping-pong機制），依據投票容錯機制來檢查叢集的健康狀態（如果超過半數的節點認為一個節點掛了，那它就掛了，上圖中的紅色節點）。如果掛了的節點有從節點，那麼會將從節點扶正，這時候叢集還可以繼續提供服務。如果沒有從節點，那麼叢集就不可用了。

架構細節:

A、所有的redis節點彼此互聯(PING-PONG機制),內部使用二進位制協議優化傳輸速度和頻寬。

B、節點的fail是通過叢集中超過半數的節點檢測失效時才生效。

C、叢集是否可繼續提供服務需要判斷掛了的節點是否有從節點。

D、客戶端與redis節點直連,不需要中間proxy層.客戶端不需要連線叢集所有節點,連線叢集中任何一個可用節點即可

E、redis-cluster把所有的物理節點對映到[0-16383]slot上,cluster 負責維護node<->slot<->value。

（4）redis叢集中內建了 16384 個雜湊槽，當需要在 redis叢集中放置一個 key-value 時，redis 先對 key 使用 crc16 演算法算出一個結果，然後把結果對 16384 求餘數，這樣每個key 都會對應一個編號在 0-16383 之間的雜湊槽，redis 會根據節點數量大致均等的將哈希槽對映到不同的節點。同理，當需要在redis叢集中獲取一個key的時候，先計算這個key在哪個槽，然後這個槽在哪臺伺服器上，最後在跳轉到那臺伺服器上取出key即可。

（5）redis叢集的搭建（關閉防火牆）：

因為投票容錯機制，redis叢集中至少應該有三個節點。要保證叢集的高可用，需要每個節點有一個備份機。redis叢集至少需要6臺伺服器。可以搭建偽分散式。使用一臺虛擬機器執行6個redis例項。需要修改redis的埠號7001-7006

（6）獲取與插槽對應的節點

實際上，當客戶端向叢集中的任意一個節點發送命令後，該命令會判斷相應的鍵是否在當前節點中，如果在當前節點，會向單機例項一樣處理該命令；如果鍵不在該節點中，就會返回一個MOVE重定向的請求，告訴客戶端這個節點目前由哪個節點負責，然後客戶端再將同樣的請求向目標節點重新發送一次以獲得結果。

相比單機例項，叢集的命令重定向也增加了命令的請求次數，因此請求重定向對效能還是有點影響的。

為了解決這一個問題，當發現新的重定向請求時，客戶端應該在重新向正確節點發送命令的同時，快取插槽的路由資訊，就是記錄下當前插槽是由哪一個節點負責的。這樣每次發起請求時，客戶端首先計算屬於哪一個插槽，然後根據路由的快取判斷插槽由哪一個節點負責。考慮到插槽總數比較少，快取所有插槽的路由資訊後，每次發起命令只發向正確的節點，從而到達和單機例項同樣的效能。

（7）故障恢復

在一個叢集中，每個節點都會定期向其他節點發送ping命令，並通過有沒有收到回覆來判斷目標節點是否已經下線。具體來說，叢集中的每一個節點每隔1秒鐘就會隨機選擇5個節點，然後選擇最久沒有響應的節點發送ping命令。

如果一定時間內目標節點沒有響應回覆，則發起ping命令的節點會主觀認為該節點已經下線。如果要在整個叢集中的所有節點都認為某一個節點下線，需要一定數量的節點都認為這個節點疑似下線才可以，這一個具體的過程為：

A：一旦節點A認為節點B疑似下線，就會在叢集中廣播這個資訊，所有其他節點收到訊息後會記錄下這一資訊

B：當進群中某一節點C收到半數以上的節點認為B疑似下線，就會將B標記為下線，並且向叢集中的其他節點廣播這一個資訊，從而使用B節點在整個叢集中下線。

在叢集中，如果一個主資料庫下線，叢集就會進行故障恢復將其中一個從資料庫轉變成主資料庫來保證叢集的完整。

選擇扶正的從資料庫：

A、發現其複製的主資料庫下線的型資料庫（A）向每個叢集中的節點發送請求，要求對方選自己成為主資料庫。

B、如果收到請求的節點沒有選擇其他人，則同意將A設定為主資料庫

C、如果A發現有超過叢集中節點總數一半的節點同意選自己成為主資料庫，則A成功成為主資料庫

D、當有多個從資料庫同時參選主資料庫，則會出現沒有任何節點當選的可能，此時每個參選節點等待一個隨機事件重新發起參選請求，進行下一輪的選舉，直到選舉成功。

當某一個數據庫當選為主資料庫時，會通過命令salveof no one將自己轉換為主資料庫，並將舊的主資料庫的插槽轉換給自己負責。