一、产品需求澄清、PM排期及任务分解

这个没太多好说的。

二、开发设计评审(研发、测试参与)

2.1 功能设计流程图

与外部系统交互、本系统模块之间流程，比较好用的画图软件draw.io或在线的process on

2.2 数据库设计

评审

• 表结构设计是否合理；
• 表的关联关系是否合理；
• 是否创建索引；
• 是否需要放到分片库以及分片字段设计；

2.3 缓存设计

• 缓存结构是否合理 (string、hash、list、set)，

优秀实践:
1)对于C端高并发接口，hash结构要慎重用，key不能用固定的key，防止key倾斜，可以采用string结构，value尽可能压缩下，比如
("groupId:":"536363737""groupId":"989898989"}改为"536363737#989898989"，大大节省redis空间。

2)对于数据量很大，单条value报文很大的业务，如果经常判断某个值是否存在，可以考虑采用set结构，利用sismember方法，时间复杂度0(1)

• 缓存过期时间是否合理(不能怕脑袋胡乱,给一个时间，如果存放的数量，过期时间一定要给短一些，比如20分钟或半小时，否则增长很长，打爆redis)；、

• 缓存是否设计考虑预热和重建机制

• 缓存中尽可能不能使用delete、特别是存放数量很大的hash、set、List、容易阳塞redis，引发事故、替换方案:expire-1

• 是否是否设计二级缓存(本地缓存+分布存、实现方式Caffinecuaatredis),对于数据量不大热点数据般1w条以下，单条报文10Kb以下，比如网点教据、航线数挥可以放本地缓存，这些热点数据查询非常频繁，容易造成redis倾斜，本地缓存可以抗这种高并发流量

• 防穿透处理
  1)提供c端的接口，查询不到数据，尽可能不要穿透到数据库，防止打爆数据库，查不到一定记得打印告警日志，及时人工干预

  2)提前将数据预热到缓存中(系统启动预热或者运营后台有手动刷新缓存按钮或者有个job刷缓存)

4、job设计

• job逻辑要考虑幂等
• job逻辑尽可能轻量级，不要太重，导致执行逻辑很久(如果确实逻辑比较复杂，可以分拆J0b或者从代码层面优化，例如:分批并行处理、减少单次处理数据)
• 构建数据到缓存类似的job，尽可能选择时间在晚上12点以后，尽量不要白天进行，因为白天流量很大，重建缓存容易引起接口抖动
• 对于定时执行的job，设计执行时间的时候，要慎重考虑线上整个job执行的时间，根据这个时间配置cron表达式，不要拍脑袋随意设置不然本次job没执行完，下一次job执行的时候容易错过。
• 对于大表数据(百万、千万甚至亿级)，可以利用xxljob、saturn等分布式调度框架的分片处理能力，并行刷数据，提供处理速度。

5、接口设计

• 高并发接口必须在测试环境压测，清楚的知道接口支持的QPS，另外根据压测报告给出的优化建议，及时调整线上的配置、代码优化。
• 提供给C端的接口，要清楚曝光位置、然后根据接口可能预计调用的流量、压测的接口最大支持的QPS，决定是否扩容、是否需要限流及兜底逻辑、是否熔断。
• 程序中涉及的异常信息，及时配置错误监控告警，遇事做到心中有数。
• 对于业务关键位置，及时打印info级别的业务追踪日志，如果是高并发接口，要做好开关，能秒级关闭，因为打印日志也特别耗性能。
• 程序设计方面，高并发接口，尽可能使用缓存、能异步就异先一般用不要用多线程异》，尽可能买用无锁设计防止线程10CK CPU冲高，批量写库
• 接口前置逻辑提前，尽早过滤掉不合规逻辑，缩短接口整个调用链路时长，提升接口整体吞吐量。
• 接口要考虑无状态设计、幂等设计(考虑分布式锁唯一key)、安全设计(接口方法签名、是否接第三方防刷服务判断是否黑产用户)
• 对第三方服务做到0信任，考虑降级、熔断，与业务方确认好兜底逻辑处理。
• 工具类尽可能使用apache、google等出的、一些github小众的开源框架很多在高并发场景有bug和性能瓶颈。
• 接口的时间复杂度，部分逻辑在设计的时候尽可能保证是0(1)，例如调用第三方接口，f循环调用的，是否可以提到循环外，传多个d批量调用一次，时间复杂度从0(n)降为0(1)。

6、监控设计

• 核心接口做好监控，例如:调用量上涨/下跌80%、接口健康度监控(5分钟error超过100次、5分钟接口超过11000次、5分钟不可用次数超过1000次)
• 应用监控，例如:应用cpu、内存层、gc、繁忙线程数、数据库连接池连接数监控告警
• 中间件监控，例如:redis可用性、cpu-内存-流量-大key-热key-慢查询监控、kafka可用性-消息积压情况-丢失率监控告警数据库监控，例如:mysql cpu、慢sql监控告警
• 业务监控，例如:发券量暴涨或暴跌、活动注册人数同比或环比异常

7、预案设计

1)设计全局开关(系统接近不可用，通过配置中心全局开关快速切断接口流量，保证系统可用)
2)遇到系统故障，非核心功能通过配置中心开关下线，保证整体服务可用
3)应用能自动扩容这里就要求应用做到无状态设计，比如:我们之间有一些应用有调用加密机，但是新应用节点需要申请白名单，这种设计方式就没法自动扩容)