2012-12-10 4 views
5

저는 지난 9 개월 동안 무거운 학습 곡선이었던 CQRS 프로젝트 (첫 번째 작업)에 참여했습니다. 현재 JOliver의 우수한 EventStore를 쓰기 모델로 사용하고 있으며 PostGresSql을 읽는 모델로 사용하고 있습니다.Redis MQ를 사용하는 CQRS

내 읽기 및 쓰기 데이터베이스가 동일한 시스템에 있으므로 쓰기 데이터베이스가 변경되면 동일한 동기 호출에서 읽기 모델이 변경됩니다. 내가 CQRS를 배우는 것처럼

가 나는 등 MassTransit, NServiceBus 같은 메시지 큐/서비스 버스 프레임 워크와 아무 경험이 없기 때문에이 갈 수있는 가장 좋은 방법이라고 생각

나는의 대부분 지점에서 지금이다 내 아키텍처는 메시지 큐 프레임 워크를 소개합니다.

오늘 저는 ServiceStack의 일부인 Redis MQ를 보았습니다. 나머지 레퍼토리 기반 HTTP 클라이언트에 이미 ServiceStack을 사용하고 있기 때문에 이것이 올바른 방법이라고 생각됩니다.

내 질문은 Redis MQ를 구현하기 위해 내가 알아야 할 (또는 오해가있는 경우) 필요한 정보와 Redis MQ가 올바른 선택인지에 대한 질문입니다.

이제 Redis MQ를 쓰기 및 읽기 데이터베이스 사이의 내구성 큐로 사용할 것입니다. 내 이벤트 저장소가 내 도메인에서 어떤 일이 발생했음을 기록하면 Redis MQ에 게시합니다. 이벤트/메시지를 수신하는 서비스는 Redis MQ로부터 이벤트/메시지를 수신하고 일단 처리 (예 : 읽기 모델에 대한 업데이트 또는 쓰기)하면 알림/응답이 이벤트 저장소로 돌아가서 이벤트 저장소에 메시지가 청취자/가입자에 의해 수신되고 처리된다.

소리가 맞습니까?

또한 Redis MQ 아키텍처는 NSB, RavenDB, MassTransit 등이 제공하는 모든 것을 제공합니까?

또한 Windows 2008 및 2003 서버에 배포 할 예정입니다. Redis는 이러한 OS에서 안정적입니까?

답변

2

지금부터 알다시피, Redis MQ를 쓰기 및 읽기 데이터베이스 사이의 내구성 큐 으로 사용합니다.

예.

도메인에 내 이벤트 저장소에 이벤트가 발생 했음이 기록되면 Redis MQ에 게시됩니다.

예 및 여러 가지 방법으로 수행 할 수 있습니다. 이벤트 저장소에 지속되는 트랜잭션의 일부로 발생하거나 이벤트 저장소에서 지속적으로 이벤트를 공개하는 대역 외 프로세스를 가질 수 있습니다.

통보/응답 메시지가 수신기/가입자에 의해 수신되고 처리 된 이벤트 상점에게 다시 이벤트 저장소 간다.

일반적으로 이벤트 게시자에 대한 응답은 생략됩니다. 이것은 게시자와 구독자를 완전히 분리합니다. 메시지가 게시되면 모든 관심있는 가입자가 메시지를 처리한다는 가정을합니다.문제가 발생하면 오류를 기록해야합니다.

또한 Redis MQ 아키텍처는 NSB, RavenDB, MassTransit 등이 제공하는 모든 것을 제공합니까?

내가 레디 스 MQ를 실행 경험이 없어,하지만 난 레디 스가 NSB와 MassTransit의 가치 제안 중 하나입니다 술집/하위를 지원하는지 알고 (베어 본 MSMQ 말을 반대로). pub/sub 이상의 MT와 NSB가 sagas이고 Redis MQ가 최소한 상자에서 나온 것을 지원하는 것처럼 보이지는 않습니다. 당신은 자동적으로 억지력이되어서는 안되기 때문에 무용담을 필요로하지 않을 수도 있습니다. RavenDB는 메시지 대기열이 아니므로 여기서는 적용되지 않습니다.

또한 Windows 2008 및 2003 서버에 배포 할 예정입니다. Redis 은 이러한 OS에 안정적입니까?

2008 R2에서 Redis를 실행했고 안정적 ​​이었으므로 Redis MQ도 안정적이라고 생각합니다.

+0

귀하의 모든 도움에 감사드립니다. 내 경우에는 어떤 내구성 메시징 대기열을 사용해야할지 결정해야하지만, 며칠을 보내고 여전히 최선의 것을 배우는 것이 필요하다고 생각합니다. 너는 무엇을 제안 하겠는가? :) –

+1

프로덕션에서 가장 많이 사용한 것은 NSB + MSMQ이지만 MT는 동등하게 기능 할 수 있지만 워드 프로세서가 부족합니다. NSB의 라이센스가 일치하는지 확인하십시오. 레디 스 MQ는 흥미롭지 만 논평 할 수는 없습니다. 전반적으로 메시징이 인프라 관련 문제인지 더 잘 이해할 수 있도록 몇 가지 다른 방법을 시도해 보시고 앱의 나머지 부분에서 많이 익숙해 져서는 안됩니다. – eulerfx

+0

다시 한번 당신의 지혜에 감사드립니다. :) NSB가 제공하는 아이디어가 있습니다. Redis MQ가 실패한 메시지를 다시 시도하는 방법, 실패한 메시지를 보는 방법 또는 어떤 메시지를 처리해야하는지 확인하는 메시지 대기열을 보는 방법 등을 알아야합니다. NSB 라이센싱을 살펴볼 필요가 있습니다. 많은 메시징이 필요 없으며이 단계에서 읽기 및 쓰기 데이터베이스가 동일한 시스템에 있습니다. –

3

Redis의 메시지 대기열 구현 ServiceStack 구현이 작업 대기열 시나리오에 더 적합하다고 생각합니다. 즉, 메시지를 Redis 목록의 끝에 넣은 다음 수신자에게 메시지가 있음을 알리기 위해 Redis pub-sub를 사용합니다 큐에서 당기기. 모든 소비자가 메시지를 놓고 경쟁하게됩니다.

이벤트 소싱의 경우 RabbitMQ에서 제공하는 팬 아웃 또는 주제 기반 메시징 토폴로지에 관심이있을 수 있습니다. 사용자가 Redis 데이터 구조를 사용하여 그런 종류의 것을 직접 만들지 못하게하는 것은 아닙니다.

+1

답장을 보내 주셔서 감사합니다. 내 경우에는 도메인 모델 (쓰기)과 읽기 모델이 동기화되지 않도록하려는 경우에만 하나의 구독자 만 내 읽기 모델입니다. 이 경우 RedisMQ는 괜찮습니까? –

+2

그래, 현재의 RedisMQ 구현은 당신의 필요에 완벽합니다. – DanB

2

Redis를 사용하여 NServiceBus에 대한 대기열 및 지속성 구현 인 GitHub의 내 작은 프로젝트에 관심이있을 수 있습니다. https://github.com/mackie1001/NServicebus.Redis

나는 그것을 생산 준비라고 부르지 않고 NSB 4로 포팅하고 철저한 테스트를하고 싶지만 그 고기는 완성되었다.

+0

정보를 제공해 주셔서 감사합니다. –