RabbitMQ消息队列-RabbitMQ的优劣势及产生背景

本篇并没有直接讲到技术，例如没有先写个Helloword。我想在选择了解或者学习一门技术之前先要明白为什么要现在这个技术而不是其他的，以免到最后发现自己学错了。同时如果已经确定就是他，最好先要了解下技术产生的背景等因素，以便对技术有更深刻全面的了解（那句话怎么讲的“你不了解过去的我，又怎么理解现在的我”）。

为什么使用RabbitMQ

为什么我开始选择学习RabbitMQ：

1. 安装部署简单，上手门槛低，功能丰富，符合AMQP标准；
2. 企业级消息队列，经过大量实践考验的高可靠；
3. 集群易扩展，可以轻松的增减集群节点；
4. 有强大的WEB管理页面。

企业为什么将RabbitMQ作为消息队列系统：

在我学习RabbitMQ的初期我在网上查到一些这方面的资料，我认为比较好的是下面这封http://www.doc88.com/p-5826232080382.html 一方面是他对于RabbitMQ的评价本身，更重要的是对于技术选型评价的两个维度：十万米高空看技术和显微镜看技术。

十万米高空看RabbitMQ：

1. 有商业化的运营，不会轻易死掉；
2. 遵循AMQP协议，不会被绑架；
3. 强大的社区支持，为技术进步提供动力；
4. 大量成功的应用案例，例如阿里、网易等互联网巨头都有使用。

显微镜看RabbitMQ：

1. Erlang开发，AMQP的最佳搭档，在支持持久化的消息队列中性能算很优秀的；
2. 支持消息持久化、支持消息确认机制、灵活的任务分发机制等，支持功能非常丰富；
3. 可靠性高；
4. 集群扩展很容易，并且可以通过增加节点实现成倍的性能提升；
5. WEB管理和监控，有些技术癌更喜欢命令行界面，但WEB管理为后期运维提供很大的便利。
   RabbitMQ劣势：
   在kafka和zero面前性能被虐成渣，（持久化消息和ACK确认的情况下生产和消费消息单机大约在1-2万左右）

结论：如果你希望使用一个可靠性高、功能强大、易于管理的消息队列系统那么就选择RabbitMQ吧，如果你想用一个性能高，但偶尔丢点数据不是很在乎可以使用kafka或者zeroMQ。

RabbitMQ产生的背景

1、消息队列系统最在可以追溯到上个世纪（是不是感觉很久远，其实是1983年，那时候我还没用出生）。1983年最早的消息队列软件Teknekron诞生，当时紧用于一些金融交易等系统。

2、上世纪九十年代，诞生了多家消息队列系统，例如IBM MQ、微软的MSMQ、TIBCO MQ等消息队列在企业中的应用也愈加广泛。显然这些商用的消息队列系统如果企业要使用需要付出高昂的成本，并且各个消息队列之间使用不同的API不同的协议。

3、2004年，AMQP（Advanced Message Queuing Protocol,高级消息队列协议）开始开发。通过这一标准可以和任意AMQP供应商提供的MQ服务进行交互。

4、2006年，光阴荏苒时光如梭，一转眼就说到了重点。我们的主角使用Erlang语言实现的AMQP开源版本，RabbitMQ诞生了，同年AMQP协议首次发布。

为什么叫RabbitMQ？
很多人估计和我一样也有这个疑问，我在《RabbitMQ实战》这本书中找到了答案：兔子行动非常迅速而且繁殖起来也非常疯狂，所以就把Rabbit用作这个分布式软件的命名（就是真么简单）。

转自：https://blog.csdn.net/super_rd/article/details/70229714