SequoiaDBセッション（セッション）の紹介
セッション（セッション）の基本的な考え方
二つの概念は、セッション接続と混乱するのは簡単です。
人気の用語は、セッション（セッション）通信するための通信開始から通信相手の終了時文脈（コンテキスト）です。このコンテキストでは、サーバー側のメモリの一部です：どのアプリケーション、ユーザがログインすると、他の情報によって、この接続でクライアントマシンを記録します。
接続されている（接続）：エンド接続は、クライアント・データベース・インスタンスから物理パスです。ネットワーク接続が確立され、またはIPC機構を介して機械に設定することができます。通常、専用のサーバまたはクライアント・プロセスとディスパッチャの間の接続を確立します。
セッションに設計SequoiaDB
セッションでSequoiaDB異なるサービスに対応したさまざまなセッションがあります。主なタスクは、通信プロセスを介して送信されるセッション要求を終了することです。セッション要求の様々な種類が異なるように処理することができます。
通信面
異なるタイプのサービスを提供するため、及びサービスの分離との間のノードに、SequoiaDBは、通信面の複数を提供します。手短に言えば、一方の通信プレーンは、異なるポートがSequoiaDBに設置されている異なるタイプのサービスを提供し、サービスポートに対応する、理由のポート番号は、予約の範囲を必要とします。
：SequoiaDBは現在、次のいくつかの通信プレーン提供
•ローカル平面（ローカルサービス）ベースのサービスポート番号SVCNAME使用
。ポート番号1つの+ SVCNAME：REPL面•（REPLサービス）
•シャード平面（シャードサービス）：ポート番号SVCNAME + 2
•CAT面（CATサービス）：ポート番号SVCNAMEの+ 3
•REST面（RESTサービス）：ポート番号SVCNAMEの+ 4。
•OM平面（OMサービス）：SVCNAME 5が使用するポート番号は、+
異なるノードに開かこのサービスは、同一平面ではありません。家の中の何かが、それは皆で共有されているかのように、いくつかのドアを開いて同じ部屋のように、平面異なるサービスに異なるノードが提供する、データがアクセスされます。各プレーンにアクセスするために1人の以上のユーザーを有していてもよく、したがって、システム内でそれらの同時実行制御を行うこと。
ローカルセッション（ローカルセッション）
ローカルセッションが作成されたときに直接接続されたノード（SVCNAMEすなわち設定）。ここではダイレクトコネクト比較的広い意味、単独で使用するかどうかを直接、接続されているローカルサービスポート、またはクラスタ内の任意のノードに接続された任意のノードがあります。クライアントは、ローカル・ノード上でセッションを調整するコーディネーター・ノードに接続すると作成されます。モニターがローカルポートに新しい接続要求を受信すると、（メモリ構造）を新しいセッションを作成し、サービススレッド（実行単位）、それら（添付）をアップバインドします。フォローアップクライアントが直接、この新しいサービススレッドと対話します。
コードガイド
- 図以下継承セッションSequoiaDBの様々なタイプ。
それが図、ローカルセッション、同期セッション、セッション複製の増加/総量からわかるように、同じ基本クラス_ISessionから継承されています。キーセッションのいくつかのネットワークが導入されているの下には、主にセッション確立/時間、セッション、および操作の構造を破壊します。
-
セッションを終了しようとするまで、データ構造に対応するローカルセッションがクラス_pmdLocalSessionであり、スレッドの主な機能は、_pmdLocalSession ::ラン（）はこの関数の内部で循環させるように、会話スレッドの後に開始し、メッセージが受信され、処理は、ループを抜けます。
- ローカルセッションは、異なるプロセスを実行するために、異なるプロセッサをバインドすることができます。コーディネータ・ノードは、バインディングは_pmdCoordProcessorであり、ノードとデータノードのカタログのため、結合が_pmdDataProcessorあります。それは、要求のタイプを識別できない場合、コーディネータ・ノードは最初、メッセージ処理のため_pmdCoordProcessorインタフェースを呼び出すためには、処理のために再び_pmdDataProcessorインタフェースと呼ぶことにします。
分区会话(Shard Session)
分区会话存在于编目节点与数据节点上，因为是在这两种节点上真正分布式存储数据，真正与分片这个概念相关。协调节点上不存储数据，不 涉及到分片，因此它上面没有分片会话。在代码实现上，分片会话的管理整合到了 clsCB 中(它还管理着复制会话)。
当通过 shard 平面连接到节点时，在节点上就会创建一个分区会话。 shard 平面与本地平面存在一些差异:
shard 平面看不到节点上的系统集合空间，本地平面可以
通过 shard 平面进行的操作会写复制日志，通过本地平面的不会(这也就是为什么直连数据节点下进行数据操作会造成主备数据不一致 的原因，如果是通过 shard 平面连接数据节点操作，则数据变更会被同步到备节点上)
分区会话是继承自统一的异步会话框架，包含一个分区会话管理器，由它来负责分区会话的创建等工作。会话的主要工作则是在被创建后，处 理客户的请求。关于异步会话的机制，详见相关的介绍。
当协调节点通过 shard 平面连接到数据节点时，新创建的会话接收到的第一个消息是 init session(在 3.0 后的版本中是 package 消息，它将 init session 及部分其它消息打包到一个消息包中)。
代码导读
- 分区会话管理器类是 _clsShardSessionMgr，分区会话类是 _clsShdSession
- 通过异步会话管理器( _clsShardSessionMgr 的父类) 的 getSession() 接口来获取已有 session，或者创建一个新的异步会话
- _clsShdSession 的主消息处理入口是 _clsShdSession::_onOPMsg，它根据消息码，调用对应的消息处理函数，并发送应答消息
同步(或复制)会话(Repl Session)
分区组内的节点间，通过同步动作来保证数据的一致性，分为正常运行状态下的增量同步，和异常情况下的全量同步。同步也是通过对应的同 步会话与同步线程来处理的。由于同步涉及到两个节点，数据生产方称为源端，数据消费方称为目标端。由于只有数据节点与编目节点上会进 行数据复制，因此只有在这两种类型的节点上，才会存在同步会话。
1）增量同步会话
增量同步会话在复制组正常运行期间存在，分为增量同步源端会话和目标端会话。在数据/编目节点的启动过程中，就会开启增量同步的监听， 而无论其是主节点还是从节点。同时，它也会主动启动一个增量复制目标端会话，并向它选定的源端发送同步请求。源端节点上会被动创建一 个增量同步源端会话。然后，这两个会话开始进行交互，完成数据同步。详见 增量同步 相关章节。
2）全量同步会话
全量同步会话是进行全量同步时存在，在集群正常运行期间及全量同步完成后不存在，也分为源端和目标端。需要全量同步的场景有三种:
• 节点的重放速度跟不上主节点，主节点上复制日志绕接，导致备节点还未获取到的复制日志被覆盖，备节点无法继续增量同步。
• 节点异常重启，启动后根据读取到的异常启动状态决定全量同步。
• 节点正常停止后正常重启，但停的时间较长，期间其它节点上的日志已经发生了绕接。
无论是上述哪种情况，都是先有增量复制会话，然后由于这些原因导致增量同步无法继续进行的时候，就会在目标节点上主动创建一个全量同 步会话(以及对应的线程)，且当前的增量复制线程退出。全量同步会话一旦启动之后，就会向源端发送一个全量同步开始的消息。此时源端 上会被动创建一个全量同步源端会话。至此，全量同步的会话创建完成，然后，这两个会话之间开始进行交互，完成数据同步。详见 全量同步 相关章节。
代码导读
- 同步相关的会话，都是异步会话，这四种会话，使用同一个会话管理器来进行管理:_clsReplSessionMgr
- 四种会话对应的类为:_clsReplSrcSession，_clsReplDstSession，_clsF***cSession，_clsFSDstSession
- 异步会话响应的消息类型及对应的处理函数，一般在对应的类中通过 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/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