通过异步机制解耦主干流程和附加流程

在web2.0系统中,用户的一次写操作,可能不仅仅意味着系统里要新增一条相应的记录,系统里可能还有很多统计性的事情要做。

比如在社区系统中,一个用户发了一个帖子,系统除了生成这个帖子的记录之外,还要给用户的发贴数加1,用户使用过的tag数加1,每个tag对应的帖子数加1 。。。

可以把主流程(生成帖子记录)和附加流程(各种加1)整合在一个事务里执行,程序健壮且易理解。但也可以在完成主流程后,发一条消息出去,让消息的消费者完成这些统计操作。

这种
异步机制最明显的好处,就像很多人说的那样,可以
尽快响应用户请求,提升性能

但更重要的好处是,
它实现了解耦,有利于各模块独立发展,并促进分工

1.
把附加流程实现在主流程的模块里,不符合主模块的职责定位; 主模块可能要因此依赖很多附加模块的库,不利于系统的简洁,对发布也有影响。

2.
把附加流程实现在主流程的模块里,不利于主模块和附加模块的开发人员各司其责,代码也容易遗漏或出错

由于异步消息的不可靠性,这样做也有它的副作用

1. 消息可能会丢失,导致附加流程未能执行。 要解决这个问题,只有使用不丢消息的消息中间件:这个中间件只有在收到消费者的回执后才会删除消息。

2. 消息可能重复,导致附加流程执行两次。如果你的附加流程不是统计性质,则让消费者做好幂等性就好了; 如果是统计类操作的话,那就要另建去重措施了。如果对统计数值的准确性要求不高,可以用bloom filter简单搞定; 否则的话,需要在缓存里保存一段时间内的消息ID,收到消息后做下比对再决定要不要消费它。

Leave a Comment

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.