Pipelining ใน Redis คืออะไรและควรใช้เมื่อไร?

Question

Accepted Answer

**Pipelining** ส่งหลายคำสั่ง Redis ใน network round-trip เดียว แทนที่จะรอ reply ของแต่ละคำสั่งก่อนส่งคำสั่งถัดไป มันเพิ่ม throughput อย่างมากเมื่อออกคำสั่งจำนวนมาก เพราะ network latency — ไม่ใช่ Redis เอง — มักเป็นคอขวด

## ปัญหา: latency ของ round-trip

```text
Normally each command is a request→reply round-trip:
  send GET → wait for reply → send GET → wait for reply → ... (N × network latency)
→ Redis processes each command in microseconds, but each round-trip adds network
  latency (e.g. 0.5ms). For 1000 commands, that's ~500ms JUST in waiting!
```

## Pipelining: batch คำสั่ง

```js
// send all commands at once, then read all replies — ONE round-trip
const pipeline = redis.pipeline();
for (const id of userIds) pipeline.get(`user:${id}`);
const results = await pipeline.exec();   // all replies returned together
// => 1000 commands in ~one round-trip instead of 1000 → dramatically faster
```

ไคลเอนต์ส่งหลายคำสั่งโดยไม่รอ จากนั้นอ่าน reply ทั้งหมดพร้อมกัน — ยุบ N round-trip ให้เหลือประมาณหนึ่ง เป็นการเพิ่มความเร็วอย่างมากสำหรับการดำเนินการจำนวนมาก

## Pipelining เทียบกับ transaction เทียบกับ MGET

```text
PIPELINING → batches commands for THROUGHPUT (NOT atomic — other clients' commands
  can interleave between your pipelined commands; it's just network batching)
MULTI/EXEC → atomic execution (commands run together, no interleaving) — different goal
MGET/MSET  → batch GETs/SETs in one command (use these for simple multi-key string ops)
→ Pipelining is for throughput; transactions are for atomicity. They can combine.
```

## ควรใช้เมื่อไร

```text
✓ Doing MANY independent commands (bulk reads/writes, batch processing, warming a cache)
✓ When network latency dominates (client and Redis have non-trivial latency between them)
✗ NOT needed for a single command, or when each command depends on the previous reply
⚠️ Don't pipeline a HUGE number at once (memory for buffered replies) — batch in chunks
```

## ทำไมจึงสำคัญ

การเข้าใจ pipelining มีค่าสำหรับการ **ปรับแต่ง throughput ของ Redis** ซึ่งเป็นข้อกังวลในทางปฏิบัติที่พบบ่อยเมื่อแอปพลิเคชันออกคำสั่ง Redis จำนวนมาก

ข้อมูลเชิงลึกหลักคือ Redis เร็วมากจน **network round-trip latency ไม่ใช่การประมวลผลของ Redis มักเป็นคอขวด** เมื่อทำการดำเนินการจำนวนมาก — request-reply round-trip ของแต่ละคำสั่งเพิ่ม network latency ดังนั้น 1000 คำสั่งแบบลำดับอาจใช้เวลาส่วนใหญ่ไปกับการรอเครือข่าย **Pipelining** แก้สิ่งนี้ด้วยการรวมหลายคำสั่งเข้าเป็นประมาณหนึ่ง round-trip (ส่งทั้งหมด แล้วอ่าน reply ทั้งหมดพร้อมกัน) มักเปลี่ยนหลายร้อยมิลลิวินาทีให้เหลือไม่กี่ — เป็นการเพิ่มความเร็วที่มากและส่งผลบ่อยครั้งสำหรับการดำเนินการจำนวนมากเช่น batch read/write, การ warm cache และการประมวลผลจำนวนมาก

การเข้าใจ **ความแตกต่างจาก transaction** สำคัญ: pipelining เป็นเพียงการ batch เครือข่ายเพื่อ throughput และ **ไม่เป็น atomic** (คำสั่งของไคลเอนต์อื่นแทรกได้) ขณะที่ `MULTI`/`EXEC` ให้ atomicity — เป็นเป้าหมายที่ต่างกันซึ่งบางครั้งสับสน และการใช้ตัวที่ถูกต้องมีความสำคัญ

การรู้ **ว่าควรใช้เมื่อไร** (หลายคำสั่งอิสระที่ latency เป็นตัวกำหนด) และเมื่อไรไม่ควร (คำสั่งเดียว, หรือเมื่อแต่ละคำสั่งขึ้นอยู่กับ reply ก่อนหน้า, หรือ batch มากเกินไปจนใช้หน่วยความจำสำหรับ buffered reply หมด) สะท้อนวิจารณญาณเชิงปฏิบัติที่ดี

เนื่องจากการออกคำสั่ง Redis จำนวนมากเป็นเรื่องพบบ่อยและ network latency มักเป็นตัวกำหนด และเนื่องจาก pipelining เป็นเทคนิคมาตรฐานที่มีประสิทธิภาพสูงในการ batch พวกมันอย่างมีประสิทธิภาพ (ต่างจาก transaction) การเข้าใจ pipelining — ปัญหา latency ที่มันแก้ วิธีทำงาน ความต่างจากกลไก atomicity และเมื่อไรควรใช้ — จึงเป็นความรู้ Redis ที่มีค่าและเกี่ยวข้องในทางปฏิบัติสำหรับการสร้างแอปพลิเคชันที่มีประสิทธิภาพซึ่งโต้ตอบกับ Redis อย่างหนัก