前面針對server啟動到選舉leader進行了壹個小結，現在進入leader和follower的啟動交互過程，需要先講ZooKeeperServer，
在之前源碼閱讀的25節裏面帶過了壹部分，這裏詳細講解ZooKeeperServer的源碼
繼承關系如下
本節主要講解內容如下
在源碼閱讀第24節講解了，這裏不贅述
是SessionTracker的內部接口
如下圖
除去log，jmx相關部分，源碼如下
ChangeRecord是ZooKeeperServer的內部類，下面會介紹
ServerStats,ZooKeeperServerListener都在25節的源碼介紹過
這個類並沒有調用，不用管
定義異常
這個數據結構為了促進PrepRequestProcessor以及FinalRequestProcessor的信息***享,講到調用鏈的時候再講。
其中，StatPersisted在源碼閱讀7中講DataNode的時候講過了
描述當前server所處的狀態
這裏列舉處兩個底層調用的構造函數
啟動涉及到db的數據加載，這裏也有集群和單機兩種，調用順序為
主要是集群的時候，server選完了leader，由leader才能調用數據加載loadData
下面按照單機版startdata函數展開
初始化zkDb完成數據加載
恢復session和數據，單機版啟動或者集群版leader選舉之後調用lead方法時，會調用該方法。
主要完成設置zxid以及把無效的session給kill掉的工作
這裏註意，為什麽需要幹這件事情，在下面思考中會說
裏面調用了setZxid(不展開)以及killSession函數
清除db中臨時會話記錄，會話跟蹤器也清除記錄
入口是ZooKeeperServer#startup，zkServer都是在上述加載了db的數據之後，調用startup來完成啟動
啟動的入口函數
調用了createSessionTracker等函數，介紹如下
createSessionTracker 完成會話跟蹤器的創建
這裏是默認的單機版實現，在集群版不同的角色有不同的實現,主要是參數sid不會傳1，而是配置中的sid
startSessionTracker 啟動會話跟蹤器
設置服務器運行狀態，對於ERROR和SHUTDOWN的state，進行對應的操作
在 源碼閱讀25:服務器異常報警，關閉機制 講過，這裏不贅述
安裝請求處理鏈路,是PrepRequestProcessor -> SyncRequestProcessor -> FinalRequestProcessor順序
具體在後面請求處理鏈路再講
兩個函數getServerId和expire
processConnectRequest用於處理client的連接請求，不展開
值得註意的地方是重連的調用
展開如下
重連的核心函數
驗證sessionId和傳遞來的密碼的正確性
根據sessionId生成密碼
在會話跟蹤器SessionTracker中判斷會話是否還有小
完成會話初始化，根據參數valid代表認證通過與否，用來判斷server是接收連接請求，還是發出closeConn的請求,不展開，重要部分如下
除去的get,set,jmx,shutdown相關函數，剩下重要函數如下
部分函數列舉如下
獲取下壹個server的zxid,調用方需要確保控制並發順序
上面ZooKeeperServer#expire調用了close函數，介紹如下
該函數用於提交壹個 關閉某個sessionId 的請求
這裏有兩個函數
之前在源碼21節 會話管理中講解了會話清除，在sessionTracker的記錄是馬上清除的，而DateTree中臨時會話的清除是通過調用鏈壹步步來的，也就是說兩個步驟不是同步的，所以如果中間服務器狀態改變了，會出現不壹致的情況
requestsInProcess代表正在處理的請求個數
就是說發出請求時，requestsInProcess+1，最後完成請求時，requestsInProcess-1.涉及到請求處理鏈。
ZooKeeperServer#checkPasswd調用
ZooKeeperServer#generatePasswd
就是sessionId要和sessionId^superSecret生成的第壹個隨機數相匹配即可
密碼不是client端設置的，是根據sessionId生成的
ZooKeeperServer#processConnectRequest 裏面調用reopenSession中
在上面已經講了,核心就是
這裏還沒有深入看，先存疑
比如思考中提到的loadData為什麽會出現數據不壹致，屬於某種異常情況的處理
為什麽不放到另外壹個類裏面去