基于Redis实现分布式消息队列(1)

1、为什么需要消息队列?

当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异。

举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力。

再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送。

再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开。1:00到4:00和ERP联通,和电商系统断开。

再举个例子,服务员点菜快,厨师做菜慢。

再举个例子,到银行办事的人多,提供服务的窗口少。

乖乖排队吧。

2、使用消息队列有什么好处?

2.1、提高系统响应速度

使用了消息队列,生产者一方,把消息往队列里一扔,就可以立马返回,响应用户了。无需等待处理结果。

处理结果可以让用户稍后自己来取,如医院取化验单。也可以让生产者订阅(如:留下手机号码或让生产者实现listener接口、加入监听队列),有结果了通知。获得约定将结果放在某处,无需通知。

2.2、提高系统稳定性

考虑电商系统下订单,发送数据给生产系统的情况。

电商系统和生产系统之间的网络有可能掉线,生产系统可能会因维护等原因暂停服务。

如果不使用消息队列,电商系统数据发布出去,顾客无法下单,影响业务开展。

两个系统间不应该如此紧密耦合。应该通过消息队列解耦。同时让系统更健壮、稳定。

3、为什么需要分布式?

3.1、多系统协作需要分布式

消息队列中的数据需要在多个系统间共享数据才能发挥价值。

所以必须提供分布式通信机制、协同机制。

3.2、单系统内部署环境需要分布式

单系统内部,为了更好的性能、为了避免单点故障,多为集群环境。

集群环境中,应用运行在多台服务器的多个JVM中;数据也保存在各种类型的数据库或非数据库的多个节点上。

为了满足多节点协作需要,需要提供分布式的解决方案。

4、分布式环境下需要解决哪些问题

4.1、并发问题

需进行良好的并发控制。确保“线程安全“。

不要出现一个订单被出货两次。不要出现顾客A下的单,发货发给了顾客B等情况。

4.2、简单的、统一的操作机制

需定义简单的,语义明确的,业务无关的,恰当稳妥的统一的访问方式。

4.3、容错

控制好单点故障,确保数据安全。

4.4、可横向扩展

可便捷扩容。

5、如何实现?

成熟的消息队列中间件产品太多了,族繁不及备载。

成熟产品经过验证,接口规范,可扩展性强。

结合事业环境因素、组织过程遗产、实施运维考虑、技术路线考虑、开发人员情况等原因综合考虑,基于Redis自己做一个是最可行的选择。

如何做呢?

请听下回分解。

时间: 2024-10-15 03:55:18

基于Redis实现分布式消息队列(1)的相关文章

基于Redis实现分布式消息队列(汇总目录)

基于Redis实现分布式消息队列(1)– 缘起 http://blog.csdn.net/stationxp/article/details/45595733 基于Redis实现分布式消息队列(2)– 分布式消息队列功能设计 http://blog.csdn.net/stationxp/article/details/45596619 基于Redis实现分布式消息队列(3)– Redis功能分析 http://blog.csdn.net/stationxp/article/details/457

[转载] 基于Redis实现分布式消息队列

转载自http://www.linuxidc.com/Linux/2015-05/117661.htm 1.为什么需要消息队列?当系统中出现“生产“和“消费“的速度或稳定性等因素不一致的时候,就需要消息队列,作为抽象层,弥合双方的差异. 举个例子:业务系统触发短信发送申请,但短信发送模块速度跟不上,需要将来不及处理的消息暂存一下,缓冲压力. 再举个例子:调远程系统下订单成本较高,且因为网络等因素,不稳定,攒一批一起发送. 再举个栗子,交互模块5:00到24:00和电商系统联通,和内部ERP断开.

基于Redis实现分布式消息队列(3)

1.Redis是什么鬼? Redis是一个简单的,高效的,分布式的,基于内存的缓存工具. 假设好服务器后,通过网络连接(类似数据库),提供Key-Value式缓存服务. 简单,是Redis突出的特色. 简单可以保证核心功能的稳定和优异. 2.性能 性能方面:Redis是足够高效的. 和Memecached对比,在数据量较小大情况下,Redis性能更优秀. 数据量大到一定程度的时候,Memecached性能稍好. 简单结论:但总体上讲Redis性能已经足够好. // Ref: Redis性能测试

基于Redis实现分布式消息队列(2)

1.消息队列需提供哪些功能? 在功能设计上,我崇尚奥卡姆剃刀法则. 对于消息队列,只需要两个方法: 生产 和 消费. 具体的业务场景是任务队列,代码设计如下: public abstract class TaskQueue{ private final String name ; public String getName(){return this.name;} public abstract void addTask(Serializable taskId); public abstract

基于Redis实现分布式消息队列(4)

1.访问Redis的工具类 public class RedisManager { private static Pool<Jedis> pool; protected final static Logger logger = Logger.getLogger(RedisManager.class); static{ try { init(); } catch (Exception e) { e.printStackTrace(); } } public static void init()

基于redis的延迟消息队列设计

需求背景 用户下订单成功之后隔20分钟给用户发送上门服务通知短信 订单完成一个小时之后通知用户对上门服务进行评价 业务执行失败之后隔10分钟重试一次 类似的场景比较多 简单的处理方式就是使用定时任务 假如数据比较多的时候 有的数据可能延迟比较严重,而且越来越多的定时业务导致任务调度很繁琐不好管理. 队列设计 目前可以考虑使用rabbitmq来满足需求 但是不打算使用,因为目前太多的业务使用了另外的MQ中间件. 开发前需要考虑的问题? 及时性 消费端能按时收到 同一时间消息的消费权重 可靠性 消息

灵感来袭,基于Redis的分布式延迟队列

延迟队列 延迟队列,也就是一定时间之后将消息体放入队列,然后消费者才能正常消费.比如1分钟之后发送短信,发送邮件,检测数据状态等. Redisson Delayed Queue 如果你项目中使用了redisson,那么恭喜你,使用延迟队列将非常的简单. 基于Redis的Redisson分布式延迟队列(Delayed Queue)结构的RDelayedQueue Java对象在实现了RQueue接口的基础上提供了向队列按要求延迟添加项目的功能.该功能可以用来实现消息传送延迟按几何增长或几何衰减的发

基于Docker搭建分布式消息队列Kafka

本文基于Docker搭建一套单节点的Kafka消息队列,Kafka依赖Zookeeper为其管理集群信息,虽然本例不涉及集群,但是该有的组件都还是会有,典型的kafka分布式架构如下图所示.本例搭建的示例包含Zookeeper + Kafka + Kafka-manger #获取镜像 ·         zookeeper镜像:zookeeper:3.4.9 ·         kafka镜像:wurstmeister/kafka:0.10.2.0 ·         kafka-manager

Netty构建分布式消息队列(AvatarMQ)设计指南之架构篇

目前业界流行的分布式消息队列系统(或者可以叫做消息中间件)种类繁多,比如,基于Erlang的RabbitMQ.基于Java的ActiveMQ/Apache Kafka.基于C/C++的ZeroMQ等等,都能进行大批量的消息路由转发.它们的共同特点是,都有一个消息中转路由节点,按照消息队列里面的专业术语,这个角色应该是broker.整个消息系统通过这个broker节点,进行从消息生产者Producer到消费者Consumer的消息路由.当然了,生产者和消费者可以是多对多的关系.消息路由的时候,可以