关于订单数据统计的问题

> 问题 1 、虽然 log 表确实必须得有，但是订单的统计为什么不能直接在订单操作的过程中直接把相关的数据写入统计表，而是要异步的定时任务去做？

因为统计数据的更新是订单操作事件的**副作用**。

副作用是一定会成功的，因为并没有事务关系（如果你下单成功了，那么统计数据中的订单数量一定能够加 1，没有业务规则能够阻碍统计数据的改变）。

如果你把订单操作和副作用放在同一个事务里面，那么就会降低响应时间和吞吐量。


> 2 、这样的设计有什么好处吗？

第一，解耦。订单处理只需要考虑怎么处理订单，以及订单的操作应当写哪些日志。至于日志怎么做统计信息，订单处理的程序不需要考虑。

第二，batching 。如果日志处理和修改某些统计信息可以是批量的，那么这种 batching 可以提升速度（ 10 次订单数量+1 操作，vs 1 次订单数量+10 操作）

> 3 、更合适的方案是怎样的？

首先，如果想要做到实时，可以考虑“推”方式的消息队列。

其次，如果系统本身并发要求不高，那么应当采取把订单操作和副作用放在同一个事务里面进行提交，这可以**简化编程**。

原来的方案虽然性能较好，但是把副作用从事务里拆出，需要保证两点：1. log 是 1 次或多次送达的。2. log 可以被重复消费。

第一点可以使用 outbox pattern + ack 来保证；第二点可以让消费者建立去重表。 我所说的这两点是标准的解决方案。

可以看出提升性能的代价就是开发复杂度的增加。