背景
公司群发通知模块性能存在问题，我进行全面的系统调优，系统处理能力大幅提升。
原发送流程
优化后的发送流程
优化的点
- 说明：以下问题基本都是压测过程遇到的，有些问题普通的功能测试暴露不了。
- 优化目标：保证高可用、高并发、可扩展。
添加索引
普通索引：
- 现象：发送过程出现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会导致业务流程中断，导致业务没有执行完整
- 原因：业务流程太长
- 预估可能会出现的系统问题，合理的设计做补偿措施，就算出错了也要有办法能够补偿回来
使用缓存
库存处理等使用缓存，避免频繁操作数据库
…
