Command-Query Responsibility Segregation（CQRS）
RabbitMQを使ってアプリケーションの読み取り操作と書き込み操作を分離するCQRSパターンを適用します。データ量の多いシステムのスケーラビリティとパフォーマンスを向上させます。
「Command-Query Responsibility Segregation（CQRS）」はCoddyKit上の無料RabbitMQ Messaging & Async Systemsレッスンです。 これはレッスン3/4です。 下記で完全なレッスンを無料で読むことができます。その後、ブラウザ内の組み込みコードエディタと24時間対応の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
よくある質問
「Command-Query Responsibility Segregation（CQRS）」レッスンは無料ですか？
はい。「Command-Query Responsibility Segregation（CQRS）」の完全なテキストはこのウェブで無料で読めます。インタラクティブに演習し（組み込みコードエディタと24時間対応のAIチューター）、RabbitMQ Messaging & Async Systemsコースの残りをアンロックするには、CoddyKit PROにアップグレードしてください。 RabbitMQ Messaging & Async Systemsコースには全4レッスンが含まれています。
「Command-Query Responsibility Segregation（CQRS）」で何を学びますか？
RabbitMQを使ってアプリケーションの読み取り操作と書き込み操作を分離するCQRSパターンを適用します。データ量の多いシステムのスケーラビリティとパフォーマンスを向上させます。 ブラウザで直接実行するハンズオンコードでRabbitMQ Messaging & Async Systemsを演習し、24時間対応のAIチューターがレッスンを進める中での質問に答えます。
RabbitMQ Messaging & Async Systemsを始めるのに経験は必要ですか？
事前経験は必要ありません。CoddyKitのRabbitMQ Messaging & Async Systemsは初級者から上級者向けに構成されているため、ここから始めるか最初から始めて、自分のペースで進むことができます。 これはレッスン3/4です。
「Command-Query Responsibility Segregation（CQRS）」レッスンにはどのくらい時間がかかりますか？
ほとんどのCoddyKitレッスンは約5～10分かかります。各レッスンはコンパクトでインタラクティブなので、着実に進歩し、ウェブとアプリ全体で正確に前回の場所から再開できます。
このRabbitMQ Messaging & Async Systemsレッスンでコードを書いて実行できますか？
はい。すべてのRabbitMQ Messaging & Async Systemsレッスンに組み込みコードエディタが含まれているため、ブラウザでリアルコードを書いて実行し、即座のAIフィードバックを取得できます。ローカル設定は不要です。
このコースのすべてのレッスン
- メッセージ処理における冪等性
- RabbitMQによるSagaパターン
- Command-Query Responsibility Segregation（CQRS）
- 信頼性の高い公開を実現するOutboxパターン