Redis กำลังมาแรงในชุมชนเทคโนโลยีในขณะนี้ มาไกลจากการเป็นโครงการส่วนตัวขนาดเล็กจาก Antirez ไปจนถึงการเป็นมาตรฐานอุตสาหกรรมสำหรับการจัดเก็บข้อมูลหน่วยความจำ ด้วยเหตุนี้จึงมาพร้อมกับชุดแนวทางปฏิบัติที่ดีที่สุดที่คนส่วนใหญ่ยอมรับได้ในการใช้ Redis อย่างเหมาะสม ด้านล่างนี้ เราจะสำรวจเคล็ดลับสั้นๆ 10 ข้อเกี่ยวกับการใช้ Redis อย่างถูกต้อง
1. หยุดใช้คีย์ *
โอเค บางทีการตะโกนใส่คุณอาจไม่ใช่วิธีที่ดีในการเริ่มบทความนี้ แต่อาจเป็นจุดที่สำคัญที่สุด บ่อยครั้งที่ฉันดูอินสแตนซ์ redis ดึง commandstats อย่างรวดเร็ว และดู KEYS ที่จ้องมองกลับมาที่ฉัน ด้วยความเป็นธรรม หากมาจากจุดยืนเชิงโปรแกรม ก็ควรที่จะมี psuedocode ที่ทำสิ่งต่อไปนี้:
for key in 'keys *':
doAllTheThings()แต่ถ้าคุณมี 13 ล้านคีย์ สิ่งต่างๆ จะชะลอตัวลง เนื่องจาก KEYS คือ O(n) โดยที่ n คือจำนวนคีย์ที่ส่งคืน ความซับซ้อนของคุณจึงถูกผูกไว้โดย dbsize นอกจากนี้ ในระหว่างการดำเนินการทั้งหมดนี้ จะไม่มีการเรียกใช้งานอื่นกับอินสแตนซ์ของคุณ
ให้ตรวจสอบ SCAN ซึ่งช่วยให้คุณ… สแกนฐานข้อมูลของคุณทีละส่วนแทน การดำเนินการนี้ทำงานบนอินเตอร์เรเตอร์ คุณจึงสามารถหยุดและไปได้ตามที่เห็นสมควร
2. ค้นหาสิ่งที่ทำให้ Redis ช้าลง
เนื่องจาก Redis ไม่มีบันทึกที่ละเอียดที่สุด จึงมักจะยากที่จะติดตามว่าเกิดอะไรขึ้นภายในอินสแตนซ์ของคุณ โชคดีที่ Redis มียูทิลิตี commandstat ให้คุณแสดงสิ่งนี้:
127.0.0.1:6379> INFO commandstats
# Commandstats
cmdstat_get:calls=78,usec=608,usec_per_call=7.79
cmdstat_setex:calls=5,usec=71,usec_per_call=14.20
cmdstat_keys:calls=2,usec=42,usec_per_call=21.00
cmdstat_info:calls=10,usec=1931,usec_per_call=193.10ซึ่งจะให้รายละเอียดเกี่ยวกับคำสั่งทั้งหมด จำนวนครั้งที่เรียกใช้ จำนวนไมโครวินาทีที่ใช้ในการดำเนินการ (ทั้งหมดและเฉลี่ยต่อการโทร)
หากต้องการรีเซ็ตสิ่งนี้ ให้เรียกใช้ CONFIG RESETSTAT แล้วคุณจะได้แถบสเลทใหม่ล่าสุด
3. ใช้ Redis-Benchmark เป็นพื้นฐาน ไม่ใช่ความจริงของพระกิตติคุณ
Salvatore ผู้สร้าง Redis พูดอย่างชาญฉลาดว่า:“การทดสอบ Redis ที่ทำ GET/SET ก็เหมือนกับการทดสอบ Ferrari ว่าทำความสะอาดกระจกได้ดีเพียงใดเมื่อฝนตก” หลายครั้งที่ผู้คนมาหาฉันสงสัยว่าเหตุใดผลลัพธ์ Redis-Benchmark ของพวกเขาจึงน้อยกว่าค่าที่เหมาะสม แต่เราต้องคำนึงถึงปัจจัยต่างๆ หลายประการ เช่น:
- มีข้อจำกัดด้านไคลเอ็นต์ใดบ้างที่เราอาจพบได้
- มีความแตกต่างในการกำหนดเวอร์ชันหรือไม่
- การทดสอบที่กำลังดำเนินการเกี่ยวข้องกับสิ่งที่แอปพลิเคชันจะดำเนินการหรือไม่
Redis-Benchmark ให้พื้นฐานที่ยอดเยี่ยมเพื่อให้แน่ใจว่าเซิร์ฟเวอร์ Redis ของคุณไม่ได้ทำงานผิดปกติ แต่ไม่ควรถือเป็น "การทดสอบการโหลด" ที่แท้จริง การทดสอบการโหลดจะต้องสะท้อนถึงลักษณะการทำงานของแอปพลิเคชันของคุณ และจากสภาพแวดล้อมที่ใกล้เคียงกับการผลิตมากที่สุด
4. แฮชคือเพื่อนที่ดีที่สุดของคุณ
เชิญแฮชไปทานอาหารเย็น แฮชไวน์และรับประทานอาหาร คุณจะทึ่งในความสุขที่พวกเขาสามารถนำมาได้หากคุณเพียงแค่ให้โอกาสพวกเขา ฉันเคยเห็นโครงสร้างหลักมากเกินไปเช่นนี้มาก่อน:
foo:first_name
foo:last_name
foo:addressในตัวอย่างข้างต้น foo อาจเป็นชื่อผู้ใช้สำหรับผู้ใช้ และแต่ละอันเป็นคีย์ที่แยกจากกัน การทำเช่นนี้จะเพิ่มพื้นที่สำหรับข้อผิดพลาด และเพิ่มคีย์ที่ไม่จำเป็นลงในส่วนพับ ให้พิจารณาแฮชแทน ทันใดนั้นคุณมีกุญแจดอกเดียว:
127.0.0.1:6379> HSET foo first_name "Joe"
(integer) 1
127.0.0.1:6379> HSET foo last_name "Engel"
(integer) 1
127.0.0.1:6379> HSET foo address "1 Fanatical Pl"
(integer) 1
127.0.0.1:6379> HGETALL foo
1) "first_name"
2) "Joe"
3) "last_name"
4) "Engel"
5) "address"
6) "1 Fanatical Pl"
127.0.0.1:6379> HGET foo first_name
"Joe"5. ตั้งค่า TTL นั้น!
เมื่อใดก็ตามที่เป็นไปได้ ให้ใช้ประโยชน์จากคีย์ที่หมดอายุ ตัวอย่างที่สมบูรณ์แบบคือการจัดเก็บบางอย่างเช่นคีย์การตรวจสอบสิทธิ์ชั่วคราว เมื่อคุณดึงคีย์การตรวจสอบสิทธิ์ ลองใช้ OAUTH เป็นตัวอย่าง คุณมักจะได้รับเวลาหมดอายุ เมื่อคุณตั้งค่าคีย์ ให้ตั้งค่าด้วยการหมดอายุเดียวกัน แล้ว Redis จะล้างข้อมูลให้คุณ! ไม่จำเป็นต้องใช้ KEYS * เพื่อย้ำคีย์เหล่านั้นอีกต่อไปใช่ไหม
6. การเลือกนโยบายการขับไล่ที่เหมาะสม
ในขณะที่เราอยู่ในหัวข้อการทำความสะอาดกุญแจ เรามาพูดถึงเรื่องการขับไล่กัน เมื่ออินสแตนซ์ Redis ของคุณเต็ม Redis จะพยายามถอดกุญแจออก ฉันขอแนะนำ volatile-lru โดยขึ้นอยู่กับกรณีการใช้งานของคุณ สมมติว่าคุณมีคีย์ที่ใกล้หมดอายุ หากคุณกำลังใช้งานบางอย่างเช่นแคชและไม่มีชุดการหมดอายุ คุณอาจพิจารณา allkeys-lru ฉันขอแนะนำให้ตรวจสอบตัวเลือกที่มีที่นี่
7. หากข้อมูลของคุณมีความสำคัญ ให้ลอง/ยกเว้น
หากการส่งข้อมูลไปยังอินสแตนซ์ Redis เป็นสิ่งสำคัญอย่างยิ่ง เราขอแนะนำให้คุณลอง/ยกเว้น เนื่องจากไคลเอนต์ Redis เกือบทั้งหมดได้รับการกำหนดค่าให้ "ดับแล้วไม่ลืม" จึงควรพิจารณาเสมอว่าเมื่อใดที่คีย์ไม่ได้สร้างไปยังฐานข้อมูลจริงๆ ความซับซ้อนที่เพิ่มเข้ามาในการเรียก Redis ของคุณนั้นแทบจะเป็นไปไม่ได้เลยในกรณีนี้ และคุณสามารถมั่นใจได้ว่าข้อมูลสำคัญของคุณจะไปถึงที่ที่ควรจะเป็น
8. อย่าท่วมอินสแตนซ์เดียว
เมื่อใดก็ตามที่เป็นไปได้ ให้แบ่งปริมาณงานระหว่างอินสแตนซ์ Redis หลายรายการ ในเวอร์ชัน 3.0.0 Redis Cluster พร้อมใช้งานแล้ว Redis Cluster ช่วยให้คุณสามารถแยกคีย์ระหว่างชุดของมาสเตอร์/สลาฟที่กำหนดตามช่วงคีย์ รายละเอียดของเวทย์มนตร์เบื้องหลัง Cluster ทั้งหมดสามารถพบได้ที่นี่ และหากคุณกำลังมองหาบทช่วยสอน ไม่ต้องไปหาที่ไหนอีกแล้ว หากการจัดกลุ่มไม่ใช่ตัวเลือก ให้พิจารณาเนมสเปซและแจกจ่ายคีย์ของคุณในหลาย ๆ อินสแตนซ์ สามารถอ่านบทความที่น่าทึ่งเกี่ยวกับการแบ่งพาร์ติชั่นข้อมูลของคุณได้จากเว็บไซต์ redis.io ที่นี่
9. แกนมากขึ้น =ดีกว่าใช่ไหม!
ผิด. Redis เป็นกระบวนการแบบเธรดเดียว และอย่างมากที่สุด จะใช้สองคอร์หากคุณเปิดใช้งานการคงอยู่ ยกเว้นกรณีที่คุณวางแผนจะเรียกใช้หลายอินสแตนซ์บนโฮสต์เดียวกัน หวังว่าสำหรับการทดสอบนักพัฒนาซอฟต์แวร์ในกรณีนี้ คุณไม่จำเป็นต้องมีแกนมากกว่า 2 คอร์สำหรับอินสแตนซ์ Redis
10. ฮาทุกอย่าง!
Redis Sentinel ได้รับการทดสอบเป็นอย่างดีแล้ว และผู้ใช้จำนวนมากได้ใช้งานจริงในการผลิต (รวม ObjectRocket ด้วย!) หากคุณต้องพึ่งพา Redis อย่างมากสำหรับแอปพลิเคชันของคุณ คุณจะต้องพิจารณาโซลูชัน HA (ความพร้อมใช้งานสูง) เพื่อให้คุณออนไลน์ได้ แน่นอน หากคุณไม่ต้องการจัดการทั้งหมดนั้นเอง ObjectRocket ขอเสนอแพลตฟอร์ม HA ของเราพร้อมการสนับสนุน 24×7 สำหรับการบริโภคของคุณ ลองดูสิ
