RabbitMQ Messaging & Async Systems · 강의

명령-조회 책임 분리(CQRS)

RabbitMQ를 사용하여 애플리케이션의 읽기 작업과 쓰기 작업을 분리하는 CQRS 패턴을 적용합니다. 데이터 집약적 시스템의 확장성과 성능을 개선합니다.

레슨 3/411개 단계

명령-조회 책임 분리(CQRS)은(는) CoddyKit의 무료 RabbitMQ Messaging & Async Systems 강의입니다. 이것은 4개 중 3번째 강의입니다. 아래에서 전체 강의를 무료로 읽을 수 있으며, 내장 코드 에디터와 24/7 AI 튜터와 함께 브라우저에서 직접 실습할 수 있습니다. 이 강의는 RabbitMQ Messaging & Async Systems 학습 경로의 일부이며, 진행 상황이 웹과 CoddyKit 앱에 동기화됩니다. RabbitMQ Messaging & Async Systems 강의에는 총 4개의 강의가 포함되어 있습니다.

이 강의의 일부는 아직 번역되지 않았으며 영어로 표시됩니다.

What is CQRS?

Ever wished your application could handle tons of writes and reads without slowing down? That's where CQRS comes in! It stands for Command-Query Responsibility Segregation.

CQRS is an architectural pattern that separates the operations for reading data from the operations for updating data. Think of it as having two specialized teams: one for taking orders and one for answering questions.

Understanding Commands

The "Command" side handles all requests that change the state of your application. These are actions like "CreateProduct", "UpdateOrderStatus", or "AddUser".

Commands are imperative: They tell the system to do something specific.
Commands are processed: They go through handlers that validate and execute the requested change.
Commands often trigger events: After a command is successfully processed, an event might be published.

Understanding Queries

The "Query" side is all about retrieving data. These are requests like "GetProductDetails", "ListAllOrders", or "FindUsersByLocation".

Queries are declarative: They ask for information without changing anything.
Queries use optimized models: Data is often stored in a read-optimized format, perfect for fast retrieval.
Queries return data: They provide the information requested by the user interface or other services.

Benefits of CQRS

Separating commands and queries offers several advantages, especially in complex systems:

Scalability: You can scale read and write services independently. Read models often get more traffic.
Performance: Read models can be highly optimized for queries (e.g., de-normalized data, different databases).
Flexibility: Different data stores can be used for reads (e.g., NoSQL for speed) and writes (e.g., SQL for consistency).
Simplicity: Each model is simpler, focused on its specific task.

RabbitMQ's Role in CQRS

RabbitMQ is an excellent fit for implementing CQRS, particularly for the command side. When a command is issued, it can be published as a message to a RabbitMQ queue.

Consumers (command handlers) then pick up these messages and execute the business logic to update the write model. This makes command processing asynchronous and decoupled.

Producer: Update Product Name

Let's imagine we want to update a product's name. We'll send a "UpdateProductNameCommand" message to RabbitMQ. Here's a simple Java producer example:

import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;

public class CommandProducer {
    private final static String QUEUE_NAME = "product_commands";

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost"); // Assuming RabbitMQ is local

        try (Connection connection = factory.newConnection();
             Channel channel = connection.createChannel()) {

            channel.queueDeclare(QUEUE_NAME, false, false, false, null);

            String commandJson = "{\"commandType\":\"UpdateProductName\", \"productId\":\"P123\", \"newName\":\"New Awesome Product\"}";
            channel.basicPublish("", QUEUE_NAME, null, commandJson.getBytes("UTF-8"));
            System.out.println(" [x] Sent command: '" + commandJson + "'");
        }
    }
}

Consumer: Process Product Update

On the other side, a consumer service (our command handler) listens for these commands. When it receives an "UpdateProductName" command, it updates the authoritative write model (e.g., a SQL database).

This consumer represents the "write" side of our CQRS architecture.

import com.rabbitmq.client.Channel;
import com.rabbitmq.client.Connection;
import com.rabbitmq.client.ConnectionFactory;
import com.rabbitmq.client.DeliverCallback;

public class CommandConsumer {
    private final static String QUEUE_NAME = "product_commands";

