redis分布式緩存

一、概述

為了解決單台redis服務性能不足的問題，所以讓redis讀寫分離

二、redis性能測試

　　工具：

　　redis—benchmark

　　官方自帶的redis性能測試工具看，可以觀看redis的實際性能。服務器的硬件配置、網絡狀態、測試環境都會對redis性能有所影響

　　使用語法：redis-benchmark

三TPS、QPS、RT

　　在描述系統的高並發能力時，吞吐量（TPS）、QPS、響應時間（RT）經常提到。

　　響應時間RT

　　吞吐量TPS

　　每秒查詢率QPS

響應時間（RT）

　　響應時間是指系統對請求作出響應的時間，在討論系統的響應時間時，通常是指該系統所有功能的平均時間或者所有功能的最大響應時間。

吞吐量TPS

　　吞吐量是指系統在單位時間內處理請求的數量

　　資源配置合理，每個用戶看到的平均響應時間並不隨用戶數的增加而線性增加

　　吞吐量是一個比較用用的標准，最大吞吐量基本一致，可以判斷兩個系統處理能力基本一致

每秒查詢率（QPS）

　　每秒查詢率QPS是對一個特定的查詢服務器在規定時間內所處理流量多少的衡量標准，也就是最大吞吐能力

　　可以測算Redis性能，通過benchmark來測試QPS是多少，來估算redis性能。

四、讀寫能力分離

　　如果一台服務器的QPS不能滿足要求，我們還可以對讀寫能力擴展，解決性能瓶頸。運行新的服務器簡稱從服務器，讓從服務器與主服務器進行連接，然后主服務器發送數據副本，從服務器通過網絡根據主武器的數據副本進行准實時更新，具體的更新速度取決於網絡帶寬。

　　這樣我們就有額外的從服務器處理讀請求，通過將讀請求分散到不同的服務器上面進行處理，用戶可以從新添加的從服務器上獲得額外的讀查詢處理能力。

　　redis本身是支持讀寫分離的。在配置文件修改

　　具體位修改redis.conf文件，添加添加 slaveof 192.168.200.128 6379

五、redis同步原理

　　redis的主從復制，就是主服務器執行寫操作命令，從服務器通過主服務器的數據的變化，同步數據到從服務器。但是如果主服務器下線，從服務器無法連接到主服務器，那么數據同步該如何拿到不能連接主服務器這段時間的命令呢？

　　主從復制中的主從服務器雙方的數據庫將保存x相同的數據，概念上將這種現象乘坐數據庫狀態一致。

　　redis有兩種持久化方式：RDB全量持久化和AOF增量持久化

　　2主要有完成重同步和部分重同步兩種模式

　　

功能主要有以下三個部分構成：

　　主服務的復制偏移量和從服務器的復制偏移量

　　主服務器的復制積壓緩沖區，默認大小為1M

　　服務器的運行ID，用於存儲服務器表示

　　如果從服務器斷線重寫連接，獲取主服務器的運行ID與重接后的主服務器運行ID進行對比，判斷是不是原來的主服務器，從而決定是執行部分重同步，還是執行完整重同步。

六、Sentinel實現高可用（哨兵）

　　Sentinel介紹

　　不用哨兵，主節點掛掉，將從節點晉升到主節點，同時需要修改應用方的主節點地址，還需要命令所有從節點去復制新的主節點

　　這個工程費時費力，所以有了哨兵機制

　

Sentinel的使用

　　主要是先修改sentinel.conf的配置。

原理

　　Sentinel主要是監控服務器的狀態，並決定是否進行故障轉移，Sentinel判斷服務是否下線，分為主觀下線和客觀下線

　　主觀下線：

　　　　主觀下線指的是單個Sentinel實例對服務器做出的下線判斷

　　　　特點：

　　　　如果一個服務器沒有在指定的時間內，對向它發送PING命令的Sentinel返回一個有效回復，那么Sentinel就會將這個服務器標記為主觀下線。

　　客觀下線：

　　　　多個Sentinel實例在對同一個服務器做出SDOWN判斷，並且通過命令互相交流之后，得出服務器下線判斷。（一個Sentinel和另一個Sentinel可以互相交流，詢問對方是否認為給定的服務器已下線）

　　　　特點：

　　　　　　從主觀下線狀態切換到客觀下線狀態並沒有嚴格規定的法定人數順發，而是使用了流言傳播：如果Sentinel在給定的時間范圍內，從其他Sentinel哪里接收到了足夠數量的主服務器下線報告，那么Sentinel就會將主服務器的狀態從主觀下線改變為客觀下線。

　　　　注意點：

　　　　　　客觀下線只適用於主服務器，對於其他類型的redis實例，Sentinel在將他們判斷為下線前不需要進行協商，所以從服務器或者其他Sentinel不會達到客觀下線條件。只要一個Sentinel發現某個主服務器進入客觀下線狀態，這個Sentinel就可能被其他Sentinel推選出，並對失效的主服務器執行自動故障遷移操作。

七、Sentinel三大工作任務

　　監控：Sentinel會不斷地檢查你的主服務器和從服務器是否運作正常。

　　提醒：當被監控的某個redis服務器出現問題時，Sentinel可以通過API向管理員或者其他應用程序發送通知。

　　自動故障遷移：當一個主服務器不能正常工作時，Sentinel會開始一次自動故障轉移操作，他會將失效主服務器的一個從服務器升級為新的主服務器，並讓失效主服務器的其他從服務器改為復制新的主服務器。

　　當客戶單試圖連接失效的主服務器時，集群也會向客戶端返回新主服務器的地址，是的集群可以使用新主服務器代替失效服務器。

