用户注册案例
使用异步模型的优点
快速响应
不在需要等待。生产者将数据发送消息队列后，可继续往下执行，不虚等待耗时的消费处理
削峰填谷(需要修改)
互联网产品会在不同的场景其并发请求量不同。互联网应用的访问压力随时都在变化，系统的访问高峰和低谷的并发压力可能也有非常大的差距。
如果按照压力最大的情况部署服务器集群，那么服务器在绝大部分时间内都处于闲置状态。
但利用消息队列，我们可以将需要处理的消息放入消息队列，而消费者可以控制消费速度，因此能够降低系统访问高峰时压力，而在访问低谷的时候还可以继续消费消息队列中未处理的消息，保持系统的资源利用率。
降低耦合
如果调用是同步，如果调用是同步的，那么意味着调用者和被调用者必然存在依赖，一方面是代码上的依赖，应用程序需要依赖发送邮件相关的代码，如果需要修改发送邮件的代码，就必须修改应用程序，而且如果要增加新的功能
那么目前主要的消息队列有哪些，其有缺点是什么？(好好记下这个高频题目啦)
砸钱一台机器扛不住了，需要多台机器帮忙，既然使用多台机器，就希望不要把压力都给一台机器，所以需要一种或者多种策略分散高并发的计算压力，从而引入负载均衡，那么到底是如何分发到不同的服务器的呢？
最初实现负载均衡采取的方案很直接，直接上硬件，当然也就比较贵，互联网的普及，和各位科学家的无私奉献，各个企业开始部署自己的方案，从而出现负载均衡服务器。
HTTP重定向负载均衡
也属于比较直接，当HTTP请求叨叨负载均衡服务器后，使用一套负载均衡算法计算到后端服务器的地址，然后将新的地址给用户浏览器，浏览器收到重定向响应后发送请求到新的应用服务器从而实现负载均衡，如下图所示：
HTTP重定向负载均衡
优点：
简单，如果是java开发工程师，只需要servlet中几句代码即可
缺点：
加大请求的工作量。第一次请求给负载均衡服务器，第二次请求给应用服务器
因为要先计算到应用服务器的 IP 地址，所以 IP 地址可能暴露在公网，既然暴露在了公网还有什么安全可言
DNS负载均衡
了解计算机网络的你应该很清楚如何获取 IP 地址，其中比较常见的就是 DNS 解析获取 IP 地址。
用户通过浏览器发起HTTP请求的时候，DNS 通过对域名进行即系得到 IP 地址，用户委托协议栈的 IP 地址简历 HTTP 连接访问真正的服务器。这样不同的用户进行域名解析将会获取不同的IP地址从而实现负载均衡。
DNS负载均衡
乍一看，和HTTP重定向的方案不是很相似吗而且还有 DNS 解析这一步骤，也会解析出 IP 地址，不一样的暴露？
每次都需要解析吗，当然不，通常本机就会有缓存，在实际的工程项目中通常是怎么样的呢？
通过 DNS 解析获取负载均衡集群某台服务器的地址；
负载均衡服务器再一次获取某台应用服务器，这样子就不会将应用服务器的 IP 地址暴露在官网了。
反向代理负载均衡
这里典型的就是Nginx提供的反向代理和负载均衡功能。用户的请求直接叨叨反向代理服务器，服务器先看本地是缓存过，有直接返回，没有则发送给后台的应用服务器处理。
