- 高频交易系统会因为相差几毫秒而错失交易，损失百万。
- 推荐系统因为延迟，不能做更多的策略，导致推荐效果差流失用户。
上述问题的技术原因都是因为服务延迟升高，而造成延迟升高的原因是庞大的用户规模和业务逻辑的快速增长不可避免的导致架构设计的过时，业务规模增长过快与服务质量升级较慢造成了这一主要矛盾，这一矛盾限定了技术架构必须面向未来不断的动态演进，以适应业务的不同需求。而作为工程师需要驾驭技术架构的变化趋势作出关键的技术决策，治理业务规模增长导致的系统复杂度。系统延迟直接影响用户体验/服务质量/现金收入 其作为最核心的技术指标之一,也是治理系统复杂度的主要目标。
如何在保证可靠性的同时随着业务规模(QPS与逻辑复杂度)的增长而降低系统延迟呢?
为解决这一问题，本篇内容将给大家提供一个通用的系统延迟优化策略工具箱，希望在遇到系统性能瓶颈时在这里找到可以尝试的策略。
我们从一个研发人员面对一个优化任务时所要采取的行动为线索串联所有的关键知识点:
- 性能分析，确定性能瓶颈究竟发生在系统的哪个部分。
- 验证收益，持续监控优化后的系统，拿到指标提升的证据。
延迟(Latency)即为用户请求到返回结果的耗时，有时也称作为响应时间,等于传输耗时+处理时间，任意物理空间内的传播运动均会产生延迟，因此任意系统从输入到输出之间均会存在延迟，它会反映每个用户真正的耗时情况，因此直接影响用户的体验。
吞吐(Throughput) 即是单位时间内系统处理任务(事务)的数量，通常有QPS和TPS等表述方式，它能够衡量系统真正的处理效率，因此直接刻画系统的性能。
并发度强调系统在同一时刻能够处理的任务数量，因此有 并发度 = 延迟 * 吞吐。
性能简单来说就是完成任务的时间，对于计算机系统来说完成每个任务都是需要消耗资源的，如果某种资源受限就会导致执行时不必要的等待，这种等待导致完成任务的时间变长，进而导致性能降低。
对于完成时间通常有两种: 本质时间(受限于硬件物理特性如时钟频率)和偶然时间(资源不足导致等待)
而这种资源受限的情况通常仅来自于两种原因: 机器与人，计算机系统尤其是现在互联网系统中，研发与运维人员同样是这个系统的一部分。
对于人来说通常指的是实现程序的逻辑不能充分利用机器资源导致资源不足进而影响性能。