巨杉內核筆記（一）| SequoiaDB 會話（session）簡介

SequoiaDB 會話（session）簡介

會話（Session）的基本概念
容易弄混淆的兩個概念是會話與鏈接。
通俗來說，會話(Session) 是通訊雙方從開始通訊到通訊結束期間的一個上下文(Context)。這個上下 文是一段位於服務器端的內存:記錄了本次鏈接的客戶端機器、經過哪一個應用程序、哪一個用戶登陸等信息。
而鏈接(Connection):鏈接是從客戶端到數據庫實例的一條物理路徑。鏈接能夠在網絡上創建，或者在本機經過IPC機制創建。一般會在客戶 端進程與一個專用服務器或一個調度器之間創建鏈接。

SequoiaDB 中的會話設計
SequoiaDB 中的會話有不少種，不一樣的會話對應不一樣的服務。會話的主要任務是處理通訊的對端發過來的請求。各類類型的會話能處理的請求不同。

通訊平面
爲了提供不一樣類型的服務，並使各服務之間隔離，SequoiaDB 的節點提供了多個通訊平面。簡單來說，一個通訊平面對應一個服務端口，不一樣 的端口提供不一樣類型的服務，這也就是在安裝 SequoiaDB 時，要求必定範圍內的端口號預留的緣由。
SequoiaDB 中當前提供了以下幾個通訊平面:
• local 平面(local service): 使用基礎服務端口號 svcname
• repl 平面(repl service):使用端口號 svcname + 1
• shard 平面(shard service):使用端口號 svcname + 2
• cat 平面(cat service):使用端口號 svcname + 3

• rest 平面(rest service):使用端口號 svcname + 4
• om 平面(om service):使用端口號 svcname + 5
不一樣的節點上開啓的服務平面不同。節點上經過不一樣平面提供不一樣的服務，就像同一間屋子開了幾個門，被訪問的數據就如同屋子裏面的東 西，是你們所共享的。每個平面均可能有一個或多個用戶來進行訪問，所以，在系統內部要作好它們的併發控制。

本地會話(Local Session)
本地會話是在直連節點(即配置的 svcname)時建立。這裏的直連含義比較寬泛，鏈接任意節點的本地服務端口便是直連，不管是單機，仍是 集羣中的任意節點。客戶端鏈接到協調節點時，協調節點上也是建立的本地會話。 本地端口上的監聽接收到新的鏈接請求時，會建立一個新的 會話(內存結構)及一個服務線程(執行單元)，將它們綁定(attach)起來。後續客戶端直接與這個新的服務線程進行交互。

代碼導讀

1. SequoiaDB 中各種型的會話繼承關係以下圖所示。

從圖中能夠看到，本地會話、增量/全量同步會話、複製會話等，都是繼承自同一個基類 _ISession。下面結合組網對其中幾個關鍵的會話進行介紹，主要是會話創建/銷燬的時機、會話的結構、操做等。

1. 本地會話對應數據結構是類 _pmdLocalSession，線程的主函數是 _pmdLocalSession::run()，會話線程啓動後，就在這個函數裏循環， 
接收及處理消息，直到會話須要結束時退出該循環。 

2. 本地會話能綁定不一樣的 processor，以執行不一樣的處理流程。對於協調節點，綁定的是 _pmdCoordProcessor，對於編目節點和數據節點，綁定的是 _pmdDataProcessor。對於協調節點，會先調用 _pmdCoordProcessor 的接口進行消息處理，在沒法識別請求類型時，則會再次調用 _pmdDataProcessor 的接口進行處理。 


分區會話(Shard Session)
分區會話存在於編目節點與數據節點上，由於是在這兩種節點上真正分佈式存儲數據，真正與分片這個概念相關。協調節點上不存儲數據，不 涉及到分片，所以它上面沒有分片會話。在代碼實現上，分片會話的管理整合到了 clsCB 中(它還管理着複製會話)。
當經過 shard 平面鏈接到節點時，在節點上就會建立一個分區會話。 shard 平面與本地平面存在一些差別:
shard 平面看不到節點上的系統集合空間，本地平面能夠
經過 shard 平面進行的操做會寫複製日誌，經過本地平面的不會(這也就是爲何直連數據節點下進行數據操做會形成主備數據不一致 的緣由，若是是經過 shard 平面鏈接數據節點操做，則數據變動會被同步到備節點上)
分區會話是繼承自統一的異步會話框架，包含一個分區會話管理器，由它來負責分區會話的建立等工做。會話的主要工做則是在被建立後，處 理客戶的請求。關於異步會話的機制，詳見相關的介紹。
當協調節點經過 shard 平面鏈接到數據節點時，新建立的會話接收到的第一個消息是 init session(在 3.0 後的版本中是 package 消息，它將 init session 及部分其它消息打包到一個消息包中)。

代碼導讀

1. 分區會話管理器類是 _clsShardSessionMgr，分區會話類是 _clsShdSession

2. 經過異步會話管理器( _clsShardSessionMgr 的父類) 的 getSession() 接口來獲取已有 session，或者建立一個新的異步會話

3. _clsShdSession 的主消息處理入口是 _clsShdSession::_onOPMsg，它根據消息碼，調用對應的消息處理函數，併發送應答消息

