“不懂异步的过来”

个人对于异步的认知，更多是来自阻塞。同步就是阻塞的，一个请求没有完成，就一直阻塞在那里，直到完成返回响应或者超时退出。异步编程模式可以是代码解耦，程序更加灵活，扩展性更强。

文绉绉的话听很多了，就不能有话简单说嘛？

好吧，首先举个简单的例子，我们在麦当劳买汉堡的时候，前台有一位mm，专门负责下单，然后后面有专门的厨师负责烹饪。如果是同步的，当我们下完单，mm就只能跟你聊天，直到厨师将东西做好递给mm，然后mm再拿给你。这想起来很美好，可是如果后面有长龙队伍等着，这合理吗？所以mm下完单后就会叫你去另一边等了（可怜），然后继续为下一位顾客下单。等到厨师做完汉堡后，mm听到叮叮的响声，就会将汉堡拿给你。这个就是典型的异步实例，术语上称为“咖啡豆模型”（Coffee Bean），核心就是将订单接收和订单处理分开！

在rabbitmq中，就提供这样的编程支持。订单接收和订单处理之间有一个中间层，就是rabbit。订单接收和订单处理都是消息的生产者和消费者。之所以我们传统的编程思想是同步的，是因为我们的代码跟着逻辑走，将整个任务看成一个整体，一个原子操作。异步编程的时候，就会将整个任务经过清晰的分析后进行拆分，变成构成任务整体的一个个更小的任务。

变成这种模式，在访问量变大的时候，可以多增加订单处理（订单接收一般不会成为瓶颈，如果真的成为瓶颈，那么恭喜你生意兴隆），由于rabbitmq天生的消费者轮询机制，所以你连负载均衡器都不需要了（爽吧）。如果不横向扩展消息订单处理，那么用户在下了订单后，一直处于等待状态，虽然你是赚钱了，但是用户体验不好，下次就不来了。还有一个好处，采用消息队列解耦后，我们可以使用不同的程序语言去获取订阅队列，整个架构更加灵活，语言将不成为系统的枷锁。

前文提到了rabbit对于服务消费者有天然的负载均衡，也就是实现了一对多的请求。但是当前端服务器（生产者）不足以负荷更多的需求时候，这时候，增加一台或者多台前端服务器，将消息写到rabbitmq中同一交换器上，这样也能传到相应的服务消费者上去，也就是多对多的方式。而且，这个多的服务生产者，可以不仅仅是同一个应用程序，也可以是不同的生产者，这样的话，多个不同的生产者都可以往相同类型的消费者中传递消息，也就是消费者的逻辑可以给多个服务调用，可以避免服务消费者逻辑被其他代码复制冗余。