专栏首页杨建荣的学习笔记MySQL毫秒必争的优化场景

MySQL毫秒必争的优化场景

这几天在做一个极限优化的问题,问题的瓶颈不是几分钟优化到几秒钟,而是需要从近2毫秒优化到1毫秒以内,至于这个指标1毫秒到底是怎么来的,这是一个业务层面可见的指标体系,即如果超过了一定的延迟范围,则整个数据通道都会产生阻塞,所以优化目标有些过于清晰,导致整个优化过程还是蛮有压力的。

整体的系统架构是这样的三层结构,LVS使用负载均衡和转发,而中间件层使用了路由转发。数据分片节点有8个。

对于读写延迟,指标是不一样的,对于读延迟是在1毫秒以内,而写延迟是在5毫秒以内。可参考的系统使用了存储,所以这是和MySQL的一种平行的较量,即商业数据库采用了存储来满足IO需求,而MySQL使用水平扩展来提高IO吞吐率。

整个优化的过程有一个重要的拐点,那就是初期会认为主要的性能开销是在LVS的三层架构的通信代价层面,所以在开始的时候是使用了2个中间件,测试时由LVS模式改造为直连中间件的模式,这种模式下,性能不降反升,从我们的分析来看,感觉主要是单个中间件层面的使用情况有限。

而通过负载均衡可以对性能进行扩展,所以改造为3个中间件节点之后,性能有了明显的提升,即从1.5毫秒优化到了1.1毫秒。

ID

改进方案

读延迟(平均值)

写延迟(平均值)

1

LVS模式测试,2个中间件

1.5ms

5.0ms

2

由LVS模式改进为直连中间件,

1.6ms

5.2ms

只连接一个中间件节点

3

切换为LVS模式,2个中间件

1.5ms

5.0ms

4

增加积分中间件,

1.1ms

4.5ms

由2个中间件扩展为3个

5

修改中间件连接数配置,

1.1ms

4.5ms

分片节点由200缩减为100

6

修改SQL语句逻辑

0.8ms

3.2ms

7

调整为2倍压力

0.8ms

3.0ms

8

调整为4倍压力(压测1个多小时)

0.8ms

3.3ms

而在这个过程中,尝试了很多种方案,都收效甚微,比较明显的改进还是在SQL层面,有一条SQL语句,使用了主键,语句类似于:

select count(1),value from test_data where id=xxx;

这条语句优化为:

select value from test_data where id=xxxx;

之后,性能从1.1毫秒直接提升了0.3毫秒,到了0.8毫秒。

达到了性能标准之后,让人提心吊胆的阶段就是把目前的压力提高2倍,是否能够支持1毫秒以内的性能延迟。

通过测试来看,还是很稳定的,平均延迟没有任何变化,而经过业务高峰期的洗礼之后,整个延迟的平均值稳定在0.8毫秒,在这个基础上,我们继续进行压力测试,把压力提高到了4倍,读写延迟依然比较稳定,所以到了这个阶段之后,我们的性能测试算是有了一个好的开始。

当然从后续的规划来看使用LVS模式需要在同一个网段,对于跨IDC的场景来说,还是存在一些限制情况,所以我们也在考虑进行consul方向的压力测试,来评估在这种业务压力之下,consul的性能表现。

本文分享自微信公众号 - 杨建荣的学习笔记(jianrong-notes)

原文出处及转载信息见文内详细说明,如有侵权,请联系 yunjia_community@tencent.com 删除。

原始发表时间:2019-07-25

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

我来说两句

0 条评论
登录 后参与评论

相关文章

  • python技术面试题(十二)--SQL注入、项目部署

    It's up to you how far you go. If you don't try, you'll never know!

    小闫同学啊
  • 项目部署(二)

    What would life be if we had no courage to attempt anything?

    小闫同学啊
  • Nginx配置详解(推荐)

    Nginx功能丰富,可作为HTTP服务器,也可作为反向代理服务器,邮件服务器。支持FastCGI、SSL、Virtual Host、URL Rewrite、Gz...

    习惯说一说
  • FastDFS的简单使用

    互联网中有海量的文件,比如电商网站有海量的图片文件,视频网站有海量的视频文件,如果使用传统的模式上传文件,肯定是不可取的。因此需要使用第三方服务...

    宋先生
  • 秒懂Dubbo框架(原理篇)

    在上文 性能基础之常见RPC框架浅析 中我们详细介绍常见的 RPC 框架,本文将详细介绍 Dubbo 框架。

    高楼Zee
  • 简单聊聊企业应用架构的演变

    早期, 企业的对外提供的服务比较单一, 客户流量也相对不足。 因此将所有的模块,代码打包在一个项目中,集中部署一台机器上。

    终身幼稚园
  • Python 面试题大全系列(三)

    物理层:网线,电缆等物理设备 数据链路层:Mac 地址 网络层:IP 地址 传输层:TCP,UDP 协议 应用层:FTP 协议,Email,WWW 等

    周萝卜
  • 除了负载均衡,Nginx还可以做限流、缓存、黑白名单……

    Nginx应该是现在最火的web和反向代理服务器,没有之一。她是一款诞生于俄罗斯的高性能web服务器,尤其在高并发情况下,相较Apache,有优异的表现。那除了...

    用户1516716
  • 到底什么是CDN?

    可是,大家在追剧的时候,有没有想过一个问题——为什么有时候明明自己手机的网速很快,但观看视频时,仍然卡顿?

    鲜枣课堂
  • 云原生世界中的隐形人如何拥抱 Istio

    身为一个企业服务部门的 IT 工人,在为甲方殚精竭虑的同时,经常有一种跟世界脱节的感觉:流量经济持续不断的冲刷之下,微服务、云原生等新的架构和概念如火如荼;大咖...

    崔秀龙

扫码关注云+社区

领取腾讯云代金券