CQRS使用Redis MQ

JD.*_*JD. 5 nservicebus redis cqrs servicestack

在过去的9个月里,我一直致力于CQRS项目(我的第一个),这是一个沉重的学习曲线.我目前在我的写模型中使用JOliver优秀的EventStore,并使用PostGresSql作为我的阅读模型.

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

当我学习CQRS时,我觉得这是最好的方式,因为我没有使用消息队列/服务总线框架,如MassTransit,NServiceBus等.

我现在处于大部分架构的位置,以引入消息队列框架.

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

我的问题更多的是了解我需要知道什么(或者我是否有任何误解)来实现Redis MQ以及Redis MQ是否是正确的选择?

根据我的理解,我会将Redis MQ用作写入和读取数据库之间的持久队列.一旦我的事件存储记录了我的域中发生的事情,它就会发布到Redis MQ.监听事件/消息服务将从Redis的MQ接收事件/消息,一旦处理它(即更新或写入读取模式),通知/响应追溯到事件店里告诉事件存储的消息已被收听者/订阅者接收和处理.

这听起来不错吗?

Redis MQ架构也会为我提供NSB,RavenDB,MassTransit等提供的所有功能吗?

另外,我将部署到Windows 2008和2003服务器.Redis对于这些操作系统是否稳定?

eul*_*rfx 2

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

是的,这是正确的。

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

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

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

返回给事件发布者的响应通常被省略。这真正将发布者与订阅者脱钩。您假设消息一旦发布,所有感兴趣的订阅者都会处理它。如果发生某些情况,应记录错误。

Redis MQ 架构是否还能为我提供 NSB、RavenDB、MassTransit 等提供的一切?

我没有运行 Redis MQ 的经验,但我知道 Redis 支持 pub/sub,这是 NSB 和 MassTransit 的价值主张之一(而不是简单的 MSMQ)。MT 和 NSB 提供的超出 pub/sub 的功能都是传奇,而且 Redis MQ 似乎至少不支持开箱即用的功能。您可能永远不需要传奇,因此这不应自动成为一种威慑。RavenDB 不是消息队列,因此不适用于此处。

另外,我将部署到 Windows 2008 和 2003 服务器。Redis 对于这些操作系统稳定吗?

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