业务代码堆积太多难维护代码维护 _太多

代码维护(业务代码太多难以维护)
背景
最近业务需求变化很快，时不时需要添加新的功能。原始功能代码太多。如果在原有的基础上直接增加新的功能，代码会很臃肿，很难维护，原有的功能也可能会受到影响。我想到了用消息队列来解耦。因为增加的功能是统计性的，不是很重要，所以即使偶尔出现故障也不会影响。所以我选择Redis轻量级消息队列，通过使用简单的发布和订阅[不会被持久化的消息]来解耦新功能。
科学普及
作为程序员，我们几乎都知道消息队列的使用场景:解耦、异步和削峰。
业界通常使用三种消息队列:
RocketMQ支持多种协议，重量级，更适合企业级开发，消息可靠。
Kafaka吞吐量高，主要用于日志系统。
Redis非流消息队列
优点:轻便、高效、施工简单(这也是我这次选择的主要原因。)
缺点:消息的可靠性没有保证。发布时，如果客户端不在线，消息将丢失且无法检索。
消息队列的两种模型:
1队列模型(生产者-消费者模型)一条消息只属于一个消费者。

2发布-订阅模型一条消息只归多个消费者所有。
【业务代码堆积太多难维护代码维护】
真正的战斗
1配置redis 。
2用户配置

3发布者配置

写在最后
欢迎大家评论转发。最后，我想重申一下，redis消息队列不仅是一种方式，也是一种可以坚持的方式，我后面会分享。

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

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