สวัสดี! ฉันชื่อ Alexey Pyankov เป็นนักพัฒนาของบริษัท Sportmaster ในนั้น ฉันเล่าให้ฟังว่าการทำงานบนเว็บไซต์ Sportmaster เริ่มต้นขึ้นในปี 2012 ได้อย่างไร ความคิดริเริ่มใดบ้างที่เราจัดการเพื่อ “ผลักดัน” และในทางกลับกัน เรารวบรวมคราดอะไร
วันนี้ฉันต้องการแบ่งปันความคิดที่เป็นไปตามหัวข้ออื่น - การเลือกระบบแคชสำหรับแบ็กเอนด์ Java ในแผงผู้ดูแลระบบของไซต์ โครงเรื่องนี้มีความหมายพิเศษสำหรับฉัน - แม้ว่าเรื่องราวจะคลี่คลายเพียง 2 เดือน แต่ในช่วง 60 วันนี้เราทำงาน 12-16 ชั่วโมงและไม่มีวันหยุดแม้แต่วันเดียว ฉันไม่เคยคิดหรือจินตนาการมาก่อนว่าจะทำงานหนักขนาดนี้ได้
ดังนั้นฉันจึงแบ่งข้อความออกเป็น 2 ส่วนเพื่อไม่ให้โหลดทั้งหมด ในทางตรงกันข้ามส่วนแรกจะเบามาก - การเตรียมการ การแนะนำ ข้อควรพิจารณาบางประการเกี่ยวกับแคชคืออะไร หากคุณเป็นนักพัฒนาที่มีประสบการณ์อยู่แล้วหรือเคยทำงานกับแคช ด้านเทคนิคไม่น่าจะมีอะไรใหม่ในบทความนี้ แต่สำหรับรุ่นน้อง การทบทวนเล็กๆ น้อยๆ เช่นนี้สามารถบอกเขาได้ว่าควรมองไปในทิศทางใดหากพบว่าตัวเองอยู่ทางแยกดังกล่าว
เมื่อเว็บไซต์ Sportmaster เวอร์ชันใหม่ถูกนำไปใช้จริง ข้อมูลก็ได้รับในลักษณะที่พูดง่ายๆ ว่าไม่สะดวกนัก พื้นฐานคือตารางที่เตรียมไว้สำหรับเวอร์ชันก่อนหน้าของไซต์ (Bitrix) ซึ่งจะต้องถูกดึงเข้าสู่ ETL นำมาสู่รูปแบบใหม่และเสริมด้วยสิ่งเล็กๆ น้อยๆ มากมายจากระบบอื่นๆ อีกนับสิบ เพื่อให้รูปภาพหรือคำอธิบายผลิตภัณฑ์ใหม่ปรากฏบนเว็บไซต์ คุณต้องรอจนถึงวันถัดไป - อัปเดตเฉพาะตอนกลางคืนวันละครั้งเท่านั้น
ในตอนแรก มีความกังวลมากมายตั้งแต่สัปดาห์แรกของการผลิต ซึ่งความไม่สะดวกสำหรับผู้จัดการเนื้อหานั้นเป็นเพียงเรื่องเล็กๆ น้อยๆ แต่ทันทีที่ทุกอย่างคลี่คลาย การพัฒนาโครงการก็ดำเนินต่อไป - ไม่กี่เดือนต่อมาในต้นปี 2015 เราก็เริ่มพัฒนาแผงผู้ดูแลระบบอย่างแข็งขัน ในปี 2015 และ 2016 ทุกอย่างเป็นไปด้วยดี เราเปิดตัวเป็นประจำ แผงผู้ดูแลระบบครอบคลุมการเตรียมข้อมูลมากขึ้นเรื่อย ๆ และเรากำลังเตรียมพร้อมสำหรับความจริงที่ว่าในไม่ช้าทีมงานของเราจะได้รับความไว้วางใจในเรื่องที่สำคัญและซับซ้อนที่สุด - ผลิตภัณฑ์ วงจร (การเตรียมและบำรุงรักษาข้อมูลผลิตภัณฑ์ทั้งหมดอย่างเต็มรูปแบบ) แต่ในช่วงฤดูร้อนปี 2017 ก่อนที่จะเปิดตัววงจรสินค้าโภคภัณฑ์ โครงการจะพบว่าตัวเองตกอยู่ในสถานการณ์ที่ยากลำบากมาก - เนื่องจากปัญหาแคช ฉันต้องการพูดคุยเกี่ยวกับตอนนี้ในส่วนที่สองของสิ่งพิมพ์สองตอนนี้
แต่ในโพสต์นี้ผมจะเริ่มต้นจากที่ไกลๆ ผมจะนำเสนอ แนวคิดบางประการเกี่ยวกับการแคช ซึ่งจะเป็นขั้นตอนที่ดีในการเลื่อนดูก่อนที่จะมีโปรเจ็กต์ขนาดใหญ่
เมื่องานแคชเกิดขึ้น
งานแคชไม่เพียงแค่ปรากฏขึ้นเท่านั้น เราเป็นนักพัฒนาที่เขียนผลิตภัณฑ์ซอฟต์แวร์และต้องการให้เป็นที่ต้องการ หากสินค้าเป็นที่ต้องการและประสบความสำเร็จ ผู้ใช้ก็จะมา และเพิ่มมากขึ้นเรื่อยๆ แล้วมีผู้ใช้จำนวนมากจึงทำให้สินค้ามีการโหลดสูง
ในระยะแรก เราไม่ได้คิดถึงการปรับให้เหมาะสมและประสิทธิภาพของโค้ด สิ่งสำคัญคือฟังก์ชันการทำงาน การเปิดตัวนักบินและการทดสอบสมมติฐานอย่างรวดเร็ว และหากภาระเพิ่มขึ้น เราก็จะปั๊มเหล็กขึ้น เราเพิ่มมันสองหรือสามครั้ง ห้าครั้ง หรืออาจจะ 10 เท่า ที่ไหนสักแห่งที่นี่ – การเงินจะไม่ยอมอีกต่อไป จำนวนผู้ใช้จะเพิ่มขึ้นกี่ครั้ง? จะไม่เป็นแบบ 2-5-10 แต่ถ้าสำเร็จจะอยู่ที่ 100-1000 ถึง 100 เท่า นั่นคือไม่ช้าก็เร็วคุณจะต้องทำการเพิ่มประสิทธิภาพ
สมมติว่าบางส่วนของโค้ด (ขอเรียกส่วนนี้ว่าฟังก์ชัน) ใช้เวลานานอย่างไม่เหมาะสม และเราต้องการลดเวลาในการดำเนินการลง ฟังก์ชันสามารถเข้าถึงฐานข้อมูลได้ หรืออาจเป็นการดำเนินการของตรรกะที่ซับซ้อนก็ได้ สิ่งสำคัญคือต้องใช้เวลานานในการดำเนินการ คุณสามารถลดเวลาดำเนินการได้มากเพียงใด? ในขีดจำกัดคุณสามารถลดให้เหลือศูนย์ได้เลย คุณจะลดเวลาดำเนินการให้เป็นศูนย์ได้อย่างไร? คำตอบ: กำจัดการดำเนินการโดยสิ้นเชิง ให้ส่งคืนผลลัพธ์ทันที คุณจะรู้ผลลัพธ์ได้อย่างไร? คำตอบ: คำนวณหรือดูที่ไหนสักแห่ง การคำนวณใช้เวลานาน และการสอดแนมคือการจดจำผลลัพธ์ที่ฟังก์ชันสร้างครั้งล่าสุดเมื่อเรียกใช้ด้วยพารามิเตอร์เดียวกัน
นั่นคือการนำฟังก์ชันไปใช้นั้นไม่สำคัญสำหรับเรา ก็เพียงพอแล้วที่จะรู้ว่าผลลัพธ์นั้นขึ้นอยู่กับพารามิเตอร์ใด จากนั้นหากค่าพารามิเตอร์แสดงในรูปแบบของออบเจ็กต์ที่สามารถใช้เป็นคีย์ในที่เก็บข้อมูลบางส่วนได้ ผลการคำนวณก็สามารถบันทึกและอ่านออกในครั้งต่อไปที่มีการเข้าถึงได้ หากการเขียนและการอ่านผลลัพธ์เร็วกว่าการดำเนินการฟังก์ชัน เราก็จะได้กำไรในแง่ของความเร็ว จำนวนกำไรสามารถสูงถึง 100, 1000 และ 100 เท่า (10^5 ค่อนข้างเป็นข้อยกเว้น แต่ในกรณีของฐานที่ค่อนข้างล้าหลัง ก็เป็นไปได้ทีเดียว)
ข้อกำหนดพื้นฐานสำหรับระบบแคช
สิ่งแรกที่อาจกลายเป็นข้อกำหนดสำหรับระบบแคชคือความเร็วในการอ่านที่รวดเร็ว และความเร็วในการเขียนในระดับที่น้อยกว่าเล็กน้อย นี่เป็นเรื่องจริง แต่จนกว่าเราจะเปิดตัวระบบเป็นการใช้งานจริงเท่านั้น
มาเล่นคดีนี้กัน
สมมติว่าเราได้เตรียมโหลดปัจจุบันด้วยฮาร์ดแวร์ และตอนนี้กำลังค่อยๆ เปิดตัวแคช จำนวนผู้ใช้เพิ่มขึ้นเล็กน้อย โหลดก็เพิ่มขึ้น - เราเพิ่มแคชเล็กน้อย ขันเข้าไปตรงนี้และตรงนั้น สิ่งนี้จะดำเนินต่อไประยะหนึ่งและตอนนี้ในทางปฏิบัติแล้วฟังก์ชั่นหนัก ๆ ไม่ได้ถูกเรียกอีกต่อไป - โหลดหลักทั้งหมดตกอยู่ที่แคช จำนวนผู้ใช้ในช่วงเวลานี้เพิ่มขึ้น N ครั้ง
และหากการจัดหาฮาร์ดแวร์เริ่มแรกอาจเป็น 2-5 เท่า ด้วยความช่วยเหลือของแคช เราสามารถปรับปรุงประสิทธิภาพได้ 10 เท่า หรือในกรณีที่ดี 100 เท่า ในบางสถานที่อาจเป็นตามปัจจัย 1000 รายการ นั่นคือบนฮาร์ดแวร์เดียวกัน – เราประมวลผลคำขอมากกว่า 100 เท่า เยี่ยมเลย คุณสมควรได้รับขนมปังขิง!
แต่ตอนนี้ ในช่วงเวลาดีๆ ระบบขัดข้องและแคชก็พังโดยบังเอิญ ไม่มีอะไรพิเศษ - ท้ายที่สุดแล้ว แคชถูกเลือกตามความต้องการ "ความเร็วในการอ่านและเขียนสูง ส่วนที่เหลือไม่สำคัญ"
เมื่อเทียบกับโหลดเริ่มต้น ปริมาณสำรองเหล็กของเราคือ 2-5 เท่า และโหลดในช่วงเวลานี้เพิ่มขึ้น 10-100 เท่า เมื่อใช้แคช เราได้ยกเลิกการเรียกใช้ฟังก์ชันที่หนักหน่วง ดังนั้นทุกอย่างจึงทำงานได้ และตอนนี้หากไม่มีแคช ระบบของเราจะช้าลงกี่ครั้ง? จะเกิดอะไรขึ้นกับเรา? ระบบจะล่ม..
แม้ว่าแคชของเราจะไม่ขัดข้อง แต่ล้างได้เพียงชั่วระยะเวลาหนึ่งเท่านั้น แต่จะต้องได้รับการอุ่นเครื่องและจะใช้เวลาสักครู่ และในช่วงนี้ภาระหลักก็จะตกอยู่ที่ฟังก์ชันการทำงาน
สรุป: โครงการที่ใช้งานจริงที่มีโหลดสูงจำเป็นต้องมีระบบแคชไม่เพียงแต่จะมีความเร็วในการอ่านและเขียนสูงเท่านั้น แต่ยังต้องมั่นใจในความปลอดภัยของข้อมูลและความต้านทานต่อความล้มเหลวอีกด้วย
แป้งของทางเลือก
ในโครงการที่มีแผงผู้ดูแลระบบตัวเลือกจะเป็นดังนี้: ก่อนอื่นเราติดตั้ง Hazelcast เพราะ เราคุ้นเคยกับผลิตภัณฑ์นี้แล้วจากประสบการณ์ของเว็บไซต์หลัก แต่ที่นี่ตัวเลือกนี้กลับกลายเป็นว่าไม่ประสบความสำเร็จ - ภายใต้โปรไฟล์โหลดของเรา Hazelcast ไม่เพียงแต่ช้า แต่ยังช้ามากอีกด้วย และในขณะนั้นเราก็ได้ลงทะเบียนสำหรับวันวางจำหน่ายแล้ว
ผู้สปอยเลอร์: สถานการณ์เกิดขึ้นได้อย่างไรที่เราพลาดเรื่องใหญ่และจบลงด้วยสถานการณ์ที่รุนแรงและตึงเครียด - ฉันจะบอกคุณในส่วนที่สอง - และเราจะจบลงอย่างไรและเราจะออกไปได้อย่างไร แต่ตอนนี้ - ฉันจะบอกว่ามันเป็นความเครียดมากและ "คิด - ฉันคิดไม่ออก เรากำลังเขย่าขวด" “การเขย่าขวด” ก็ถือเป็นการสปอยล์เช่นกัน และมีรายละเอียดเพิ่มเติมในภายหลัง
สิ่งที่เราทำ:
- เราสร้างรายชื่อระบบทั้งหมดที่ Google และ StackOverflow แนะนำ 30 กว่าๆ นิดหน่อย
- เราเขียนการทดสอบที่มีภาระงานทั่วไปสำหรับการผลิต ในการทำเช่นนี้ เราได้บันทึกข้อมูลที่ส่งผ่านระบบในสภาพแวดล้อมการใช้งานจริง ซึ่งเป็นการดมกลิ่นข้อมูลที่ไม่ได้อยู่ในเครือข่าย แต่อยู่ภายในระบบ ข้อมูลนี้ถูกใช้ในการทดสอบอย่างแน่นอน
- ด้วยทั้งทีม ทุกคนจะเลือกระบบถัดไปจากรายการ กำหนดค่า และดำเนินการทดสอบ มันไม่ผ่านการทดสอบ มันไม่รับภาระ – เราทิ้งมันไปและไปยังอันถัดไปในแถว
- ในระบบที่ 17 เห็นได้ชัดว่าทุกอย่างสิ้นหวัง หยุดเขย่าขวดได้เวลาคิดอย่างจริงจังแล้ว
แต่นี่เป็นตัวเลือกเมื่อคุณต้องการเลือกระบบที่จะ "ผ่านความเร็ว" ในการทดสอบที่เตรียมไว้ล่วงหน้า จะเป็นอย่างไรหากยังไม่มีการทดสอบดังกล่าวและคุณต้องการเลือกอย่างรวดเร็ว?
เรามาจำลองตัวเลือกนี้กันดีกว่า (มันยากที่จะจินตนาการว่านักพัฒนาระดับกลางขึ้นไปอาศัยอยู่ในสุญญากาศ และในขณะที่เลือกยังไม่ได้กำหนดความต้องการของเขาอย่างเป็นทางการว่าควรลองใช้ผลิตภัณฑ์ใดก่อน ดังนั้น การให้เหตุผลเพิ่มเติมจึงขึ้นอยู่กับนักทฤษฎี/ปรัชญา/ เกี่ยวกับจูเนียร์)
เมื่อตัดสินใจเกี่ยวกับข้อกำหนดแล้ว เราจะเริ่มเลือกโซลูชันทันที ทำไมต้องคิดค้นล้อใหม่: เราจะไปนำระบบแคชสำเร็จรูปมาใช้
หากคุณเพิ่งเริ่มต้นและค้นหาใน Google ก็ให้หรือรับคำสั่งซื้อ แต่โดยทั่วไปแล้วหลักเกณฑ์จะเป็นเช่นนี้ ก่อนอื่นคุณจะพบกับ Redis ซึ่งได้ยินทุกที่ จากนั้นคุณจะพบว่า EhCache เป็นระบบที่เก่าแก่และผ่านการพิสูจน์แล้วมากที่สุด ต่อไป เราจะเขียนเกี่ยวกับ Tarantool ซึ่งเป็นการพัฒนาในประเทศที่มีแง่มุมที่เป็นเอกลักษณ์ของโซลูชัน และยัง Ignite เนื่องจากขณะนี้กำลังได้รับความนิยมเพิ่มขึ้นและได้รับการสนับสนุนจาก SberTech ในตอนท้ายยังมี Hazelcast เพราะในโลกธุรกิจมักปรากฏอยู่ในบริษัทขนาดใหญ่
รายการไม่ครบถ้วนสมบูรณ์ มีหลายสิบระบบ และเราจะทำพลาดเพียงสิ่งเดียวเท่านั้น เรามาเลือก 5 ระบบสำหรับ “การประกวดความงาม” แล้วทำการเลือกกัน ใครจะเป็นผู้ชนะ?
Redis
เราอ่านสิ่งที่พวกเขาเขียนบนเว็บไซต์อย่างเป็นทางการ
- โครงการโอเพ่นซอร์ส นำเสนอการจัดเก็บข้อมูลในหน่วยความจำ ความสามารถในการบันทึกบนดิสก์ การแบ่งพาร์ติชันอัตโนมัติ ความพร้อมใช้งานสูงและการกู้คืนจากการขัดข้องของเครือข่าย
ดูเหมือนว่าทุกอย่างเรียบร้อยดี คุณสามารถเอามันไปทำได้เลย - ทุกสิ่งที่คุณต้องการมันก็ทำได้ แต่เพื่อความสนุก เรามาดูผู้สมัครคนอื่นๆ กันดีกว่า
เอ๊ะแคช
- "แคชที่ใช้กันอย่างแพร่หลายที่สุดสำหรับ Java" (แปลสโลแกนจากเว็บไซต์อย่างเป็นทางการ) โอเพ่นซอร์สอีกด้วย จากนั้นเราก็เข้าใจว่า Redis ไม่ใช่สำหรับ Java แต่เป็นเรื่องทั่วไป และเพื่อที่จะโต้ตอบกับมันคุณต้องมีกระดาษห่อ และ EhCache จะสะดวกยิ่งขึ้น ระบบสัญญาอะไรอีกบ้าง? ความน่าเชื่อถือ ได้รับการพิสูจน์แล้ว มีฟังก์ชันการทำงานเต็มรูปแบบ มันก็เป็นเรื่องธรรมดาที่สุดเช่นกัน และแคชข้อมูลเป็นเทราไบต์
Redis ถูกลืม ฉันพร้อมที่จะเลือก EhCache แล้ว
แต่ความรู้สึกรักชาติผลักดันให้ฉันเห็นว่ามีอะไรดีเกี่ยวกับ Tarantool
ทารันทูล
- ตรงตามการกำหนด “แพลตฟอร์มบูรณาการข้อมูลแบบเรียลไทม์” ฟังดูซับซ้อนมาก ดังนั้นเราจึงอ่านหน้านี้โดยละเอียดและพบข้อความดัง: “แคชข้อมูล 100% ใน RAM” สิ่งนี้น่าจะทำให้เกิดคำถาม เพราะอาจมีข้อมูลมากกว่าหน่วยความจำได้มาก คำอธิบายก็คือหมายความว่า Tarantool ไม่ได้เรียกใช้การทำให้เป็นอนุกรมเพื่อเขียนข้อมูลลงดิสก์จากหน่วยความจำ แต่จะใช้คุณสมบัติระดับต่ำของระบบแทน เมื่อหน่วยความจำถูกแมปกับระบบไฟล์ที่มีประสิทธิภาพ I/O ที่ดีมาก โดยทั่วไปแล้วพวกเขาทำสิ่งที่ยอดเยี่ยมและยอดเยี่ยม
มาดูการใช้งานกัน: ทางหลวงขององค์กร Mail.ru, Avito, Beeline, Megafon, Alfa-Bank, Gazprom...
หากยังคงมีข้อสงสัยเกี่ยวกับ Tarantool กรณีการใช้งานที่ Mastercard ก็ทำให้ฉันจบสิ้น ฉันทานทารันทูล
แต่อย่างไรก็ตาม…
จุดชนวน
…ยังมีอีกไหม ถูกเรียกเก็บเงินเป็น "แพลตฟอร์มการประมวลผลในหน่วยความจำ...ความเร็วในหน่วยความจำบนข้อมูลระดับเพตะไบต์" นอกจากนี้ยังมีข้อดีหลายประการที่นี่: แคชในหน่วยความจำแบบกระจาย พื้นที่จัดเก็บและแคชคีย์-ค่าที่เร็วที่สุด การปรับสเกลแนวนอน ความพร้อมใช้งานสูง ความสมบูรณ์ที่เข้มงวด โดยทั่วไปปรากฎว่าตัวที่เร็วที่สุดคือ Ignite
การใช้งาน: Sberbank, American Airlines, Yahoo! ญี่ปุ่น. จากนั้นฉันก็พบว่า Ignite ไม่เพียงแต่ถูกนำไปใช้ใน Sberbank เท่านั้น แต่ทีม SberTech ส่งบุคลากรไปยังทีม Ignite เองเพื่อปรับแต่งผลิตภัณฑ์ มันช่างน่าดึงดูดจริงๆ และฉันพร้อมที่จะใช้ Ignite แล้ว
ไม่มีความชัดเจนเลยว่าทำไม ฉันกำลังดูจุดที่ห้าอยู่
เฮเซลคาสท์
ฉันไปที่ไซต์ , การอ่าน. และปรากฎว่าวิธีแก้ปัญหาที่เร็วที่สุดสำหรับการกระจายแคชคือ Hazelcast มีลำดับความสำคัญเร็วกว่าโซลูชันอื่นๆ ทั้งหมด และโดยทั่วไปเป็นผู้นำในด้านตารางข้อมูลในหน่วยความจำ เมื่อเทียบกับภูมิหลังนี้ การทำอย่างอื่นไม่ใช่การเคารพตัวเอง นอกจากนี้ยังใช้การจัดเก็บข้อมูลซ้ำซ้อนเพื่อการดำเนินงานอย่างต่อเนื่องของคลัสเตอร์โดยไม่สูญเสียข้อมูล
เท่านี้ก็พร้อมเอา Hazelcast แล้ว
การเปรียบเทียบ
แต่ถ้าคุณดูผู้สมัครทั้งห้าคนได้รับการอธิบายในลักษณะที่แต่ละคนดีที่สุด วิธีการเลือก? เราจะเห็นได้ว่าอันไหนฮิตที่สุด ลองเปรียบเทียบดู แล้วจะหายปวดหัว
เราเจอแบบนี้ ให้เลือก 5 ระบบของเรา
จัดเรียงดังนี้: Redis อยู่ด้านบน Hazelcast อยู่ในอันดับที่สอง Tarantool และ Ignite กำลังได้รับความนิยม EhCache เป็นและยังคงเหมือนเดิม
แต่มาดูกัน : ลิงค์ไปเว็บไซต์, สนใจระบบทั่วไป, รับสมัครงาน - เยี่ยมมาก! นั่นคือเมื่อระบบของฉันล้มเหลว ฉันจะพูดว่า: “ไม่ มันเชื่อถือได้! มีรับสมัครงานมากมาย..." การเปรียบเทียบง่ายๆ เช่นนี้จะไม่เกิดขึ้น
ระบบทั้งหมดนี้ไม่ได้เป็นเพียงระบบแคชเท่านั้น นอกจากนี้ยังมีฟังก์ชันการทำงานมากมาย รวมถึงเมื่อข้อมูลไม่ได้ถูกปั๊มไปยังไคลเอนต์เพื่อการประมวลผล แต่ในทางกลับกัน: โค้ดที่ต้องดำเนินการกับข้อมูลจะย้ายไปยังเซิร์ฟเวอร์ จะถูกดำเนินการที่นั่น และผลลัพธ์จะถูกส่งกลับ และมักไม่ถือว่าเป็นระบบแยกต่างหากสำหรับการแคช
เอาล่ะ อย่าเพิ่งยอมแพ้ เรามาดูการเปรียบเทียบระบบกันโดยตรงกันดีกว่า ลองใช้สองตัวเลือกแรก - Redis และ Hazelcast เราสนใจเรื่องความเร็วและเราจะเปรียบเทียบตามพารามิเตอร์นี้
Hz กับ Redis
เราพบสิ่งนี้ :
สีน้ำเงินคือ Redis สีแดงคือ Hazelcast Hazelcast ชนะทุกที่และมีเหตุผลสำหรับสิ่งนี้: เป็นแบบมัลติเธรด ได้รับการปรับปรุงให้เหมาะสมที่สุด แต่ละเธรดทำงานร่วมกับพาร์ติชันของตัวเอง ดังนั้นจึงไม่มีการบล็อก และ Redis เป็นแบบเธรดเดียว มันไม่ได้รับประโยชน์จาก CPU แบบมัลติคอร์สมัยใหม่ Hazelcast มี I/O แบบอะซิงโครนัส ส่วน Redis-Jedis มีการบล็อกซ็อกเก็ต ท้ายที่สุดแล้ว Hazelcast ใช้โปรโตคอลไบนารี่ และ Redis เน้นข้อความเป็นศูนย์กลาง ซึ่งหมายความว่ามันไม่มีประสิทธิภาพ
ในกรณีที่เรามาดูแหล่งเปรียบเทียบอื่นกัน เขาจะแสดงอะไรให้เราดู?
Redis กับ Hz
อีกประการหนึ่ง :
ตรงกันข้าม สีแดงคือเรดิส นั่นคือ Redis มีประสิทธิภาพเหนือกว่า Hazelcast ในแง่ของประสิทธิภาพ Hazelcast ชนะการเปรียบเทียบครั้งแรก Redis ชนะครั้งที่สอง อธิบายได้อย่างแม่นยำมากว่าทำไม Hazelcast จึงชนะการเปรียบเทียบครั้งก่อน
ปรากฎว่าผลลัพธ์ของอันแรกนั้นถูกควบคุมจริงๆ: Redis ถูกจับในกล่องฐาน และ Hazelcast ได้รับการปรับแต่งสำหรับกรณีทดสอบ จากนั้นปรากฎว่า ประการแรก เราไม่สามารถเชื่อใจใครได้ และประการที่สอง เมื่อเราเลือกระบบในที่สุด เรายังต้องกำหนดค่าให้ถูกต้อง การตั้งค่าเหล่านี้ประกอบด้วยพารามิเตอร์หลายสิบเกือบร้อยรายการ
เขย่าขวด
และฉันสามารถอธิบายกระบวนการทั้งหมดที่เราทำตอนนี้ได้ด้วยคำอุปมาต่อไปนี้: “การเขย่าขวด” นั่นคือตอนนี้คุณไม่จำเป็นต้องเขียนโปรแกรม แต่สิ่งสำคัญคือต้องสามารถอ่าน Stackoverflow ได้ และฉันมีบุคคลในทีมที่เป็นมืออาชีพซึ่งทำงานในลักษณะนี้ในช่วงเวลาวิกฤติ
เขากำลังทำอะไร? เขาเห็นของพัง เห็นร่องรอยของสแต็ก ดูคำบางคำจากมัน (อันไหนคือความเชี่ยวชาญของเขาในโปรแกรม) การค้นหาใน Google พบสแต็กโอเวอร์โฟลว์ท่ามกลางคำตอบ โดยไม่ต้องอ่านโดยไม่ต้องคิดในบรรดาคำตอบของคำถามเขาเลือกสิ่งที่คล้ายกับประโยค "ทำสิ่งนี้และสิ่งนั้น" มากที่สุด (การเลือกคำตอบดังกล่าวคือพรสวรรค์ของเขาเพราะไม่ใช่คำตอบที่ได้รับไลค์มากที่สุดเสมอไป) ใช้ , ดู: ถ้ามีอะไรเปลี่ยนแปลงก็เยี่ยมเลย หากยังไม่เปลี่ยนแปลง ให้ย้อนกลับ และทำซ้ำการเปิดตัว-ตรวจสอบ-ค้นหา และด้วยวิธีที่เป็นธรรมชาตินี้ เขารับประกันว่าโค้ดจะทำงานได้หลังจากผ่านไประยะหนึ่ง เขาไม่รู้ว่าทำไม เขาไม่รู้ว่าเขาทำอะไร เขาอธิบายไม่ได้ แต่! การติดเชื้อนี้ได้ผล และ “ไฟก็ดับแล้ว” ทีนี้ เรามาดูกันว่าเราทำอะไรบ้าง เมื่อโปรแกรมทำงานก็จะง่ายขึ้นตามลำดับ และช่วยประหยัดเวลาได้มาก
วิธีการนี้อธิบายได้ดีมากด้วยตัวอย่างนี้
ครั้งหนึ่งการสะสมเรือใบในขวดเป็นที่นิยมอย่างมาก ในขณะเดียวกันเรือใบก็มีขนาดใหญ่และเปราะบางและคอขวดก็แคบมากจนไม่สามารถดันเข้าไปข้างในได้ วิธีการประกอบมัน?
มีวิธีดังกล่าวรวดเร็วและมีประสิทธิภาพมาก
เรือประกอบด้วยสิ่งเล็กๆ น้อยๆ มากมาย เช่น กิ่งไม้ เชือก ใบเรือ กาว เราใส่ทั้งหมดนี้ลงในขวด
เราหยิบขวดด้วยมือทั้งสองข้างแล้วเริ่มเขย่า เราเขย่าและเขย่าเธอ และมักจะกลายเป็นขยะโดยสิ้นเชิงแน่นอน แต่บางครั้ง. บางทีก็กลายเป็นเรือ! แม่นยำยิ่งขึ้นบางสิ่งที่คล้ายกับเรือ
เราแสดงสิ่งนี้ให้ใครบางคนเห็น:“ Seryoga คุณเห็นไหม!?” และแท้จริงแล้วเมื่อมองจากระยะไกลก็ดูเหมือนเรือ แต่สิ่งนี้ไม่สามารถปล่อยให้ดำเนินต่อไปได้
มีอีกวิธีหนึ่ง พวกมันถูกใช้โดยผู้ขั้นสูง เช่น แฮกเกอร์
ฉันมอบหมายงานให้ผู้ชายคนนี้ เขาทำทุกอย่างแล้วจากไป และคุณดู - ดูเหมือนว่าจะเสร็จแล้ว และสักพักเมื่อต้องสรุปโค้ด เรื่องนี้ก็เริ่มขึ้นเพราะเขา... ดีที่เขาหนีไปได้ไกลแล้ว คนเหล่านี้คือผู้ที่ทำสิ่งนี้โดยใช้ตัวอย่างขวด คุณเห็นไหมว่าแก้วโค้งงออยู่ที่ก้นแก้ว และยังไม่ชัดเจนว่าจะโปร่งใสหรือไม่ จากนั้น "แฮกเกอร์" ก็ตัดก้นเรือออก ใส่เรือเข้าไปตรงนั้น จากนั้นติดกาวด้านล่างกลับเข้าไปใหม่ และมันก็เหมือนกับว่ามันควรจะเป็นอย่างนั้น
จากมุมมองของการวางปัญหาทุกอย่างดูเหมือนจะถูกต้อง แต่การใช้เรือเป็นตัวอย่าง: ทำไมต้องสร้างเรือลำนี้ขึ้นมา ใครต้องการมันล่ะ? ไม่มีฟังก์ชันการทำงานใดๆ โดยปกติแล้วเรือดังกล่าวจะเป็นของขวัญให้กับบุคคลระดับสูงโดยวางมันไว้บนหิ้งเหนือพวกเขาเพื่อเป็นสัญลักษณ์บางอย่างเป็นเครื่องหมาย แล้วถ้าเป็นคนแบบนี้ เป็นหัวหน้าธุรกิจใหญ่ หรือข้าราชการระดับสูง แล้วธงจะยืนหยัดได้อย่างไร เพราะถูกแฮ็กคอขาดไปแล้ว? จะดีกว่าถ้าเขาไม่เคยรู้เรื่องนี้มาก่อน แล้วสุดท้ายพวกเขาจะสร้างเรือที่สามารถมอบให้กับคนสำคัญได้อย่างไร?
สิ่งสำคัญเพียงอย่างเดียวที่คุณไม่สามารถทำอะไรได้คือร่างกาย และตัวเรือก็พอดีกับคอพอดี ในขณะที่ตัวเรือประกอบนอกขวด แต่ไม่ใช่แค่การประกอบเรือเท่านั้น แต่ยังเป็นงานหัตถกรรมเครื่องประดับอีกด้วย คันโยกแบบพิเศษจะถูกเพิ่มเข้าไปในส่วนประกอบต่างๆ ซึ่งช่วยให้สามารถยกขึ้นได้ ตัวอย่างเช่นใบเรือถูกพับเก็บไว้นำเข้าอย่างระมัดระวังจากนั้นด้วยความช่วยเหลือของแหนบพวกมันจะถูกดึงและยกขึ้นอย่างแม่นยำด้วยความแม่นยำ ผลลัพธ์ที่ได้คืองานศิลปะที่สามารถมอบให้ได้ด้วยจิตสำนึกที่ชัดเจนและความภาคภูมิใจ
และถ้าเราอยากให้โปรเจ็กต์ประสบความสำเร็จ ต้องมีช่างจิวเวลรี่ในทีมอย่างน้อยหนึ่งคน คนที่ใส่ใจในคุณภาพของผลิตภัณฑ์และคำนึงถึงทุกด้านโดยไม่เสียสละสิ่งใดๆ แม้ในช่วงเวลาที่เกิดความเครียด เมื่อสถานการณ์จำเป็นต้องทำอย่างเร่งด่วนโดยสูญเสียสิ่งสำคัญ โครงการที่ประสบความสำเร็จทั้งหมดซึ่งมีความยั่งยืนและผ่านการทดสอบของกาลเวลาถูกสร้างขึ้นบนหลักการนี้ มีบางอย่างที่แม่นยำและไม่เหมือนใครเกี่ยวกับสิ่งเหล่านี้ ซึ่งเป็นสิ่งที่ใช้ประโยชน์จากความเป็นไปได้ที่มีอยู่ทั้งหมด ในตัวอย่างที่มีเรืออยู่ในขวด ข้อเท็จจริงที่ว่าตัวเรือทะลุคอจะถูกแสดง
กลับมาที่หน้าที่เลือกเซิร์ฟเวอร์แคชของเรา วิธีการนี้สามารถนำไปใช้ได้อย่างไร? ฉันเสนอตัวเลือกนี้ในการเลือกจากระบบทั้งหมดที่มีอยู่ - อย่าเขย่าขวด อย่าเลือก แต่ให้ดูว่าพวกเขามีหลักการอะไรบ้าง สิ่งที่ต้องมองหาเมื่อเลือกระบบ
จะหาคอขวดได้ที่ไหน
เรามาพยายามอย่าเขย่าขวด อย่าผ่านทุกสิ่งที่มีอยู่ทีละขวด แต่มาดูกันว่าปัญหาจะเกิดอะไรขึ้นถ้าเราออกแบบระบบดังกล่าวด้วยตัวเองโดยฉับพลันสำหรับงานของเรา แน่นอนว่าเราจะไม่ประกอบจักรยานยนต์ แต่เราจะใช้แผนภาพนี้เพื่อช่วยเราค้นหาจุดที่ต้องใส่ใจในคำอธิบายผลิตภัณฑ์ มาร่างแผนภาพดังกล่าวกัน
หากระบบมีการกระจาย เราจะมีเซิร์ฟเวอร์หลายเครื่อง (6) สมมติว่ามีสี่อัน (สะดวกที่จะวางไว้ในภาพ แต่แน่นอนว่าสามารถมีได้มากเท่าที่คุณต้องการ) หากเซิร์ฟเวอร์อยู่บนโหนดที่แตกต่างกัน นั่นหมายความว่าเซิร์ฟเวอร์ทั้งหมดเรียกใช้โค้ดบางส่วนที่รับผิดชอบในการรับรองว่าโหนดเหล่านี้ก่อตัวเป็นคลัสเตอร์ และในกรณีที่เกิดการหยุดทำงาน ให้เชื่อมต่อและจดจำซึ่งกันและกัน
เรายังต้องการโค้ดลอจิก (2) ซึ่งจริงๆ แล้วเกี่ยวกับการแคช ลูกค้าโต้ตอบกับโค้ดนี้ผ่าน API บางตัว รหัสไคลเอ็นต์ (1) สามารถอยู่ใน JVM เดียวกันหรือเข้าถึงได้ผ่านเครือข่าย ตรรกะที่นำมาใช้ภายในคือการตัดสินใจว่าจะทิ้งวัตถุใดไว้ในแคชและทิ้งวัตถุใด เราใช้หน่วยความจำ (3) เพื่อจัดเก็บแคช แต่หากจำเป็น เราสามารถบันทึกข้อมูลบางส่วนลงในดิสก์ (4)
มาดูกันว่าโหลดจะเกิดขึ้นในส่วนไหน จริงๆ แล้ว ทุกลูกศรและทุกโหนดจะถูกโหลด ประการแรก ระหว่างรหัสไคลเอ็นต์และ API หากนี่คือการสื่อสารผ่านเครือข่าย การทรุดตัวจะสังเกตเห็นได้ค่อนข้างชัดเจน ประการที่สอง ภายในกรอบงานของ API เอง - หากเราหักโหมด้วยตรรกะที่ซับซ้อน เราก็อาจประสบปัญหากับ CPU ได้ และคงจะดีถ้าตรรกะไม่เสียเวลากับความทรงจำ และยังคงมีการโต้ตอบกับระบบไฟล์ - ในเวอร์ชันปกติจะเป็นซีเรียลไลซ์ / กู้คืนและเขียน / อ่าน
ถัดไปคือการโต้ตอบกับคลัสเตอร์ เป็นไปได้มากว่าจะอยู่ในระบบเดียวกัน แต่อาจแยกจากกัน ที่นี่คุณต้องคำนึงถึงการถ่ายโอนข้อมูล ความเร็วของการจัดลำดับข้อมูล และการโต้ตอบระหว่างคลัสเตอร์ด้วย
ในด้านหนึ่ง เราสามารถจินตนาการได้ว่า "เกียร์ใดบ้างที่จะเปลี่ยน" ในระบบแคชเมื่อประมวลผลคำขอจากโค้ดของเรา และในทางกลับกัน เราสามารถประมาณได้ว่าโค้ดของเราจะสร้างคำขอใดบ้างและจำนวนเท่าใดสำหรับระบบนี้ นี่ก็เพียงพอที่จะตัดสินใจได้ไม่มากก็น้อย - เพื่อเลือกระบบสำหรับกรณีการใช้งานของเรา
เฮเซลคาสท์
มาดูวิธีใช้การสลายตัวนี้กับรายการของเรา ตัวอย่างเช่น เฮเซลแคสต์
ในการใส่/รับข้อมูลจาก Hazelcast รหัสไคลเอ็นต์จะเข้าถึง (1) API Hz ช่วยให้คุณสามารถเรียกใช้เซิร์ฟเวอร์แบบฝังได้ และในกรณีนี้ การเข้าถึง api เป็นการเรียกเมธอดภายใน JVM ซึ่งถือว่าฟรี
เพื่อให้ตรรกะใน (2) ทำงานได้ Hz อาศัยแฮชของอาร์เรย์ไบต์ของคีย์ซีเรียลไลซ์ กล่าวคือ คีย์จะถูกซีเรียลไลซ์ไม่ว่าในกรณีใดๆ นี่เป็นค่าใช้จ่ายที่หลีกเลี่ยงไม่ได้สำหรับ Hz
มีการใช้กลยุทธ์การขับไล่อย่างดี แต่สำหรับกรณีพิเศษคุณสามารถเพิ่มกลยุทธ์ของคุณเองได้ คุณไม่ต้องกังวลเกี่ยวกับส่วนนี้
สามารถเชื่อมต่อที่เก็บข้อมูล (4) ได้ ยอดเยี่ยม. การโต้ตอบ (5) สำหรับการฝังสามารถพิจารณาได้ทันที การแลกเปลี่ยนข้อมูลระหว่างโหนดในคลัสเตอร์ (6) - ใช่ มันมีอยู่ นี่คือการลงทุนเพื่อความทนทานต่อข้อผิดพลาดโดยแลกกับความเร็ว คุณลักษณะ Hz Near-cache ช่วยให้คุณลดราคา - ข้อมูลที่ได้รับจากโหนดอื่นในคลัสเตอร์จะถูกแคช
สิ่งที่สามารถทำได้ในสภาวะเช่นนี้เพื่อเพิ่มความเร็ว?
ตัวอย่างเช่น เพื่อหลีกเลี่ยงการทำให้คีย์เป็นอนุกรมใน (2) ให้แนบแคชอื่นไว้ที่ด้านบนของ Hazelcast เพื่อรับข้อมูลที่ร้อนแรงที่สุด Sportmaster เลือกคาเฟอีนเพื่อจุดประสงค์นี้
สำหรับการบิดที่ระดับ (6) Hz มีพื้นที่จัดเก็บข้อมูลสองประเภท: Imap และ ReplicatedMap
เป็นเรื่องที่ควรค่าแก่การกล่าวถึงว่า Hazelcast เข้าสู่กลุ่มเทคโนโลยี Sportmaster ได้อย่างไร
ในปี 2012 ขณะที่เรากำลังดำเนินการโครงการนำร่องชุดแรกสำหรับไซต์ในอนาคต Hazelcast เองที่กลายเป็นลิงก์แรกที่เครื่องมือค้นหากลับมา คนรู้จักเริ่มต้น "ครั้งแรก" - เรารู้สึกทึ่งกับความจริงที่ว่าเพียงสองชั่วโมงต่อมาเมื่อเราขัน Hz เข้าสู่ระบบมันก็ใช้งานได้ และมันก็ทำงานได้ดี ในตอนท้ายของวันเราผ่านการทดสอบหลายอย่างและมีความสุข และพลังสำรองนี้ก็เพียงพอที่จะเอาชนะความประหลาดใจที่ Hz ขว้างออกมาเมื่อเวลาผ่านไป ตอนนี้ทีม Sportmaster ไม่มีเหตุผลที่จะละทิ้ง Hazelcast
แต่ข้อโต้แย้งเช่น "ลิงก์แรกในเครื่องมือค้นหา" และ "HelloWorld ถูกรวบรวมอย่างรวดเร็ว" แน่นอนว่าเป็นข้อยกเว้นและเป็นคุณลักษณะของช่วงเวลาที่ตัวเลือกเกิดขึ้น การทดสอบจริงสำหรับระบบที่เลือกเริ่มต้นด้วยการเปิดตัวสู่การใช้งานจริง และในขั้นตอนนี้คุณควรให้ความสนใจเมื่อเลือกระบบใดๆ รวมถึงแคชด้วย ที่จริงแล้วในกรณีของเราเราสามารถพูดได้ว่าเราเลือก Hazelcast โดยบังเอิญ แต่กลับกลายเป็นว่าเราเลือกถูกต้อง
สำหรับการผลิต สิ่งสำคัญยิ่งกว่านั้นมาก: การตรวจสอบ การจัดการความล้มเหลวในแต่ละโหนด การจำลองข้อมูล ต้นทุนในการปรับขนาด นั่นคือควรให้ความสนใจกับงานที่จะเกิดขึ้นระหว่างการบำรุงรักษาระบบ - เมื่อโหลดสูงกว่าที่วางแผนไว้หลายสิบเท่า เมื่อเราอัปโหลดบางอย่างผิดที่โดยไม่ได้ตั้งใจ เมื่อเราต้องการเปิดตัวเวอร์ชันใหม่ ของโค้ด แทนที่ข้อมูลและทำโดยไม่มีใครสังเกตเห็นสำหรับลูกค้า
สำหรับข้อกำหนดทั้งหมดนี้ Hazelcast ตอบโจทย์ได้อย่างแน่นอน
ยังมีต่อ
แต่ Hazelcast ไม่ใช่ยาครอบจักรวาล ในปี 2017 เราเลือก Hazelcast เป็นแคชของผู้ดูแลระบบ โดยอิงจากความประทับใจที่ดีจากประสบการณ์ในอดีต สิ่งนี้มีบทบาทสำคัญในเรื่องตลกที่โหดร้ายเพราะเหตุนี้เราจึงพบว่าตัวเองตกอยู่ในสถานการณ์ที่ยากลำบากและ "กล้าหาญ" ออกจากมันเป็นเวลา 60 วัน แต่จะมีเพิ่มเติมในส่วนถัดไป
ในระหว่างนี้... สุขสันต์วันรหัสใหม่!
ที่มา: will.com