背景
1、产品的问题点
- PostgreSQL 读写分离非常不友好, 没有内置的对业务完全透明的读写分离功能.
2、问题点背后涉及的技术原理
- 为什么要读写分离?
- 读请求占比较高, 并且单个实例无法支撑业务的请求吞吐时, 通过增加只读实例, 将读请求分流到只读实例以满足业务需求.
- 什么是业务透明的读写分离?
- 应用发起SQL, 数据库根据SQL是否会对数据库产生写操作自动分发到主库或只读库.
3、这个问题将影响哪些行业以及业务场景
- 读占比和吞吐较大的业务
- 读请求相对来说比较复杂, 需要耗费较大IO和CPU计算, 怕影响主实例(RW实例)的业务
4、会导致什么问题?
- 没有读写分离功能, 业务必须连接多个数据源, 在代码中自己判断, 将读、写请求发送到不同的数据源. 增加了程序设计复杂度.
- 而且只读和读写节点可能发生角色切换, 代码里面不仅要判断SQL是否要路由到RO, 还要判断当前数据源到底是RO还是RW角色.
5、业务上应该如何避免这个坑
- 使用 pgpool-II 中间件
6、业务上避免这个坑牺牲了什么, 会引入什么新的问题
- 通过pgpool-II连接数据库, 性能存在巨大的损耗
- 多一跳延迟增加、
- pgpool-II自身的损耗
- 高并发小事务损耗50%以上 (tpc-b测试样例)
- 功能不完备, 例如:
- 函数内的query不能再路由
- 自定义函数需要配置黑白名单, 否则统一路由到rw节点. (函数白名单、黑名单需要手工维护)
- 增加了1个组件增加了1份故障点
- 增加了配置复杂度, 例如
- 心跳检测配置
- 从库与主库延迟多少后自动踢出只读实例列表
- 恢复后是否自动加入只读实例列表
- 连接池个数, 空闲自动释放时间, 生命周期等
7、数据库未来产品迭代如何修复这个坑
- 希望内核层面支持对业务透明的自动读写分离
- 不管是rw还是ro节点, 平等对待所有连接. 应用可以使用驱动来load balance连接
- 从库与主库延迟自动踢出只读实例列表, 恢复后是否自动加入只读实例列表
- 解析SQL, 生成执行计划, 自动路由plan execute
- 根据SQL的代价来决定是否要将sql分发给只读实例. 用户可以设置代价阈值.
- 不依赖外部产品
