keep源碼

A. Zookeeper之兩階段提交源碼分析

zookeeper集群為了保證數據一致性，使用了兩階段提交。
在zookeeper集群的角色有：leader、follower、observer。
在這幾個角色中處理讀寫請求是不同的：
讀請求：從當前節點直接讀取數據
寫請求：在leader直接進行兩階段提交、在非leader則是把請求轉交給leader處理
所以，分析兩階段提交就是分析集群模式下的請求處理。在單機模式在請求處理是經過RequestProcessor請求處理鏈處理。
單個zookeeprt請求處理主要有以下幾步：
1、對當前請求生成日誌txn
2、持久化日誌txn
3、根據日誌txn更新Database
兩階段提交（2PC）步驟：

其中標綠色的PrepRequestProcessor、SyncRequestProcessor、CommitProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.LeaderZooKeeperServer#setupRequestProcessors

org.apache.zookeeper.server.quorum.ProposalRequestProcessor#ProposalRequestProcessor

org.apache.zookeeper.server.quorum.LeaderRequestProcessor#processRequest

①、檢查是不是local session本地session，創建臨時節點會升級session
org.apache.zookeeper.server.quorum.QuorumZooKeeperServer#checkUpgradeSession

②、交給下一個請求處理器處理

作用與單機模式相同，給請求Request的Hdr和Txn賦值，然後交給下一個請求處理器處理

如果是寫請求(request.getHdr() != null)，則會把當前請求封裝為協議並發送給follower。發送之後交給SyncRequestProcessor持久化處理

org.apache.zookeeper.server.quorum.Leader#propose

org.apache.zookeeper.server.quorum.Leader#sendPacket
發送到所有其他Followe節點forwardingFollowers

把請求放入到queuedRequests阻塞隊列

①、對請求進行持久化與單機相同
org.apache.zookeeper.server.SyncRequestProcessor#run

向lead發送自己的ack（2PC發送ACK）

org.apache.zookeeper.server.quorum.Leader#processAck

org.apache.zookeeper.server.quorum.Leader#tryToCommit

org.apache.zookeeper.server.quorum.CommitProcessor#commit
提交當前請求，放入到committedRequests，最終會更新database

CommitProcessor類參數：
queuedRequests：表示接收到的請求，沒有進行兩階段的提交
queuedWriteRequests：表示接收到的寫請求，沒有進行兩階段的提交
committedRequests：表示可以提交的請求，在兩階段驗證過半之後進行會在本地進行committe操作，便添加到這個隊列
commitIsWaiting：表示存在可以提交的請求（committedRequests是否有值，有true）
pendingRequests：是一個map集合，表示每個客戶端sessionId的請求
Leader類參數：
outstandingProposals：表示記錄提議的請求的隊列，符合過半機制之後會移除
toBeApplied：表示記錄待生效的請求，在FinalRequestProcessor移除
①、processRequest
org.apache.zookeeper.server.quorum.CommitProcessor#processRequest

首先判斷是否需要兩階段提交。如果需要則會添加到queuedWriteRequests隊列
org.apache.zookeeper.server.quorum.CommitProcessor#needCommit
如果是更改操作則返回true

d、然後，再看一下這個while的退出條件。
①、從queuedRequests取出的是空
②、如果queuedRequests數據不為空，那麼requestsToProcess是大於0的。這時只有maxReadBatchSize < 0或readsProcessed <= maxReadBatchSize才能退出。
maxReadBatchSize < 0表示默認是-1，如果配置了這個參數當連續讀了readsProcessed時，也會退出。
③、pendingRequests和committedRequests不為空
e、commitIsWaiting有待提交的

org.apache.zookeeper.server.quorum.Leader.ToBeAppliedRequestProcessor#processRequest
刪除toBeApplied

其中標綠色的FollowerRequestProcessor、CommitProcessor、SyncRequestProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.FollowerZooKeeperServer#setupRequestProcessors

開了兩條鏈：
FollowerRequestProcessor(firstProcessor)---->CommitProcessor----->FinalRequestProcessor
SyncRequestProcessor---->SendAckRequestProcessor

org.apache.zookeeper.server.quorum.FollowerRequestProcessor#processRequest
請求添加到queuedRequests隊列

FollowerRequestProcessor是一個線程，會從queuedRequests獲取請求
org.apache.zookeeper.server.quorum.FollowerRequestProcessor#run

createSession和closeSession也會轉發給lead節點處理

org.apache.zookeeper.server.quorum.SendAckRequestProcessor#processRequest
在用SendAckRequestProcessor處理之前會先調用SyncRequestProcessor進行持久化處理，由於與單機或lead處理相同就不單獨列出來了。
向領導者發送確認ack包

org.apache.zookeeper.server.quorum.Learner#writePacket

在經過FollowerRequestProcessor處理後，lead端會得到一個Request的請求
org.apache.zookeeper.server.quorum.LearnerHandler#run

org.apache.zookeeper.server.quorum.Leader#submitLearnerRequest

