电脑知识与技术

商用App服务端数据访问架构改造研究

作者:洪亮 来源:电脑知识与技术 202021期 时间:2020-09-13

摘要:商用App因为使用人数较多,对于服务端数据库访问有着较高的要求。如果数据访问架构不合理,当访问请求较多时,容易出现访问超时的情况。文中,主要就对商用App服务...

  摘要:商用App因为使用人数较多,对于服务端数据库访问有着较高的要求。如果数据访问架构不合理,当访问请求较多时,容易出现访问超时的情况。文中,主要就对商用App服务端数据访问架构改造进行了分析。

  关键词:商用App;服务端;数据访问;架构

  中图分类号:TP393 文献标识码:A

  文章编号:1009-3044(2020)21-0076-02

  开放科学(资源服务)标识码(0SID):

  1 背景研究

  1.1系统商用问题

  某国某运营商的掌上App项目中,近期出现了用户使用过程中App响应慢,卡顿甚至系统崩溃的问题。经过问题排查发现问题大概率出现在业务高峰期,并且随着用户量的增加,问题的出现概率越高。系统前端向服务端的请求出现超时。进而检查服务端,发现超时的原因在于数据库链接满载,读写吞吐量达到瓶颈导致请求超时。

  1.2系统服务端架构分析

  通过对目前系统服务端的架构做分析,发现目前服务端是采用的单一数据访问架构,服务端通过web项目将业务服务封装为restful接口给前端App调用,服务端的业务类访问单一的Mysql数据库,当读写数据量大时,业务类到Mysql的链接处就出现了瓶颈,出现了上面提到的问题。所以为了解决这个问题就必须改造现网系统服务端的数据访问架构,从单一数据库访问改造为分布式或集群架构,用来扩展数据库访问效率和吞吐量,并可提升数据访问的高可用性。

  1.3 架构选型

  目前业界有多种Mysql数据库的分布式/集群方案,通过对各种方案的优劣并结合项目实际情况为本次的改造选择使用MysqI+Mycat的架构,中间件对代码影响最小,易于架构改动,以及后期扩展。

  2 架构实现

  第一部分的改造将一台Mysql数据库扩展为两台Mysql,一主一备,通过原生的复制机制实现双向复制,加入Mycat中间件代理两台Mysql,实现读写的负载均衡,并且Mycat通过心跳机制检测到主库宕机后,自动切换到备机。业务测代码不需要修改,只需要修改数据库的连接由Mysql的地址切换到Mycat即可。

  第二部分的改造也有两种方案,第一种:将一台Mycat扩展为两台,业务测访问VIP(虚拟IP),两台keepalive竞争VIP,并由HAproxy转发到其中一台Mycat,实现负载均衡高可用。

  第二种:Mycat依旧为两台,但是负载均衡不在服务端,而是放在客户端(及业务代码端),使用java原生提供的LoadBal-ancing协议,将对数据库的读写请求负载在多个MYcat实例上实现Mycat的高可用。LoadBalancing原理:mysql connector/J驱动创建的LoadBalancedConnection是一个逻辑链接,其内部持有一个物理链接列表,即与每个host建立一个Connection。url中的每个host都是平等的主host,当客户端获取连接时会有两种random(默认随机)和bestResponseTime(最小响应时间)两种均衡策略,可以在参数** loadBalanceStrategy**中指定,架构图如图1。

  关于两种方案的选择,方案一自定义软负载是自己实现的,功能单一,负载策略只有轮询,而且健康检查在很长一段时间出现连接泄露的问题,稳定性不够好,还需要做一些优化和测试进行打磨;方案二是基于mysql的Java连接驱动做的负载均衡,是官方提供的方案,稳定性和可用性更高,而且我们在经过很长一段时间的压测和容错性测试,发现其性能很优越,负载均衡策略也更丰富,使用过程更简单,所以决定使用方案二。

  3 环境搭建

  3.1 Mycat+Mysql搭建

  首先在两台Linux主机上安装Mycat,然后再安装两台Mysql,端口号分别为3301和3302,安装方法这里不赘述。接着对两台Mycat进行配置,分别代理两台Mysql数据库,分别对server.xml.schemas.xml做相應的配置,实现代理一主一从两个Mysql数据库,并且从库也为主库的备用库,注意schemas.xml中的balance类型设置为2,所有的主库和从库都参与读操作的负载均衡。

  3.2 功能验证

  3.2.1 负载均衡

  启动两台Mysql和两台Mycat,从任意一台Mysql主机访问Mycat,指令为:

  mysql -h172.16.23.126 -P8066 -uroot -pmycat0001

  端口指向其中一台My at,用户名密码,执行多次查询操作,读操作负载均衡日志中展示的结果,已实现了在主从库中负载读的操作。

  3.2.2故障迁移

  手动停掉主库模拟数据库宕机的情况,mycat自动将从库切换为主库,不影响读写操作,并且当主库故障恢复后,再次测试多次查询操作,恢复到之前的负载均衡状态。

  3.2.3 主从复制

  关于主从复制功能,因为目前一主一从的架构下写操作都在主库,读操作在主库与从库间负载,所以需要主从保持复制同步数据。这里使用Mysql原生的复制机制,通过bin log实现数据的同步。验证过程:同样登陆mycat,执行插入,修改或删除操作,首先数据会入主库,查询主库表能够查询到写操作的结果,这时再查询从库,发现数据和主库一致,说明复制操作完成。当停掉其中一个数据库后,再次执行插入,修改或删除操作,然后手动恢复停掉的数据库,再次查询该数据库的表数据,发现两库数据保持一致,说明在故障恢复后,主从复制的机制仍然有效。

  4 性能测试

  4.1 测试前提准备

  有一个重要的指标需要注意,就是数据库的最大连接数,要模拟现网项目的真实场景,这个配置是至关重要的,所以首先需要将两台Mysql数据库的最大连接数设置和现网项目保持一致,这里我们设置为2000。

  4.2 采集样本准备

  准备两组采集样本,第一组采集对单例mysql读操作的性能數据,初始并发请求为0,每过10秒钟增加100并发请求,一直增加到并发5000,然后保持60秒,然后每秒减少100并发,直到并发为0。通过对上述场景下的mysql单例吞吐量,请求书,失败率三个方面表现做观察和分析。第二组则对Mycat架构下一主一从的mysql做读操作的性能数据,同样采用以上的递增并发测试场景。

  4.3 压测工具准备

  采用开源压力测试工具JMeter作为本次的性能压力测试工具,并创建压测模板。新建两个stepping thread group,一个是连接单例mysql,一个连接mycat,采用同样的读查询SQL。

  4.4 压测结果分析

  首先在对单例mysql的测试中我们可以看到刚开始时请求成功的TPS达到1700左右,然后随着并发量的提升,TPS逐渐降低,到4分钟时差不多降到1600左右,这个时候的并发请求快到了2000,后面继续降低,并且开始出现请求错误的响应,继续到9分钟左右,并发到达峰值5000,成功请求TPS降到1500左右。

  14分钟总共处理请求数155万,平均响应时长1014ms,响应错误率13.46%,也就是成功响应的请求数为134万。

  然后看mycat代理2台mysql负载均衡的测试结果,刚开始时请求成功的TPS达到3500左右,然后随着并发量的提升,TPS逐渐降低,到4分钟时差不多降到3300左右,这个时候的并发请求快到了2000,后面继续降低,并且开始出现请求错误的响应,继续到9分钟左右,并发到达峰值5000,成功请求TPS降到3100左右。

  14分钟总共处理请求数337万,平均响应时长529ms,响应错误率17.73%,也就是成功响应的请求数为277万。

  综合对比分析,可见在mycat的代理分布式mysql的环境下,不论从吞吐量,处理请求书,响应延时以及成功请求数等各方面,几乎提升了一倍的性能,效果比较理想。

  5 稳定性测试

  为了保证在升级到新的架构后数据库访问的稳定性,所以要做稳定性测试,在新的mycat代理2台mysql环境下,继续使用JMeter工具压测,测试样本调整为保持2000并发请求,并持续24小时,观察新架构下的数据访问稳定性,从测试结果可以看得出24个小时保持高并发下mycat+mysql表现稳定,吞吐量保持在3200-3300左右,平均请求延时在600ms左右,总共的请求错误率在1.1%左右,可以说结果比较理想。

  6 扩展性

  目前为止已经完成了将单例mysql扩展为2台mysql负载均衡的架构,这里称为扩容阶段1。并且通过压力测试结果可以得出性能确实提升的结论,所以再升级为新的架构后,理论上可以有效缓解现网App客户在使用时的卡顿、响应慢、崩溃等问题。当然考虑到用户量的不断增加,新的架构也必须要考虑到良好的扩展性,对于后期的扩容本文也给出了响应的架构演进,扩容阶段2将增加两台mysql,一共4台,做双主单从,两主互为主备,相互复制,主从之前相互复制,读操作在4台中负载均衡,效率应为阶段1的两倍左右。随着用户量继续增加,再到扩容阶段3再增加两台mysql,一共6台,在双主的情况下做双主双从,这时可以将负载均衡策略改为再除了当前主机之外的其他5台mysql做读负载,主机只做写,读写分离,让主机写效率更高。如果用户量还在持续上升,那么架构将演进到最终阶段,架构升级为N主N从,可以考虑将写负载到N台主库上,所有从库做读负载均衡。

  【通联编辑:李雅琪】

转载请注明出处。

1.本站遵循行业规范,任何转载的稿件都会明确标注作者和来源;2.本站的原创文章,请转载时务必注明文章作者和来源,不尊重原创的行为我们将追究责任;3.作者投稿可能会经我们编辑修改或补充。

相关文章
  • 基于B/S架构固定资产管理系统设计与实现

    基于B/S架构固定资产管理系统设计与实现

  • 关于云数据中心网络安全服务架构的探讨

    关于云数据中心网络安全服务架构的探讨

  • 基于MVC架构的电子商务网站设计与实现

    基于MVC架构的电子商务网站设计与实现

  • 基于B/S架构的职业院校实验室仪器预报系统的设计与实现

    基于B/S架构的职业院校实验室仪器预报系统的设计与实现

网友点评
精彩导读