项目需求分析（2）
核心 API
对于 Broker 来说, 要实现以下核心 API，通过这些 API 来实现消息队列的基本功能
\1. 创建交换机 (exchangeDeclare)
\2. 销毁交换机 (exchangeDelete)
\3. 创建队列 (queueDeclare)
\4. 销毁队列 (queueDelete)
\5. 创建绑定 (queueBind)
\6. 解除绑定 (queueUnbind)
\7. 发布消息 (basicPublish)
\8. 订阅消息 (basicConsume)
\9. 确认消息 (basicAck)
\10. 取消订阅 (basicCancel)
另一方面, Producer 和 Consumer 则通过网络的方式, 远程调用这些 API, 实现 生产者消费者模型
关于 VirtualHost：对于 RabbitMQ 来说, VirtualHost 也是可以随意创建删除的
交换机类型
对于 RabbitMQ 来说, 主要支持四种交换机类型：
• Direct
• Fanout
• Topic
• Header
其中 Header 这种方式比较复杂, 比较少见。常用的是前三种交换机类型，项目中也主要实现这三种
• Direct: 生产者发送消息时, 直接指定被该交换机绑定的队列名
• Fanout: 生产者发送的消息会被复制到该交换机的所有队列中
• Topic: 绑定队列到交换机上时, 指定一个字符串为 bindingKey。发送消息指定一个
字符串为 routingKey。当 routingKey 和 bindingKey 满足一定的匹配条件的时候, 则把消息投递到指定队列
这三种操作就像给 qq 群发红包.
• Direct 是发一个专属红包, 只有指定的人能领.
• Fanout 是使用了魔法, 发一个 10 块钱红包, 群里的每个人都能领 10 块钱.
• Topic 是发一个画图红包, 发 10 块钱红包, 同时出个题, 得画的像的人, 才能领. 也是每个领到的人都能领 10 块钱
持久化
Exchange, Queue, Binding, Message 等数据都有持久化需求
当程序重启 / 主机重启, 保证上述内容不丢失
网络通信
生产者和消费者都是客户端程序, Broker 则是作为服务器，通过网络进行通信。
在网络通信的过程中, 客户端部分要提供对应的 api, 来实现对服务器的操作。
\1. 创建 Connection
\2. 关闭 Connection
\3. 创建 Channel
\4. 关闭 Channel
\5. 创建队列 (queueDeclare)
\6. 销毁队列 (queueDelete)
\7. 创建交换机 (exchangeDeclare)
\8. 销毁交换机 (exchangeDelete)
\9. 创建绑定 (queueBind)
\10. 解除绑定 (queueUnbind)
\11. 发布消息 (basicPublish)
\12. 订阅消息 (basicConsume)
\13. 确认消息 (basicAck)
\14. 取消订阅（basicCancel）
可以看到, 在 Broker 的基础上, 客户端还要增加 Connection 操作和 Channel 操作
• Connection 对应一个 TCP 连接
• Channel 则是 Connection 中的逻辑通道
一个 Connection 中可以包含多个 Channel。Channel 和 Channel 之间的数据是独立的，不会相互干扰。这样做主要是为了能够更好的复用 TCP 连接, 达到长连接的效果, 避免频繁的创建关闭 TCP 连接。
Connection 可以理解成一根网线. Channel 则是网线里具体的线缆.
消息应答
被消费的消息, 需要进行应答。应答模式分成两种：
• 自动应答: 消费者只要消费了消息, 就算应答完毕了，Broker 直接删除这个消息
• 手动应答: 消费者手动调用应答接口, Broker 收到应答请求之后, 才真正删除这个消息
手动应答的目的, 是为了保证消息确实被消费者处理成功了. 在一些对于数据可靠性要求高的场景, 比较常见.