SequoiaDB 会话(session)简介数据库
会话(Session)的基本概念 安全
容易弄混淆的两个概念是会话与链接。 服务器
通俗来说,会话(Session) 是通讯双方从开始通讯到通讯结束期间的一个上下文(Context)。这个上下 文是一段位于服务器端的内存:记录了本次链接的客户端机器、经过哪一个应用程序、哪一个用户登陆等信息。网络
而链接(Connection):链接是从客户端到数据库实例的一条物理路径。链接能够在网络上创建,或者在本机经过IPC机制创建。一般会在客户 端进程与一个专用服务器或一个调度器之间创建链接。 session
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引擎以及深度数据压缩等多项全新功能。
SequoiaDB使用其自研的开源数据库存储引擎,全面支持ACID(原子性、一致性、隔离性与持久性)、分布式跨表跨节点事务能力、可配置强一致与最终一致性保证、同时在优化器端支持CBO(Cost-Based Optimization)、多维度数据分区、以及HTAP等多种技术特性。
SequoiaDB数据存储引擎采用原生分布式架构,数据彻底打散在分布式节点间存储,自动化数据分布和管理,数据能够按需灵活扩展,目前生产环境实测支持超过1000个节点集群。
Multi-Model多模数据引擎
SequoiaDB灵活的数据存储类型,支持非结构化、结构化和半结构化数据全覆盖,实现多模(Multi-Model)数据统一管理,更符合云化数据架构下对于多样化业务数据的统一管理和运维要求。
SequoiaDB经过SQL的彻底支持以及Spark的整合,实现HTAP混合事务和分析处理,快速实现业务应用的弹性开发,应对更多复杂应用场景。同时,经过分布式数据库多副本机制,将在线交易和离线分析业务物理隔离,实现同一组数据在应对不一样类型业务时互不干扰。
SequoiaDB巨杉数据库原生支持数据库内核级别的高可用以及跨数据中心灾备能力,目前已经实现异地容灾备份,可知足“三地五中心”的容灾支持。同时,巨杉数据库在异地容灾基础上,实现了数据异地多活,目前已经实现双中心同时读写,中心切换RPO为0和RTO达到秒级,提供了“超金融级”的数据安全保障。
扩展阅读
会话快照
doc.sequoiadb.com/cn/index-ca…
当前会话快照
doc.sequoiadb.com/cn/index-ca…
会话列表