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产生的背景

---

一、消息队列系统最在能够追溯到上个世纪（是否是感受好久远，实际上是1983年，那时候我还没用出生）。1983年最先的消息队列软件Teknekron诞生，当时紧用于一些金融交易等系统。

二、上世纪九十年代，诞生了多家消息队列系统，例如IBM MQ、微软的MSMQ、TIBCO MQ等消息队列在企业中的应用也越发普遍。显然这些商用的消息队列系统若是企业要使用须要付出高昂的成本，而且各个消息队列之间使用不一样的API不一样的协议。

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

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

为何叫RabbitMQ？
不少人估计和我同样也有这个疑问，我在《RabbitMQ实战》这本书中找到了答案：兔子行动很是迅速并且繁殖起来也很是疯狂，因此就把Rabbit用做这个分布式软件的命名（就是真么简单）。

 

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