使用Redis实现JMS/AMQP消息传递模式

inq*_*One 18 java messaging jms amqp redis

这个问题是因为我碰到一些提到(如),有关使用邮件软件如ZeroMQ 非常久远的Redis,但我不断听到的Redis本身使用的通讯系统.因此,如果Redis与其他消息传递系统一起使用,那么当它作为消息传递系统使用时,它是否意味着Redis有一些严重的缺陷?

虽然我很清楚使用Redis进行缓存和发布/发布,但目前尚不清楚是否可以使用Redis 代替完整的消息系统,如JMS,AMQP或ZeroMQ.
仅仅依靠标准兼容性方面而只关注功能/特性,Redis是否为消息传递系统所需的所有消息传递模式/模型提供支持?

我所说的消息传递模式是:

  1. RPC/Request-reply( 使用ActiveMQ/JMS 的 示例和使用RabbitMQ/AMQP的另一个示例)
  2. 管道/工作队列(每次消息消耗一次和最多一次)
  3. 广播(每个人都订阅了频道)
  4. 组播(根据消费者的选择器过滤服务器上的消息)
  5. 任何其他消息模式?

如果是,那么Redis似乎同时解决了两个(可能更多)方面:缓存和消息传递.

我在由Java/Java EE服务器支持的Web应用程序的上下文中查看此内容.我不是从概念验证的角度来看这个,而是从大规模的软件开发角度来看.

Edit1:
用户:791406问了一个有效的问题:

"谁在乎redis是否支持这些模式; redis是否能满足您的SLA和QoS需求?"

我认为最好将这个细节作为问题的一部分,而不是在评论部分.

我目前的需求与SLA和QOS关系不大,更多的是选择我的工作(消息)工具,即使我的需求在未来(合理地)增长,我也可以使用.我首先从简单化的要求开始,我们都知道需求往往会增长.和NO,我不是在寻找一个工具,做这一切.我只是想知道Redis是否满足消息系统的预期要求,如ActiveMQ/RabbitMQ.当然,如果我的SLA/QOS需要极端/偏心,我需要一个特殊的工具来满足这一要求.例如:在某些情况下,由于特定的SLA要求,可以通过RabbitMQ选择ZeroMQ.我不是在谈论这种特殊要求.我专注于平均企业要求.

我害怕(基于我的一点理解)尽管redis可以用作当今我的消息传递需求的基本工具,但它可能是未来真正的消息传递工作的错误工具.我有使用ActiveMQ/RabbitMQ等消息传递系统的经验,并且知道它们可以用于简单到(合理)复杂的消息传递需求.

编辑2:

  1. redis网站提到"Redis经常被用作消息服务器"但是如何实现消息传递模式并不清楚.

  2. Salvatore sanfilippo提到Redis用户倾向于将其用作数据库,消息传递总线或缓存.它在多大程度上可以用作"消息传递总线"尚不清楚.

  3. 当我试图找出redis不支持的JMS的消息传递要求时,我遇到了Redis支持但JMS不支持的东西:模式匹配订阅,即客户端可以订阅glob样式模式以接收发送到的所有消息与给定模式匹配的通道名称.

结论:

我决定使用JMS来满足我的消息传递需求,并使用Redis进行缓存.

raf*_*ian 17

你有什么需要?

我认为你应该问自己的问题是"我需要什么样的消息来支持我的应用程序?" 在决定使用消息传递平台之前.谁在乎redis是否支持这些模式; redis会满足您的SLA和QoS需求吗?首先关注它,然后根据评估做出技术决策.

话虽如此,我会就如何做出决定提供我的意见......

高度可靠/持久/持久的消息
让我们采取一个极端的案例:说你正在建立一个交易或金融应用程序.此类应用程序需要严格的SLA,其中消息持久性,可靠性,一次性交付和持久性是至关重要的.使用redis作为此案例的消息传递主干可能是一个糟糕的选择,原因很多......

  • 消息重新发送(当sh*t击中风扇时)
  • redis关闭时的邮件存储复制
  • 消息事务(redis不能做XA)
  • 生产者/订户容错和断开弹性
  • 消息顺序排序
  • 经纪人关闭时发送消息(存储转发)
  • 单线程redis可能成为瓶颈

如果您的系统具有严格的SLA,那么肯定会出现部分或全部问题,那么您将如何处理这些限制?您可以围绕redis实现自定义代码来解决一些问题,但是当ActiveMq,WebsphereMQ和WebLogic JMS等成熟的消息传递平台提供持久性,可靠性和容错性时,为什么还要烦恼呢?您说您使用的是Java/Java EE堆栈,因此您可以使用一些最强大的可用消息框架,无论是开源还是商业.如果您正在进行金融交易,那么您需要考虑这些选项.

高性能/大型分布式系统消息传递
如果您正在构建一个社交网络或游戏平台,您希望性能高于可靠性,那么ZeroMq可能非常适合.它是一个套接字通信库,包含在类似消息传递的API中.它是分散的(没有经纪人),速度非常快,而且具有高弹性和容错能力.如果您需要执行N-to-N pub/sub与代理中介,流控制,消息持久性或点对点同步等操作,ZeroMq提供必要的工具和代码示例,以最少的代码完成所有操作,同时避免从头开始构建解决方案.它是用C语言编写的,但几乎每种流行语言都有客户端库.

希望有帮助......