成长之路

1、空间换时间

• 单条数据处理时，只需要极少的时间，将数据进行汇总，并储存起来。在查询时，可以很快获取查询汇总数据，从而让用户有良好的体验。

逻辑图

性能分析
查询时，如果再sum或者group关系数据，性能消耗是很大的。特别是访问量比较大的首页，需要展示的一些汇总数据， 预先计算好，性能提升百倍。

业务场景

• 存在主表和明细表的业务时，明细表的汇总数量、汇总金额存在主表上
• 常见的业务如存取款， 需要单独记录余额信息

2、缓存

• 在获取数据时，先从缓存查询，如果缓存不存在，则查询关系数据库，并写入缓存。在后面的查询，可以利用缓存。

业务场景

• 基础数据的查询
• 频繁的查询操作，数据很少变化。如用户的权限。

3、前端异步请求

• 前端请求， 先发送一个请求，后台即可返回一个标志，然后进行异步处理。前端再根据标志，重新发起请求后台结果。后台结果未计算完成，则前端继续等待后发起新的请求。

业务场景

• 大数据查询时，可能超出web浏览器等待时间
• Get参数过大，改成Post方式，返回id，然后再根据id，get结果
• 文件导入，第一次进行数据校验，返回结果。第二次，不需要重新上传文件，直接保存。

4、后台异步执行

• 利用消息中间件，将业务模块进行解耦，或者计算时间较长、对用户来说不是即刻需要获取的数据，进行异步计算。

业务场景

• 一个模块数据处理后，通知另一模块进行数据处理
• 将业务操作中，比如业务操作日志、数据汇总计算，放在异步执行
• 智能计费业务

5、定时计算

• 部分任务采用定时框架激活进行计算，预先计算后，提供也业务使用。

业务场景

• 提前计算好一些数据
• 每日定时计算一些数据

6.搜索引擎

• 利用反向索引构建的搜索引擎系统，能够帮助企业业务进行模糊搜索时，快速匹配业务数据id。 业务系统根据id，能够利用索引查询业务数据。

性能分析

• 模糊搜索关系数据库，必定是全表扫描。 利用搜素引擎，可以快速得到id，再充分利用id的索引查询关系数据库。 性能提升百倍。

业务场景

• 数据量比较大的表，需要模糊查询

7、消息回调

核心思想

• 主要用于第三方系统的对接。 第三方系统异地部署，并且不可靠性比较大，延时比较明显。 必须利用异步处理机制：消息回调，处理后续业务。

业务场景：

• 支付成功通知
• 工作流消息回调通知
• 开票信息回调通知