这个问题是因为我看到一些提及（例如this）使用消息传递软件，如ZeroMQ与Redis，但我一直听说Redis本身就是一个消息系统。因此，如果Redis与其他消息系统一起使用，是否意味着Redis本身作为消息系统时存在一些严重缺陷？
虽然我清楚Redis用于缓存和发布/订阅的用途，但不清楚Redis是否可以代替完整的消息系统，如JMS、AMQP或ZeroMQ。
不考虑符合标准的方面，仅关注功能/特性，Redis是否支持消息系统所需的所有消息模式/模型？
我所说的消息模式是：
虽然我清楚Redis用于缓存和发布/订阅的用途，但不清楚Redis是否可以代替完整的消息系统，如JMS、AMQP或ZeroMQ。
不考虑符合标准的方面，仅关注功能/特性，Redis是否支持消息系统所需的所有消息模式/模型？
我所说的消息模式是：
- RPC/请求-响应（使用ActiveMQ/JMS的example和使用RabbitMQ/AMQP的another）
- 管道/工作队列（每个消息只消费一次或最多一次）
- 广播（所有订阅频道的人）
- 组播（基于消费者选择器在服务器上过滤消息）
- 还有其他的消息模式吗？
如果有，那么Redis似乎可以同时解决两个（可能更多）方面：缓存和消息传递。
我从一个Java / Java EE服务器支持的Web应用程序的角度来看待这个问题。我不是从概念验证的角度来看待这个问题，而是从大规模软件开发的角度来看待这个问题。
Edit1:
用户：791406提出了一个有效的问题：
"谁在乎redis是否支持这些模式; redis是否能满足您的SLA和QoS需求?"
我认为将此详细信息作为问题的一部分而不是在评论部分中提供更好。
我的当前需求与SLA和QOS无关，而更多地涉及选择一种工具（消息传递），即使在未来我的要求（合理地）增长时也可以使用。 我首先从简单的要求开始，我们都知道要求往往会增长。 而且不，我不是在寻找一个可以完成所有工作的工具。 我只想知道Redis是否能够满足像ActiveMQ/RabbitMQ这样的消息传递系统通常期望的要求。当然，如果我的SLA/QOS需求极端/偏离常规，我需要获取一个特殊的工具来满足这些要求。例如：在某些情况下，由于特定的SLA要求，可能会选择ZeroMQ而不是RabbitMQ。我不是在谈论这些特殊要求。我关注的是平均企业需求。基于我的一点了解，我担心Redis虽然可以用作今天我的消息传递需求的基本工具，但它可能不是未来真正消息传递工作的正确工具。我有使用ActiveMQ/RabbitMQ等消息传递系统的经验，知道它们可以用于简单到（合理地）复杂的消息传递需求。
编辑2：
Redis的网站提到"Redis经常被用作消息服务器", 但如何实现消息传递模式并不清楚。
Salvatore sanfilippo提到Redis用户倾向于将其用作数据库，作为消息总线或缓存。它在“消息总线”方面的服务程度未明确。
当我试图找出JMS所不支持的Redis消息需求时，我发现了一些Redis支持但JMS不支持的功能：模式匹配订阅，即客户端可以订阅符合给定模式的通道名称以接收所有发送到该模式匹配的通道的消息。
结论:
我决定使用JMS来满足我的消息需求，并使用Redis进行缓存。
MULTI/EXEC的更多信息：http://redis.io/topics/transactions。如果在`EXEC`之后某些命令失败，则有些情况下以前的命令仍然会被提交，而不会回滚；这是故意设计的，因为Redis更注重性能而非可靠性。 - raffian