หลังจากที่พูดคุยเรื่องการนำ Redis มาใช้งาน
ทั้งการจัดเก็บข้อมูลชั่วคราว (caching data)
ทั้งการใช้งาน pub/sub สำหรับ messaging system
ซึ่งมีการสรุปเรื่อง architecture ของ Redis ที่เหมาะสมต่องาน
มีรูปแบบต่าง ๆ ดังนี้
รูปแบบที่ 1 สำหรับคนจริง พังได้ คือ Single Redis Instance
ติดตั้งง่ายสุด ๆ
แต่พังแล้วพังเลย ต้องติดตั้งหรือ restart ใหม่
ใช้สำหรับการจัดการ service ที่มีขนาดเล็ก รับความเสี่ยงได้
แต่ถ้าทำการ persistence ข้อมูลลง disk ได้ดี
ทั้ง RDB และ AOF ก็ลดความเสีายงเรื่องข้อมูลหายได้
รูปแบบที่ 2 Redis High Availability (HA)
สำหรับระบบที่ต้องการความเสถียรมากขึ้น
ให้ทำการ replicate ข้อมูลไปยัง instance/server อื่น ๆ ซะ
เหมือนกับ master/slave นั่นเอง
เขียนข้อมูลที่ master หรือ primary instance
อ่านข้อมูลที่ slave หรือ secondary ซึ่งมีได้มากกว่า 1 instance
แต่มาพร้อมกับความซับซ้อนในการ deploy
รูปแบบที่ 3 Redis Sentinel
จะมีกลุ่มของ instance ที่เรียกว่า sentinel
สำหรับการจัดการ instance ต่าง ๆ ใน redis HA หรือ cluster
ช่วยทำให้แต่ละ instance ทำงานร่วมกันได้ดี
นั่นคือเมื่อมีเครื่องใดเครื่องหนึ่งแล้ว
sentinel จะจัดการให้ cluster ทำงานได้
เช่นเครื่อง master พังแล้ว sentinel จะเลือกเครื่องอื่น ๆ มาเป็น master ต่อไป
และ sentinel จะทำการ monitor และ ส่งข้อมูลของ cluster
ไปยัง client ที่ติดต่อมาอีกด้วย
ปัญหาหลัก ๆ ของ sentinel คือ ความซับซ้อน จำนวน instance
รวมทั้งเรื่อง network ระหว่าง instance ต้องเร็วและเสถียร
รูปแบบที่ 4 Redis Cluster
เป็นรูปแบบที่ได้รับความนิยม
ทำมาสำหรับการ scale แบบ horizontal คือการเพิ่มเครื่องเข้ามา
แถมสามารถกระจายข้อมูลแบบ shading ได้อีก
แต่ก็ซับซ้อนมาก ๆ
ดังนั้นจากทั้ง 4 รูปแบบนั้น ต้องเลือกจากความต้องการทาง business
รวมทั้งความสามารถของทีมอีกด้วย
เพื่อเลือกให้เหมาะสมกับงานต่อไป
