使用JDBC进行openGauss的读写分离及负载均衡
读写分离
读写分离是什么
读写分离顾名思义,就是将读操作和写操作分离开来,形成一种主备的结构,主机负责写操作,从机负责读操作。openGauss数据库组装成集群并使用JDBC连接时,支持一主多备情况下的读写分离,当URL中配置服务器地址时,可以通过URL中的属性标示来区分JDBC返回的连接是否是区分主机和备机。
优越特性
自动寻主
读写分离一定程度上依赖主机的识别,这里会介绍openGauss数据库的自动寻主机制。openGauss数据库应用场景下,典型配置为一主两备。当主机宕机后,备机会升主,这时和旧主机相连的连接都会失效,所以为了能够让业务以最快的速度恢复使用,我们在驱动层设计一种“自动寻主”的机制,该机制可以找到主备切换后的主机,并且整个寻主过程对于上层应用来说是透明的,上层应用的开发人员不需要自动寻主的具体细节,只需做上一定适配即可实现业务的高可用。
性能提升
对比PostgreSQL 的读写分离,PostgreSQL 在数据库资源占用超过85%时,查询数据库情况语句会出现失效,针对这一问题我们做了优化。
查询语句修改为
select local_role, db_state from pg_stat_get_stream_replications();
有效的避免了PostgreSQL 在读写分离方面出现的问题。
相关参数
hostRecheckSeconds参数,Integer类型,因为JDBC尝试连接主机后会保存主机状态:连接成功或连接失败,所以这个参数就是用于设置在主机状态发生更改时再次检查主机状态的时间段,默认的时间是10秒。
运作流程
读写分离流程
第一步,设置参数开启targetServerType=master。
第二步,判断输入的主机列表是否已经加入了候选主机列表中,如果不存在hostStatusMap中并且更新时间间隔超过10s同时HostStatus状态也和现在一致,这时直接加入候选主机列表。
第三步,对列表进行遍历查找对应的节点信息,如果找到了,通过konwnStatus查看状态是否一致,一致就执行sql查询语句,之后更新全局变量hostStatusMap及局部变量konwnStatus中存储。
第四步,当前操作的节点状态如果与用户选择的节点状态一致则返回主机连接,之后用户可以根据连接进行读或者写操作。
负载均衡
jdbc负载均衡是什么
jdbc负载均衡简单来说就是将所有的连接均衡的分摊到多个数据库上面,借此达到减轻单个数据库的数据处理压力从而提高整体的性能的一种方式。但是要注意一点,openGauss的负载均衡是能进行读操作使用,所以在只读时开启时是没有问题的,但如果有写操作的话,因为负载均衡不会考虑主备的区别,所以会让从机进行读操作,这时会报错。
独有特性
传统的负载均衡
jdbc负载均衡
负载均衡是现在很常用的均衡每个服务器性能的处理手段,像我们常见的Nginx的负载均衡,很少会有人在驱动上面直接进行负载均衡。从实际的效果的来看,在开启负载均衡后整体的性能并没有下降,但是因为连接打到了多个不同的数据库上面,整体的处理效率得到了显著的提升。虽然看上去和传统的负载均衡达到的效果差不多,但是对比传统的通过额外的一台机器做负载均衡比起来,我们有着独特的优势。首先我可以通过配置参数开启负载均衡并设置 我们想要的主机列表,这一点上面操作就会比较简单。其次节约了成本,不在需要另外一个机器专门进行负载均衡。并且还具备故障隔离,当某个数据库故障后,负载均衡可以感知到故障,并自动停止向故障数据库节点转发请求。
负载均衡的参数设置
loadBalanceHosts:在默认模式下(禁用),顺序连接URL中指定的多个数据库。如果启用,则使用洗牌算法从候选主机列表中随机选择一个主机建立连接。
洗牌算法(Shuffle)
这里使用了collections类中自带的shuffle方法来实现随机的建立连接,名称叫做洗牌算法,所以它就和洗牌一样会把原有的数据库列表顺序打乱,就像洗牌一样。方法的实现大概就是从前往后遍历列表重复的随机选择一个元素交换到当前遍历到的位置。等遍历一遍结束后,我们就会得到一个乱序的数据库列表。
优点:调用现有的Java接口,实现简单并且效果显著。
运作流程
负载均衡流程
第一步,设置参数,在url后面拼接loadBalanceHosts参数,其为true时会开启负载均衡,默认是不开启的。
第二步,JDBC连接数据库,通过解析url获取可连接的数据库列表
第三步,根据洗牌算法获得的数据库列表来,用来调整接下来要连接的数据库。
欢迎访问openGauss官方网站
openGauss开源社区官方网站:
https://opengauss.org
openGauss组织仓库:
https://gitee.com/opengauss
openGauss镜像仓库:
https://github.com/opengauss-mirror
扫码关注我们
微信公众号|openGauss
微信社群小助手|openGauss-bot
本文分享自微信公众号 - openGauss(openGauss)。
如有侵权,请联系 support@oschina.cn 删除。
本文参与“OSC源创计划”,欢迎正在阅读的你也加入,一起分享。

