代码维护（业务代码堆积太多难维护）

代码维护（业务代码堆积太多难维护）

背景

最近业务需求变化快，时不时地要新增加个新功能。原来的功能代码太多了，如果在原来的基础上直接增加新功能，未免会让代码臃肿，变得难以维护，并且还有可能影响到原来的功能。我想到了利用消息队列来解耦，由于增加的功能是统计性的，也不是很重要，即使偶尔的失败也不影响，所以我选择Redis轻量级消息队列，利用简单发布订阅【不会持久化消息】来解耦新功能。

科普

消息队列的使用场景，作为一个程序员几乎都知道：解耦，异步，削峰。

业界常用的消息队列有3种：

RocketMQ，支持很多协议，重量级，更适合于企业级的开发，消息可靠。

kafaka 吞吐量高，主要用于日志系统。

redis 非stream消息队列

优点：轻量级 高效，搭建简单（这也是我这次选择的主要原因。）

缺点：不保证消息的可靠性。发布时若客户端不在线，则消息丢失，不能寻回。

消息队列的2种模型：

1 队列模型（生产者 消费者模型） 一个消息只被一个消费者拥有。

2 发布订阅模型 一个消息只被多个消费者拥有。

实战

1 配置好redis

2 订阅者者配置

3 发布者配置

写在最后

欢迎大家评论，转发。看到最后，我想重复申明redis消息队列不止这一种方式，还有一种可以持久化的方式，以后我会分享。

消息 队列 模型 我想 代码