RabbitMQ实战：性能和安全

本系列是「RabbitMQ实战：高效部署分布式消息队列」书籍的总结笔记。

前两篇介绍了RabbitMQ在可用性、监控方面的考虑，这是基础保障，因为在某些场景下是不容许丢失消息的，但它和性能往往是对立的，需要根据业务场景做取舍。

当处理一些敏感数据时，比如银行卡信息，需要考虑安全性问题，上一篇总结了数据传输安全方面的知识点，这里就比较好理解了。

通过介绍，你会了解到：

• 对速度的考虑
• 对内存和进程的考虑
• 对安全的考虑

对速度的考虑

有很多因素影响RabbitMQ投递消息的速度，包括消息持久化、路由算法、绑定数目、以及消息确认策略等，下面分别来介绍。

消息持久化

当发布消息时，需要决定丢失其中的任何消息是否可以接受，如果可以接受，可以将delivery-model设置为1，消息就不会持久化到硬盘了。

消息确认

当消费消息时，可以在队列订阅时，通过设定no-ack标记加快消息投递，如果设置为true，服务器就会在消息发送给客户端后自动将其出队。

这样，处理完消息之后就无须再发送确认消息回服务器了，能极大地加快消费者消费消息，但由于某些原因连接中断了，或客户端应用程序发生故障了，消息就永远消息了。

路由算法和绑定规则

前面介绍了3种类型的交换器：direct、fanout、topic，每种交换器代表了服务器实现的特定路由算法，会根据消息的路由键以及队列与交换器之间的绑定来选择队列。

在服务器端，交换器和绑定作为记录条目存储在Mnesia数据库中，当匹配消息路由键时，会尝试查找对应路由键的绑定。

fanout交换器在路由消息的时候，会忽略路由键，不需要进行查找。direct只有一个绑定，也会比较快，topic存储的路由信息比较复杂，由于路由键可以包含以点分隔的多个词，所以匹配消息路由键不仅仅是简单字符串的匹配，也会占用更多内存。

RabbitMQ实现了trie树数据结构用来存储绑定路由键模式，以支持快速查询，关于这种数据结构，我之前没接触过，据说比桶状哈希表还快，后面专门写一篇介绍这个数据结构吧。

投递消息

在交换器找到消息需要路由的目的地之后，会将目的地列表返回给rabbit_router，之后会将消息的