1、空间换时间
- 单条数据处理时，只需要极少的时间，将数据进行汇总，并储存起来。在查询时，可以很快获取查询汇总数据，从而让用户有良好的体验。
逻辑图
性能分析
查询时，如果再sum或者group关系数据，性能消耗是很大的。特别是访问量比较大的首页，需要展示的一些汇总数据， 预先计算好，性能提升百倍。
业务场景
- 存在主表和明细表的业务时，明细表的汇总数量、汇总金额存在主表上
- 常见的业务如存取款， 需要单独记录余额信息
2、缓存
- 在获取数据时，先从缓存查询，如果缓存不存在，则查询关系数据库，并写入缓存。在后面的查询，可以利用缓存。
业务场景
- 基础数据的查询
- 频繁的查询操作，数据很少变化。如用户的权限。
3、前端异步请求
- 前端请求， 先发送一个请求，后台即可返回一个标志，然后进行异步处理。前端再根据标志，重新发起请求后台结果。后台结果未计算完成，则前端继续等待后发起新的请求。
业务场景
- 大数据查询时，可能超出web浏览器等待时间
- Get参数过大，改成Post方式，返回id，然后再根据id，get结果
- 文件导入，第一次进行数据校验，返回结果。第二次，不需要重新上传文件，直接保存。
4、后台异步执行
- 利用消息中间件，将业务模块进行解耦，或者计算时间较长、对用户来说不是即刻需要获取的数据，进行异步计算。
业务场景
- 一个模块数据处理后，通知另一模块进行数据处理
- 将业务操作中，比如业务操作日志、数据汇总计算，放在异步执行
- 智能计费业务
5、定时计算
- 部分任务采用定时框架激活进行计算，预先计算后，提供也业务使用。
业务场景
- 提前计算好一些数据
- 每日定时计算一些数据
6.搜索引擎
- 利用反向索引构建的搜索引擎系统，能够帮助企业业务进行模糊搜索时，快速匹配业务数据id。 业务系统根据id，能够利用索引查询业务数据。
性能分析
- 模糊搜索关系数据库，必定是全表扫描。 利用搜素引擎，可以快速得到id，再充分利用id的索引查询关系数据库。 性能提升百倍。
业务场景
- 数据量比较大的表，需要模糊查询
7、消息回调
核心思想
- 主要用于第三方系统的对接。 第三方系统异地部署，并且不可靠性比较大，延时比较明显。 必须利用异步处理机制：消息回调，处理后续业务。
业务场景：
- 支付成功通知
- 工作流消息回调通知
- 开票信息回调通知