分布式系统中引入RabbitMQ是为了解决什么问题？

刚进新公司，就被安排了一个任务，去解决没有消息队列的分布式系统带来的问题。

 

在分布式系统发展的初期，系统可能已经具备了搜索系统，但是如果我们的增删改查都在数据库中进行，那么是否存在一些问题？

• 商品的原始数据保存在数据库中，增删改查都在数据库中完成

• 搜索服务数据来源是索引库，如果数据库商品发生变化，索引数据是不能够及时更新的。

• 商品详情做了页面静态化，静态页面数据也不会随着数据库商品发生变化。

如果后台修改了商品的价格，搜索页面和商品详情页显示的依然是旧的价格，这样显然不行。

那么，想一下可以如何解决呢？

    方案1：每当后台对商品做增删改操作，同时要修改索引库及静态页面

    方案2：搜索服务和商品页面服务对外提供操作接口，后台在商品正删改后，调用接口

 

如此，会导致后台在商品服务中需要嵌入索搜和商品页面服务，代码的耦合度增高。那么应该如何

去解决这个问题呢？此时就需要引入消息队列。

    

 

什么是消息队列？（MQ，Message Queue）

以上是维基百科上面是解释

    

    消息队列是典型的：生产者

消费者模型。生产者不断向消息队列中生产消息，消费者不断地从队列中获取消息。因为消息的生产和消费都是异步的，而且只关心消息的发送和接收，没有逻辑地侵入，这样就实现了生产者和消费者的解耦。

 

结合前面所说的问题：

• 商品服务队商品增删改以后，无需去操作索引库或静态页面，只是发送一条消息，也不关心消息被谁接收。

• 搜索服务和静态页面服务接受消息，分别去处理索引库和静态页面

如果以后有其他系统也依赖商品服务的数据，同样监听消息即可，商品服务无需任何代码修改。

 

AMQP和JMS

AMQP,是高级消息队列协议。

JMS是Java消息服务应用程序接口

 

ActiveMQ:

ActiveMQ是Apache出品，最流行，老牌的消息队列，以往使用的很多，但是现在性能比较落后，慢慢地少用了。

目前的状况，面对超大规模的并发时，性能跟不上。

Kafka:只关注吞吐量，不关注数据安全性

RabbitMQ:是基于AMQP的一款消息管理系统，性能较好，同时具备较好的稳定性。

官网： http://www.rabbitmq.com/

官方教程：http://www.rabbitmq.com/getstarted.html

ActiveMQ：基于JMS

RabbitMQ：基于AMQP协议，erlang语言开发，稳定性好

RocketMQ：基于JMS，阿里巴巴产品，目前交由Apache基金会

Kafka：分布式消息系统，高吞吐量