资讯频道 → 编程语言
阅读更多

6顶
0踩

编程语言

原创新闻 Disque：Redis作者新开发的消息队列

2015-03-17 17:30 by 副主编 mengyidan1988 评论(3) 有6966人浏览
Disque redis

声明：ITeye资讯文章的版权属于ITeye网站所有，严禁任何网站转载本文，否则必将追究法律责任！

[刘江/文]Redis的作者Salvatore Sanfilippo（网名Antirez）今天发表了一篇新博客文章，详细介绍了自己几个月以来在晚上和周末开发的新项目——Disque。这个项目今年1月份Antirez曾经在邮件列表中透露过，现在看来已经离正式发布不远了。

Disque是一个分布式的消息队列。与Redis有单结点和分布式模式不同，单一Disque结点也是只有一个结点的集群。它是一个AP系统，也就是具有Availability（可用性）和Partition tolerance（分区容错性）。另外它能在各种情形下保持高扩展性：无论是多生产者和多消费者处理多队列，还是所有生产者和消费者都在一个队列。

另外，Disque的设计中有一点重大牺牲，就是只尽力提供而不保证消息的排序。

Antirez还通过回答Adrian Colyer（AspectJ的作者，曾任SpringSource CTO，后来有人指出，Antirez记错了，这些问题是Jacques Chester提出的）在Hacker News上某次讨论（但这一讨论没有查到）中所提问题的方式，更详细地描述了Disque的特性：
  • 消息发送可以选择至少一次或者最多一次。
  • 消息需要消费者确认。
  • 如果没有确认，会一直重发，直至到期。确认信息会广播给拥有消息副本的所有结点，然后消息会被垃圾收集或者删除。
  • 队列是持久的。
  • Disque默认只运行在内存里，持久性是通过同步备份实现的。
  • 队列为了保证最大吞吐量，不是全局一致的，但会尽力提供排序。
  • 在压力大的时候，消息不会丢弃，但会拒绝新的消息。
  • 消费者和生产者可以通过命令查看队列中的消息。
  • 队列尽力提供FIFO。
  • 一组master作为中介，客户端可以与任一结点通信。
  • 中介有命名的队列，无需消费者和生产者干预。
  • 消息发送是事务性的，保证集群中会有所需数量的副本。
  • 消息接收不是事务性的。
  • 消费者默认是接收时是阻塞的，但也可以选择查看新消息。
  • 生产者在队列满时发新消息可以得到错误信息，也可以让集群异步地复制消息。
  • 支持延迟作业，粒度是秒，最久可以长达数年。但需要消耗内存。
  • 消费者和生产者可以连接不同的结点。

开发初衷

Antirez之所以动念开发Disque，是因为看到很多人用Redis来处理队列，但这样做的优势和劣势都很明显：Redis很快、易用而且很多基础设施里已经在用；但是Redis的高可用性/集群特性的设计完全偏向可变数据结构，这与不可变的消息非常不同，并非最佳方案。

消息中介重要的功能是保证至少一次或者最多一次发送消息，而且前者更重要。Antirez开始想通过少量修改Redis来实现，但几天后发现客户端算法太复杂了。Redis已经有很多功能，再增加功能并非什么好主意。何况消息队列的运作方式与Redis很不同。

那么，是不是可以新开发一个消息队列呢？

世界上已经有很多消息队列了，新做一个有价值吗？Antirez想，既然有这么多人用Redis来处理消息队列，已有的方案看上去要么太简单要么太复杂，其中必有机会，于是他动手了。

开发过程

他头一次没有直接上来就写代码，而是花了几个星期思考设计，尝试从用户角度理解什么样的消息队列会让人更爽。主要的使用场景没变：延迟作业。Disque是通用系统，但主要针对的问题，是发送可能要处理的作业的消息。如果有什么违背了这一场景，就会被干掉。

设计有了，Antirez直接从Redis代码入手。幸运的是Redis部分就是编写C分布式系统的一个框架。协议、网络库、客户端处理、结点到结点的消息总线已经有了，无需重头再写。但他又不想影响Redis本身，于是采取了比较实际的办法：开一个Redis分支，然后将Redis专用的东西全部删掉，只剩一个框架，再开始实现设计。

到目前为止，他已经完成了80%左右的工作，还剩下AOF硬盘持久性没做，此外还需要对API做一些改善。

让我们期待他尽快放出代码吧。

Hacker News上Parse.ly的CTO Andrew Montalenti(@pixelmonkey )将Disque和Kafka做了比较：

引用
设计上AP和部分排序都很类似。但Disque会在发送完成后垃圾收集数据，而Kafka在SLA/TTL中保持所有消息，允许重新处理。Disque在服务器端处理最多一次，而Kafka是由客户端处理的。


Blekko的工程副总Chuck Mcmanis（@ChuckMcM）也给出了自己的经验：

