背景

公司群发通知模块性能存在问题，我进行全面的系统调优，系统处理能力大幅提升。

原发送流程

优化后的发送流程

优化的点

• 说明：以下问题基本都是压测过程遇到的，有些问题普通的功能测试暴露不了。
• 优化目标：保证高可用、高并发、可扩展。

添加索引

普通索引：

• 现象：发送过程出现SQL超时异常。
• 原因：基本都是随着数据量不断提升，某些表没有索引导致的，对于群发这个场景，会因为这种异常影响主流程。
• 建议：设计表的时候预估业务量，对于关键字段添加索引是成本最低的性能优化手段。

唯一索引：

• 现象：生成的雪花ID重复，导致数据库要求的唯一字段重复。
• 原因：多节点雪花算法指定了相同的数据中心ID和机器ID，高并发情况下导致重复。
• 建议：某些需要保证唯一的场景，不要过分依靠代码逻辑，数据库添加唯一索引至少可以保证一致性。

优化表结构（垂直拆分、水平拆分）

• 现象：发送过程中有一个发送记录表被锁死。
• 原因：发送、第三方回调、定时任务都会去操作这个表（包括新增、修改），update操作的时候会加锁，导致大量请求排队处理。（这里把发送记录和回调记录拆成了2个表，瞬间缓解了压力）
• 建议：合理的进行表结构设计，解耦，不强相关的字段可以拆成多个表。

雪花ID处理

• 现象：生成的雪花ID重复
• 原因：多节点雪花算法指定了相同的数据中心ID和机器ID，高并发情况下导致重复。
• 建议：网上有很多方案
  • 大厂的做法应该是有一个专门生成雪花ID的服务集群
  • 思路是使用注册中心、redis等维护数据中心ID和机器ID
  • 我们目前的临时方案是采用redis的递增，每次服务重启递增拿id，到某个值之后清零（这种方案解决我们目前的场景没什么问题，当集群机器数增加和遇到不断重启的场景可能会有点问题）

使用设计模式

• 现象：之前代码很多地方采用if else、switch，代码可读性和可扩展性都很差。
• 原因：一开始开发时间比较赶，想着if else、switch写起来方便。
• 建议：预估可能会频繁扩展的地方使用工厂模式、策略模式、模板方法模式提高扩展性。（主要就是添加新功能可以尽可能少的改动其他代码）

池化思想

• 现象：http句柄被用完
• 原因：
  • 服务有时候发送大量http请求，导致http句柄被用完。
  • redis、数据库没用连接池导致频繁创建和销毁连接。
  • 没用线程池，导致频繁创建销毁线程等。
• 建议：能用池的就尽量用池，可以提高效率、节约资源。

批处理思想

• 现象：接口效率低、占用资源多
• 原因：频繁操作数据库、频繁调用第三方接口
• 建议：看看能不能分批处理、有没有批量接口

集群思想

• 现象：处理慢
• 原因：一台机器处理能力有限
• 建议：想办法利用集群的优势、把压力分散到其他节点

使用MQ

• 现象：突然的流量洪流使系统满载或者崩溃
• 原因：系统处理能力有限
• 建议：使用MQ销峰，先把要处理的任务推送到MQ，消费者根据自己的消费能力指定消费线程数慢慢处理。

使用多线程

• 现象：代码执行效率低
• 原因：逻辑多，串行处理，没用充分利用cpu和内存资源
• 建议：适当使用多线程相关技术提高效率，JUC包下面的工具

JVM调优

• 现象：OOM、系统停顿
• 原因：代码复杂之后（高并发、大数据）、运用了很多线程池、批处理，内存和cpu消耗会有上升
• 建议：
  • 通过压测合理设置JVM参数（垃圾回收器、堆内存配置等）
  • 常用的观察工具使用（本地VisualVM、线上Arthas等，还有其他的）；
  • 观察GC次数和时间，Full GC会暂停整个进程
  • 观察堆内存使用情况（防止各个区域OOM）

使用限流

• 现象：突然的流量洪流使系统满载或者崩溃
• 原因：系统处理能力有限
• 限制接口处理能力，多余请求直接拒绝

服务拆分

• 现象：已经不能从技术上优化系统了
• 原因：服务处理能力有限，业务放到一起会互相影响
• 合理的服务拆分，根据不同服务的业务量来选择部署方案

数据一致性保证

• 现象：服务重启、OOM会导致业务流程中断，导致业务没有执行完整
• 原因：业务流程太长
• 预估可能会出现的系统问题，合理的设计做补偿措施，就算出错了也要有办法能够补偿回来

使用缓存

库存处理等使用缓存，避免频繁操作数据库
…