同步(或複製)會話(Repl Session)
分區組內的節點間，經過同步動做來保證數據的一致性，分爲正常運行狀態下的增量同步，和異常狀況下的全量同步。同步也是經過對應的同 步會話與同步線程來處理的。因爲同步涉及到兩個節點，數據生產方稱爲源端，數據消費方稱爲目標端。因爲只有數據節點與編目節點上會進 行數據複製，所以只有在這兩種類型的節點上，纔會存在同步會話。
1）增量同步會話
增量同步會話在複製組正常運行期間存在，分爲增量同步源端會話和目標端會話。在數據/編目節點的啓動過程當中，就會開啓增量同步的監聽， 而不管其是主節點仍是從節點。同時，它也會主動啓動一個增量複製目標端會話，並向它選定的源端發送同步請求。源端節點上會被動建立一 個增量同步源端會話。而後，這兩個會話開始進行交互，完成數據同步。詳見 增量同步 相關章節。

2）全量同步會話
全量同步會話是進行全量同步時存在，在集羣正常運行期間及全量同步完成後不存在，也分爲源端和目標端。須要全量同步的場景有三種:
• 節點的重放速度跟不上主節點，主節點上覆制日誌繞接，致使備節點還未獲取到的複製日誌被覆蓋，備節點沒法繼續增量同步。
• 節點異常重啓，啓動後根據讀取到的異常啓動狀態決定全量同步。

• 節點正常中止後正常重啓，但停的時間較長，期間其它節點上的日誌已經發生了繞接。
不管是上述哪一種狀況，都是先有增量複製會話，而後因爲這些緣由致使增量同步沒法繼續進行的時候，就會在目標節點上主動建立一個全量同 步會話(以及對應的線程)，且當前的增量複製線程退出。全量同步會話一旦啓動以後，就會向源端發送一個全量同步開始的消息。此時源端 上會被動建立一個全量同步源端會話。至此，全量同步的會話建立完成，而後，這兩個會話之間開始進行交互，完成數據同步。詳見 全量同步 相關章節。

代碼導讀

1. 同步相關的會話，都是異步會話，這四種會話，使用同一個會話管理器來進行管理:_clsReplSessionMgr

2. 四種會話對應的類爲:_clsReplSrcSession，_clsReplDstSession，_clsFSSrcSession，_clsFSDstSession

3. 異步會話響應的消息類型及對應的處理函數，通常在對應的類中經過 OBJ_MSG_MAP 等宏進行定義，請參考代碼。

會話的查看
可經過 snapshot 查看會話快照，可查看當前會話或系統中的全部會話。這個命令實現的實際上是與線程對應，可返回全部線程的信息，包括系 統後臺線程。查詢會話的詳細結果見相關文檔。
代碼導讀
session 的導出動做在類 _monSessionFetcher 類中實現，在其 init() 函數中準備好數據。可選擇查看當前會話(使用當前線程的 eduCB 接口 導出)或全部會話(使用 _pmdEDUMgr 的接口導出)。 在準備好數據後，由上層統一的 context 框架調用該類的 fetch 接口獲取數據。

SequoiaDB簡介：
SequoiaDB 巨杉數據庫是一款金融級分佈式關係型數據庫， 其自研的原生分佈式存儲引擎支持完整 ACID，具有彈性擴展、高併發和高可用特性，支持 MySQL、PostgreSQL 和 SparkSQL 等多種 SQL 訪問形式，適用於核心交易、數據中臺、內容管理等應用場景。

標準SQL支持，MySQL協議級兼容
SequoiaDB目前支持 MySQL、PostgreSQL 和 SparkSQL 等多種 SQL 訪問形式。SequoiaDB還提供了類S3對象訪問以及Posix文件系統接口、MongoDB兼容的原生JSON引擎以及深度數據壓縮等多項全新功能。

金融級分佈式OLTP
SequoiaDB使用其自研的開源數據庫存儲引擎，全面支持ACID（原子性、一致性、隔離性與持久性）、分佈式跨表跨節點事務能力、可配置強一致與最終一致性保證、同時在優化器端支持CBO（Cost-Based Optimization）、多維度數據分區、以及HTAP等多種技術特性。

分佈式架構
SequoiaDB數據存儲引擎採用原生分佈式架構，數據徹底打散在分佈式節點間存儲，自動化數據分佈和管理，數據能夠按需靈活擴展，目前生產環境實測支持超過1000個節點集羣。

Multi-Model多模數據引擎
SequoiaDB靈活的數據存儲類型，支持非結構化、結構化和半結構化數據全覆蓋，實現多模（Multi-Model）數據統一管理，更符合雲化數據架構下對於多樣化業務數據的統一管理和運維要求。

HTAP混合事務/分析處理
SequoiaDB經過SQL的徹底支持以及Spark的整合，實現HTAP混合事務和分析處理，快速實現業務應用的彈性開發，應對更多複雜應用場景。同時，經過分佈式數據庫多副本機制，將在線交易和離線分析業務物理隔離，實現同一組數據在應對不一樣類型業務時互不干擾。

數據安全與多活容災
SequoiaDB巨杉數據庫原生支持數據庫內核級別的高可用以及跨數據中心災備能力，目前已經實現異地容災備份，可知足「三地五中心」的容災支持。同時，巨杉數據庫在異地容災基礎上，實現了數據異地多活，目前已經實現雙中心同時讀寫，中心切換RPO爲0和RTO達到秒級，提供了「超金融級」的數據安全保障。

擴展閱讀
會話快照
http://doc.sequoiadb.com/cn/i...

當前會話快照
http://doc.sequoiadb.com/cn/i...

會話列表
http://doc.sequoiadb.com/cn/i...