《分散式快取》讀書筆記二

如果一個鎖守護多個相互獨立的狀態變數，可以通過分拆鎖，使每一個鎖守護不同的變數，從而改進可伸縮性

分拆鎖有時候可以被擴充套件，分成若干加鎖塊的集合，並且使他們歸屬於相互獨立的物件，這樣的情況就是分離鎖

系統提倡服務無狀態，分散式環境中任何節點也是無狀態的，可以隨意重啟和替代，便於做擴充套件

考慮冪等性設計

C:任何的讀寫都應該看起來是“原子”的，或序列的，所有的讀寫請求都好像被全域性排序

A:對任何非失敗節點都應該在有限時間內給出請求的迴應

P:允許節點之間丟失任意多的訊息

Paxos 理論簡介

Prepare 階段：

1.Proposer 傳送 Prepare，生成全域性唯一且遞增的提案ID，向Paxos 叢集的所有機器傳送請求

2.Acceptor 應答 Prepare

Accept 階段：

1.Proposer 傳送 Accept（Prepare階段多數派返回值，就是超過 n/2+1，n為機器數）

2.Acceptor 應答 Accept

 2PC：

1.提交請求階段確定相關參與者對於事務處理是否準備就緒

2.提交階段基於投票結果，由協調器決定提交事務或者是退出事務處理

3PC在2PC的基礎上增加了一次互動，既preCommit 預提交，只要預提交成功，則一定保證doCommit提交成功

Raft角色型別：

領導者：處理所有客戶端互動，日誌複製等動作

選民：完全被動的角色，等待被通知投票

候選人：選舉過程中提名自己的實體，一旦選舉成功，則成為領導者

 Gossip 去中心化分散式協議

心跳檢測：收到心跳可以確認節點正常，但是收不到心跳卻不能確認該節點已經死亡

快取的結果為空也要進行快取

snowflake 優缺點

優點：

基於記憶體，很快快。

沒有什麼依賴，實現也特別簡單。

可以根據實際情況調整各各位段，方便靈活。

缺點：

只能趨勢遞增。（有些也不叫缺點，網上有些如果絕對遞增，競爭對手中午下單，第二天在下單即可大概判斷該公司的訂單量，危險！！！）

依賴機器時間，如果發生回撥會導致可能生成 id 重複。

LRU核心思想是如果資料最近被訪問過，那麼將來被訪問的概率也更高