5

在过去的 9 个月里，我一直在从事 CQRS 项目（我的第一个项目），这是一个沉重的学习曲线。我目前在我的写入模型中使用 JOliver 出色的 EventStore，并在我的读取模型中使用 PostGresSql。

我的读数据库和写数据库都在同一台机器上，这意味着当对写数据库进行更改时，在同一个同步调用中对读模型进行更改。

当我学习 CQRS 时，我觉得这是最好的方法，因为我没有使用过 MassTransit、NServiceBus 等消息队列/服务总线框架的经验。

现在，我的大部分架构都已到位，可以引入消息队列框架。

今天，我遇到了 Redis MQ，它是 ServiceStack 的一部分，因为我们已经将 ServiceStack 用于基于 Rest 的 HTTP 客户端，这似乎是正确的方法。

我的问题更多是关于了解我需要知道什么（或者如果我有任何误解）来实现 Redis MQ 以及 Redis MQ 是否是正确的选择？

现在据我了解，我将使用 Redis MQ 作为写入和读取数据库之间的持久队列。一旦我的事件存储记录了我的域中发生的事情，它就会发布到 Redis MQ。侦听事件/消息的服务将从 Redis MQ 接收事件/消息，一旦它处理了它（即更新或写入读取模型），通知/响应将返回到事件存储以告诉事件存储消息已被侦听器/订阅者接收并处理。

这听起来正确吗？

Redis MQ 架构也能给我 NSB、RavenDB、MassTransit 等提供的一切吗？

此外，我将部署到 Windows 2008 和 2003 服务器。Redis 对于这些操作系统是否稳定？

4

3 回答 3

3

我认为 Redis 中消息队列的 ServiceStack 实现更适合作业队列场景——它将消息推送到 Redis 列表的末尾，然后使用 Redis pub-sub 通知监听订阅者有一条消息要从队列。任何消费者都会竞争消息。

对于事件溯源，您可能对 RabbitMQ 提供的一种扇出或基于主题的消息拓扑更感兴趣，但这并不妨碍您自己使用 Redis 数据结构构建这类东西。

于 2012-12-20T15:23:27.947 回答
2

你可能对我在 GitHub 上的一个小项目感兴趣，它是一个使用 Redis 的 NServiceBus 的队列和持久性实现。https://github.com/mackie1001/NServicebus.Redis

我不会称它为生产就绪，我想将它移植到 NSB 4 并进行一些彻底的测试，但它的实质已经完成。

于 2013-02-24T21:59:55.060 回答
2

现在据我了解，我将使用 Redis MQ 作为写入和读取数据库之间的持久队列。

是的，这是正确的。

一旦我的事件存储记录了我的域中发生的事情，它就会发布到 Redis MQ。

是的，这可以通过多种方式完成。它可以作为持续到事件存储的事务的一部分发生，或者您可以有一个带外进程，该进程不断地从事件存储发布事件。

通知/响应返回到事件存储，告诉事件存储消息已被侦听器/订阅者接收和处理。

返回给事件发布者的响应通常被省略。这真正将发布者与订阅者分离。您假设一旦消息发布，所有感兴趣的订阅者都会处理它。如果发生了什么事，应该记录一个错误。

Redis MQ 架构也能给我 NSB、RavenDB、MassTransit 等提供的一切吗？

我没有运行 Redis MQ 的经验，但我知道 Redis 支持 pub/sub，这是 NSB 和 MassTransit 的价值主张之一（而不是说准系统 MSMQ）。MT 和 NSB 在 pub/sub 之外提供的是sagas，而且 Redis MQ 似乎至少不支持那些开箱即用的东西。你可能永远不需要 sagas，所以这不应该自动成为一种威慑。RavenDB 不是消息队列，因此不适用于此处。

此外，我将部署到 Windows 2008 和 2003 服务器。Redis 对于这些操作系统是否稳定？

我在 2008 R2 上运行过 Redis，它一直很稳定，所以我认为 Redis MQ 也会很稳定。

于 2012-12-10T17:57:11.903 回答