วิธีใช้ Redis สำหรับแอปพลิเคชันการวัดแสงแบบเรียลไทม์

ชานมาร์เป็นผู้จัดการผลิตภัณฑ์อาวุโสที่ Redis Labs

การวัดแสงไม่ใช่แค่ปัญหาการนับธรรมดา การวัดแสงมักสับสนกับการวัด แต่โดยปกติแล้วจะมีมากกว่านั้น การวัดแสงเกี่ยวข้องกับการวัด แต่เป็นกระบวนการต่อเนื่องโดยปกติจะมีเป้าหมายในการควบคุมการใช้งานหรือการไหลของทรัพยากรในช่วงเวลาหนึ่ง แอปพลิเคชันสมัยใหม่รวมการวัดแสงไว้ในรูปแบบต่างๆมากมายตั้งแต่การนับคนวัตถุหรือเหตุการณ์ไปจนถึงการควบคุมการใช้งานการควบคุมการเข้าถึงและการจัดสรรความจุ

โซลูชันการวัดแสงโดยทั่วไปจะต้องประมวลผลข้อมูลจำนวนมากในขณะที่เป็นไปตามข้อกำหนดด้านประสิทธิภาพที่เข้มงวด ขึ้นอยู่กับขนาดของโซลูชันการนับและการวัดแสงอาจเกี่ยวข้องกับการอัปเดตฐานข้อมูลหลายพันครั้งหากไม่ใช่นับล้านครั้งในทุก ๆ วินาที ข้อกำหนดหลักของฐานข้อมูลเพื่อรองรับโซลูชันดังกล่าวคือปริมาณงานที่สูงสำหรับการดำเนินการเขียนและเวลาแฝงต่ำ (มิลลิวินาที) สำหรับการตอบกลับ

Redis ซึ่งเป็นแพลตฟอร์มฐานข้อมูลในหน่วยความจำแบบโอเพนซอร์สมอบประโยชน์ทั้งสองนี้ในขณะที่ยังประหยัดต้นทุนในแง่ของการใช้ทรัพยากรฮาร์ดแวร์น้อยที่สุด ในบทความนี้เราจะตรวจสอบคุณสมบัติบางอย่างของ Redis ที่ทำให้เป็นตัวเลือกที่ดีสำหรับโซลูชันการวัดแสงและเราจะใช้ Redis เพื่อจุดประสงค์นั้นได้อย่างไร แต่ก่อนอื่นเรามาดูการใช้การวัดแสงทั่วไปบางส่วน

การใช้งานระบบวัดแสงทั่วไป

