Request/reply (RPC) hoạt động như thế nào trong RabbitMQ?

Question

Accepted Answer

**Request/reply (RPC)** qua RabbitMQ cho phép giao tiếp request-response kiểu đồng bộ sử dụng messaging — một client gửi một request và nhận một response qua một reply queue, dùng một **correlation ID** để khớp các response với các request. Đó là một mẫu hữu ích cho các cuộc gọi service-to-service.

## Cách RPC hoạt động trong RabbitMQ

```text
Mẫu RPC qua messaging:
  1. CLIENT gửi một message REQUEST, bao gồm:
     → một queue REPLY-TO (nơi response nên đi đến)
     → một CORRELATION ID (ID duy nhất để khớp response với request này)
  2. SERVER (consumer) xử lý request và gửi một RESPONSE đến reply-to queue,
     bao gồm cùng CORRELATION ID
  3. CLIENT nhận response từ reply queue của nó, khớp nó theo CORRELATION ID →
     ghép response với request gốc
→ request-response qua messaging bất đồng bộ
```

## Tại sao correlation ID quan trọng

```text
→ một client có thể có NHIỀU request đang chờ trên một reply queue → response đến lẫn lộn
→ CORRELATION ID khớp mỗi response với request của nó (response nào cho cuộc gọi nào)
→ không có nó, client không thể biết response nào trả lời request nào
```

## Các cân nhắc

```text
✓ TIMEOUT → client phải xử lý việc không có response (server có thể down/chậm) → đừng chờ
  mãi mãi
✓ Reply queue → một reply queue cho mỗi client (thường exclusive), hoặc tính năng direct-reply-to
✓ RPC qua messaging thêm độ trễ so với cuộc gọi trực tiếp → cân nhắc xem bất đồng bộ có chấp nhận được không
⚠️ ghép cặp thời gian của client và server (kiểu đồng bộ) → đôi khi messaging bất đồng bộ
  tốt hơn RPC
```

## Tại sao điều này quan trọng

Hiểu cách request/reply (RPC) hoạt động trong RabbitMQ là điều có giá trị bởi vì đó là một **mẫu messaging hữu ích cho giao tiếp service-to-service**, nên đó là kiến thức liên quan cho nhu cầu đó.

RPC qua RabbitMQ cho phép giao tiếp request-response kiểu đồng bộ dùng messaging, hữu ích khi các service cần response.

Hiểu **cách nó hoạt động** — một client gửi một request với một **reply-to queue** (nơi response đi đến) và một **correlation ID** (để khớp response), server xử lý và gửi một response đến reply queue với cùng correlation ID, và client nhận và khớp response theo correlation ID — làm rõ cơ chế cho request-response qua messaging bất đồng bộ.

Hiểu **tại sao correlation ID quan trọng** là insight then chốt: vì một client có thể có nhiều request đang chờ trên một reply queue (với response đến lẫn lộn), **correlation ID khớp mỗi response với request của nó** (báo cho client response nào trả lời cuộc gọi nào) — không có nó, client không thể ghép response với request, khiến correlation ID thiết yếu cho mẫu RPC.

Hiểu các **cân nhắc** — xử lý **timeout** (client phải xử lý việc không có response vì server có thể down hoặc chậm, không chờ mãi mãi), thiết lập reply queue (queue exclusive cho mỗi client hoặc direct-reply-to), độ trễ mà RPC thêm so với cuộc gọi trực tiếp, và lưu ý rằng RPC ghép cặp thời gian của client và server (nên đôi khi messaging bất đồng bộ tốt hơn giao tiếp đồng bộ kiểu RPC) — phản ánh việc dùng mẫu một cách chu đáo.

Hiểu RPC qua RabbitMQ cung cấp một cách để thực hiện giao tiếp request-response qua messaging (với các lợi ích tách rời và độ tin cậy của messaging), hữu ích cho một số kịch bản service-to-service, trong khi nhận ra khi nào messaging bất đồng bộ có thể tốt hơn.

Vì request/reply (RPC) qua RabbitMQ là một mẫu hữu ích cho giao tiếp request-response service-to-service (dùng reply queue và correlation ID) và hiểu cách nó hoạt động cùng các cân nhắc của nó là liên quan cho nhu cầu đó, nên hiểu cách RPC hoạt động trong RabbitMQ là kiến thức RabbitMQ có giá trị, liên quan thực tế — một mẫu hữu ích cho giao tiếp request-response qua messaging (với correlation ID khớp response với request), liên quan cho các cuộc gọi service-to-service, và phản ánh sự hiểu biết về khi nào messaging kiểu RPC phù hợp so với messaging bất đồng bộ thuần túy.