八、互聯網冷備和熱備

　　冷備：　　

　　　　概念：

　　　　　　冷備發生在數據庫已經正常關閉的情況下，當正常關閉時會提供給我們一個完整的數據庫

　　　　優點：

　　　　　　非常快速的備份方法

　　　　　　低度維護，高度安全

　　　　缺點：

　　　　　　單獨使用時，只能提供某一時間點上的恢復

　　　　　　在實施備份的全過程中，數據庫必須要作備份而不能作其他工作。也就是說，在冷備份過程中，數據庫必須是關閉狀態。

　　熱備：

　　　　概念：

　　　　　　熱備份是在數據庫運行的情況下，采用歸檔模式方式備份數據庫的方法

　　　　優點：

　　　　　　備份的時間短

　　　　　　備份時數據庫扔可使用

　　　　　　可達到秒級恢復

　　　　缺點：

　　　　　　若熱備份不成功，所得結果不可用於時間點的恢復

　　　　　　對於維護，要仔細小心

九、Sentinel整合SpringBoot

　　　設置redis密碼，在所有的redis配置文件redis.conf中，添加配置　

集群中主機和備機的redis.conf配置文件都需要添加

# 設置密碼
requirepass 123456

# 設置訪問主服務器密碼
masterauth 123456

在Sentinel哨兵的配置文件sentinel01.conf中添加以下設置：

sentinel auth-pass mymaster 123456

整合SpringBoot

首先導入依賴，在yml文件中配置密碼，地址。

十、Redis內置集群

　　為了保證可以進行投票，需要至少三個主節點

　　每個主節點都需要至少一個從節點，所以需要至少三個從節點。

　　所以需要六個redis服務器。

集群環境redis節點的配置# 不能設置密碼，否則集群啟動時會連接不上

第一個redis節點node1准備好之后，再復制5份，修改六個節點的端口號為7001~7006，修改redis.conf配置文件即可也就是一共六個node，每個node都有redis.conf文件，端口不同就行

redis集群的管理工具使用的是ruby腳本語言，安裝集群需要ruby環境，先安裝ruby環境：

# 使用集群管理腳本啟動集群

./redis-trib.rb create --replicas 1 192.168.200.128:7001 192.168.200.128:7002 192.168.200.128:7003 192.168.200.128:7004 192.168.200.128:7005 192.168.200.128:7006 

ip地址都一樣

十一、集群原理

　　集群框架圖

架構特點：

　　1、所有redis節點彼此互聯

緩存雪崩：使用鎖或隊列、設置過期標志更新緩存、為key設置不同的緩存失效時間

緩存穿透：

最常見的則是采用布隆過濾器，將所有可能存在的數據哈希到一個足夠大的bitmap中，一個一定不存在的數據會被這個bitmap攔截掉，從而避免了對底層存儲系統的查詢壓力。

另外也有一個更為簡單粗暴的方法，如果一個查詢返回的數據為空（不管是數據不存在，還是系統故障），我們仍然把這個空結果進行緩存，但它的過期時間會很短，最長不超過五分鍾。通過這個直接設置的默認值存放到緩存，這樣第二次到緩沖中獲取就有值了，而不會繼續訪問數據庫，這種辦法最簡單粗暴！

三、緩存預熱

緩存預熱這個應該是一個比較常見的概念，相信很多小伙伴都應該可以很容易的理解，緩存預熱就是系統上線后，將相關的緩存數據直接加載到緩存系統。這樣就可以避免在用戶請求的時候，先查詢數據庫，然后再將數據緩存的問題！用戶直接查詢事先被預熱的緩存數據！

 

解決思路：

1、直接寫個緩存刷新頁面，上線時手工操作下；

2、數據量不大，可以在項目啟動的時候自動進行加載；

3、定時刷新緩存；

四、緩存更新

除了緩存服務器自帶的緩存失效策略之外（Redis默認的有6中策略可供選擇），我們還可以根據具體的業務需求進行自定義的緩存淘汰，常見的策略有兩種：

（1）定時去清理過期的緩存；

（2）當有用戶請求過來時，再判斷這個請求所用到的緩存是否過期，過期的話就去底層系統得到新數據並更新緩存。

兩者各有優劣，第一種的缺點是維護大量緩存的key是比較麻煩的，第二種的缺點就是每次用戶請求過來都要判斷緩存失效，邏輯相對比較復雜！具體用哪種方案，大家可以根據自己的應用場景來權衡。

五、緩存降級

當訪問量劇增、服務出現問題（如響應時間慢或不響應）或非核心服務影響到核心流程的性能時，仍然需要保證服務還是可用的，即使是有損服務。系統可以根據一些關鍵數據進行自動降級，也可以配置開關實現人工降級。

降級的最終目的是保證核心服務可用，即使是有損的。而且有些服務是無法降級的（如加入購物車、結算）。

在進行降級之前要對系統進行梳理，看看系統是不是可以丟卒保帥；從而梳理出哪些必須誓死保護，哪些可降級；比如可以參考日志級別設置預案：

（1）一般：比如有些服務偶爾因為網絡抖動或者服務正在上線而超時，可以自動降級；

（2）警告：有些服務在一段時間內成功率有波動（如在95~100%之間），可以自動降級或人工降級，並發送告警；

（3）錯誤：比如可用率低於90%，或者數據庫連接池被打爆了，或者訪問量突然猛增到系統能承受的最大閥值，此時可以根據情況自動降級或者人工降級；

（4）嚴重錯誤：比如因為特殊原因數據錯誤了，此時需要緊急人工降級。