จำเป็นต้องมีการวัดแสงในแอปพลิเคชันใด ๆ ที่ต้องวัดการใช้ทรัพยากรในช่วงเวลาหนึ่ง นี่คือสถานการณ์ทั่วไปสี่สถานการณ์:

  1. การบริโภคแบบการกำหนดราคา ซึ่งแตกต่างจากรูปแบบการชำระเงินแบบครั้งเดียวหรือแบบสมัครสมาชิกรูปแบบการกำหนดราคาตามการบริโภคช่วยให้ผู้บริโภคจ่ายเฉพาะการใช้งานจริงเท่านั้น ผู้บริโภคมีความยืดหยุ่นอิสระและประหยัดค่าใช้จ่ายมากขึ้นในขณะที่ผู้ให้บริการได้รับการรักษาผู้บริโภคมากขึ้น

    การนำแบบจำลองดังกล่าวไปใช้อาจเป็นเรื่องยุ่งยาก บางครั้งระบบวัดแสงต้องติดตามรายการการใช้งานจำนวนมากและเมตริกหลายรายการในแผนเดียว ตัวอย่างเช่นผู้ให้บริการระบบคลาวด์อาจกำหนดระดับราคาที่แตกต่างกันสำหรับรอบของ CPU พื้นที่เก็บข้อมูลปริมาณงานจำนวนโหนดหรือระยะเวลาที่ใช้บริการ บริษัท โทรคมนาคมอาจกำหนดระดับการใช้งานที่แตกต่างกันสำหรับนาทีข้อมูลหรือข้อความ โซลูชันการวัดแสงต้องบังคับใช้การกำหนดสูงสุดการเรียกเก็บเงินหรือการขยายบริการขึ้นอยู่กับประเภทของการกำหนดราคาตามปริมาณการใช้

  2. การ จำกัด การใช้ทรัพยากรทุกบริการบนอินเทอร์เน็ตสามารถถูกละเมิดได้จากการใช้งานที่มากเกินไปเว้นแต่บริการนั้นจะถูก จำกัด อัตรา บริการยอดนิยมเช่น Google AdWords API และ Twitter Stream API รวมการ จำกัด อัตราด้วยเหตุนี้ การละเมิดที่รุนแรงบางกรณีนำไปสู่การปฏิเสธการให้บริการ (DoS) เพื่อป้องกันการละเมิดบริการและโซลูชันที่สามารถเข้าถึงได้บนอินเทอร์เน็ตต้องได้รับการออกแบบโดยใช้กฎการ จำกัด อัตราที่เหมาะสม แม้แต่การรับรองความถูกต้องและหน้าการเข้าสู่ระบบอย่างง่ายก็ต้อง จำกัด จำนวนการลองใหม่สำหรับช่วงเวลาที่กำหนด

    อีกตัวอย่างหนึ่งที่จำเป็นต้อง จำกัด การใช้ทรัพยากรก็คือเมื่อการเปลี่ยนแปลงข้อกำหนดทางธุรกิจทำให้ระบบเดิมมีภาระมากเกินกว่าที่จะรองรับได้ อัตราการ จำกัด การโทรไปยังระบบเดิมช่วยให้ธุรกิจปรับตัวเข้ากับความต้องการที่เพิ่มขึ้นโดยไม่จำเป็นต้องเปลี่ยนระบบเดิม

    นอกเหนือจากการป้องกันการละเมิดและลดภาระแล้วการ จำกัด อัตราที่ดียังช่วยในการจัดการสถานการณ์การจราจรที่ติดขัด ตัวอย่างเช่น API ที่บังคับใช้วิธีการ จำกัด อัตรากำลังดุร้ายอาจอนุญาตให้มีการโทร 1,000 ครั้งทุกชั่วโมง หากไม่มีนโยบายการกำหนดปริมาณการใช้งานลูกค้าอาจเรียกใช้ API 1,000 ครั้งในสองสามวินาทีแรกของทุกชั่วโมงซึ่งอาจเกินกว่าที่โครงสร้างพื้นฐานจะรองรับได้ อัลกอริทึม จำกัด อัตรายอดนิยมเช่น Token Bucket และ Leaky Bucket ป้องกันการระเบิดโดยไม่เพียง แต่ จำกัด การโทรเท่านั้น แต่ยังกระจายไปตามช่วงเวลา

  3. การกระจายทรัพยากร ความแออัดและความล่าช้าเป็นสถานการณ์ทั่วไปในแอปพลิเคชันที่จัดการกับการกำหนดเส้นทางแพ็คเก็ตการจัดการงานการจราจรที่ติดขัดการควบคุมฝูงชนการส่งข้อความโซเชียลมีเดียการรวบรวมข้อมูลและอื่น ๆ แบบจำลองการจัดคิวมีตัวเลือกมากมายสำหรับการจัดการขนาดคิวตามอัตราการมาถึงและการออก แต่การนำโมเดลเหล่านี้ไปใช้ในขนาดใหญ่ไม่ใช่เรื่องง่าย

    งานค้างและความแออัดเป็นความกังวลอย่างต่อเนื่องเมื่อต้องจัดการกับสตรีมข้อมูลที่รวดเร็ว นักออกแบบที่ชาญฉลาดจำเป็นต้องกำหนดขีดจำกัดความยาวคิวที่ยอมรับได้ในขณะที่รวมทั้งการตรวจสอบประสิทธิภาพการจัดคิวและการกำหนดเส้นทางแบบไดนามิกตามขนาดคิว

  4. นับในระดับการตัดสินใจแบบ real-time ไซต์อีคอมเมิร์ซแอปพลิเคชันเกมโซเชียลมีเดียและแอปบนอุปกรณ์เคลื่อนที่ดึงดูดผู้ใช้รายวันหลายล้านคน เนื่องจากดวงตาจำนวนมากขึ้นให้รายได้มากขึ้นการนับผู้เข้าชมและการกระทำของพวกเขาอย่างถูกต้องจึงมีความสำคัญต่อธุรกิจ การนับมีประโยชน์ในทำนองเดียวกันสำหรับกรณีการใช้งานเช่นการลองใหม่ข้อผิดพลาดการยกระดับปัญหาการป้องกันการโจมตี DDoS การทำโปรไฟล์ทราฟฟิกการจัดสรรทรัพยากรตามความต้องการและการลดการฉ้อโกง