在連接Follower節點的客戶端發送更改命令請求會轉發到leader節點的prepRequestProcessor進行處理

1、run
org.apache.zookeeper.server.quorum.QuorumPeer#run

2、followLeader
org.apache.zookeeper.server.quorum.Follower#followLeader
不斷讀取從lead端的數據包

org.apache.zookeeper.server.quorum.FollowerZooKeeperServer#logRequest

其中標綠色的ObserverRequestProcessor、CommitProcessor、SyncRequestProcessor都繼承了ZooKeeperCriticalThread是一個線程。
org.apache.zookeeper.server.quorum.ObserverZooKeeperServer#setupRequestProcessors

也是開了兩條鏈：
ObserverRequestProcessor(firstProcessor)---->CommitProcessor----->FinalRequestProcessor
SyncRequestProcessor---->null
observer節點不參與兩階段提交，所以同步SyncRequestProcessor之後沒有ACK確認提交。這樣既提高了讀效率，又對寫效率沒有影響。請求處理鏈與leader、follower的功能相同不再累述。

zookeeper集群的兩階段提交，是在寫操作的情況下發生的。2PC的整體實現邏輯是在RequestProcessor請求處理鏈處理的。只有在接受到的ACK超過一半才會進行提交，提交的實現邏輯是在CommitProcessor中實現的，CommitProcessor處理器中裡面涉及多種集合、隊列等參數(需要首先了解這些參數意義，然後再讀CommitProcessor源碼)。

B. keeptalk安裝怎麼安裝

下載keeptalk源碼。
從keeptalk官網下載keeptalk源碼安裝包，解壓keeptalk文件，然後運行安裝程拆猛序，悶孝從終端旅罩橋運行（node keeptalk.js）命令，啟動keeptalk。
KeepTalk是一款開放源代碼的計算機軟體，主要用於實現P2P客戶端/伺服器文本聊天。

C. Vue keep-alive源碼

上面的 extend(Vue.options.components, builtInComponents);我們知道

D. vue列表緩存keep-alive

列表查詢出約課記錄之後，跳轉到詳情後再返回頁面內容刷新，之前搜索的結果就沒有了，為了解決這一問題，使用了keep-alive組件來實現頁面緩存。

keep-alive

keep-alive.js源碼：

只執行一次的鉤子：當vnode.componentInstance和keepAlive為州中true時，不再進入$mount過程，也就不會執行mounted以及之前的鉤子函數（beforeCreated、created、mounted）

可重復執行的activated：在patch階段，最後會執行invokeInsertHook函數，這個函數調用組件實例的insert鉤子，insert鉤子中調用了activateChildComponent函數，遞歸執行子組件中的activated鉤子函數

pageList → pageDetail → pageList，pageList保存原有狀態；pageList → 其他 → pageList，猜跡虛pageList初始化狀態

pageList → pageDetail → pageList，pageList保存原有狀態；pageList → 其他 → pageList，pageList初始化狀態

問題：方法二中，pageList → pageDetail → 其他 → pageList，pageList採用了緩存的數據， 解決：其他頁面中的beforeRouteLeave增加 this.$store.dispatch('setCacheList', '穗燃')

E. Vue—KeepAlive源碼探究，適時清理頁面緩存

使用過 Vue 的小夥伴們肯定都知道，Vue 的內部組件 keep-alive 是用來緩存我們不活動的組件的。

但是在某些情況下，我們需要緩存，某些情況下希望及時釋放掉緩存，那我們應該怎麼做呢？

有個場景是，希望模仿App的方式，每次push到當前碧敬頁面的時候，觸發 mounted 進行組件初始化，而從其他頁面返回到當前頁面時，希望可以保留當前組件的狀態。

舉個例子：
移動端的分頁列表頁面，載入了幾頁，並且有滑動記錄，但是希望進詳情頁後，返回列表頁時，可以保持分頁的狀態以及滑動的軌跡。

需求如上，這就需要 keep-alive 幫助我們緩存組件了。

但是用過 keep-alive 組件的小夥伴肯定明白，如果 include 當前列表頁面，雖然可以做到返回列表頁保持狀態，但是從其他頁面前往列表頁時，依然會載入緩存的狀態，我們不得不採用 activated 鉤子方法來處理，但這樣總歸是不優雅的。

看過一些文字有人說讓include的數組變成動態的是否能達到類似的效果，這種方式也非常好，可以很容易的達到我們想要的效果。

閱讀過源碼之後發現， keep-alive 內部實現是將組件緩存在一個 caches 數仿胡組中的，如果我們可以操作這個數組，是否可以達到靈活控制緩存組件的效果呢？

方法一比較繁瑣，但是悔大慎用起來還是很直接的，比較靈活，可以應付瀏覽器刷新的場景

方法二比較簡單，適合在移動app中使用，自己維護頁面棧，不會有瀏覽器刷新等操作，否則include的內容可能會由於刷新而出現棧異常