大家是不是经常在工作中有这样的情况，比如你工作的部门是用户中心，最开始的业务需求只是用户的注册，认证，登录，更新等简单的需求，随着公司业务增长，有很多业务线，比如风控，客服，推广系统都需要实时知道用户注册了，认证了，改资料了等，最开始客服过来找你，然后你想想说：好啊，你们提供一个接口，我在用户注册后调下你，最后你会发现一大串的系统过来，都找你通知，当你不答应时，别人会说：我们这个业务需求就是这样的，你看某某部门你们都通知了，最后你想想也是，好吧，那我通知你。这还不是最重要的，重要的是：假如这些系统中的A、B、C随着业务变动，系统下线了，D、E、F业务重构，接口改了，这个时候居然需要你配合他们修改上线，你当时心肯定会想，这是你们的需求，凭什么还给大爷似的催着我上线。还有更烦人的，你会发现，经常会有人来找你，为什么某某事件我没收到通知，你心在想，明明是你接口不稳定，还怪我呢？

怎么解决这样的尴尬？这个时候我们可以用MQ，消息队列来解决。我们把用户注册，实名认证，上传头像，修改资料等抽象成一个一个的事件，在发生事件的时候，我们只需要往消息队列中推送一个事件，同时提供一些标准化的用户资料查询接口，这个时候你就可以坐着，只需要关注接口的效率，专心的研究你的数据表是否能满足未来的用户需求了，当A、B、C、D的RD研发过来找你时，你可以说：来来来，我给你看个topic, 然后再给你这些标准接口，你们订阅这个消息队列就好了，想要什么事件你们自己看着订阅吧，什么？XXX事件没有？好，我现在申请一个topic, 有了，完事。

怎么样，你只需要保证MQ入成功就行了，MQ的机制自然保证了订阅者会收到消息，再也不用担心他们停服升级，接口负载过大，不响应，还是考虑什么幂等了。

怎么样，这个时候你会发现，A下线，没你事了，B要换接口，也没你事了，而你有更多的精力来专注自己业务系统的性能提升和可扩展性。