业务代码堆积太多难维护 代码维护
代码维护(业务代码太多,无法维护)
背景
最近业务需求变化很快,时不时要增加一个新功能 。原始功能代码太多 。如果直接在原有的基础上增加新的功能,代码会变得臃肿,难以维护,甚至会影响原有的功能 。我想到了用消息队列来解耦 。由于添加的功能是统计的,不是很重要,即使它们偶尔失败,我也选择Redis轻量级消息队列,通过使用简单的发布和订阅[不会持久的消息]来解耦新功能 。
科学普及
作为程序员,几乎所有人都知道消息队列的使用场景:解耦、异步和削峰 。
业界通常使用三种类型的消息队列:
RocketMQ支持很多协议,重量级,更适合企业级开发,消息可靠 。
Kafaka吞吐量高,主要用于日志系统 。
Redis非流消息队列
优点:轻量、高效、搭建简单(这也是我这次选择的主要原因 。)
缺点:消息的可靠性没有保证 。发布时,如果客户端不在线,消息将丢失且无法检索 。
消息队列的两种模型:
1队列模型(生产者-消费者模型)一条消息只属于一个消费者 。
2发布和订阅模型一条消息只归多个消费者所有 。
真正的战斗
1配置redis
2用户配置
【业务代码堆积太多难维护 代码维护】
3发布者配置
写在最后
欢迎大家评论转发 。最后我想重申一下,redis消息队列不仅仅是这样,还有一种可以持久的方式,以后我会分享 。
推荐阅读
- 南京秦淮区皇册家园小区垃圾堆积如山 皇册家园
- 写字楼租赁业务分析报告 业务报告
- 国道、省道、县道、乡道的代码分别是什么 省道编号
- 代码防泄漏的22种实用技术手段 计算机实用技术
- 主板检测卡代码a5怎么处理 a5蒸压加气混凝土砌块
- pbt是什么面料怎么样?服装面料的英文缩写代码?
- 58股票代码;现在58优品的股票多少钱一股
- 复制代码到粘帖板_复制、粘贴中的”粘”读音该是zan还是nian?
- 最难推销的不是商品 销售员简历
- 家中宽带的错误代码都代表啥问题? 错误代码651