及时处理还是非及时处理

在编写业务代码的时候，常规性的是及时处理业务逻辑，因为写代码一般是串行的，先做什么事，再做什么事，但是有时候为了业务接耦等原因，也会用到非及时处理的方式，比如常用的多线程，消息队列，定时任务都属于非及时处理。

用及时处理，还是非及时处理，应该从哪些方面思考呢？

第一思考方面是业务，其次是扩展性和容错性。

举几个最近遇到业务场景，思考下应该要用什么处理方式。

场景1：做用户行为统计功能，设计的系统中有页面基础信息表需要维护，页面基础信息表包含页面标题、页面路径字段，前端工程师埋点上报的数据中包含页面标题和页面路径。

方案1（及时处理）：每次在上报埋点行为数据的时候进行保存，由于基础信息只需要保存一次，所以需要在保存之前判断页面基础信息是否存在；

方案2（非及时处理）：保存的地方不做基础信息保存的处理，单独启动一个定时任务，定时扫描最近5分钟上报的页面是否存在于基础信息表中，批量进行基础信息处理。

从业务出发，会选择方案2，因为统计数据对实时性要求没有那么高，而且代码业务也实现了解耦。

场景2：根据制成品数量来完工订单的逻辑，比如某个订单需要制作某个产品（制成品）100件，应该怎么样控制订单状态？

方案1（及时处理）：每个制成品完工的时候与订单数量对比，如果达到订单数量，进行订单完工订单处理；

方案2（非及时处理）：制成品完工不做处理，单独启动一个定时任务进行扫描，如果到达指定数量，进行订单完工；

从业务出发，会选择方案1，因为订单完工状态必须及时更新，以便下一个订单及时开始。

先从业务出发，想清楚大方向是采用及时处理还是非及时处理，然后再基于处理方案选择中间件，进行架构。

好的架构中，剖析业务是首要任务，然后兼顾扩展性和容错性，后期将会节约很多运营工作和重构工作。