Redis — แคชในหน่วยความจำเพื่อเว็บไซต์และร้านค้า
Redis คือชั้นแคชเบื้องหลังเว็บไซต์ ร้านค้า และมาร์เก็ตเพลสที่สร้างบน 4buildsite: เก็บข้อมูลที่ต้องให้บริการบ่อยไว้ในหน่วยความจำ (RAM) — หน้าเว็บที่แคชไว้ เซสชัน ตะกร้าสินค้า การจำกัดอัตรา ขณะที่ PostgreSQL ยังคงเป็นแหล่งข้อมูลที่เชื่อถือได้ และ Redis ช่วยปกป้องมันเมื่อทราฟฟิกหนัก รวมอยู่ในแพลตฟอร์มและดูแลให้ โดยคุณไม่ต้องตั้งค่าใด ๆ
Redis คืออะไร และทำงานอย่างไร
Redis (REmote DIctionary Server) เป็นฐานข้อมูลในหน่วยความจำแบบโอเพนซอร์ส: เก็บข้อมูลไว้ใน RAM แทนที่จะเป็นดิสก์ บน 4buildsite เราใช้มันเป็นชั้นแคชหน้า PostgreSQL — สำหรับทุกอย่างที่ต้องให้บริการบ่อย: หน้าเว็บ เซสชัน ตะกร้าสินค้า และการจำกัดอัตรา
ต่างจากดิสก์ RAM เร็วกว่าหลายเท่าตัว และ Redis เพิ่มโครงสร้างข้อมูลแบบเนทีฟ (string, hash, list, set, sorted set, stream) ที่ทำการดำเนินการซับซ้อนได้โดยตรงในหน่วยความจำ โดยไม่ต้องไปกลับกับฐานข้อมูลหลัก การประมวลผลคำสั่งเป็นแบบเธรดเดียว พฤติกรรมจึงคาดเดาได้ และลดความเสี่ยง race condition ระดับคำสั่ง
- ความหน่วงโดยทั่วไปต่ำกว่า 1 ms และมากกว่า 100,000 การดำเนินการต่อวินาทีบนโหนดเดียว
- โครงสร้างเนทีฟ: hash สำหรับเซสชัน, sorted set สำหรับลีดเดอร์บอร์ดและการจำกัดอัตรา, stream สำหรับคิว
- คำสั่งทำงานบนเธรดเดียว → พฤติกรรมคาดเดาได้ ไม่ต้องล็อกที่ซับซ้อน
การแคช: หน้าเว็บและข้อมูลของคุณ
กลยุทธ์คือ cache-aside: คำขอแรกอ่านจาก PostgreSQL และเก็บผลลัพธ์ใน Redis พร้อม TTL (time to live) คำขอถัด ๆ ไปดึงจากหน่วยความจำโดยตรง เมื่อคุณแก้ไขหน้า คีย์จะถูกทำให้ใช้ไม่ได้อย่างชัดเจน — เราไม่เสิร์ฟข้อมูลที่ล้าสมัยผ่าน TTL แบบสุ่มสี่สุ่มห้า
สำหรับเว็บไซต์นำเสนอหรือร้านค้า นั่นหมายความว่ารายการสินค้า เมนู หน้ายอดนิยม และส่วนของเนื้อหาจะถูกส่งมอบจากแคชแม้ทราฟฟิกหนัก โดยลดภาระให้ฐานข้อมูล ในช่วงพีค (แคมเปญ Black Friday) Redis รับคำขอที่ซ้ำกันไว้จากแคช
- Cache-aside พร้อมการทำให้แคชเป็นโมฆะอย่างชัดเจน — ลดโอกาสข้อมูลล้าสมัย
- แคชชิ้นส่วนของหน้าและผลลัพธ์คิวรี ไม่ใช่แค่ทั้งหน้า
- ช่วยลดภาระให้ PostgreSQL ในช่วงทราฟฟิกพีค
เซสชัน ตะกร้าสินค้า และการป้องกันการใช้งานในทางที่ผิด
เซสชันของผู้ใช้และ refresh token อยู่ใน Redis: หมดอายุอัตโนมัติผ่าน TTL และเพิกถอนได้ในทุกอุปกรณ์เมื่อมีคนออกจากระบบหรือเปลี่ยนรหัสผ่าน
ตะกร้าสินค้าในร้านค้าที่สร้างบน 4buildsite เก็บไว้ใน Redis สำหรับผู้เข้าชมที่ยังไม่ได้เข้าสู่ระบบ — มีวันหมดอายุ และไม่ทำให้ฐานข้อมูลหลักบวม Redis ยังบังคับใช้การจำกัดอัตราในแบบฟอร์มติดต่อและการเข้าสู่ระบบโดยใช้ sorted set ช่วยหยุดสแปมและการเดารหัสผ่านก่อนไปถึงฐานข้อมูล
- ที่เก็บเซสชันพร้อมหมดอายุอัตโนมัติและการเพิกถอนโทเคนแบบเลือกได้
- ตะกร้าสินค้าถาวรพร้อม TTL สำหรับผู้เข้าชมนิรนาม
- การจำกัดอัตราและป้องกันการใช้งานในทางที่ผิดบนแบบฟอร์มและการยืนยันตัวตน
เรียลไทม์และคิวงานเบื้องหลัง
Redis Pub/Sub และ Streams ขับเคลื่อนการอัปเดตแบบเรียลไทม์: การเปลี่ยนแปลงสต็อก การแจ้งเตือนในแอป สถานะคำสั่งซื้อที่เปลี่ยนไป — ทั้งหมดโดยที่ผู้เข้าชมไม่ต้องรีเฟรช และไม่ต้องโพลซ้ำ ๆ ที่ทำให้เซิร์ฟเวอร์เหนื่อย
งานหนัก (ประมวลผลภาพ สร้างไฟล์ส่งออก ซิงก์ข้อมูล) เข้าคิวของ Redis และถูกรันโดยเวิร์กเกอร์เบื้องหลัง คำขอของผู้เข้าชมจึงไม่ต้องประมวลผลงานหนักเหล่านี้เอง กลไกล็อกแบบกระจายช่วยป้องกันการดำเนินการสำคัญทำงานซ้ำสองครั้ง
- Pub/Sub และ Streams สำหรับเหตุการณ์สด (สต็อก คำสั่งซื้อ การแจ้งเตือน)
- คิวงานสำหรับการประมวลผลหนักที่รันแบบอะซิงโครนัส
- การล็อกแบบกระจายสำหรับการดำเนินการที่ต้องไม่รันซ้ำสองครั้ง
ข้อดีและข้อจำกัด
ข้อดี
- ข้อมูลที่แคชไว้อยู่ในหน่วยความจำ จึงให้บริการได้โดยไม่ต้องคิวรีฐานข้อมูลทุกครั้ง
- ลดภาระของ PostgreSQL เมื่อทราฟฟิกหนัก
- โครงสร้างเนทีฟสำหรับเซสชัน ตะกร้า การจำกัดอัตรา และลีดเดอร์บอร์ด
- Pub/Sub และ Streams สำหรับฟีเจอร์เรียลไทม์ โดยไม่ต้องโพล
- คิวงานสำหรับการประมวลผลหนัก โดยไม่บล็อกผู้เข้าชม
- รวมอยู่ในแพลตฟอร์มและดูแลให้ — คุณไม่ต้องตั้งค่าใด ๆ
ข้อจำกัด
- ข้อมูลอยู่ใน RAM ซึ่งแพงกว่าดิสก์ → ไม่เหมาะกับข้อมูล "เย็น" ปริมาณมหาศาล
- เป็นชั้นแคช / ชั้นเสริม ไม่ใช่แหล่งข้อมูลที่เชื่อถือได้ — ข้อมูลถาวรยังอยู่ใน PostgreSQL
- การคงอยู่ของข้อมูล (RDB/AOF) ลดความเสี่ยง แต่ไม่ได้ขจัดการสูญเสียข้อมูลช่วงไม่กี่วินาทีสุดท้ายเมื่อระบบล่มได้ทั้งหมด
- ต้องมีกลยุทธ์การทำให้แคชเป็นโมฆะที่ถูกต้อง มิฉะนั้นอาจเสิร์ฟข้อมูลที่ล้าสมัย
สรุปสั้น ๆ
ใช้ Redis กับข้อมูลที่ถูกเรียกใช้บ่อยหรือเป็นชั่วคราว — แคช เซสชัน ตะกร้า การจำกัดอัตรา เรียลไทม์ และคิวงาน อย่าใช้เป็นที่เก็บข้อมูลหลัก ส่วนนั้นเป็นหน้าที่ของ PostgreSQL บน 4buildsite คุณได้ทั้งสองอย่างที่เชื่อมต่อให้อัตโนมัติ: ไม่ต้องเลือกหรือกำหนดค่าอะไรเลย
ตารางสเปก
| ความสามารถ | รายละเอียด | จุดที่ใช้ใน builder |
|---|---|---|
| ความหน่วง | < 1 ms (ในหน่วยความจำ) | หน้าเว็บและข้อมูลที่แคชไว้ถูกให้บริการจากหน่วยความจำ |
| ปริมาณงาน | > 100,000 ops/s ต่อโหนด | รองรับทราฟฟิกหนักโดยลดภาระฐานข้อมูล |
| โครงสร้างข้อมูล | string, hash, list, set, sorted set, stream | เซสชัน ตะกร้า ลีดเดอร์บอร์ด คิว การจำกัดอัตรา |
| การคงอยู่ของข้อมูล | สแนปชอต RDB + ล็อก AOF | กู้คืนเร็วหลังรีสตาร์ต |
| การหมดอายุ | TTL รายคีย์ | ตะกร้า เซสชัน และแคชที่ล้างตัวเอง |
| เรียลไทม์ | Pub/Sub + Streams | การเปลี่ยนแปลงสต็อก การแจ้งเตือน สถานะคำสั่งซื้อ |
Redis (แคช) กับใช้ฐานข้อมูลอย่างเดียว
| เกณฑ์ | มี Redis | PostgreSQL อย่างเดียว |
|---|---|---|
| เวลาตอบสนองสำหรับข้อมูลที่ถูกเรียกซ้ำ | จากหน่วยความจำ ไม่ต้องคิวรีซ้ำ | หลายสิบ ms คิวรีทุกคำขอ |
| เมื่อทราฟฟิกหนัก | ฐานข้อมูลรับภาระน้อยลง | ฐานข้อมูลติดขัด เสี่ยงหมดเวลา |
| ตะกร้าและเซสชัน | หมดอายุอัตโนมัติ | ตารางที่โตขึ้นและเพิ่มภาระให้ฐานข้อมูล |
| เรียลไทม์ | Pub/Sub และ Streams แบบเนทีฟ | โพลซ้ำ ๆ สิ้นเปลือง |
| คิวงาน | เนทีฟ ใช้งานง่าย | โซลูชันที่ทำขึ้นเองหรือไม่มีเลย |
คำถามที่พบบ่อย
สรุปสั้น ๆ Redis คืออะไร?
ฐานข้อมูลในหน่วยความจำ ใช้เป็นชั้นแคช เซสชัน และเรียลไทม์หน้าฐานข้อมูลหลัก
ทำไมไม่ใช้แค่ PostgreSQL?
PostgreSQL คือแหล่งข้อมูลที่เชื่อถือได้ (ข้อมูลคงทน) แต่ Redis ให้บริการข้อมูลที่ถูกเรียกซ้ำจากหน่วยความจำ และรับหน้าที่ตะกร้า เซสชัน การจำกัดอัตรา และเรียลไทม์ ช่วยปกป้องฐานข้อมูลเมื่อทราฟฟิกหนัก ทั้งสองทำงานร่วมกัน
ถ้า Redis ล่ม ข้อมูลฉันจะหายไหม?
ข้อมูลถาวรของเว็บไซต์อยู่ใน PostgreSQL: Redis เก็บเพียงแคชและข้อมูลชั่วคราว และการคงอยู่ของข้อมูลแบบ RDB/AOF ช่วยลดการสูญเสีย การรีสตาร์ต Redis ไม่ควรกระทบเว็บไซต์ที่เผยแพร่แล้วของคุณ
ฉันต้องตั้งค่า Redis เองไหม?
ไม่ต้อง รวมอยู่ในแพลตฟอร์มและดูแลโดย 4buildsite คุณได้แคชและฟีเจอร์เรียลไทม์โดยไม่ต้องดูแลอะไรเลย
Redis ช่วยร้านค้าออนไลน์อย่างไร?
ตะกร้าสินค้าสำหรับผู้เข้าชม รายการสินค้าที่แคชไว้ สต็อกที่อัปเดตตามการเปลี่ยนแปลง และการป้องกันการใช้งานในทางที่ผิดตอนชำระเงินและในแบบฟอร์ม — ทั้งหมดช่วยลดภาระให้ฐานข้อมูล
Redis ช่วย SEO และ Core Web Vitals ไหม?
ช่วยทางอ้อม: แคชลดเวลาที่เซิร์ฟเวอร์ใช้ตอบกลับ (TTFB) ซึ่งส่งผลต่อ LCP ได้โดยอ้อม และ Core Web Vitals เป็นสัญญาณที่เครื่องมือค้นหาใช้พิจารณา