ความท้าทายในการออกแบบระบบวัดแสง

สถาปนิกโซลูชันต้องพิจารณาพารามิเตอร์หลายอย่างเมื่อสร้างแอปพลิเคชันการวัดแสงโดยเริ่มจากสี่ประการต่อไปนี้:

  1. ความซับซ้อนของการออกแบบการนับการติดตามและการควบคุมปริมาณข้อมูลโดยเฉพาะอย่างยิ่งเมื่อมาถึงด้วยความเร็วสูงเป็นงานที่น่ากลัว สถาปนิกโซลูชันสามารถจัดการการวัดแสงที่เลเยอร์แอปพลิเคชันโดยใช้โครงสร้างภาษาโปรแกรม อย่างไรก็ตามการออกแบบดังกล่าวไม่ยืดหยุ่นต่อความล้มเหลวหรือข้อมูลสูญหาย ฐานข้อมูลบนดิสก์แบบดั้งเดิมมีความแข็งแกร่งและรับประกันความทนทานของข้อมูลในระดับสูงในระหว่างที่เกิดความล้มเหลว แต่ไม่เพียง แต่ขาดประสิทธิภาพในการให้ประสิทธิภาพที่จำเป็นเท่านั้น แต่ยังเพิ่มความซับซ้อนโดยไม่ต้องมีโครงสร้างข้อมูลและเครื่องมือที่เหมาะสมในการใช้การวัดแสงอีกด้วย
  2. เวลาแฝงโดยทั่วไปการวัดแสงจะเกี่ยวข้องกับการอัปเดตจำนวนมากอย่างต่อเนื่อง เวลาแฝงในการอ่าน / เขียนของเครือข่ายและดิสก์จะเพิ่มขึ้นในขณะที่จัดการกับตัวเลขจำนวนมาก สิ่งนี้อาจเป็นก้อนหิมะในการสร้างข้อมูลค้างส่งจำนวนมากซึ่งนำไปสู่ความล่าช้ามากขึ้น แหล่งอื่นของเวลาแฝงคือการออกแบบโปรแกรมที่โหลดข้อมูลการวัดจากฐานข้อมูลไปยังหน่วยความจำหลักของโปรแกรมและเขียนกลับไปยังฐานข้อมูลเมื่ออัปเดตตัวนับเสร็จแล้ว
  3. ความพร้อมกันและความสม่ำเสมอ การออกแบบโซลูชันเพื่อนับรายการนับล้านนับพันล้านอาจมีความซับซ้อนเมื่อมีการบันทึกเหตุการณ์ในภูมิภาคต่างๆและทั้งหมดจำเป็นต้องมารวมกันในที่เดียว ความสอดคล้องของข้อมูลจะกลายเป็นปัญหาหากกระบวนการหรือเธรดจำนวนมากกำลังอัปเดตการนับจำนวนเดียวกันพร้อมกัน เทคนิคการล็อคหลีกเลี่ยงปัญหาความสอดคล้องและส่งมอบความสอดคล้องของระดับธุรกรรม แต่ทำให้การแก้ปัญหาช้าลง
  4. ความทนทาน การวัดแสงมีผลต่อตัวเลขรายได้ซึ่งหมายความว่าฐานข้อมูลชั่วคราวไม่เหมาะในแง่ของความทนทาน พื้นที่เก็บข้อมูลในหน่วยความจำพร้อมตัวเลือกความทนทานเป็นตัวเลือกที่สมบูรณ์แบบ

การใช้ Redis สำหรับแอปพลิเคชันการวัดแสง

ในส่วนต่อไปนี้เราจะตรวจสอบวิธีใช้ Redis สำหรับโซลูชันการนับและการวัดแสง Redis มีโครงสร้างข้อมูลในตัวคำสั่งเกี่ยวกับอะตอมและความสามารถแบบ time-to-live (TTL) ที่สามารถใช้เพื่อเพิ่มพลังงานกรณีการใช้งานการวัดแสง Redis ทำงานบนเธรดเดียว ดังนั้นการอัปเดตฐานข้อมูลทั้งหมดจึงถูกทำให้เป็นอนุกรมทำให้ Redis สามารถดำเนินการเป็นที่เก็บข้อมูลที่ไม่มีการล็อก สิ่งนี้ช่วยลดความยุ่งยากในการออกแบบแอปพลิเคชันเนื่องจากนักพัฒนาไม่จำเป็นต้องใช้ความพยายามใด ๆ ในการซิงโครไนซ์เธรดหรือใช้กลไกการล็อกเพื่อความสอดคล้องของข้อมูล  

