这是学习笔记的第 2035 篇文章
这几天在做一个极限优化的问题，问题的瓶颈不是几分钟优化到几秒钟，而是需要从近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的性能表现。