    public static void main(String[] argv) throws Exception {
        ConnectionFactory factory = new ConnectionFactory();
        factory.setHost("localhost");

        Connection connection = factory.newConnection();
        Channel channel = connection.createChannel();

        channel.queueDeclare(QUEUE_NAME, false, false, false, null);
        System.out.println(" [*] Waiting for commands. To exit press CTRL+C");

        DeliverCallback deliverCallback = (consumerTag, delivery) -> {
            String message = new String(delivery.getBody(), "UTF-8");
            System.out.println(" [x] Received command: '" + message + "'");
            // In a real app, parse JSON, validate, update write model (e.g., database)
            System.out.println(" [x] Product write model updated for: " + message.split(":")[2].split(",")[0]);
        };
        channel.basicConsume(QUEUE_NAME, true, deliverCallback, consumerTag -> { });
    }
}

Synchronizing Read Models

After the write model is updated, how does the read model get the new data? This is often done by publishing events.

When a product name changes, the command handler can publish a "ProductNameUpdatedEvent" to another RabbitMQ exchange. A separate service (a projector or denormalizer) subscribes to this event and updates the read-optimized data store.

Write Model: Optimized for transactional consistency.
Read Model: Optimized for query performance.

Fast Data Retrieval

With the read model now updated, client applications can query it directly. Since this model is specifically designed for reads, queries are often much faster and simpler.

For example, a product catalog service would query this read model to display product details, without ever touching the complex transactional write model.

CQRS Core Principle

Consider the architecture we've discussed. What is the primary benefit of separating read and write models in CQRS?

인터랙티브 레슨에서 답해보세요

CQRS: Scalability & Performance

In this lesson, you learned about Command-Query Responsibility Segregation (CQRS). We saw how it separates data modification (commands) from data retrieval (queries), often using different data models.

RabbitMQ plays a crucial role by enabling asynchronous processing of commands, allowing for independent scaling and optimization of your application's read and write functionalities. This pattern is powerful for data-intensive and high-performance systems.

무료로 시작

AI 튜터와 함께 RabbitMQ Messaging & Async Systems을(를) 배우세요 — 무료

브라우저에서 실제 코드를 작성하고 실행하며, 24/7 AI 튜터로부터 즉각적인 도움을 받고, 웹이나 앱에서 중단한 부분부터 계속 학습하세요.

코스: 11
레슨: 44

무료로 학습 시작 전체 코스 보기

자주 묻는 질문

“명령-조회 책임 분리(CQRS)” 강의는 무료인가요?

네 — “명령-조회 책임 분리(CQRS)” 전체 내용을 이 웹사이트에서 무료로 읽을 수 있습니다. 인터랙티브하게 실습하려면(내장 코드 에디터와 24/7 AI 튜터), CoddyKit PRO로 업그레이드하면 RabbitMQ Messaging & Async Systems 강의 전체를 잠금 해제할 수 있습니다. RabbitMQ Messaging & Async Systems 강의에는 총 4개의 강의가 포함되어 있습니다.

“명령-조회 책임 분리(CQRS)”에서 뭘 배우나요?

RabbitMQ를 사용하여 애플리케이션의 읽기 작업과 쓰기 작업을 분리하는 CQRS 패턴을 적용합니다. 데이터 집약적 시스템의 확장성과 성능을 개선합니다. 브라우저에서 직접 실행하는 실습 코드로 RabbitMQ Messaging & Async Systems을(를) 배우며, 24/7 AI 튜터가 강의를 진행하면서 질문에 답변해줍니다.

RabbitMQ Messaging & Async Systems을(를) 시작하는 데 경험이 필요한가요?

사전 경험은 필요하지 않습니다. CoddyKit의 RabbitMQ Messaging & Async Systems은(는) 초급자부터 고급 학습자까지를 위해 구성되어 있으므로, 여기서 시작하거나 처음부터 시작할 수 있으며 자신의 속도대로 진행할 수 있습니다. 이것은 4개 중 3번째 강의입니다.

“명령-조회 책임 분리(CQRS)” 강의는 얼마나 걸리나요?

대부분의 CoddyKit 강의는 약 5~10분이 소요됩니다. 각 강의는 간결하고 인터랙티브하여 꾸준한 진행이 가능하며, 웹과 앱에서 중단한 부분부터 바로 시작할 수 있습니다.

이 RabbitMQ Messaging & Async Systems 강의에서 코드를 작성하고 실행할 수 있나요?

네. 모든 RabbitMQ Messaging & Async Systems 강의에는 내장 코드 에디터가 포함되어 있으므로, 브라우저에서 바로 실제 코드를 작성하고 실행한 후 즉시 AI 피드백을 받을 수 있습니다 — 로컬 설정이 필요 없습니다.

이 강의의 모든 강의

← RabbitMQ Messaging & Async Systems(으)로 돌아가기