Atomic Redis คำสั่งสำหรับการนับ

Redis จัดเตรียมคำสั่งเพื่อเพิ่มค่าโดยไม่จำเป็นต้องอ่านไปยังหน่วยความจำหลักของแอปพลิเคชัน

คำสั่ง คำอธิบาย
INCR สำคัญ เพิ่มค่าจำนวนเต็มของคีย์ทีละคีย์
INCRBY การเพิ่มที่สำคัญ เพิ่มค่าจำนวนเต็มของคีย์ด้วยตัวเลขที่กำหนด
INCRBYFLOAT การเพิ่มที่สำคัญ เพิ่มค่าลอยตัวของคีย์ตามจำนวนที่กำหนด
DECR สำคัญ ลดค่าจำนวนเต็มของคีย์ทีละคีย์
DECRBY การลดลงของคีย์ ลดค่าจำนวนเต็มของคีย์ด้วยตัวเลขที่กำหนด
HINCRBY การเพิ่มฟิลด์คีย์ เพิ่มค่าจำนวนเต็มของฟิลด์แฮชตามจำนวนที่กำหนด
HINCRBYFLOAT การเพิ่มฟิลด์คีย์ เพิ่มค่าลอยของฟิลด์แฮชตามจำนวนที่กำหนด

Redis จัดเก็บจำนวนเต็มเป็นจำนวนเต็มที่ลงนาม 64 บิตฐาน 10 ดังนั้นขีด จำกัด สูงสุดสำหรับจำนวนเต็มจึงเป็นจำนวนที่มาก: 263 - 1 = 9,223,372,036,854,775,807

Time-to-Live (TTL) ในตัวบนปุ่ม Redis

หนึ่งในกรณีการใช้งานทั่วไปในการวัดแสงคือการติดตามการใช้งานตามเวลาและเพื่อ จำกัด ทรัพยากรหลังจากหมดเวลา ใน Redis เราสามารถตั้งค่าเวลาในการถ่ายทอดสดสำหรับคีย์ได้ Redis จะปิดใช้งานปุ่มโดยอัตโนมัติหลังจากหมดเวลาที่ตั้งไว้ ตารางต่อไปนี้แสดงวิธีการต่างๆในการหมดอายุคีย์

คำสั่ง คำอธิบาย
EXPIRE วินาทีสำคัญ กำหนดเวลาของคีย์ให้เป็นวินาที
EXPIREAT การประทับเวลาที่สำคัญ ตั้งค่าการหมดอายุของคีย์เป็นการประทับเวลา Unix
PEXPIRE มิลลิวินาทีที่สำคัญ กำหนดเวลาของคีย์ให้เป็นมิลลิวินาที
PEXPIREAT การประทับเวลาที่สำคัญ ตั้งค่าการหมดอายุของคีย์เป็นการประทับเวลา UNIX ในหน่วยมิลลิวินาที
SET ค่าคีย์ [EX วินาที] [PX มิลลิวินาที] ตั้งค่าสตริงเป็นคีย์พร้อมกับเวลาที่เป็นทางเลือกในการถ่ายทอดสด

ข้อความด้านล่างนี้จะบอกเวลาในการถ่ายทอดสดของคีย์ในรูปแบบวินาทีและมิลลิวินาที

คำสั่ง คำอธิบาย
TTL สำคัญ หาเวลาอยู่เพื่อหากุญแจ
PTTL สำคัญ หาเวลาที่จะใช้ชีวิตเพื่อหากุญแจในหน่วยมิลลิวินาที

เปลี่ยนโครงสร้างข้อมูลและคำสั่งเพื่อการนับที่มีประสิทธิภาพ

Redis เป็นที่ชื่นชอบสำหรับโครงสร้างข้อมูลเช่น Lists, Sets, Sorted Sets, Hashes และ Hyperloglogs สามารถเพิ่มอีกมากมายผ่าน Redis module API

Redis Labs

