在web2.0系统中，用户的一次写操作，可能不仅仅意味着系统里要新增一条相应的记录，系统里可能还有很多统计性的事情要做。
比如在社区系统中，一个用户发了一个帖子，系统除了生成这个帖子的记录之外，还要给用户的发贴数加1，用户使用过的tag数加1，每个tag对应的帖子数加1 。。。
可以把主流程（生成帖子记录）和附加流程（各种加1）整合在一个事务里执行，程序健壮且易理解。但也可以在完成主流程后，发一条消息出去，让消息的消费者完成这些统计操作。
这种
异步机制最明显的好处，就像很多人说的那样，可以
尽快响应用户请求，提升性能。
但更重要的好处是，
它实现了解耦，有利于各模块独立发展，并促进分工。
1.
把附加流程实现在主流程的模块里，不符合主模块的职责定位； 主模块可能要因此依赖很多附加模块的库，不利于系统的简洁，对发布也有影响。
2.
把附加流程实现在主流程的模块里，不利于主模块和附加模块的开发人员各司其责，代码也容易遗漏或出错。
由于异步消息的不可靠性，这样做也有它的副作用：
1. 消息可能会丢失，导致附加流程未能执行。 要解决这个问题，只有使用不丢消息的消息中间件：这个中间件只有在收到消费者的回执后才会删除消息。
2. 消息可能重复，导致附加流程执行两次。如果你的附加流程不是统计性质，则让消费者做好幂等性就好了； 如果是统计类操作的话，那就要另建去重措施了。如果对统计数值的准确性要求不高，可以用bloom filter简单搞定； 否则的话，需要在缓存里保存一段时间内的消息ID，收到消息后做下比对再决定要不要消费它。