สามวิธีในการรักษาความสม่ำเสมอของแคช

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

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

อุปสรรคสามประการต่อความสอดคล้องของแคช

แน่นอนว่าข้อดีเหล่านี้อยู่บนสมมติฐานพื้นฐานที่ว่าข้อมูลในแคชหรือแคชจะรักษาค่าเดียวกันกับข้อมูลต้นทางเสมอ แม้ว่าสิ่งนี้อาจดูเหมือนเป็นเป้าหมายที่ตรงไปตรงมา แต่ในทางทฤษฎีง่ายกว่าในทางปฏิบัติ อันที่จริง มีข้อผิดพลาดสามประการที่อาจทำให้สะดุดได้: 

1. เมื่อการเปลี่ยนแปลงฐานข้อมูลหลักไม่ปรากฏในแคช

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

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

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

2. เมื่อมีความล่าช้าในการอัปเดตผลลัพธ์แคช

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

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

3. เมื่อโหนดแคชไม่สอดคล้องกัน

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

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

ค่าใช้จ่ายของแคชที่ไม่สอดคล้องกัน

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

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

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

สามวิธีในการต่อต้านความไม่สอดคล้องกัน

โชคดีที่แต่ละแหล่งที่มาของแคชอาจมีความไม่สอดคล้องกันข้างต้น มีวิธีแก้ปัญหาจำนวนหนึ่งที่เกี่ยวข้อง

1. แคชใช้ไม่ได้

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

2. แคชการเขียนผ่าน

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

3. เขียนหลังแคช

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

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

Redis Enterprise ช่วยเหลือ

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

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

การทำสำเนาทางภูมิศาสตร์แบบแอ็คทีฟแอ็กทีฟเฉพาะของ Redis Enterprise ใช้อัลกอริธึมที่ซับซ้อนซึ่งออกแบบมาเพื่อจัดการกับข้อขัดแย้งในการเขียนที่อาจเกิดขึ้นซึ่งอาจทำให้แคชไม่สอดคล้องกัน อัลกอริธึมเหล่านี้อิงตามประเภทข้อมูลจำลองที่ไม่มีข้อขัดแย้ง (CRDT) ซึ่งช่วยให้มั่นใจว่าการเขียนจากการจำลองหลายรายการสามารถรวมเข้าด้วยกันในลักษณะที่รักษาความสอดคล้องได้อย่างมีประสิทธิภาพ

ไชโยสำหรับฮ็อบก็อบลิน!

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

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

รับเรื่องราวทั้งหมดของการแคช อ่าน การแคชตามขนาดด้วย Redis , โดย ลี อัตชิสัน