场景1：重试、重定向
重试成功前的访问都很慢的，因为可能遇到了各种需要重试的错误，同时重试本身也会增加响应时间。
自定义了重试的策略：当遇到超时等错误时直接进行重试。
一方面我们尽量减少引发重试的因素，另一方面我们要控制好重试，例如：
- 控制好重试的次数
- 错峰重试的时间
- 尽可能准确识别出重试的成功率，以减少不必要的重试，例如我们可以通过”熔断“”快速失败“等机制来实现。
场景2：失败引发轮询
访问的域名由于负载均衡把它绑定了多个IP地址，一些IP地址指向的服务临时不服务时，则引发轮询，增加了延时。
场景3：GC的”STW“停顿
如果某天我们看到零星请求有”掉队“，且没有规律，但又持续发生，我们往往都怀疑是网络抖动，但是假设我们的组件是部署在同一个网络内，实际上，不大可能是网络原因导致的，更可能是GC的原因。跟踪GC有N多方法。比如 注册一个GC的通知回调，加GC跟踪日志。
场景4：资源争用
服务器上的定时日志归档抢占了我们的资源，导致应用程序速度临时下降，还有许多类似的资源争用，比如：机器装一些logstash、collectd等监控软件，而这些监控软件如果不限制它们对资源的使用，同样也可能会争用我们很多的资源。
解决方法：
- 降低资源争用，例如让备份慢一点
- 错峰，错开备份时间，每个事件在一个范围随机时间进行
- 避免资源共享，避免多个机器 / 虚拟机使用同一块磁盘
场景5：延时加载
场景6：网络抖动
网络抖动是衡量网络服务质量的一个指标。假设我们的网络最大延迟是100ms，最小延迟10ms，那么网络抖动就是90ms，即网络延迟的最大值和最小值的差值，差值越小，意味着抖动越小，网络越稳定。
网络的延迟包括两个方面：传输延时和处理延时。忽略处理延时，我们可以使用traceroute命令来查看传输延时。
image.png
默认了一个潜规则：网络延时越大，网络越抖动。
场景7：缓存失效
缓存失效是导致偶发性延时增加的常用情况，也是相对来说比较好定位的问题，因为接口的执行路径肯定是不同的，只要我们有充足的日志，即可找出问题所在。
针对这种情况，一方面我们可以增加缓存时间来尽力减少长延时请求，但要求的空间也会增加，我们还可以取消缓存的TTL，更新数据库时实时更新缓存，这样读取数据就可以一直通过缓存进行。
