1.为什么要使用消息队列？
1.通过异步处理提高系统性能；削峰、减少响应所需时间
如果不使用消息队列时，用户请求的大量数据直接写入到数据库中，在高并发的情况下，写入能力骤降，响应变慢；使用消息队列后，用户请求后可以立即加入到队列，然后返回给用户，数据库通过消息队列消费消息，因此响应速度能得到大幅改善。
消息队列具有很好的削峰作用的功能——即通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。
用户请求数据后，由于异步操作，比如消费消息后与数据库的操作可能出现失败的情况，这种情况我们就不能直接提示用户操作成功，需要通过后置处理来提醒用户成功或失败。
2..降低系统耦合性
模块之间不存在直接调用，可扩展性更好。消费队列是利用发布-订阅模式工作，生产者发布消息，一个或多个消费者消费消息，新增业务只需要订阅消息从而实现网站业务的可扩展性设计。
2.使用消息队列带来的一些问题
系统可用性降低：加入MQ之后，需要考虑消息丢失或者说MQ挂掉等等的情况
系统复杂性提高：需要保证消息不被重复消费，处理消息丢失的情况、保证消息传递的顺序性等等问题
一致性问题：我上面讲了消息队列可以实现异步，消息队列带来的异步确实可以提高系统响应速度。但是，万一消息的真正消费者并没有正确消费消息怎么办?这样就会导致数据不一致的情况了!
3.JMS
JMS(JAVA Message Service,Java消息服务)API是一个消息服务的标准或者说是规范。ActiveMQ 就是基于 JMS 规范实现的。
JMS两种消息模型：1.点对点；2.发布/订阅
JMS 五种不同的消息正文格式：
StreamMessage -- Java原始值的数据流
MapMessage--一套名称-值对
TextMessage--一个字符串对象
ObjectMessage--一个序列化的 Java对象
BytesMessage--一个字节的数据流
3.AMQP
AMQP，即Advanced Message Queuing Protocol,一个提供统一消息服务的应用层标准 高级消息队列协议(二进制应用层协议)，是应用层协议的一个开放标准,为面向消息的中间件设计，兼容 JMS。基于此协议的客户端与消息中间件可传递消息，并不受客户端/中间件同产品，不同的开发语言等条件的限制。RabbitMQ 就是基于 AMQP 协议实现的。
4.常见的消息队列对比
从五个方面分析：
吞吐量：万级的ActiveMQ和RebbitMQ的吞吐量，要比十万甚至百万级别的RocketMQ 和 Kafka 低一个数量级
可用性：都可以实现高可用，ActiveMQ 和 RabbitMQ 都是基于主从架构实现高可用性。RocketMQ 基于分布式架构。 kafka 也是分布式的，一个数据多个副本，少数机器宕机，不会丢失数据，不会导致不可用
时效性：RabbitMQ 基于erlang开发，所以并发能力很强，性能极其好，延时很低，达到微秒级。其他三个都是ms 级。
功能支持：Kafka 功能较为简单，主要支持简单的MQ功能，在大数据领域的实时计算以及日志采集被大规模使用，其他都较为完善
消息丢失：丢失可能性很低
5.什么是 Dubbo?
Apache Dubbo (incubating) |ˈdʌbəʊ| 是一款高性能、轻量级的开源Java RPC 框架，它提供了三大核心能力:面向接口的远程方法调用，智能容错和负载均衡，以及服务自动注册和发现。简单来说 Dubbo 是一个分布式服务框架，致力于提供高性能和透明化的RPC远程服务调用方案，以及SOA服务治理方案。
6.什么是 RPC?
RPC是远程过程调用，他是一种通过网络从远程计算机请求服务，而不需要了解网络协议，比如两台计算机，A提供一个服务，B提供一个服务，服务A想要调用B的服务，虽然也可以通过HTTP调用实现，但是HTTP可能会处理比较慢，并且优化不好，用RPC就是为了解决这个问题。
7.RPC原理
1.服务消费方调用本地方式提供的服务
2.client stub接收到调用后将调用信息组装成网络消息的传输体
3.client stub找到服务提供方，将消息发送
4.server stub接收到消息后进行解码
5.server stub根据解码结果调用本地服务
7.将本地调用的结果打包成消息发送回client stub
8.client stub对消息进行解密，发送给服务消费方
9.消费方获得结果
8.为什么要用 Dubbo?
Dubbo的诞生与SOA分布式架构有着密切的联系，SOA面向服务的架构，将系统拆分为服务层、表现层两个部分，服务层对业务逻辑进行处理，表现层只需要处理与页面的交互，业务逻辑都交给服务层进行处理。SOA的两个特色就是服务提供者和服务消费者
Dubbo有四点特性：
1.负载均衡：可部署多台服务器，系统访问时由dubbo决定具体调用哪一台
2.服务调用链路形成：部署的服务越多，服务启动的依赖关系就会模糊，dubbo可以解决我们服务间是如何调用的问题；
3.服务访问压力以及时长统计、资源调度和治理：提供可视化工具，可以对服务进行治理
4.服务降级：如果一台服务挂掉后，会自动调用其他的服务。
9.什么是分布式?
分布式就是将系统的各个模块通过服务的方式，部署到不同服务器上，用以减轻服务器压力，并且可以提高系统并发量和性能。
10.为什么使用分布式？
1.系统拆分为不同的模块便于开发；
2.系统拆分为不同的模块便于系统的维护，提高系统的性能。
11.Dubbo的图解
Provider: 暴露服务的服务提供方
Consumer: 调用远程服务的服务消费方
Registry: 服务注册与发现的注册中心
Monitor: 统计服务的调用次数和调用时间的监控中心Container: 服务运行容器
Container: 服务运行容器
重要知识点总结:
注册中心负责服务地址的注册与查找，相当于目录服务，服务提供者和消费者只在启动时与注册中心交互，注册中心不转发请求，压力较小
监控中心负责统计各服务调用次数，调用时间等，统计先在内存汇总后每分钟一次发送到监控中心服务器，并以报表展示
注册中心，服务提供者，服务消费者三者之间均为长连接，监控中心除外
注册中心通过长连接感知服务提供者的存在，服务提供者宕机，注册中心将立即推送事件通知消费者
注册中心和监控中心全部宕机，不影响已运行的提供者和消费者，消费者在本地缓存了提供者列表
注册中心和监控中心都是可选的，服务消费者可以直连服务提供者
服务提供者无状态，任意一台宕掉后，不影响使用
服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
12.Dubbo 提供的负载均衡策略
1.基于权重的随机负载均衡机制；2.基于权重的轮询负载均衡机制；3.最少活跃调用数，最慢的服务活跃数计数差大；4.一致性hash
13.zookeeper宕机与dubbo直连的情况
zookeeper宕掉后，dubbo还能基于缓存在一段时间内提供服务。dubbo的健壮性表现在：
1. 监控中心宕掉不影响使用，只是丢失部分采样数据
2. 数据库宕掉后，注册中心仍能通过缓存提供服务列表查询，但不能注册新服务
3. 注册中心对等集群，任意一台宕掉后，将自动切换到另一台
4. 注册中心全部宕掉后，服务提供者和服务消费者仍能通过本地缓存通讯
5. 服务提供者无状态，任意一台宕掉后，不影响使用
6. 服务提供者全部宕掉后，服务消费者应用将无法使用，并无限次重连等待服务提供者恢复