低调大师中文资讯倾力打造互联网数据资讯、行业资源、电子商务、移动互联网、网络营销平台。
持续更新报道IT业界、互联网、市场资讯、驱动更新,是最及时权威的产业资讯及硬件资讯报道平台。
转载内容版权归作者及来源网站所有,本站原创内容转载请注明来源。
- 上一篇
大规模 K8s 集群管理经验分享 · 中篇
🔥【高手问答第 271 期 -- 聊聊大规模 K8s 集群管理】之经验分享·上篇获得了同学们的广泛关注,在技术同学的努力下,经验分享·中篇也来和大家见面啦!一起来看看吧~ Q1:如何合理优化每一个容器的大小和资源利用,提高性价比? A1:监控,监控,还是监控,不断去审视容器的资源分配量跟实际使用量,看看配置的是否合理。 Q2:用 kubeadm 装集群会给后期运维增加困难吗?我记得前两年官方不建议在生产环境用 kubeadm 装,但是现在文档中已经写了生产也可以用 kubeadm,这能不能理解成已经成熟了? A2:我们在最开始做 K8s 的时候也是“kubeadm 不建议”的年代,因为我们是自己写了一套部署工具,这个工具后面也会开源出来,可以关注一下 Erda 项目, 开源后我们会把代码放进去。 题外话,不管使用什么工具,可能都需要对工具具体做了什么有一个比较深入的了解,这样后面遇到问题也就有思路去解决了👌。 Erda 开源地址: https://github.com/erda-project/erda Q3:如何看待中间件比如 mysql / redis / mq / kafka...
- 下一篇
7张图揭晓RocketMQ存储设计的精髓
RocketMQ作为一款基于磁盘存储的中间件,具有无限积压能力,并提供高吞吐、低延迟的服务能力,其最核心的部分必然是它优雅的存储设计。 温馨提示:本文节选自新上市《RocketMQ技术内幕》第二版本,一个最大的改变就是在进入源码分析之前,首先通过图文的方式,提炼出RocketMQ的核心工作机制,降低源码阅读的难度,引发思考。 1、存储概述 RocketMQ存储的文件主要包括Commitlog文件、ConsumeQueue文件、Index文件。 RocketMQ将所有主题的消息存储在同一个文件中,确保消息发送时按顺序写文件,尽最大能力确保消息发送的高可用性与高吞吐量。 但消息中间件一般都是基于主题的订阅与发布模式,消息消费时必须按照主题进行筛选消息,显然从Commitlog文件中按照topic去筛选消息会变得及其低效,为了提高根据主题检索消息的效率,RocketMQ引入了ConsumeQueue文件,俗称消费队列文件。 关系型数据库可以按照字段属性进行记录检索,作为一款主要面向业务开发的消息中间件,RocketMQ也提供了基于消息属性的检索能力,底层的核心设计理念是为Commitlog文...
相关文章
文章评论
共有0条评论来说两句吧...