"เผยแพร่ครั้งแรกใน มีนาคม 2558 ที่ ObjectRocket.com/blog"
Redis® เป็นเครื่องมือที่ยอดเยี่ยม และชุมชนเทคโนโลยีรักมัน! มันเดินทางไกลมาจากโปรเจกต์ส่วนตัวเล็กๆ ของ Antirez จนกลายเป็น industry-standard in-memory data storage ด้วยนั้นมาชุดแนวทางปฏิบัติที่ดีที่สุดสำหรับการใช้ Redis อย่างถูกต้อง ในบทความนี้ เราสำรวจ 10 เคล็ดลับเร็วๆ สำหรับการใช้ Redis อย่างถูกต้อง
1. หยุดใช้ KEYS
โอเค การร้องรามคุณอาจไม่ใช่วิธีเริ่มต้นบทความที่ดี แต่จุดนี้อาจเป็นสิ่งสำคัญที่สุด บ่อยครั้งที่ผมดูอินสแตนซ์ Redis ดึง commandstats เร็วๆ แล้วเห็น KEYS ส่องมาอยู่ตรงหน้า ในความเป็นจริง จากมุมมองทางการเขียนโปรแกรม จะสมเหตุสมผลที่จะมี pseudocode คล้ายกับนี้:
for key in 'keys *': doAllTheThings() แต่มันเมื่อคุณมี 13 ล้าน keys สิ่งต่างๆ จะช้าลง เนื่องจาก KEYS เป็น O(n) โดยที่ n คือจำนวน keys ที่คืนค่า ความซับซ้อนของคุณถูกผูกมัดกับขนาดฐานข้อมูล นอกจากนี้ ตลอดการดำเนินการทั้งหมด คุณไม่สามารถรันอะไรกับอินสแตนซ์ของคุณได้
แทนที่จะเป็นเช่นนั้น ดู SCAN ซึ่งอนุญาตให้คุณสแกนผ่านฐานข้อมูลของคุณเป็นช่วงๆ แทน มันทำงานบน iterator ดังนั้นคุณสามารถหยุดและไปได้ตามที่คุณเห็นเหมาะสม
2. หาว่าอะไรกำลังทำให้ Redis ช้า
เนื่องจาก Redis ไม่มี logs ที่ verbose ที่สุด มันมักยากที่จะติดตามว่าอย่างไรก็ดี Redis ให้คุณ commandstat utility เพื่อแสดงรายละเอียดคล้ายตัวอย่างต่อไปนี้:
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 นี่ให้การแบ่งส่วนของคำสั่งทั้งหมด จำนวนครั้งที่คุณรันพวกมัน และจำนวนไมโครวินาทีที่ใช้ในการดำเนินการ (รวมและเฉลี่ยต่อการเรียก) เพื่อ reset ให้รัน CONFIG RESETSTAT และคุณได้ slate ใหม่
3. ใช้ Redis-Benchmark เป็น baseline ไม่ใช่ความจริงอันสิ้นเชิง
Salvatore ผู้สร้าง Redis ขีดเส้นใต้ว่า: "การทดสอบ Redis ด้วย GET/SET เหมือนการทดสอบ Ferrari ว่ามันทำความสะอาดกระจกได้ดีแค่ไหนตอนฝนตก" หลายครั้ง คนมาหาผมถามว่าทำไม Redis-Benchmark results ของพวกเขาถึงไม่ optimal แตเราต้องคำนึงถึงปัจจัยหลายอย่าง เช่น:
- Client-side limitations
- Difference in versioning
- On-going tests
Redis-Benchmark ให้ baseline ที่ยอดเยี่ยมเพื่อให้แน่ใจว่า redis-server ของคุณพฤติกรรมปกติ แต่ไม่ควรถูกมองว่าเป็น load test จริง Load tests ต้องสะท้อนว่าแอปพลิเคชันของคุณพฤติกรรมอย่างไรในสภาพแวดล้อมที่ใกล้ production มากที่สุด
4. Hashes เป็นเพื่อนสนิทของคุณ
เชิญ hashes มากินข้าวเย็น เลี้ยงดู hashes คุณจะประหลาดใจที่ความสุขที่พวกมันนำมา หากคุณให้โอกาสพวกมัน ผมเคยเห็น key structures เหมือนต่อไปนี้มากเกินไป:
foo:first_name foo:last_name foo:address ในตัวอย่างนั้น foo อาจเป็น username สำหรับ user และแต่ละบรรทัดคือ key แยกต่างหาก นี่เพิ่มพื้นที่สำหรับข้อผิดพลาดและเพิ่ม keys ที่ไม่จำเป็นเข้าไปในกลุ่ม แทนที่จะเป็นเช่นนั้น พิจารณา hash ทันทีคุณมีเพียง key เดียว:
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 (Time To Live)!
ทุกครั้งที่เป็นไปได้ ใช้ประโยชน์จาก expiring keys ตัวอย่างที่สมบูรณ์คือการเก็บอย่างเช่น temporary authentication keys เมื่อคุณดึง auth key ใช้ OAUTH เป็นตัวอย่าง คุณมักได้ expiration time เมื่อคุณตั้งค่า key ให้ตั้งค่ามันพร้อม expiration เดียวกัน และ Redis ทำความสะอาดให้คุณเอง! ไม่ต้องใช้ KEYS เพื่อวนลูปผ่าน keys ทั้งหมดนั้นอีก
6. เลือก eviction policy ที่เหมาะสม
ขณะที่เราอยู่ในหัวข้อการทำความสะอาด keys มาแตะเรื่อง eviction ด้วย เมื่อ Redis instance ของคุณเต็ม Redis จะพยายาม evict keys ขึ้นอยู่กับ use case ของคุณ เราแนะนำ volatile-lru อย่างยิ่ง—สมมติว่าคุณมี expiring keys หากคุณรันอย่างเช่น cache และไม่มี expiry ตั้งค่า คุณอาจพิจารณา allkeys-lru เราแนะนำให้คุณดูตัวเลือกที่มีอยู่ที่นี่
7. หากข้อมูลของคุณสำคัญ ใส่ try/except
หากมันสำคัญอย่างยิ่งที่ข้อมูลจะไปถึง Redis instance ของคุณ ผมแนะนำอย่างยิ่งให้ใส่ try/except เนื่องจากส่วนใหญ่ config Redis clients ให้ fire-and-forget คุณควรวางแผนเสมอสำหรับกรณีที่ key ไม่ได้ไปถึงฐานข้อมูลจริง ความซับซ้อนที่เพิ่มเข้ามาใน Redis call ของคุณคือ next to nothing ในกรณีนี้ และคุณสามารถรับรองได้ว่าข้อมูลสำคัญของคุณไปถึงที่ที่มันควรจะเป็น
8. อย่า flood อินสแตนซ์เดียว
ทุกครั้งที่เป็นไปได้ แบ่ง workload ระหว่าง multiple Redis instances Redis Cluster พร้อมใช้งานตั้งแต่ version 3.0.0 Redis Cluster ช่วยให้คุณแยก keys ระหว่าง sets ของ primaries และ secondaries ที่กำหนดตาม key ranges คุณสามารถหาการแบ่งส่วนเต็มของ magic ข้างหลัง Redis Cluster ที่นี่ และหากคุณมองหา tutorial ไม่ต้องมองไกลกว่านี้ คุณสามารถหาได้ที่นี่ หาก clustering ไม่ใช่ตัวเลือก พิจารณา namespacing และกระจาย keys ของคุณระหว่าง multiple instances คุณสามารถหาการเขียนที่น่าทึ่งเกี่ยวกับการ partition ข้อมูลของคุณบนเว็บไซต์ redis.io
9. More cores = better performance, right?!
ผิด Redis เป็น single-threaded process และจะ consume สูงสุดสอง cores หากคุณเปิด persistence เว้นแต่คุณวางแผนรัน multiple instances บน host เดียวกัน—หวังว่าแค่สำหรับ dev testing ในกรณีนั้น—คุณไม่ควรต้องการมากกว่าสอง cores สำหรับ Redis instance
10. HA all the things!
Redis Sentinel ตอนนี้ทดสอบได้ดีแล้ว และผู้ใช้หลายคนรันใน production (Rackspace ObjectRocket รวม) หากคุณพึ่งพา Redis มากสำหรับแอปพลิเคชันของคุณ แล้วคุณต้องพิจารณา high availability (HA) solution เพื่อให้คุณออนไลน์ อย่างไรก็ตาม หากคุณไม่ต้องการจัดการทั้งหมดนั้นเอง Rackspace ObjectRocket เสนอ HA platform ของเราพร้อม 24×7 support ลองดูสิ
เรียนรู้เพิ่มเติมเกี่ยวกับบริการ DBA ของ Rackspace
ใช้แท็บ Feedback เพื่อแสดงความคิดเห็นหรือถามคำถาม คุณยังสามารถคลิก Sales Chat เพื่อแชททันทีและเริ่มสนทนาได้
คลิกที่นี่เพื่อดู The Rackspace Cloud Terms of Service
