巨杉核心筆記（一）| 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 。下面結合組網對其中幾個關鍵的會話進行介紹，主要是會話建立 / 銷燬的時機、會話的結構、操作等。

 

2.   本地會話對應資料結構是類 _pmdLocalSession ，執行緒的主函式是 _pmdLocalSession::run() ，會話執行緒啟動後，就在這個函式裡迴圈， 
 接收及處理訊息，直到會話需要結束時退出該迴圈。 


 

3. 本地會話能繫結不同的 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 為 和 RTO 達到秒級，提供了“超金融級”的資料安全保障。

 

擴充套件閱讀

會話快照

http://doc.sequoiadb.com/cn/index-cat_id-1479173713-edition_id-302

當前會話快照

http://doc.sequoiadb.com/cn/index-cat_id-1479173714-edition_id-302

會話列表

http://doc.sequoiadb.com/cn/index-cat_id-1479173733-edition_id-300

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/31534344/viewspace-2646547/，如需轉載，請註明出處，否則將追究法律責任。