โครงสร้างข้อมูล Redis มาพร้อมกับคำสั่งในตัวที่ได้รับการปรับให้เหมาะกับการดำเนินการอย่างมีประสิทธิภาพสูงสุดในหน่วยความจำ (ตรงที่เก็บข้อมูล) โครงสร้างข้อมูลบางอย่างช่วยให้คุณทำสำเร็จได้มากกว่าการนับวัตถุ ตัวอย่างเช่นโครงสร้างข้อมูลชุดจะรับประกันความเป็นเอกลักษณ์ขององค์ประกอบทั้งหมด

ชุดที่เรียงลำดับก้าวไปอีกขั้นด้วยการตรวจสอบให้แน่ใจว่ามีการเพิ่มเฉพาะองค์ประกอบที่ไม่ซ้ำกันในชุดและให้คุณจัดลำดับองค์ประกอบตามคะแนนได้ การจัดลำดับองค์ประกอบของคุณตามเวลาในโครงสร้างข้อมูลชุดเรียงลำดับจะเสนอฐานข้อมูลอนุกรมเวลาให้คุณ ด้วยความช่วยเหลือของคำสั่ง Redis คุณสามารถรับองค์ประกอบของคุณตามลำดับที่แน่นอนหรือลบรายการที่คุณไม่ต้องการอีกต่อไป

Hyperloglog เป็นโครงสร้างข้อมูลพิเศษอีกแบบหนึ่งที่ประมาณการจำนวนรายการที่ไม่ซ้ำกันหลายล้านรายการโดยไม่จำเป็นต้องจัดเก็บวัตถุด้วยตนเองหรือส่งผลกระทบต่อหน่วยความจำ

โครงสร้างข้อมูล คำสั่ง คำอธิบาย
รายการ LLEN สำคัญ รับความยาวของรายการ
ชุด SCARD สำคัญ รับจำนวนสมาชิกในชุด (cardinality)
ชุดเรียง ZCARD สำคัญ รับจำนวนสมาชิกในชุดที่จัดเรียง
ชุดเรียง ZLEXCOUNT สูงสุดของคีย์ต่ำสุด นับจำนวนสมาชิกในชุดที่จัดเรียงระหว่างช่วงพจนานุกรมที่กำหนด
กัญชา HLEN สำคัญ รับจำนวนฟิลด์ในแฮช
Hyperloglog PFCOUNT สำคัญ รับจำนวนคาร์ดินาลิตี้โดยประมาณของชุดที่สังเกตได้จากโครงสร้างข้อมูล Hyperloglog
บิตแมป BITCOUNT คีย์ [จุดเริ่มต้น] นับชุดบิตในสตริง

Redis คงอยู่และจำลองแบบในหน่วยความจำ

กรณีการใช้การวัดผลเช่นการชำระเงินเกี่ยวข้องกับการจัดเก็บและอัปเดตข้อมูลที่มีความสำคัญต่อธุรกิจ การสูญเสียข้อมูลมีผลกระทบโดยตรงต่อรายได้ นอกจากนี้ยังสามารถทำลายบันทึกการเรียกเก็บเงินซึ่งมักเป็นข้อกำหนดด้านการปฏิบัติตามข้อกำหนดหรือการกำกับดูแล

คุณสามารถปรับความสอดคล้องและความทนทานใน Redis ตามความต้องการข้อมูลของคุณ หากคุณต้องการหลักฐานบันทึกถาวรสำหรับข้อมูลการวัดแสงของคุณคุณสามารถบรรลุความทนทานได้ด้วยความสามารถในการคงอยู่ของ Redis Redis รองรับ AOF (ไฟล์ต่อท้ายเท่านั้น) ซึ่งคัดลอกคำสั่งเขียนไปยังดิสก์เมื่อเกิดขึ้นและการสแนปช็อตซึ่งรับข้อมูลตามที่มีอยู่ในช่วงเวลาหนึ่งและเขียนลงในดิสก์

สถาปัตยกรรม Redis ที่ไม่มีการล็อคในตัว

การประมวลผล Redis เป็นเธรดเดียว สิ่งนี้ทำให้มั่นใจได้ถึงความสมบูรณ์ของข้อมูลเนื่องจากคำสั่งการเขียนทั้งหมดจะถูกทำให้เป็นอนุกรมโดยอัตโนมัติ สถาปัตยกรรมนี้ช่วยลดภาระของนักพัฒนาและสถาปนิกจากภาระในการซิงโครไนซ์เธรดในสภาพแวดล้อมแบบมัลติเธรด

