先告诉你答案： 异步、削峰、解耦。
异步
异步对应着同步，了解异步先了解什么是同步。
同步： 请求发送后，在收到结果之前一直等待。
异步： 请求发送后，可以去做其他事情。
下面来看一个同步案例
用户发送请求之后，会一直等待，整个链路调用时间150ms+200ms+200ms=550ms。但是这两个200ms是没必要等待的，我们完成购票后，难道要一直等短息和邮件吗？ 那如果短信和邮件在高流量场景延迟大的情况，我们需要等待更长的时间，这期间还不能做其他事，体验感非常差。
下面来看个加入消息队列实现异步的案例
用户向购票系统发购票请求，然后消息存入消息队列，一共花费150ms+10ms=160ms，剩下的时间我们可以去做其他的操作，大幅度提升用户体验效果。但是我们需要注意的是，整个流程的时长是没变的，就像你仅仅告诉服务员要吃什么是不会影响到做餐的速度的。
削峰
这个比较好理解。
例如你开发的系统1秒只能处理500条请求，此时来了10000条，那么9500条请求得不到有效处理。
我们将消息的接收和消息的处理分开做就会好很多，一个地方专门接收消息，不进行处理，这些消息会被放进消息队列，由消费者，也就是消息处理方去慢慢的处理。这样的话即使某时间流量很大，系统也能进行处理，无非是慢一点。
解耦
例如目前我们的业务有三个功能： 校验、购票、发送短信。
此时你接到领导的要求，需要添加邮箱业务、积分业务，你的想法是不是像下图一样，直接在后面添加。这样就违反了开闭原则（不懂开闭原则可以搜一下）。
这个做法缺点很多：
1. 业务复杂的时候，我们需要过一遍代码，再写新需求，以防影响之前的业务，非常费时间。
2. 我们新增添的代码有可能影响原来程序的运行。
3. 毫无拓展性、维护性可言，当我们一直有新增需求的时候，这块代码越写越长，越来越难改，别人接手你的项目就像接到了一坨**
一个比较好的解决办法就是用消息队列进行解耦
例如下图，如果我要新增一个业务，在购票的时候增加积分，我们就可以做一个积分系统，并且在消息队列订阅购票话题（下图右侧如同短信系统、邮件系统一样），这样的话，用户购票也会进行积分增加，在没动源代码的情况下面完成了功能新增。
