目錄
1、怎麼才能夠突破單機主從架構瓶頸，讓redis支撐海量資料？
redis中分布式資料儲存的演算法
什麼是redis的雪崩和穿透？
如何保證快取與資料庫的雙寫一致性？
使用cache aside pattern
redis的併發競爭問題是什麼？如何解決這個問題？了解redis事務的cas方案嗎？
redis cluster，主要是針對海量資料+高併發+高可用的場景
（1）自動將資料進行分片，每個master上放一部分資料
（2）提供內建的高可用支援，部分master不可用時，還是可以繼續工作的
在redis cluster架構下，每個redis要放開兩個埠號，比如乙個是6379，另外乙個就是加10000的埠號，比如16379
16379埠號是用來進行節點間通訊的，也就是cluster bus的東西，集群匯流排。cluster bus的通訊，用來進行故障檢測，配置更新，故障轉移授權
在擴容的時候會導致快取無法命中，需要全部重新進行hash取餘。例如3臺-->4臺，就會有3/4=75%的無法命中。如0,1,2,3,4,5,6,7,8,9,10,11,12，其中擴容之後只有1,2,3能夠命中
一致性hash演算法（memcached） -> redis cluster，hash slot演算法
1、hash值是乙個非負整數，將非負整數的值範圍做成乙個圓環範圍
2、對集群上的節點某個屬性（比如節點名）求hash值，放到環上
3、對資料key求hash值，也放到環上，按順時針方向找到離它最近的節點，放到它上面
由於一致性hash導致加入的新節點無法均衡分攤其他節點的壓力所以對於放入的節點建立其對應的虛擬節點，然後均勻的放入到裡面。
例如下面的：將n0節點建立出多個虛擬節點然後放入到裡面
即使使用了虛擬節點，在節點逐漸增多的時候還是容易出現虛擬節點分布密集，導致hash傾斜。
redis cluster有固定的16384個hash slot（類似於一致性hash的虛擬節點），對每個key計算crc16值，然後對16384個hash slot取模，可以獲取key對應的hash slot
redis cluster中每個master都會持有部分slot，比如有3個master，那麼可能每個master持有5000多個hash slot
每增加乙個master，就將其他master的hash slot移動部分過去，減少乙個master，就將它的hash slot移動到其他master上去
資料遷移可以理解為slot(槽)和value的遷移，由於redis 是走的記憶體，所以移動資料遷移的成本是非常低的
快取雪崩發生的現象：redis掛了之後，請求全部進入到資料庫，最後導致資料庫掛掉，掛掉之後整個系統掛掉。
快取雪崩的事前事中事後的解決方案
事前：redis高可用，使用redis cluster，避免全盤崩潰
事中：hystrix限流&降級，避免mysql掛掉
事後：redis持久化，快速恢復快取資料
快取穿透的現象：有人惡意攻擊，傳送大量的請求不存在的id，然後快取沒查到全部走資料庫。然而資料庫沒有，它繼續迴圈請求，導致資料庫崩潰。
快取穿透的解決方法：只要在資料庫沒查到的id，就寫乙個空值到快取裡去（set -1 unknown）
（1）讀的時候，先讀快取，快取沒有，再讀資料庫，然後取出資料後放入快取，同時返回響應
（2）更新的時候，先刪除快取，然後再更新資料庫
2、為什麼是刪除快取，而不是更新快取呢？
如果是更新快取的話，當寫入資料庫寫資料失敗之後，而快取資料是更新後的資料，這樣就會出現資料不一致問題。
在高併發的情況下，對某個資料進行更新操作的時候，第乙個執行緒首先刪除了redis資料，然後在更新資料庫的時候，第二個執行緒來了，他發現redis 沒有資料，就到mysql 中查詢，拿到舊的資料。這個時候第乙個執行緒恰好在第乙個執行緒拿到舊的資料之後更新完畢，然後寫入到redis中，而第二個執行緒拿到舊的資料也寫入到redis中，這個時候redis中新的資料被舊的資料所覆蓋。
上面的解決辦法：mysql中寫資料的時候，必須保持時間戳，從mysql中查出來時候，與redis 中已有資料的時間戳進行比較，類似於cas比較。
對於redis的資料高併發下的資料同步：多個客戶端來共同修改redis中的某個資料，這個時候需要使用分布式鎖，通過**實現，主要是針對某一筆資料的流水號加鎖，防止多個執行緒寫入這個資料。
分布式儲存架構一 分布式儲存概念
分布式儲存系統是由大量廉價普通pc伺服器通過internet互聯，對外作為乙個整體提供服務的系統。它的規模大且成本低。分布式儲存系統的特性 分布式儲存系統挑戰主要在於資料 狀態資訊的持久化，要求在自動遷移 自動容錯 併發讀寫的過程中保證資料的一致性。資料分布均勻 資料一致性 容錯能力 事務與併發控制...
分布式架構相關知識
傳統單體架構 分布式架構系統 新功能開發 需要時間 容易開發和實現 部署不經常且容易部署 經常發布，部署複雜 隔離性故障影響範圍大 故障影響範圍小 架構設計 難度小難度級數增加 系統效能 響應時間快，吞吐量小 響應時間慢，吞吐量大 系統運維 運維簡單 運維複雜 新人上手 學習曲線大 應用邏輯 學習曲...
尚籌網07分布式架構
專案的主體結構 1 實現業務功能的工程模組 2 為了應對業務功能之外的需求 壓力給專案中增加的中介軟體等其他系統 3 為了讓整個專案能夠順暢 高效的執行,需要把業務功能和中介軟體以及其他系統有效的整合起來 乙個工程 乙個 war包 執行在乙個 tomcat 上all in one 單機版把原來的乙個...