RabbitMQ之Topic模式实战

 

目录

需求分析

生产者发送消息

1.引入依赖

2.配置文件

3.改造GoodsService

消费者接受消息

测试

---

 

需求分析

 

以微服务项目举例。

目前已经完成了商品详情和搜索系统的开发。我们思考一下，是否存在问题？

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

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

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

如果我们在后台修改了商品的价格，搜索页面和商品详情页显示的依然是旧的价格，这样显然不对。该如何解决？

这里有两种解决方案：

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

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

以上两种方式都有同一个严重问题：就是代码耦合，后台服务中需要嵌入搜索和商品页面服务，违背了微服务的独立原则。

结合前面所说的问题我们引入了消息队列：

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

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

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

通过分析，我们得知生产者需要的操作是增删改时发送商品id(spuid)给消息队列，消费者需要的操作是随着商品信息的变化增删改索引库，增删改静态页面。

RabbitMQ中三种订阅模式都适用这个需求，本文使用订阅模型-Topic