มีผลิตภัณฑ์ยอดนิยมในหน้าแรกของห้างสรรพสินค้าออนไลน์ดังนั้นอัตราการคลิกของผลิตภัณฑ์เหล่านี้จึงสูงมาก เมื่อผู้ใช้คลิกบนผลิตภัณฑ์ยอดนิยมเขาต้องป้อนหน้าข้อมูลรายละเอียดของผลิตภัณฑ์เช่นเดียวกับบน Taobao จากนั้นทุกครั้งที่คุณคลิกคุณต้องไปที่พื้นหลังเพื่อสอบถามข้อมูลรายละเอียดของผลิตภัณฑ์และคุณจะส่งคำสั่ง SQL ที่เกี่ยวข้อง ทุกครั้งที่คุณรีเฟรชหน้าโดยละเอียดคุณจะส่งคำสั่ง SQL ด้วยวิธีนี้ประสิทธิภาพจะได้รับผลกระทบอย่างมาก จากนั้นการใช้แคชทุติยภูมิของไฮเบอร์เนตสามารถแก้ปัญหานี้ได้
บางคนอาจคิดว่าเราสามารถใช้การเปลี่ยนเส้นทางได้ ด้วยวิธีนี้เมื่อผู้ใช้เข้าชมครั้งแรกพวกเขาสามารถค้นหาข้อมูลและวางไว้ในเซสชัน ในอนาคตทุกครั้งที่ผู้ใช้รีเฟรชพวกเขาสามารถไปที่เซสชันดังนั้นจึงไม่จำเป็นต้องสอบถามในฐานข้อมูล สิ่งนี้สมเหตุสมผล แต่ไม่สามารถแก้ปัญหาข้างต้นได้เพราะสิ่งที่เราต้องการแก้ไขคือผู้ใช้หลายคนจะเข้าถึงผลิตภัณฑ์เดียวกันและคลิกที่ผลิตภัณฑ์เดียวกัน การเปลี่ยนเส้นทางสามารถตรวจสอบให้แน่ใจว่าผู้ใช้รายเดียวกันจะคลิกหรือรีเฟรช แต่แคชรองสามารถแก้ปัญหาเหล่านี้ได้
ก่อนอื่นให้อธิบายเทคโนโลยีการแคชทุติยภูมิโดยใช้รายละเอียด Hibernate4.3 จากนั้นสร้างการกำหนดค่าเฉพาะสำหรับโครงการนี้
1. Hibernate4.3 ระดับ 2 การกำหนดค่าพื้นฐานแคช
ซึ่งแตกต่างจาก Hibernate3 แพ็คเกจหลักของ Hibernate4.3 ไม่มีคลาสที่เกี่ยวข้องกับแคช หากเราต้องการใช้แคชรองเราต้องเพิ่มแพ็คเกจ Jar แคช จากการดาวน์โหลดอย่างเป็นทางการของ hibernate-release-4.3.11.final มีแพ็คเกจ JAR ที่จำเป็นสำหรับแคชรองซึ่งจะต้องเพิ่มลงในโครงการก่อน ดังนี้:
จากนั้นเราจะกำหนดค่าการกำหนดค่าที่เกี่ยวข้องกับแคชใน hibernate.cfg.xml:
<hibernate-configuration> <session-factory> <property name = "Dialect"> org.hibernate.dialect.mysqldialect </property> <property name = "show_sql"> true </property> <!-กำหนดค่าแคชรองผู้ให้บริการ name = "hibernate.cache.region.factory_class"> org.hibernate.cache.ehcache.ehcacheregionfactory < /คุณสมบัติ> <การแมป /> <การแมป /> <การแมป /> <! สิ่งนี้จะแสดงผลิตภัณฑ์ยอดนิยมเป็นหลักในหน้าแรกดังนั้นคลาสผลิตภัณฑ์รองรับการแคช-> <class-cache usage = "อ่านอย่างเดียว"/> </session-factory> </hibernate-configuration>
จากนั้นเราเปิดเซิร์ฟเวอร์ Tomcat จากนั้นไปที่หน้าแรกคลิกที่ผลิตภัณฑ์ยอดนิยมและไม่มีการส่งคำสั่ง SQL ในพื้นหลัง คุณอาจสงสัยว่าแคชระดับที่สองนั้นง่ายหรือไม่? เพียงกำหนดค่าสองรายการนี้? ในความเป็นจริงเหตุผลที่แคชระดับ 2 มีผลจนถึงตอนนี้คือมันมีการกำหนดค่าเริ่มต้น มีไฟล์ ehcache-failsafe.xml ใน ehcache-core-2.3.3.jar ด้านบนซึ่งมีการกำหนดค่าเริ่มต้นแล้ว เราจะวิเคราะห์โดยละเอียดในภายหลัง มาวิเคราะห์กลยุทธ์การสืบค้นของ Hibernate ก่อน:
2. กลยุทธ์การสอบถาม Hibernate4.3
Hibernate รองรับวิธีการสืบค้นสองวิธี: Session Query และ HQL Query
มี session.save () update () delete () get () load () และวิธีการอื่น ๆ ในเซสชัน วิธีนี้ทำงานเฉพาะในบันทึกเดียวและค่าเริ่มต้นคือการสนับสนุนแคชระดับ 2 โดยไม่มีการกำหนดค่าใด ๆ ดังนั้น: การกำหนดค่าแบบอ่านอย่างเดียวมีผลสำหรับเซสชัน หากการอ่านอย่างเดียวได้รับการกำหนดค่าในแคชรองในเซสชันการดำเนินการ session.update () และ delete () จะล้มเหลวทั้งคู่จะล้มเหลว หากคุณต้องการประสบความสำเร็จคุณต้องกำหนดค่าการอ่าน-เขียน แต่บันทึก () และรับ () โหลด () สำเร็จ
HQL: วิธีนี้ใช้เพื่อใช้งานหลายระเบียนโดยค่าเริ่มต้นเช่นรายการ () และวิธีการ ExecuteUpDate () วิธีนี้ค่าเริ่มต้นของการกำหนดค่าแคชรองรวมถึงการอ่านอย่างเดียวไม่ถูกต้อง รายการของ HQL () แบบสอบถามหลายระเบียนตรวจสอบฐานข้อมูลโดยตรงและส่งผลลัพธ์การสืบค้นไปยังแคชรองซึ่งอำนวยความสะดวกในการโทรของ Get () และโหลด () ExecuteUpdate ไม่รองรับการแคชรองและยังได้รับการอัปเดตโดยตรงไปยังฐานข้อมูล Hibernate จะช่วยให้มั่นใจได้ว่าฐานข้อมูลและแคชจะถูกซิงโครไนซ์ หมายเหตุ: HQL ไม่มีวิธีการบันทึก () หากคุณต้องการแทรกข้อมูลคุณสามารถเรียกใช้เมธอดเซสชัน () เท่านั้น
[หมายเหตุ]: แคชระดับแรก (มีอยู่โดยค่าเริ่มต้น) ในไฮเบอร์เนตเรียกอีกอย่างว่าแคชระดับเซสชันไม่ได้ใช้เพื่อปรับปรุงประสิทธิภาพ แต่เพื่อจัดการธุรกรรม; แคชระดับที่สองเป็นแคช SessionFactory ซึ่งใช้ได้สำหรับทุกเซสชันและวงจรชีวิตของมันเหมือนกับ SessionFactory (SessionFactory เป็นซิงเกิลและจะถูกสร้างขึ้นเมื่อโครงการเริ่มต้น)
สำหรับกลยุทธ์การสืบค้นที่เฉพาะเจาะจงมาดูภาพต่อไปนี้:
【หมายเหตุ】: หากข้อความของภาพเล็กเกินไปคุณสามารถลากรูปภาพไปยังหน้าต่างใหม่เพื่อดู ~
ข้างต้นเป็นกลยุทธ์การสืบค้นของไฮเบอร์เนต มาดูการกำหนดค่าแคชรอง
3. ไฮเบอร์เนต 4.3 ระดับ 2 แคชการกำหนดค่าขั้นสูง
ดังที่ได้กล่าวมาแล้วเหตุผลที่เราสามารถใช้แคชระดับ 2 หลังจากกำหนดค่าสองรายการใน hibernate.cfg.xml เป็นเพราะมีการกำหนดค่าเริ่มต้น มาดูการกำหนดค่าเริ่มต้นนี้ก่อน:
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalocation = "../ config/ehcache.xsd"> <! path = "java.io.tmpdir"/> <defaultCache maxElementsInMemory = "10,000": <!-จำนวนวัตถุสูงสุดที่รองรับโดยหน่วยความจำ-> นิรันดร์ = "เท็จ": <! หน่วยคือวินาที นั่นคือถ้าไม่มีใครใช้วัตถุนี้หลังจาก 60 วินาทีมันจะถูกทำลายล่วงหน้า-> timetoliveseconds = "120": <!-วงจรชีวิตของวัตถุคือวินาที-> overflowTodisk = "true": <! MemoryStoreEvictionPolicy = "LRU": <!-นโยบายการแทนที่วัตถุ-> /> </ehcache>
คำอธิบายที่เกี่ยวข้องเกี่ยวกับการกำหนดค่าเริ่มต้นมีอยู่แล้วในความคิดเห็นด้านบนแล้ว ตอนนี้เรารู้แล้วว่าเป็นเพราะการกำหนดค่าเริ่มต้นนี้ที่แคชระดับสองของ Hibernate 4.3 สามารถดำเนินการได้อย่างถูกต้อง ตอนนี้ถ้าเราต้องการกำหนดค่าแคชตัวเองเราต้องสร้างไฟล์ ehcache.xml ใหม่ในไดเรกทอรี SRC แล้วกำหนดค่ารายการการกำหนดค่าข้างต้นใหม่ ต่อไปเราต้องทดสอบการกำหนดค่าแต่ละครั้ง ก่อนการทดสอบฉันจะโพสต์สถานการณ์ที่แสดงในหน้าแรกและสร้างตัวเลข มาอธิบายในภายหลังเมื่อทำการทดสอบ:
ด้านบนเป็นส่วนหนึ่งของเนื้อหาที่แสดงในหน้าแรก Hibernate พบข้อมูลการแสดงผลจากฐานข้อมูลและมีการแสดง เราจะหมายเลขพวกเขาและจะง่ายต่อการวิเคราะห์เมื่อเราทดสอบแคชในภายหลัง เริ่มทดสอบรายการการกำหนดค่าแคชด้านบน:
ทดสอบ 1: ทดสอบจำนวนวัตถุในหน่วยความจำ เปลี่ยนการกำหนดค่าเป็นสถานการณ์ต่อไปนี้:
<defaultCache MaxElementsInMemory = "6" <!-การตั้งค่ารองรับ 6 แคช-> นิรันดร์ = "จริง" ล้นล้น = "false" memoryStoreEvictionPolicy = "FIFO": <!
หลังจากการกำหนดค่าเสร็จสมบูรณ์เรารีสตาร์ทเซิร์ฟเวอร์และเปิดหน้าแรก เนื่องจากมีการกำหนดค่า 6 ครั้งมีเพียง 6 ระเบียนสุดท้ายที่พบในแคชเท่านั้นที่เก็บไว้นั่นคือหมายเลข 3-8 เราคลิกผลิตภัณฑ์ใด ๆ ใน 3-8 เพื่อเข้าสู่หน้ารายละเอียดผลิตภัณฑ์ โปรดทราบว่าคอนโซลในพื้นหลังไม่ได้ส่งออกข้อมูลแบบสอบถามใด ๆ ซึ่งหมายความว่าไม่มีการส่งคำสั่ง SQL อย่างไรก็ตามเมื่อเราคลิกที่หมายเลขผลิตภัณฑ์ 2 คำสั่ง SQL จะถูกส่งในพื้นหลังนั่นคือฐานข้อมูลจะถูกสืบค้น เราได้รับการสนับสนุนและคลิกที่ผลิตภัณฑ์ 2 อีกครั้งและไม่มีการส่งคำสั่ง SQL ซึ่งหมายความว่ามันถูกใส่ลงในแคช แต่แคชรองรับเพียง 6 ข้อมูลเท่านั้น เนื่องจากกลยุทธ์การเปลี่ยนวัตถุที่กำหนดค่าเป็นครั้งแรกก่อนออกดังนั้นหมายเลข 3 ในแคชจึงถูกลบออกไป เราคลิก 3 เพื่อลองและส่งคำสั่ง SQL ดังนั้นการทดสอบจะเสร็จสมบูรณ์และการดำเนินการแคชระดับที่สองเป็นเรื่องปกติ
การทดสอบ 2: วงจรชีวิตของวัตถุทดสอบ เปลี่ยนการกำหนดค่าเป็นสถานการณ์ต่อไปนี้:
<defaultCache MaxElementsInMemory = "100" Eternal = "FALSE" <!-โดยการจับคู่วงจรชีวิตต่อไปนี้จะถูกตั้งค่า-> timetoidleseconds = "20" TimetoLiveSeconds = "40" OverflowTodisk = "False" MemoryStoreEvictionPolicy
เวลาแคชจะถูกกำหนดค่าเป็น 40 วินาทีและหากไม่มีการดำเนินการใน 20 วินาทีมันจะถูกลบออก เนื่องจากเราได้กำหนด 100 ระเบียนหมายเลข 1-8 ด้านบนทั้งหมดอยู่ในแคช หลังจากเราเปิดใช้งานเซิร์ฟเวอร์เราคลิกที่หนึ่งตัวอย่างเช่นคลิกที่หมายเลข 8 และไม่มีการออกคำสั่ง SQL โดยปกติหลังจาก 20 วินาทีให้คลิกที่หมายเลข 8 และส่งคำสั่ง SQL แสดงว่าวงจรชีวิตที่เรากำหนดค่ามีผล โปรดทราบว่าการกำหนดค่าไม่สามารถสั้นเกินไปเช่น 10 วินาทีเนื่องจาก Tomcat จะใช้เวลาหลายวินาทีในการเริ่มต้น หากมีการกำหนดค่าน้อยกว่าเวลาอาจได้รับก่อนการทดสอบ ... มันจะไม่ทำงาน
ทดสอบ 3: ทดสอบว่าแคชทุติยภูมิรองรับที่เก็บฮาร์ดดิสก์หรือไม่
<defaultCache MaxElementsInMemory = "4" Eternal = "False" <!-โดยการตั้งค่าเท็จสามารถตั้งค่าวัฏจักรชีวิตต่อไปนี้ได้-> Timetoidleseconds = "100" TimetoLiveSeconds = "200" OverflowToDisk = "True" <!
เราตั้งค่าการจัดเก็บฮาร์ดดิสก์รองรับเป็นจริงและกำหนดค่าความจุสูงสุดของการจัดเก็บข้อมูลของแคชรองเป็น 4 รีสตาร์ทเซิร์ฟเวอร์ เนื่องจากแคชรองเก็บได้มากถึง 4 ระเบียนจึงต้องมีหมายเลข 5-8 การคลิก 5-8 จะไม่ส่งคำสั่ง SQL อย่างแน่นอน แต่เมื่อเราคลิก 1-4 เราจะไม่ส่งคำสั่ง SQL เนื่องจากเราได้ตั้งค่าการสนับสนุนสำหรับที่เก็บฮาร์ดดิสก์ Hibernate จะเก็บผลลัพธ์การสืบค้นบนฮาร์ดดิสก์ดังนั้นเราจึงสามารถรับข้อมูลได้โดยตรงโดยไม่ต้องส่งคำสั่ง SQL
ทดสอบ 4: ทดสอบกลยุทธ์การเปลี่ยนของแคชระดับ 2
<defaultCache <!- FIFO ถูกกำจัดและจะไม่ถูกนำมาใช้อีกครั้ง ... LRU: อัลกอริทึมที่เข้าถึงได้อย่างน้อยเมื่อเร็ว ๆ นี้ (นโยบายเวลา) จะเพิกเฉยต่อความถี่ในการเข้าถึง -> MaxElementsInMemory = "3" Eternal = "False" <!-เฉพาะเมื่อมีการกำหนดค่าเป็นเท็จสามารถตั้งค่าวงจรชีวิตต่อไปนี้ได้-> timetoidleseconds = "100" timetoliveseconds = "200" verflowTodisk = "false" <!
ตามชื่อแนะนำ LRU และ LFU มุ่งเน้นไปที่เวลาการเข้าถึงและความถี่สุดท้ายตามลำดับ ลองใช้ LFU เป็นตัวอย่าง ตอนนี้เราตั้งค่าที่เก็บข้อมูลสูงสุดเป็น 3 ระเบียนนั่นคือหมายเลข 6-8 ตอนนี้เราเข้าถึงหมายเลข 6 สามครั้งหมายเลข 7 สองครั้งหมายเลข 8 ครั้งและจะไม่ออกคำสั่ง SQL เราเข้าถึงหมายเลข 7 อีกครั้งและออกคำสั่ง SQL ตอนนี้หมายเลข 7 อยู่ในแคชหมายเลข 8 ถูกลบออกเนื่องจากมีจำนวนการเข้าถึงน้อยที่สุด เราสามารถคลิกหมายเลข 8 อีกครั้งเพื่อทดสอบออกคำสั่ง SQL และการทดสอบนั้นสำเร็จ หากเป็น LRU หมายเลข 6 ที่เพิ่งลบออกคือหมายเลข 6 เนื่องจากหมายเลข 6 คือการเข้าถึงที่เร็วที่สุด
ณ จุดนี้ฉันเชื่อว่าทุกคนได้เชี่ยวชาญในการใช้แคชรองและการทดสอบแคชรองสิ้นสุดลงที่นี่ มากำหนดค่าสำหรับโครงการห้างสรรพสินค้าออนไลน์ของเรา
4. การกำหนดค่าจริงของโครงการห้างสรรพสินค้าออนไลน์
เรากำหนดค่าจำนวนสูงสุดของระเบียนในแคชรองเป็น 1,000 ตั้งวงจรชีวิตเป็น 120 วินาทีและรอบช่วงเวลาถึง 60 วินาที เรารองรับการจัดเก็บฮาร์ดดิสก์และใช้กลยุทธ์การแทนที่ความถี่ (LFU) เนื่องจากหากอัตราการคลิกผู้ใช้สูงจะต้องวางไว้ในแคชรอง
<ehcache xmlns: xsi = "http://www.w3.org/2001/xmlschema-instance" xsi: nonamespaceschemalocation = "../ config/ehcache.xsd"> <! <defaultCache MaxElementsInMemory = "1,000" Eternal = "false" timetoidleseconds = "60" timetoliveseconds = "120" OverflowTodisk = "true" memoryStoreEvictionPolicy = "lfu" /> </ehcache>
เมื่อใช้ร่วมกับโครงการ Mall ออนไลน์การกำหนดค่าและการใช้แคชระดับสองของ Hibernate 4.3 ได้รับการแนะนำ
ที่อยู่ดั้งเดิม: http://blog.csdn.net/eson_15/article/details/51405911
ข้างต้นเป็นเนื้อหาทั้งหมดของบทความนี้ ฉันหวังว่ามันจะเป็นประโยชน์ต่อการเรียนรู้ของทุกคนและฉันหวังว่าทุกคนจะสนับสนุน wulin.com มากขึ้น