非正式全面解析 NebulaGraph 中 Session 管理
image
NebulaGraph 论坛最近有些讨论帖，各种姿势来问 NebulaGraph Session 管理相关的事情，我寻思这也不是一个法子，还是来写一篇文章来讲述下 NebulaGraph 中的 Session 管理。由于本文设定为非正式的 Session 讲解，所以本文主要分为理论和实操部分，在实操部分主要摘录了论坛用户的一些关于 Session 的理解，以及本人对 Session 相关问题的解答。
客户端交互流程
在之前的源码解读系列的客户端部分，我们讲过 Session 相关的知识点，这里来回顾下。
通过下图你能了解客户端和服务端连接时，背后的工作原理：
image
简单来说，整个 workflow 由 ConnectionPool、Session、Connection 构成，用户通过 Session 和计算引擎进行交互，但真正和计算引擎 graphd 发生数据处理关系的是连接池当中的 Connection。
Connection Pool
在连接池初始化阶段，用户使用 Session 之前需要先创建并初始化一个连接池 ConnectionPool，连接池会在初始化时会对用户指定的 NebulaGraph 服务所在地址建立连接 Connection。如果在用集群部署方式部署了多个 Graph 服务，连接池会采用轮询的策略来平衡负载，对每个地址建立近乎等量的连接。
连接池如何管理连接 Connection 呢？连接池内维护了两个队列，空闲连接队列 idleConnectionQueue 和使用中的连接队列 activeConnectionQueue，连接池会定期检测过期空闲的连接并将其关闭。这两个队列在增删元素的时候会通过读写锁来确保多线程执行的正确性。当 Session 向连接池请求连接时，会检查空闲连接队列中是否有可用的连接，如果有则直接返回给 Session 供用户使用；如果没有可用连接并且当前的总连接数没有超过配置中限定的最大连接数 maxConnSize，则新建一个连接给 Session；如果已经到达了最大连接数的限制，返回错误。
大概流程和下面流程图类似：
image
一般来说，只有在客户端程序退出时才需要关闭连接池，在关闭时池中所有的连接都会被断开。
Session
image
客户端会话 Session 通过连接池 ConnectionPool 生成，用户需要提供用户密码进行校验，在校验成功后用户会获得一个 Session 实例，并通过 Session 中的连接与服务端进行通信。最常用的接口是 execute()，如果在执行时发生错误，客户端会检查错误的类型。如果是网络原因或者和 session 通信的 graph 服务 down 掉，客户端会自动重连，尝试绑定一个可用的连接重发请求。
需要注意的是，一个 Session 不支持被多个线程同时使用，正确的方式是用多个线程申请多个 Session，每个线程使用一个 Session。Session 被释放时，其持有的连接会被放回到连接池的空闲连接队列 idleConnectionQueue中，以便于之后被其他 Session 复用。
Connection
连接 Connection 每个连接实例都是等价的，可以被任意 Session 持有。这样设计的目的是这些连接可以被不同的 Session 复用，减少反复开关 Transport 的开销。连接会将客户端的请求发送到服务端并将其结果返回给 Session。
社区用户实践
这里主要收录了用户在使用连接池、Session 遇到的比较有代表性的问题。
如何获取多个 Session
可通过 https://discuss.nebula-graph.com.cn/t/topic/3765 查看完整的交流对话。
Sharry2021gu 提问：连接池怎么会有多个 Session 呢？用来测试并发性能。像下面的 pipeline 里怎么才能获取不同的 session？
image
答：因为你给 Session 包了一层，你直接用 java-client 的 ConnectionPool 拿 Session 就可以了，ConnectionPool 是支持多线程调用 getSession 的接口。
对 Session 管理的理解
下面部分收录社区用户 wuyou 对 Session 管理的理解，你可以通过 https://discuss.nebula-graph.com.cn/t/topic/8777 了解全部内容。这块的内容同上面客户端交互流程有所重叠，不过都是需要注意的使用点。
-
NebulaPool 的
maxConnSize是最大连接数，一个 Session 只能使用一个连接，可以简单地认为 maxConnSize 就是这个 NebulaPool 里面支持的最大 Session 数量，适当调整就行了； -
NebulaPool 使用常规的单例就行，应用程序结束时记得关闭就行了。Session 的话可以在 graph 配置中设置
session_idle_timeout_secs让其自动销毁就行了； -
Session 的创建和销毁是有开销的，会有五次 IO 交互：Client 和 Graphd 会有 3 次 IO 交互以及 Graphd 和 Metad 有 2 次 IO 交互。
- Client 和 Graphd IO 交互：
- 第一次是检测连接是否是正常的；
- 第二次是做一次认证获取 sessionId；
- 第三次是 USE SPACE；
- Graphd 和 Metad IO 交互：
- 第一次是生成 sessionId；
- 第二次是获取 space 信息。
所以，一般情况下不建议每次请求都从 pool getSession，execute 之后再 release，这会有性能开销，而且还会在服务端生成很多只用一次的 Session。
- Client 和 Graphd IO 交互：
-
Session 是线程不安全的，多个线程使用同一 Session 会直接报错。应对多线程可以自己维护一份 Session 列表。如果是多个 space 的话，可以针对每个 space 维护一份 session 列表。这一点目前需要自己实现，暂时没有官方的好的方式。
自维护 Session
wuyou 提问：官方说需要自己维护 Session 是什么意思，感觉 NebulaPool 已经在维护了，应用层只需要每次直接 getSession 就完事儿了，每次执行完 nGQL 之后 session.release 释放掉 Session，让其回到 pool 中就可以。
答：这里解释下如何理解需要自己维护 Session。NebulaPool 维护的只是 Connection，Connection 是无状态的。Session 的维护是指多线程使用的情况下复用 Session 做多次查询，比如：Session 内部分 sessionInUse 和 idleSession队列，新建的 Session 放 idle 队列，用的时候起一个线程持有这个 Session 并且移到 inUse 队列，用完之后不用释放 Session 放回 idleSession 供下次使用。
Connection 的释放
wuyou 提问：放回连接池的 Connection 什么时候会被释放？
答：有两种方式来释放 Connection。第一种，手动关闭连接池时里面的连接会被释放。另外一种是，连接池里的对象池通过 setSoftMinEvictableIdleTimeMillis() 自动定期释放。
空闲会话超时设置
可通过 https://discuss.nebula-graph.com.cn/t/topic/9037 查看完整的交流对话。
Ian 提问：设置空闲会话超时时间为 8 小时，是以 SHOW SESSIONS 结果的 update_time 来加 8 小时吗？如果一直在用，就不会过期？
答：是 udpate_time + 8H。使用过程中 session 的 idle time 会更新，如果你一直在用会话就不会过期。
谢谢你读完本文 (///▽///)
要来近距离体验一把图数据库吗？现在可以用用 NebulaGraph Cloud 来搭建自己的图数据系统哟，快来节省大量的部署安装时间来搞定业务吧~ NebulaGraph 阿里云计算巢现 30 天免费使用中，点击链接来用用图数据库吧~
想看源码的小伙伴可以前往 GitHub 阅读、使用、(з)-☆ star 它 -> GitHub；和其他的 NebulaGraph 用户一起交流图数据库技术和应用技能，留下「你的名片」一起玩耍呢~
