ทำความเข้าใจกับการแคชเว็บ

ถาม: แคชประเภทใดที่เป็นแคชที่ดี

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

ดังนั้นในการแก้ปัญหา แคชใดเป็นแคชที่ดีที่สุด คำตอบของฉันสำหรับคำถามนี้คือ: แคชที่มีอัตราการเข้าชมแคชสูงเป็นแคชที่ดี

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

อัตราการเข้าถึงแคช

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

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

สำหรับการแคช: โดยปกติแล้ว บุคคลที่ใช้บ่อยที่สุดจะเป็นเพียงส่วนเล็กๆ ของทั้งหมด การใช้บ่อยน้อยที่สุดคิดเป็นสัดส่วนขนาดใหญ่ของทั้งหมด

เราจึงมักเห็นข้อมูลดังนี้:

จากองค์ประกอบแคช 10,000 รายการ มี 100 องค์ประกอบที่ใช้บ่อย เกือบทุกนาที ร้องขอข้อมูล 2,000 ชิ้นต่อชั่วโมง มีการร้องขอข้อมูล 3,000 ชิ้นวันละครั้ง และข้อมูลที่เหลือจะไม่ถูกใช้แม้แต่ครั้งเดียวหลังจากถูกโยนลงในแคช

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

อย่างไรก็ตาม: ฮาร์ดแวร์มีการพัฒนาอย่างรวดเร็ว และปริมาณข้อมูลก็เช่นกัน สำหรับเว็บไซต์ขนาดเล็ก หากแคชข้อมูล 10,000 ชิ้น ข้อมูลทั้งหมดจะถูกแคช อย่างไรก็ตาม เว็บไซต์ขนาดใหญ่มีข้อมูลหรือข้อมูลระดับ T อย่างน้อยล้านรายการ แน่นอนว่าข้อมูลทั้งหมดนี้ไม่สามารถโยนลงในแคชได้ ในเวลานี้ เป็นสิ่งสำคัญมากที่จะต้องออกแบบโซลูชันการแคชที่เหมาะสมและปรับปรุงอัตราการเข้าใช้แคช และก็เป็นสิ่งที่จำเป็น

วิธีการทั่วไปบางประการในการปรับปรุงอัตราการเข้าถึงแคช

จากมุมมองทางเทคนิคล้วนๆ เราจะบันทึกเฉพาะจำนวนคำขอของผู้ใช้ต่อหน่วยเวลา และแคชข้อมูลที่ใช้บ่อยที่สุดตามข้อมูลนี้

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

อีกตัวอย่างหนึ่ง โดยทั่วไปโพสต์ที่มีการตอบกลับจำนวนมากจะมีคนดูมากกว่าโพสต์ที่มีการตอบกลับน้อยกว่า

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

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

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

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

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

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

หลังจากที่กล่าวถึงปัญหามากมายเกี่ยวกับอัตราการเข้าถึงแคช มาสรุปมุมมองเกี่ยวกับอัตราการเข้าถึงแคชโดยย่อ:

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

กิจกรรมวงจรชีวิตของแคช

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

ในทางกลับกันอาจต้องผ่านกิจกรรมดังต่อไปนี้:

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

โดยทั่วไป ฉันจะถามว่า คุณพบกลยุทธ์การหมดอายุของแคชอะไรบ้างในแคชที่คุณสัมผัสด้วย

กลยุทธ์การหมดอายุที่พบบ่อยที่สุดมีดังนี้:

หากไม่ได้รับการร้องขอมาเป็นเวลานาน ฟังก์ชั่นนี้จะหมดอายุลง ฟังก์ชัน Section ที่ได้รับจาก ASP และ ASP.net ในความเป็นจริงมันเป็นแคช

แคชที่อาศัยการเปลี่ยนแปลงไฟล์จะหมดอายุเมื่อมีการแก้ไขไฟล์ ซึ่งโดยทั่วไปคือ Web.config ของไซต์ WEB เมื่อไฟล์เปลี่ยนแปลง ไม่เพียงแต่จะรีสตาร์ทแคชเท่านั้น แต่กระบวนการ IIS จะดำเนินการเผยแพร่ด้วย

จากนี้ คุณอาจเห็นนโยบายการหมดอายุของแคชสำหรับการอ้างอิงจำนวนมาก ตัวอย่างเช่น นโยบายการหมดอายุของแคชที่อาศัยฐานข้อมูล

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

อีกตัวอย่างหนึ่งคือ แคชของโพสต์ในฟอรัมตามคะแนนใหม่จะหมดอายุเมื่อไม่มีรายการอ้างอิงถึงโพสต์ และโพสต์นั้นหมดอายุ

ปัญหาการซิงโครไนซ์แคช

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

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

วิธีการง่ายๆ สามารถทำให้โค้ดลอจิกของคุณซับซ้อนมากได้

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

เริ่มต้นและกรอกข้อมูลแคช

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

จำเป็นต้องพิจารณาประเด็นต่อไปนี้ระหว่างการดำเนินการเตรียมใช้งานข้อมูลแคช:

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

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

http://blog.csdn.net/ghj1976/archive/2007/09/01/1768676.aspx