系统性能

提升系统性能经验

架构设计：

冗余能力:

• 如果一个系统的可用性为90%，两台机器的可用性为1-0.1*0.1=99%，机器越多，可用性会更高。
• 对于DB这种对连接数有瓶颈的，需要在业务上做好分库分表也是一种冗余的水平扩展能力。

故障转移能力:

• 部分业务场景对于DB的依赖性很高，在DB不可用的情况下，能不能转移或者先中断现场，保存上下文。

  • 对当前的业务场景上下文写入延迟队列，等故障恢复后再对数据进行消费和计算。

• 有些不可抗力和第三方问题，可能会严重影响整个业务的可用性，因此要做好异地多话，冗余灾备以及定期演练。

系统资源隔离性:

• 在异常处理中，经常会因为上游数据的大量上报导致队列阻塞，影响时效性。

  • 因此可以做好核心业务和非核心业务资源隔离，对于秒杀类的场景甚至可以单独部署独立的集群支撑业务。

• 如果A系统可用性90%，B系统的可用性40%，A系统某服务强依赖B系统，那么A系统的可用性为P(A|B), 可用性大大降低。

事前防御:

做好监控：

• 对系统的CPU，线程CE、IO、服务调用TPS、DB计算耗时等设置合理的监控阈值，发现问题及时应急。

做好限流/熔断/降级等：

• 瞬间流量问题很容易引发故障，一定要做好压测和熔断能力。
• 秒杀类的业务减少对核心系统的强依赖，提前做好预案管控，对于缓存的雪崩等也要有一定的预热和保护机制。
• 同时有些业务开放了不合理的接口，采用爬虫等大量请求Web接口，也要有识别和熔断的能力。

提升代码质量：

• 核心业务在大促期间做好封网、资金安全提前部署核对主动验证代码的可靠性，编码符合规范等等。
• 提前做好压测和代码Review。

事后防御和恢复：

事前做好可监控和可灰度，事后做好任何场景下的故障可回滚。

其他防御能力：

• 部署过程中做好代码的平滑发布，问题代码机器快速地摘流量。
• 上下游系统调用的发布，保证依赖顺序。
• 发布过程中，正常的业务已经在发布过的代码中执行，逆向操作在未发布的机器中执行，保证业务一致性。

如何提升系统写性能

写性能为什么难提升：

1、丢 写 的代价往往比丢 读 大。

2、写 必须和磁盘打交道，而 读 是可以使用缓存的。

3、写 往往需要加锁，而 读 不需要。

4、写 容易造成资损，而 读 一般不涉及资损。

写性能提升整体策略：

因为 写 行为主要是和DB打交道。

• 所以：一方面是对DB的优化，一方面是对使用的优化。

DB优化：

• 数据分片。
• 选择合适的数据库。

使用优化：

• 合理加锁。
  • 尽量使用乐观锁，悲观锁场景控制锁粒度。
• 异步法。
  • 将同步的过程转换为异步的过程。
• 批量插入。
  • 内存聚合：
    • 多个请求过来，写到内存的queue中。
    • 然后每个线程循环检查自己的状态。
    • 系统中定时从queue中捞取批量请求一起执行。
  • 流水聚合：
    • 把请求的流水落库，然后通过定时任务捞取所有的流水，并在内存中统一计算结果。
    • 然后更新数据库，标记原流水状态，结束。
• 文件法。
  • 第一步：写文件。
  • 第二步：定时任务去读取文件信息，然后执行写入DB动作。

接口超时问题

网络异常:

• 网络抖动，带宽被占满

线程池满了:

• 多种业务场景共用同一个线程池，可以拆分成多个线程池

数据库死锁

SQL语句没走索引

传入参数太多

超时时间设置过短:

• 不建议多种业务场景共用同一个超时时间，最好根据并发量的不同，单独设置不同的超时时间。

一次性返回数据太多

死循环

服务OOM