ในกรณีของแอปพลิเคชันมือถือยอดนิยมสำหรับผู้บริโภคอาจมีผู้ใช้หลายพันคนและบางครั้งหลายล้านคนเข้าถึงแอปพลิเคชันพร้อมกัน สมมติว่าแอปพลิเคชันกำลังวัดเวลาที่ใช้และผู้ใช้สองคนขึ้นไปสามารถแชร์นาทีพร้อมกันได้ เธรดแบบขนานสามารถอัปเดตอ็อบเจ็กต์เดียวกันได้โดยไม่ต้องกำหนดภาระเพิ่มเติมในการตรวจสอบความสมบูรณ์ของข้อมูล ซึ่งจะช่วยลดความซับซ้อนของการออกแบบแอปพลิเคชันในขณะที่มั่นใจในความเร็วและประสิทธิภาพ

การใช้งานตัวอย่างการวัด Redis

มาดูโค้ดตัวอย่างกัน หลายสถานการณ์ด้านล่างนี้จะต้องมีการใช้งานที่ซับซ้อนมากหากฐานข้อมูลที่ใช้ไม่ใช่ Redis

การบล็อกการพยายามเข้าสู่ระบบหลายครั้ง

เพื่อป้องกันการเข้าถึงบัญชีโดยไม่ได้รับอนุญาตบางครั้งเว็บไซต์จะบล็อกผู้ใช้ไม่ให้พยายามเข้าสู่ระบบหลายครั้งภายในช่วงเวลาที่กำหนด ในตัวอย่างนี้เรา จำกัด ไม่ให้ผู้ใช้พยายามเข้าสู่ระบบมากกว่าสามครั้งในหนึ่งชั่วโมงโดยใช้ฟังก์ชันการแสดงเวลาที่สำคัญง่ายๆ

กุญแจสำคัญในการระงับจำนวนครั้งในการเข้าสู่ระบบ:

user_login_attempts:

ขั้นตอน:

รับจำนวนครั้งในปัจจุบัน:

รับ user_login_attempts:

ถ้าเป็นโมฆะให้ตั้งค่าคีย์ด้วยเวลาหมดอายุเป็นวินาที (1 ชั่วโมง = 3600 วินาที):

กำหนด user_login_attempts: 1 3600

หากไม่เป็นโมฆะและหากจำนวนมากกว่า 3 แสดงว่ามีข้อผิดพลาด:

ถ้าไม่เป็นโมฆะและถ้าจำนวนน้อยกว่าหรือเท่ากับ 3 ให้เพิ่มจำนวน:

INCR user_login_attempts:

เมื่อพยายามเข้าสู่ระบบสำเร็จคีย์อาจถูกลบดังนี้:

DEL user_login_attempts:

จ่ายตามที่คุณไป

โครงสร้างข้อมูล Redis Hash มีคำสั่งง่ายๆในการติดตามการใช้งานและการเรียกเก็บเงิน ในตัวอย่างนี้สมมติว่าลูกค้าทุกคนมีข้อมูลการเรียกเก็บเงินที่เก็บไว้ใน Hash ดังที่แสดงด้านล่าง:

customer_billing:

     การใช้งาน

     ค่าใช้จ่าย

     .

     .

สมมติว่าแต่ละหน่วยมีค่าใช้จ่ายสองเซนต์และผู้ใช้ใช้ไป 20 หน่วย คำสั่งในการอัปเดตการใช้งานและการเรียกเก็บเงิน ได้แก่ :

ลูกค้า hincrby: การใช้งาน 20

ลูกค้า hincrbyfloat: ต้นทุน. 40

อย่างที่คุณสังเกตเห็นแอปพลิเคชันของคุณสามารถอัปเดตข้อมูลในฐานข้อมูลได้โดยไม่ต้องให้แอปพลิเคชันโหลดข้อมูลจากฐานข้อมูลลงในหน่วยความจำของตัวเอง นอกจากนี้คุณสามารถแก้ไขแต่ละฟิลด์ของวัตถุ Hash ได้โดยไม่ต้องอ่านทั้งวัตถุ

โปรดทราบ: จุดประสงค์ของตัวอย่างนี้คือการแสดงวิธีใช้hincrbyและhincrbyfloatคำสั่ง ในการออกแบบที่ดีคุณจะหลีกเลี่ยงการจัดเก็บข้อมูลที่ซ้ำซ้อนเช่นการใช้งานและค่าใช้จ่าย