引用
开发这样的系统，我的建议是：永远不要依赖时间，总是假设至少一次，而且开发内置的错误检查和更正机制，这样在消息协议里有两个或者多个不变量违反时，可以从消息流中计算出正确结果。


本文来自刘江的博客。
6
顶
0
踩
评论 共 3 条 请登录后发表评论
3 楼 yixiandave 2015-03-19 17:14
sdieskz123 写道
可以先把Redis3正式版做出来，在做这个也不迟

等3.0等哭了
2 楼 sdieskz123 2015-03-19 13:05
可以先把Redis3正式版做出来，在做这个也不迟
1 楼 james_lover 2015-03-17 17:50
kafka已经不错了，metaQ也可以啊，又一个轮子。

发表评论

您还没有登录,请您登录后再发表评论

相关推荐

  • disque：Disque是一个分布式消息代理

    Disque，内存中的分布式作业队列 Disque是一项正在进行的实验，目的是构建一个分布式的内存中消息代理。 它的目标是捕获“ Redis作为作业队列”用例的本质，该用例通常是使用阻止列表操作来实现的，并通过简单的方法...

  • Disque：Redis之父新开源的分布式内存作业队列

    Disque是Redis之父Salvatore Sanfilippo新开源的一个分布式内存消息代理。它适应于“Redis作为作业队列”的场景，但采用了一种专用、独立、可扩展且具有容错功能的设计，兼具Redis的简洁和高性能，并且用C语言实现为...

  • Redis实现消息队列的4种方案

    原文链接：Redis实现消息队列的方案 Redis作为内存中的数据结构存储，常用作数据库、缓存和消息代理。它支持数据结构，如 字符串，散列，列表，集合，带有范围查询的排序集（sorted sets），位图（bitmaps），超级...

  • Redis能否用作MQ消息队列？

    如果你的业务需求足够简单，想把 Redis 当作队列来使用，肯定最先想到的就是使用 List 这个数据类型。 因为 List 底层的实现就是一个「链表」，在头部和尾部操作元素，时间复杂度都是 O(1)，这意味着它非常符合消息...

  • Redis作者又一大作：Disque分布式内存队列（一）

    导读：Disque 是 Redis 之父 Salvatore Sanfilippo 新开源的一个分布式内存消息队列。本文是作者编写的该软件设计和使用的说明。Disque ...

  • 消息队列中为什么不用redis作为队列

    文章目录1 引言1.1 Redis中List队列1.1.1 简单使用1.1.2 解决cpu空转问题1.1.3 Redis阻塞式拉取1.2 Redis发布订阅1.2.1 简单使用1.2.2 发布订阅的缺点1.3 Redis中的Stream1.3.1 简单使用1.3.2 stream阻塞拉取1.3.3 ...

  • Redis做消息队列时与专业的消息队列的差别

    有些人认为 Redis 很轻量，用作队列很方便。但有些人也认为 Redis 会「丢」数据，最好还是用「专业」的队列中间件更稳妥。 那你觉得究竟哪种方案更好呢？ 下面，我就和大家聊一聊把 Redis 当作队列，究竟是否合适...

  • 基于Redis的Stream类型的完美消息队列解决方案（全）

    文章目录1 概述2 追加新消息，XADD，生产消息3 从消息队列中获取消息，XREAD，消费消息4 消息ID说明5 消费者组模式，consumer group6 Pending 等待列表7 消息转移8 坏消息问题，Dead Letter，死信问题9 信息监控，...

  • java版直播间源码-disque-module:Disque移植为Redis模块

    Disque，一个内存中的分布式作业队列 Disque 是一项正在进行的实验，旨在构建分布式、内存中的消息代理。 它的目标是捕捉通常使用阻塞列表操作实现的“Redis 作为作业队列”用例的本质，并将其移动到一个临时的、自...

  • Redis实现消息队列

    BRPOP，从队列中取出消息，阻塞模式 就是一个典型的基于FIFL队列的解决方案。其中LPUSH是生产者做的事，而BRPOP是消费者做的事。 优点： 实现简单 Reids支持持久化消息，意味着消息不会丢失，可以重复查看...

  • Redis Streams (消息队列)

    文章目录什么是 Redis Stream？Redis Stream 的特点Redis Stream 的相关命令Streams 消息太多了怎么办？设置 Stream 的上限怎么避免消息丢失？...Redis Stream 是 Redis 5.0 版本新增加的数据结构。

  • 作为8年经验的资深后端，让我来聊聊Redis能不能当队列来使用

    支持发布 / 订阅，支持多组生产者、消费者处理消息消费者下线，数据会丢失不支持数据持久化，Redis 宕机，数据也会丢失消息堆积，缓冲区溢出，消费者会被强制踢下线，数据也会丢失有没有发现，除了第一个是优点之外...

  • 【消息队列之Disque 】

     Disque is ongoing experiment to build a distributed, in memory, message broker. Its goal is to capture the essence of the "Redis as a jobs queue" use case, which is usually implemented ...

  • redis和mysql实现消息队列_基于Redis实现消息队列的典型方案

    基于Redis实现消息队列典型方案1 概述2 基于List的 LPUSH+BRPOP 的实现3 PUB/SUB，订阅/发布模式4 基于SortedSet有序集合的实现5 基于 Stream 类型的实现6 其他实现1 概述消息队列，Message Queue，常用于解决并发...

  • Redis消息队列和KafKa优劣对比

    Redis消息队列和KafKa优劣对比 redis 消息推送（基于分布式 pub/sub）多用于实时性较高的消息推送，并不保证可靠。 其他的mq和kafka保证可靠但有一些延迟（非实时系统没有保证延迟）。redis-pub/sub断电就清空，而...

  • mysql消息队列推送到redis_Redis实现消息队列之发布订阅模式

    发布订阅(pub/sub)是一种消息通信模式：发送者(pub)在某一频道发送消息，订阅者(sub)接收消息。发布订阅模式类似与微博关注，比如说博主mango被张三、李四、王五关注，那么mango发一篇微博的时候张李王三人都会从...

  • 完整的污水处理项目：WinCC 7.0带西门子300程序及中文注释的工艺流程

    内容概要：本文详细介绍了一个完整的污水处理自动化控制系统，该系统基于WinCC 7.0和西门子S7-300 PLC构建。文中涵盖了从数据采集、处理到报表生成的全过程，尤其强调了详细的中文注释和实用的技术细节。具体包括：PLC程序中的液位值滤波、WinCC画面中的阀门开度设置校验、报表模块的时间戳命名技巧以及报警记录的画面分层显示等。此外，还介绍了工艺流程图的动态效果、PID控制参数整定、数据归档处理等多个方面的技术和实践经验。 适用人群：从事自动化控制领域的工程师和技术人员，尤其是熟悉WinCC和西门子PLC的从业者。 使用场景及目标：适用于污水处理厂或其他类似工业环境的自动化控制系统设计与维护。主要目标是提高系统的可靠性和可维护性，确保操作的安全性和高效性。 其他说明：本文不仅提供了具体的代码实现和配置方法，还分享了许多宝贵的实战经验和注意事项，如防止误操作的设计、优化系统性能的方法等。这些内容对于理解和掌握工业自动化控制系统的实际应用非常有帮助。

  • 2025年中央电大计算机专业毕业论文.doc

    2025年中央电大计算机专业毕业论文.doc

  • COMSOL空气流注放电模型——集成针-针电极及Helmholtz光电离过程等离子体模拟新范式

    内容概要：本文详细介绍了如何利用COMSOL的等离子体模块构建针-针电极间的空气流注放电模型。主要内容涵盖了几何结构的定义、物理场配置（如电子、正负离子的载流子选择）、化学反应的设定（包括21组带电粒子反应）以及Helmholtz光电离过程的具体实现方法。文中还提供了多个代码片段用于解释各个步骤的操作方式，并强调了求解器配置和边界条件处理的关键点。此外，作者分享了一些实用的小技巧，如初始步长设置、网格细化等，以确保模型能够稳定收敛并得到合理的仿真结果。 适合人群：从事等离子体物理研究的专业人士，特别是那些对高压放电现象感兴趣的科研工作者和技术人员。 使用场景及目标：适用于希望深入了解和模拟针-针电极间空气流注放电行为的研究项目。通过该模型可以更好地理解电场分布、粒子密度变化等微观物理过程，从而为实际工程应用提供理论支持。 阅读建议：由于涉及较多的技术细节和数学公式，建议读者具备一定的电磁学、流体力学基础知识，并且最好有一定的COMSOL软件使用经验。同时，在实践中可以根据自己的研究方向调整模型参数进行探索。

  • 组态王仿真学习案例：石灰石断烧系统详解，实时历史曲线记录、报表分析与报警管理一网打尽，入门到进阶全功能展示

    内容概要：本文详细介绍了利用组态王进行石灰石煅烧系统的仿真开发，涵盖实时曲线绘制、报警系统配置、报表生成功能等多个方面。文章从实际案例出发，通过具体的代码片段和操作步骤，讲解了如何实现温度PID控制、设备联锁、能源统计等功能。同时，作者分享了许多实践经验，如解决曲线不刷新问题、优化报警逻辑、提高报表生成效率等，帮助读者快速掌握组态王的核心技术和应用场景。 适合人群：对工业自动化感兴趣的初学者以及希望深入了解组态王使用的工程师。 使用场景及目标：适用于需要构建工业控制系统仿真模型的学习者或开发者，旨在通过实例演练提升对组态王的理解和运用能力，最终能够独立完成类似项目的开发。 其他说明：文中提供了丰富的代码示例和技术细节，有助于读者更好地理解和实践。此外，还特别强调了一些常见的错误和注意事项，如控件命名规范、数据源绑定规则等，确保项目顺利实施。

Global site tag (gtag.js) - Google Analytics