MySQL毫秒必争的优化场景

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

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

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

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

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

而在这个过程中，尝试了很多种方案，都收效甚微，比较明显的改进还是在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的性能表现。