代码维护(业务代码堆积太多难维护) 背景 最近业务需求变化快,时不时地要新增加个新功能。原来的功能代码太多了,如果在原来的基础上直接增加新功能,未免会让代码臃肿,变得难以维护,并且还有可能影响到原来的功能。我想到了利用消息队列来解耦,由于增加的功能是统计性的,也不是很重要,即使偶尔的失败也不影响,所以我选择Redis轻量级消息队列,利用简单发布订阅【不会持久化消息】来解耦新功能。 科普 消息队列的使用场景,作为一个程序员几乎都知道:解耦,异步,削峰。 业界常用的消息队列有3种: RocketMQ,支持很多协议,重量级,更适合于企业级的开发,消息可靠。 kafaka吞吐量高,主要用于日志系统。 redis非stream消息队列 优点:轻量级高效,搭建简单(这也是我这次选择的主要原因。) 缺点:不保证消息的可靠性。发布时若客户端不在线,则消息丢失,不能寻回。 消息队列的2种模型: 1队列模型(生产者消费者模型)一个消息只被一个消费者拥有。 2发布订阅模型一个消息只被多个消费者拥有。 实战 1配置好redis 2订阅者者配置 3发布者配置 写在最后 欢迎大家评论,转发。看到最后,我想重复申明redis消息队列不止这一种方式,还有一种可以持久化的方式,以后我会分享。