- A+
本文来自曹政大神的微信公众号【caoz的梦呓】，caoz的文章篇篇犀利，值得细读与收藏，特转载过来，分享给大家，如果你也喜欢，可以微信搜索“caoz的梦呓”来关注他。文章所有版权归原作者曹政所有！
很多人会问我说，他们有个系统，流量有多大，用户有多多，然后问我用什么方案，实话说，这样的问题基本上都没办法回答，你必须首先清楚，你的负载构成是怎样的，以及负载增加的趋势是怎样的，才能有针对性的给出方案。
1、负载的构成
你要提出优化方案，首先你要知道你系统的负载是怎么构成的，
CPU开销是多少，是哪些进程和服务占用的。
内存开销是多少，是哪些进程和服务占用的，如果内存占用了swap分区，大量的硬盘虚拟内存操作，效率自然会直线下降。
I/O开销 是多少，读请求的频率，写请求的频率，什么服务和什么操作占用了大量的i/o。
连接数是多少，是怎么分布的，比如http链接多少，数据库链接多少，memcache链接多少，当然更细致的三次握手的链接是多少。
了解这些，是优化的基础，这些都不清楚，谈个毛优化方案。
2、负载增长趋势
随着应用请求的增加，你的系统的负载是怎么增加的。
第一种，是线性增加，就是请求两倍，负载变成两倍
第二种，是指数增加，请求两倍，负载变成四倍甚至更多，
有人会奇怪，为什么这样呢？因为请求增加和数据量增加很可能是一致的，比如一个毫无索引的遍历查询，数据量增加了一倍，查询效率就降低50%，请求量又增加1倍，所以负载就增加了4倍。 这种就是非常不合理的技术架构。
第三种，收敛增加，随着你的请求增加规模，负载的增加低于线性增加并逐步收敛，比如说，大量使用缓存和异步更新，请求越多，缓存命中率越高，异步更新的请求合并率越高，这样负载的增加就呈现为收敛性，这样系统的支撑性就会很强大。
3、系统阈值
很多时候，我们系统出现瓶颈，并不是因为负载很高，而是因为某个请求规模超越了系统阈值，导致无法应答请求。
典型范例如
syn flood攻击时，最大的syn连接池被占满，导致无法应答新的请求，而此时服务器负载非常之低，这就是典型服务器很闲但不响应的情况。
http链接数越界，http链接超时设置较长，大量链接没有释放，导致链接数超过默认最大值，http服务器无法响应新请求。
mysql链接数越界，大量使用常链接或不释放链接，导致大量sleep链接占满系统默认连接数，数据库无法响应新请求。
最大文件打开数越界，大量使用临时文件和缓存文件，大量的文件打开操作，而系统默认值没有调优。
类似这样的还有很多，以上只是最常见的一些。
这就是很多人觉得奇怪的一个现象，我看了一下系统负载不高为啥我服务器不响应了？要充分理解各种系统阈值，并针对自己的应用特性进行调优，才可以充分发挥系统硬件特性，实话说，很多系统或服务的默认阈值都偏低。
4、峰谷的规律和预测
通常，负载和请求并非一条平顺的曲线，每天都有波峰和波谷，如果有大的活动或市场推广计划，很可能也会有一条非常陡峭的增加曲线。
这时候需要运营者有一个预测和判断，知道波峰在什么时候会发生，而且要知道相关的规律是什么。
5、异常的监控和跟踪
之前我的系列文章有提过一点，要对各种异常敏感，很多严重的性能问题其实是有先兆的，比如偶尔的501错误，偶尔的访问卡顿，偶尔的链接出错，很多时候，用户刷新一下，这个问题就没有了，但是很可能此事系统已经进入了一个不稳定的状态。
有经验和有意识的架构师或运维专家，应该会做日志的跟踪和审计，随时查看这种错误信息的出现频率，并对此进行持续的跟踪监控，在高并发的真实环境中，在一定比例内，这样的偶发异常是非常难免的，你要问我如何彻底杜绝，对不起，我也不会，但是首先，这个比例应该是非常低的，比如说在万分之几甚至更低，当异常响应超过千分之几的时候你就应该足够敏感和足够紧张的去研究这个问题了。其次，当异常频现的时候应该在程序里埋点做跟踪了，并尽可能记录异常频次较高时候的系统负载值和各种连接数与阈值的比例。然后基于异常的一些提示信息在网上进行搜索，当然，不同的异常存在不同的可能，我没办法给出一揽子解决的方案，但是我希望提醒，当异常开始快速增加的时候，你至少要知道，系统已经呈现出可能崩溃的前兆了。
认识负载，是优化系统的关键，今天先讲这些，这个系列并未结束。
最近在多个城市穿梭，因此更新不够稳定，谢谢您继续关注和支持！
