为什么要使用消息系统
这是最开始的一种架构：
- 大量的请求到达Web网站时，我们可以通过Redis缓存减少数据库对数据的查询压力。但是对于大量的增、删、改等请求，Redis无法完成，所以需要一个专门的消息系统来“缓存”这些请求。
- 一些非法操作会同时发送海量的查询请求，这时如果Redis中没有对应的数据，则这些请求就会被转嫁到Mysql，Mysql会瞬间承受大量的查询压力，来不及将对应的数据发送到Redis中，直接导致数据库宕机。所以也需要一个消息系统来“缓存”这些请求。
所以我们就使用下面的架构缓解数据库压力
备注：Redis可以做消息系统，但是无法适应大量的消息存储，一旦内存不足，直接完蛋。
消息系统的应用场景
- 解耦合
如上图所示，如果没有消息系统的情况下，，Web网站会直接调用手机认证和邮箱认证的接口，如果认证系统调用方式或者接口发生变更，Web网站的相关代码也需要更改，并且重新打包编译部署启动，这段时间网站无法使用，是无法容忍的问题。
因此我们使用消息系统，采取下面的方式：
如上图使用了消息系统可以做到web服务和其他的服务之间的解耦合,如三方的接口/调用方式做了更改, 我们不需要修改web服务的代码,也不需要重新启动web服务,只需要修改消息系统中调用三方服务的代码即可。
- 异步处理
假设一个场景：
当我们注册账号时，需要获取短信验证码或者邮箱认证，我们获取到发送认证成功后才会返回发送成功信息，在这之前，我们需要耗费大量时间等待我们的操作是否成功，严重影响用户体验。
因此我们采用消息系统的异步处理的特性解决此问题
异步处理在会先返回结果后再执行发送信息，避免了用户长时间等待操作是否成功的通知。
- 流量削峰
如上图，当有了消息系统，可以短时间拦截大量的请求，形成消息队列，交给Mysql慢慢的执行（可以理解为 大坝：当洪水来临，拦截下来，慢慢放流）
- 消息通信
客户端A 和 B 进行通信时，必须双方同时在线才能通信，否则不行。
但是引入消息系统后，我们可以将A的“发送信息”存入到消息系统中，当B上线后再将存入消息系统的“发送信息”发送给他。公众号群发的消息也是用此实现的。
