这是学习笔记的第 1810篇文章
这几天有一个业务库的负载比往常高了很多，最直观的印象就是原来的负载最高是100%，现在不是翻了几倍或者指数级增长，而是突然翻了100倍，导致业务后端的数据写入剧增，产生了严重的性能阻塞。
这类问题引起了我的兴趣和好奇心，经过和业务方沟通了解，这个业务类型偏向于数据的密集型写入，不存在事务，但是有明确的统计需求。目前的统计频率是每7分钟做一次统计，会存在几类统计场景，基本都是全表扫描级别的查询语句。当前数据库的架构很简单，是一个主从，外加MHA的高可用。
问题的改进方向是减少主库的压力，因为目前主库的压力一方面在于并发写入压力，另一方面在于全表扫描的压力，对于CPU和IO压力都很大。统计的SQL导致了资源成为瓶颈，结果原本简单的insert也成为了慢日志SQL,相比而言，写入需求是硬需求，而统计需求是辅助需求，所以在这种场景下和业务方沟通，快速的响应方式就是把主库的统计需求转义到从库端。
转移了读请求的负载，写入压力得到了极大缓解，后来也经过业务方的应用层面的优化，整体的负载情况就相对乐观了。
主库的监控负载如下，可以看到有一个明显降低的趋势，CPU负载从原来的90%以上降到了不到10%。IO的压力也从原来的进100%降到了25%左右。
从库的监控负载如下，可以看到压力有了明显的提升。CPU层面的体现不够明显，主要的压力在于IO层面，即全表数据的扫描代价极高。
这个算是优化的第一步改进，后续还会有更大的压力场景，所以在这个基础上，我们需要对已有的架构做一些改进和优化，第一目前的架构暂时能够支撑密集型数据写入，但是不能够支持指数级别的压力请求，而且存储容量很难以扩展。
考虑到资源的成本和使用场景，所以我们暂时把架构调整为如下的方式，即添加两个数据节点，然后打算启用中间件的方式来做分布式的架构设计。对于从库暂时为了节省成本，就对原来的服务器做了资源扩容，即单机多实例的模式，这样一来写入的压力就可以完全支撑住了。
但是这种方式有一个潜在的隐患，那就是从库的中间件层面来充当数据统计的角色，一旦出现性能问题，对于中间件的压力极大，很可能导致原本的统计任务会阻塞。同时从库端的资源瓶颈除了磁盘空间外就是IO压力，目前通过空间扩容解决不了这个硬伤。
在和业务同学进一步沟通后，发现他们对于这一类表的创建是动态配置的方式，在目前的中间件方案中很难以落实。而且对于业务来说，统计需求变得更加不透明了。所以一种行之有效的改进方式就是从应用层面来做数据路由，比如有10个业务，业务1，业务2在第一个节点，业务3，业务5在第二个节点等等，按照这种路由的配置方式来映射数据源，相对可控，更容易扩展，所以架构方式改为了这种：
而整个的改进中，最关键的一环是对于应用SQL性能的改进，如果SQL性能的改进能够初见成效，后续的架构改进就会更加轻松。
后面继续码一篇，持续关注。
