1、 单发单收
2、 单发送多接收
+++++++++++++++++++++前面两种没有使用exchange++++++++++++++++++
3、 Publish/Subscribe（广播）--ExchangeType：fanout
使用场景：发布、订阅模式，发送端发送广播消息，多个接收端接收。
4、 Routing（按路线发送接收）--ExchangeType：direct
使用场景：发送端按routingKey发送消息，不同的接收端按不同的routingKey接收消息。
5、Topics（按topic发动接受）--ExchangeType：topic
使用场景：发送端不只按固定的routingKey发送消息，而是按照字符串“匹配”发送，接收端同样如此。
1、 持久化--persistence
2、 发送ack确认---delivery acknowledgements
3、 广播确认---publisher confirms
4、高可用性--HA
（1）集群
（2）镜像队列
三、 解决问题
使用背景：
1、异步调用
2、多节点
3、消息队列
未加入MQ下发流程：
1、 云平下发配置1，LB将此任务提交给AFC1处理
2、AFC1将任务提交给本地的阻塞队列，然后保存DB
3、消费者从阻塞队列中取配置任务，进行配置下发
弊端：
1、 无法共享队列，局部保证时序。
1、 如何保证配置任务在rabbitmq中保存时不丢失？
配置镜像队列侧略
2、 当rabbitMq宕机重启时，如何处理之前的connection连接？
设置自动恢复连接，确保重启时，NODE能和rabbitmq通过原有的connection进行通信
3、 出现分裂情况怎么处理
配置了pause_monirity策略：（RabbitMQ处理网络分区的策略），另外 两种是 pause-if-all-down模式和autoheal模式。
MQ会自动检测其自身是否处于“少数派”，MQ会自动关闭这些节点的运作，当分区结束时又会启动。
4、 protobuf序列化
5、 ack及持久化的消息模式保证消息的可靠性。
gRPC
使用背景：
1、
转载于:https://www.cnblogs.com/snowwhite/p/9432888.html
相关资源：数据结构—成绩单生成器