He3DB中He3Proxy设计的方案02.docx
免费下载
He3DB
中
He3Proxy
的
3
种方案
-02
he3db
中
session
一致性执行逻辑
方 案 非 常 简 单 ， 核 心 点 在 于 如 何 获 取 每 个 节 点 最 新 的
LSN
呢 ？ 参 照
PolarDB[1]
的解法，可以有两种方式：
（
1
）查询通道返回，即每次查询操作结果中返回
LSN
信息；
（
2
）节点定期上报最新的
LSN
点位；
当然也有其他方式获取比如建立长链接通道、消息中间件、服务发现机制
等，考虑架构复杂性、性能损耗、实际收益等因素个人认为
PolarDB
的
处理方式比较得当；
LSN
数据不需要落地，维护在
session
内存即可，链
接断开后数据随之销毁。
看到这里你可能会问 并发大的情况下岂不是主库压力会非常大？
传统数据库中从机回放速度相对较慢，大并发下因从机未完成回放，请求
只能落到主节点，确实会造成主节点压力过大，需要结合实际业务去权衡
方案。
在云原生数据库
He3DB
架构下，得益于数据的物理复制，速度极快，可
能在主节点数据返回时，数据复制已经开始，也就是说下次查询请求到来
时，极可能读节点已经可以提供最新数据的查询，所以在这种架构体系下，
主节点压力并不会太大，读节点可以分摊查询请求。
进一步细化，我们可以将
LSN
信息的维护细化到表粒度，这样可以提高负
载的精确性，比如更新
t2
返回的
LSN
为
88
，紧接着查询的是
t1
数据，
它的最大
LSN
才到
77
，因此可以选择
LSN >= 77
的节点进行负载，而
不是
>=88
。
He3Proxy
中我们 选 择 复用
PG
的系 统 表
pg_stat_replication
的数
据维护
LSN
和节点的关系，连接建立时先查询
pg_stat_replication
中
的数据，维护基础的
node
与
LSN
关系，并通过后续连接查询结果中携带
的
LSN
信息更新关系。接着讨论下如何在返回结果中携带
LSN
信息呢？
LSN
维护方式
of 8
免费下载
【版权声明】本文为墨天轮用户原创内容，转载时必须标注文档的来源（墨天轮），文档链接，文档作者等基本信息，否则作者和墨天轮有权追究责任。如果您发现墨天轮中有涉嫌抄袭或者侵权的内容，欢迎发送邮件至：contact@modb.pro进行举报，并提供相关证据，一经查实，墨天轮将立刻删除相关内容。
下载排行榜
评论