目录
1.核心API
2.交换机类型
3.持久化
4.网络通信
5.小结
1.核心API
消息队列服务器（Broker Server），要提供的核心API
1.创建队列（queueDeclare）
此处不使用 Create 这样的术语，而是使用 Declare，是因为：
Create 就只是单纯的“创建”
Declare 起到的效果：不存在就创建，存在就什么都不做
2.销毁队列（queueDelete）
3.创建交换机（exchangeDeclare）
4.销毁交换机（exchangeDelete）
5.创建绑定（queueBind）
6.解除绑定（queueUnbind）
7.发布消息（basicPublish）
8.订阅消息（basicConsume）
9.确认消息（basicAck）
与TCP通过确认应答类似：
这个API起到的效果，是可以让消费者显式的告诉broker server，这个消息我已经处理完毕了
提高整个系统的可靠性，保证消息处理没有遗漏
问题：为什么没有消费消息的API？
对于MQ和消费者之间的工作模式，有两种：
1.Push（推） Broker 把收到的数据 ，主动发给订阅的消费者。RabbitMQ只支持 推 的方式。
2.Pull（拉）消费者主动调用Broker 的 API 取数据。Kafka就能支持拉。
2.交换机类型
交换机在转发消息的时候，有一套转发的规则。提供几种不同的交换机类型（ExchangeType）来描述不同的转发规则。
RabbitMQ主要实现了 四种 交换机类型 （AMPQ协议定义）
1.Direct 直接交换机
2.Fanout 扇出交换机
3.Topic 主题交换机
4.Header 消息头交换机 （规则复杂，应用场景少）
1.Direct直接交换机
生产者发送消息的时候，就会指定“目标队列”的名字。交换机收到之后，就看绑定的队列里有没有匹配的队列，如果有转发过去（把消息塞到对应的队列中），如果没有就丢弃。
2.Fanout扇出交换机
生产者发送消息，交换机收到之后，就把消息转发给绑定的所有队列。
3.Topic主题交换机
关键概念：
1.bindingKey：把队列和交换机绑定的时候，指定一个单词（像一个暗号）
2.routingKey：生产者发送消息的时候，也指定一个单词
如果当前bindingKey和routingKey 能够对上暗号，此时就把这个消息转发到对应的队列里。
3.持久化
虚拟主机，交换机，队列，绑定，消息等都需要Broker Server 组织管理。所以这些对应的数据需要存储和管理起来。此时内存和硬盘都会各自存储一份，以内存为主，硬盘为辅。
内存存储的原因：
对于MQ来说，能够高效的转发处理数据，是非常关键的指标。因此使用内存来组织上述数据，得到的效率，就比硬盘中高的多。
硬盘存储的原因：
为了防止内存的数据随着 进程重启/主机重启 丢失。
4.网络通信
其他服务器（生产者/消费者）通过网络，与Broker Server进行交互。
此处采用：TCP + 自定义应用层协议 实现 生产者/消费者 和Broker Server 之间的交互工作
主要工作：
客户端通过网络调用Broker Server 提供的编程接口，所以客户端这边也要提供上述API，只不过服务器的上述API是真正的业务逻辑，客户端这边仅仅知识发送请求和接收响应。
虽然调用的是本地方法，实际上就像似调用了一个远端服务器方法一样 -> 远程过程调用（RPC）
远程过程调用（RPC）：
简单解释：可以视为编写客户端服务器程序，通信过程的一种设计思想。
5.小结
通过需求分析的出具体要做的事情：
1.需要实现生产者 ， Broker Server，消费者三部分。
生产者和消费者，主要编写客户端和服务器的网络通信部分。消费者和生产者具体的业务逻辑并不关心，给客户端一组API，让客户端的业务代码通过网络通信来调用Broker Server上的方法即可。
2.实现Broker Server 以及 Broker Server 内部的一些基本概念和核心API
3.持久化
把上述这些关键数据，在硬盘中的存储。
解决存储在数据库/文件中，以及后续服务器重启重新获取上述数据的问题。
最终目标：
实现一个分布式系统下的生产者消费者模型（不支持分布式部署功能），只是一个单机的Broker Server，但是能给多个生产者消费者服务。
专业的 MQ 都是支持集群的：
优点：
1.提高可用性
2.处理更高的并发
3.数据互相备份
