นี่เป็นเรื่องราวต่อเนื่องของเรื่องราวอันยาวนานเกี่ยวกับเส้นทางที่ยากลำบากของเราในการสร้างระบบที่ทรงพลังและมีภาระงานสูงที่รับรองการทำงานของ Exchange ส่วนแรกอยู่ที่นี่:
ข้อผิดพลาดลึกลับ
หลังจากการทดสอบหลายครั้ง ระบบการซื้อขายและการหักบัญชีที่ได้รับการอัปเดตก็ถูกนำไปใช้งาน และเราพบข้อบกพร่องที่เราสามารถเขียนเรื่องราวนักสืบลึกลับได้
ไม่นานหลังจากเปิดตัวบนเซิร์ฟเวอร์หลัก ธุรกรรมรายการหนึ่งได้รับการประมวลผลโดยมีข้อผิดพลาด อย่างไรก็ตาม ทุกอย่างเป็นปกติดีบนเซิร์ฟเวอร์สำรอง ปรากฎว่าการดำเนินการทางคณิตศาสตร์อย่างง่ายในการคำนวณเลขชี้กำลังบนเซิร์ฟเวอร์หลักให้ผลลัพธ์เชิงลบจากอาร์กิวเมนต์จริง! เราทำการวิจัยต่อไป และในการลงทะเบียน SSE2 เราพบความแตกต่างในหนึ่งบิต ซึ่งมีหน้าที่ในการปัดเศษเมื่อทำงานกับตัวเลขทศนิยม
เราเขียนโปรแกรมทดสอบอย่างง่ายเพื่อคำนวณเลขชี้กำลังด้วยชุดบิตการปัดเศษ ปรากฎว่าในเวอร์ชันของ RedHat Linux ที่เราใช้ มีข้อบกพร่องในการทำงานกับฟังก์ชันทางคณิตศาสตร์เมื่อมีการแทรกบิตที่โชคร้ายเข้าไป เรารายงานเรื่องนี้กับ RedHat หลังจากนั้นไม่นานเราก็ได้รับแพตช์จากพวกเขาและเผยแพร่ออกไป ไม่มีข้อผิดพลาดเกิดขึ้นอีกต่อไป แต่ก็ไม่ชัดเจนว่าบิตนี้มาจากไหน หน้าที่รับผิดชอบมัน fesetround จากภาษา C เราวิเคราะห์โค้ดของเราอย่างรอบคอบเพื่อค้นหาข้อผิดพลาดที่ควรจะเป็น: เราตรวจสอบสถานการณ์ที่เป็นไปได้ทั้งหมด ดูฟังก์ชันทั้งหมดที่ใช้การปัดเศษ พยายามสร้างเซสชันที่ล้มเหลวอีกครั้ง ใช้คอมไพเลอร์ต่าง ๆ พร้อมตัวเลือกที่แตกต่างกัน ใช้การวิเคราะห์แบบสถิตและไดนามิก
ไม่พบสาเหตุของข้อผิดพลาด
จากนั้นพวกเขาก็เริ่มตรวจสอบฮาร์ดแวร์: พวกเขาทำการทดสอบโหลดของโปรเซสเซอร์ ตรวจสอบ RAM; เรายังทำการทดสอบสถานการณ์ที่ไม่น่าเป็นไปได้ของข้อผิดพลาดหลายบิตในเซลล์เดียว ไม่มีประโยชน์
ในท้ายที่สุด เราก็ตัดสินใจเลือกทฤษฎีจากโลกแห่งฟิสิกส์พลังงานสูง: อนุภาคพลังงานสูงบางอนุภาคบินเข้าไปในศูนย์ข้อมูลของเรา เจาะผนังเคส กระแทกโปรเซสเซอร์ และทำให้สลักทริกเกอร์ติดอยู่เล็กน้อย ทฤษฎีไร้สาระนี้เรียกว่า "นิวตริโน" หากคุณอยู่ห่างไกลจากฟิสิกส์ของอนุภาค นิวตริโนแทบจะไม่มีปฏิสัมพันธ์กับโลกภายนอก และไม่สามารถส่งผลกระทบต่อการทำงานของโปรเซสเซอร์ได้อย่างแน่นอน
เนื่องจากไม่สามารถค้นหาสาเหตุของความล้มเหลวได้ เซิร์ฟเวอร์ "ที่ละเมิด" จึงถูกลบออกจากการทำงานในกรณีดังกล่าว
หลังจากนั้นไม่นาน เราก็เริ่มปรับปรุงระบบสำรองข้อมูลแบบ hot: เราแนะนำสิ่งที่เรียกว่า "warm Reserve" (warm) - แบบจำลองแบบอะซิงโครนัส พวกเขาได้รับกระแสธุรกรรมที่อาจอยู่ในศูนย์ข้อมูลที่แตกต่างกัน แต่ warms ไม่ได้โต้ตอบกับเซิร์ฟเวอร์อื่นอย่างจริงจัง
เหตุใดจึงทำเช่นนี้? หากเซิร์ฟเวอร์สำรองข้อมูลล้มเหลว warm ที่เชื่อมโยงกับเซิร์ฟเวอร์หลักจะกลายเป็นข้อมูลสำรองใหม่ นั่นคือหลังจากเกิดความล้มเหลว ระบบจะไม่คงอยู่กับเซิร์ฟเวอร์หลักเพียงเซิร์ฟเวอร์เดียวจนกว่าจะสิ้นสุดช่วงการซื้อขาย
และเมื่อระบบเวอร์ชันใหม่ได้รับการทดสอบและนำไปใช้งาน ก็เกิดข้อผิดพลาดในการปัดเศษบิตขึ้นอีกครั้ง ยิ่งไปกว่านั้น ด้วยจำนวนเซิร์ฟเวอร์อุ่นที่เพิ่มขึ้น ข้อผิดพลาดก็เริ่มปรากฏบ่อยขึ้น ในขณะเดียวกัน ผู้ขายก็ไม่มีอะไรต้องแสดง เนื่องจากไม่มีหลักฐานที่เป็นรูปธรรม
ในระหว่างการวิเคราะห์สถานการณ์ครั้งต่อไป มีทฤษฎีเกิดขึ้นว่าปัญหาอาจเกี่ยวข้องกับระบบปฏิบัติการ เราเขียนโปรแกรมง่ายๆ ที่เรียกใช้ฟังก์ชันในวงวนไม่สิ้นสุด fesetroundจดจำสถานะปัจจุบันและตรวจสอบผ่านโหมดสลีป ซึ่งทำได้ในเธรดที่แข่งขันกันจำนวนมาก หลังจากเลือกพารามิเตอร์สำหรับโหมดสลีปและจำนวนเธรดแล้ว เราเริ่มสร้างข้อผิดพลาดของบิตอย่างต่อเนื่องหลังจากเรียกใช้ยูทิลิตี้ประมาณ 5 นาที อย่างไรก็ตาม ฝ่ายสนับสนุน Red Hat ไม่สามารถทำซ้ำได้ การทดสอบเซิร์ฟเวอร์อื่นๆ ของเราแสดงให้เห็นว่าเฉพาะเซิร์ฟเวอร์ที่มีโปรเซสเซอร์บางตัวเท่านั้นที่เสี่ยงต่อข้อผิดพลาด ในเวลาเดียวกันการเปลี่ยนไปใช้เคอร์เนลใหม่ช่วยแก้ปัญหาได้ ในท้ายที่สุด เราก็เปลี่ยนระบบปฏิบัติการ และสาเหตุที่แท้จริงของจุดบกพร่องก็ยังไม่ชัดเจน
และจู่ๆ ปีที่แล้วก็มีบทความเรื่องฮาเบรเผยแพร่”" สถานการณ์ที่อธิบายไว้ในนั้นคล้ายกับของเรามาก แต่ผู้เขียนได้ดำเนินการตรวจสอบเพิ่มเติมและหยิบยกทฤษฎีที่ว่าข้อผิดพลาดอยู่ในไมโครโค้ด และเมื่อมีการอัพเดตเคอร์เนล Linux ผู้ผลิตก็อัพเดตไมโครโค้ดด้วย
การพัฒนาระบบต่อไป
แม้ว่าเราจะกำจัดข้อผิดพลาดออกไปแล้ว แต่เรื่องราวนี้บังคับให้เราต้องพิจารณาสถาปัตยกรรมของระบบอีกครั้ง ท้ายที่สุดแล้ว เราไม่ได้รับการปกป้องจากการเกิดข้อผิดพลาดดังกล่าวซ้ำอีก
หลักการต่อไปนี้เป็นพื้นฐานสำหรับการปรับปรุงระบบการจองครั้งต่อไป:
- คุณไม่สามารถเชื่อใจใครได้ เซิร์ฟเวอร์อาจทำงานไม่ถูกต้อง
- การจองส่วนใหญ่
- การรับรองฉันทามติ เป็นส่วนเสริมเชิงตรรกะของการจองส่วนใหญ่
- ความล้มเหลวสองครั้งเป็นไปได้
- ความมีชีวิตชีวา รูปแบบการสแตนด์บายร้อนใหม่ไม่ควรเลวร้ายไปกว่ารูปแบบก่อนหน้า การซื้อขายควรดำเนินต่อไปอย่างต่อเนื่องจนกระทั่งถึงเซิร์ฟเวอร์สุดท้าย
- เวลาแฝงเพิ่มขึ้นเล็กน้อย การหยุดทำงานใดๆ นำมาซึ่งความสูญเสียทางการเงินมหาศาล
- การโต้ตอบกับเครือข่ายน้อยที่สุดเพื่อรักษาเวลาแฝงให้ต่ำที่สุดเท่าที่จะเป็นไปได้
- การเลือกเซิร์ฟเวอร์หลักใหม่ในไม่กี่วินาที
ไม่มีโซลูชันใดในตลาดที่เหมาะกับเรา และโปรโตคอล Raft ยังอยู่ในช่วงเริ่มต้น ดังนั้นเราจึงสร้างโซลูชันของเราเอง
เครือข่าย
นอกจากระบบการจองแล้ว เรายังเริ่มปรับปรุงการโต้ตอบของเครือข่ายให้ทันสมัยอีกด้วย ระบบย่อย I/O ประกอบด้วยกระบวนการมากมาย ซึ่งมีผลกระทบที่เลวร้ายที่สุดต่อความกระวนกระวายใจและเวลาแฝง ด้วยกระบวนการหลายร้อยกระบวนการที่จัดการการเชื่อมต่อ TCP เราจึงถูกบังคับให้สลับไปมาระหว่างกระบวนการเหล่านั้นอย่างต่อเนื่อง และในระดับไมโครวินาที การดำเนินการนี้ค่อนข้างใช้เวลานาน แต่ส่วนที่แย่ที่สุดคือเมื่อกระบวนการได้รับแพ็กเก็ตสำหรับการประมวลผล กระบวนการจะส่งไปยังคิว SystemV หนึ่งคิว จากนั้นรอเหตุการณ์จากคิว SystemV อื่น อย่างไรก็ตาม เมื่อมีโหนดจำนวนมาก การมาถึงของแพ็กเก็ต TCP ใหม่ในกระบวนการหนึ่งและการรับข้อมูลในคิวในอีกกระบวนการหนึ่งแสดงถึงเหตุการณ์ที่แข่งขันกันสองรายการสำหรับระบบปฏิบัติการ ในกรณีนี้ หากไม่มีตัวประมวลผลทางกายภาพสำหรับทั้งสองงาน ตัวหนึ่งจะถูกประมวลผล และตัวที่สองจะถูกวางไว้ในคิวที่รอ ไม่สามารถคาดเดาผลที่ตามมาได้
ในสถานการณ์ดังกล่าว สามารถใช้การควบคุมลำดับความสำคัญของกระบวนการแบบไดนามิกได้ แต่จะต้องใช้การเรียกระบบที่ใช้ทรัพยากรมาก ด้วยเหตุนี้ เราจึงเปลี่ยนไปใช้เธรดเดียวโดยใช้ epoll แบบคลาสสิก ซึ่งช่วยเพิ่มความเร็วและลดเวลาในการประมวลผลธุรกรรมลงอย่างมาก นอกจากนี้เรายังกำจัดกระบวนการสื่อสารเครือข่ายและการสื่อสารผ่าน SystemV ที่แยกจากกัน ซึ่งช่วยลดจำนวนการเรียกของระบบลงอย่างมาก และเริ่มควบคุมลำดับความสำคัญของการดำเนินงาน บนระบบย่อย I/O เพียงอย่างเดียว สามารถประหยัดเวลาได้ประมาณ 8-17 ไมโครวินาที ขึ้นอยู่กับสถานการณ์ รูปแบบเธรดเดี่ยวนี้ถูกใช้โดยไม่มีการเปลี่ยนแปลงตั้งแต่นั้นมา หนึ่งเธรด epoll ที่มีระยะขอบก็เพียงพอที่จะให้บริการการเชื่อมต่อทั้งหมด
การประมวลผลธุรกรรม
ภาระงานที่เพิ่มขึ้นในระบบของเราจำเป็นต้องอัปเกรดส่วนประกอบเกือบทั้งหมด แต่น่าเสียดายที่การเติบโตของความเร็วสัญญาณนาฬิกาของโปรเซสเซอร์ที่ซบเซาในช่วงไม่กี่ปีที่ผ่านมาทำให้ไม่สามารถปรับขนาดกระบวนการแบบเผชิญหน้าได้อีกต่อไป ดังนั้นเราจึงตัดสินใจแบ่งกระบวนการของเครื่องยนต์ออกเป็นสามระดับ โดยระดับที่ยุ่งที่สุดคือระบบการตรวจสอบความเสี่ยง ซึ่งจะประเมินความพร้อมของเงินทุนในบัญชีและสร้างธุรกรรมด้วยตนเอง แต่เงินอาจเป็นสกุลเงินที่แตกต่างกันได้ และจำเป็นต้องพิจารณาว่าควรแบ่งการประมวลผลคำขอตามเกณฑ์ใด
วิธีแก้ปัญหาเชิงตรรกะคือการหารด้วยสกุลเงิน: เซิร์ฟเวอร์หนึ่งซื้อขายเป็นดอลลาร์ อีกแห่งเป็นปอนด์ และหนึ่งในสามเป็นยูโร แต่หากด้วยรูปแบบดังกล่าว มีการส่งธุรกรรมสองรายการเพื่อซื้อสกุลเงินที่แตกต่างกัน ปัญหาของการซิงโครไนซ์กระเป๋าเงินก็จะเกิดขึ้น แต่การซิงโครไนซ์ทำได้ยากและมีราคาแพง ดังนั้นจึงเป็นการถูกต้องที่จะแบ่งแยกส่วนตามกระเป๋าสตางค์และแยกตามเครื่องมือ อย่างไรก็ตาม การแลกเปลี่ยนทางตะวันตกส่วนใหญ่ไม่ได้มีหน้าที่ในการตรวจสอบความเสี่ยงอย่างละเอียดเหมือนกับที่เราทำ ดังนั้นโดยส่วนใหญ่มักจะทำแบบออฟไลน์ เราจำเป็นต้องใช้การยืนยันออนไลน์
ลองอธิบายด้วยตัวอย่าง เทรดเดอร์ต้องการซื้อ $30 และคำขอไปที่การตรวจสอบธุรกรรม: เราจะตรวจสอบว่าเทรดเดอร์รายนี้ได้รับอนุญาตให้เข้าสู่โหมดการซื้อขายนี้หรือไม่ และเขามีสิทธิ์ที่จำเป็นหรือไม่ หากทุกอย่างเป็นไปตามลำดับ คำขอจะถูกส่งไปยังระบบตรวจสอบความเสี่ยง เช่น เพื่อตรวจสอบความเพียงพอของเงินทุนเพื่อทำธุรกรรม โปรดทราบว่าจำนวนเงินที่ต้องการถูกบล็อกอยู่ในขณะนี้ จากนั้นคำขอจะถูกส่งต่อไปยังระบบการซื้อขายซึ่งจะอนุมัติหรือไม่อนุมัติธุรกรรม สมมติว่าธุรกรรมได้รับการอนุมัติ - จากนั้นระบบตรวจสอบความเสี่ยงจะทำเครื่องหมายว่าเงินไม่ได้ถูกบล็อก และรูเบิลจะกลายเป็นดอลลาร์
โดยทั่วไป ระบบตรวจสอบความเสี่ยงประกอบด้วยอัลกอริธึมที่ซับซ้อนและทำการคำนวณที่ต้องใช้ทรัพยากรจำนวนมาก และไม่เพียงแค่ตรวจสอบ "ยอดคงเหลือในบัญชี" เท่านั้น เนื่องจากอาจดูเหมือนเห็นได้อย่างรวดเร็วในครั้งแรก
เมื่อเราเริ่มแบ่งกระบวนการ Engine ออกเป็นระดับต่างๆ เราพบปัญหา: โค้ดที่มีอยู่ในเวลานั้นใช้อาร์เรย์ข้อมูลเดียวกันในขั้นตอนการตรวจสอบความถูกต้องและการตรวจสอบความถูกต้อง ซึ่งจำเป็นต้องเขียนฐานโค้ดใหม่ทั้งหมด ด้วยเหตุนี้เราจึงยืมเทคนิคในการประมวลผลคำสั่งจากโปรเซสเซอร์สมัยใหม่: แต่ละอันแบ่งออกเป็นขั้นตอนเล็ก ๆ และดำเนินการหลายอย่างพร้อมกันในรอบเดียว
หลังจากการปรับเปลี่ยนโค้ดเล็กน้อย เราได้สร้างไปป์ไลน์สำหรับการประมวลผลธุรกรรมแบบขนาน ซึ่งธุรกรรมแบ่งออกเป็น 4 ขั้นตอนของไปป์ไลน์: การโต้ตอบของเครือข่าย การตรวจสอบ การดำเนินการ และการเผยแพร่ผลลัพธ์
ลองดูตัวอย่าง เรามีระบบประมวลผลสองระบบ แบบอนุกรมและแบบขนาน ธุรกรรมแรกมาถึงและถูกส่งเพื่อตรวจสอบความถูกต้องในทั้งสองระบบ ธุรกรรมที่สองมาถึงทันที: ในระบบคู่ขนาน ธุรกรรมจะถูกนำไปใช้งานทันที และในระบบตามลำดับ ธุรกรรมจะอยู่ในคิวเพื่อรอให้ธุรกรรมแรกผ่านขั้นตอนการประมวลผลปัจจุบัน นั่นคือข้อได้เปรียบหลักของการประมวลผลไปป์ไลน์คือเราประมวลผลคิวธุรกรรมได้เร็วขึ้น
นี่คือวิธีที่เราสร้างระบบ ASTS+
จริงอยู่ไม่ใช่ทุกอย่างจะราบรื่นนักเมื่อใช้สายพานลำเลียงเช่นกัน สมมติว่าเรามีธุรกรรมที่ส่งผลต่ออาร์เรย์ข้อมูลในธุรกรรมใกล้เคียง นี่เป็นสถานการณ์ปกติสำหรับการแลกเปลี่ยน ธุรกรรมดังกล่าวไม่สามารถดำเนินการในไปป์ไลน์ได้เนื่องจากอาจส่งผลกระทบต่อผู้อื่น สถานการณ์นี้เรียกว่าอันตรายของข้อมูล และธุรกรรมดังกล่าวจะถูกประมวลผลแยกกัน: เมื่อธุรกรรม "เร็ว" ในคิวหมด ไปป์ไลน์จะหยุด ระบบจะประมวลผลธุรกรรม "ช้า" จากนั้นจึงเริ่มไปป์ไลน์อีกครั้ง โชคดีที่สัดส่วนของธุรกรรมดังกล่าวในโฟลว์โดยรวมมีขนาดเล็กมาก ดังนั้นไปป์ไลน์จึงหยุดน้อยมากจนไม่ส่งผลกระทบต่อประสิทธิภาพโดยรวม
จากนั้นเราก็เริ่มแก้ไขปัญหาการซิงโครไนซ์เธรดการดำเนินการสามเธรด ผลลัพธ์ที่ได้คือระบบที่ใช้วงแหวนบัฟเฟอร์ที่มีเซลล์ขนาดคงที่ ในระบบนี้ ทุกอย่างขึ้นอยู่กับความเร็วในการประมวลผล ข้อมูลจะไม่ถูกคัดลอก
- แพ็กเก็ตเครือข่ายขาเข้าทั้งหมดจะเข้าสู่ขั้นตอนการจัดสรร
- เราวางพวกมันไว้ในอาร์เรย์และทำเครื่องหมายว่าพร้อมใช้งานสำหรับสเตจ #1
- ธุรกรรมครั้งที่สองมาถึงแล้ว และพร้อมอีกครั้งสำหรับระยะที่ 1
- เธรดการประมวลผลแรกจะเห็นธุรกรรมที่มีอยู่ ประมวลผล และย้ายไปยังขั้นตอนถัดไปของเธรดการประมวลผลที่สอง
- จากนั้นจะประมวลผลธุรกรรมแรกและแฟล็กเซลล์ที่เกี่ยวข้อง
deleted- ตอนนี้สามารถใช้งานได้ใหม่แล้ว
คิวทั้งหมดได้รับการประมวลผลในลักษณะนี้
การประมวลผลแต่ละขั้นตอนใช้เวลาหน่วยหรือสิบไมโครวินาที และถ้าเราใช้รูปแบบการซิงโครไนซ์ระบบปฏิบัติการมาตรฐาน เราจะเสียเวลาในการซิงโครไนซ์มากขึ้น นั่นเป็นเหตุผลที่เราเริ่มใช้สปินล็อค อย่างไรก็ตาม นี่เป็นรูปแบบที่แย่มากในระบบเรียลไทม์ และ RedHat ไม่แนะนำให้ทำเช่นนี้อย่างเคร่งครัด ดังนั้นเราจึงใช้สปินล็อคเป็นเวลา 100 มิลลิวินาที จากนั้นสลับไปที่โหมดเซมาฟอร์เพื่อกำจัดโอกาสที่จะเกิดการหยุดชะงัก
เป็นผลให้เราได้รับประสิทธิภาพประมาณ 8 ล้านธุรกรรมต่อวินาที และแท้จริงแล้วอีกสองเดือนต่อมา เกี่ยวกับ LMAX Disruptor เราเห็นคำอธิบายของวงจรที่มีฟังก์ชันการทำงานเหมือนกัน
ขณะนี้อาจมีการดำเนินการหลายเธรดในขั้นตอนเดียว ธุรกรรมทั้งหมดได้รับการประมวลผลทีละรายการตามลำดับที่ได้รับ เป็นผลให้ประสิทธิภาพสูงสุดเพิ่มขึ้นจาก 18 รายการเป็น 50 ธุรกรรมต่อวินาที
ระบบบริหารความเสี่ยงแลกเปลี่ยน
ความสมบูรณ์แบบไม่มีขีดจำกัด และในไม่ช้า เราก็เริ่มการปรับปรุงให้ทันสมัยอีกครั้ง: ภายในกรอบของ ASTS+ เราเริ่มย้ายระบบการจัดการความเสี่ยงและการชำระหนี้ไปเป็นองค์ประกอบที่เป็นอิสระ เราพัฒนาสถาปัตยกรรมสมัยใหม่ที่ยืดหยุ่นและแบบจำลองความเสี่ยงแบบลำดับชั้นใหม่ และพยายามใช้คลาสทุกที่ที่เป็นไปได้ fixed_point แทน double.
แต่ปัญหาก็เกิดขึ้นทันที: จะซิงโครไนซ์ตรรกะทางธุรกิจทั้งหมดที่ใช้งานมานานหลายปีและโอนไปยังระบบใหม่ได้อย่างไร เป็นผลให้เวอร์ชันแรกของต้นแบบของระบบใหม่ต้องถูกยกเลิก เวอร์ชันที่สองซึ่งกำลังทำงานอยู่ในการใช้งานจริงนั้นใช้โค้ดเดียวกันซึ่งใช้งานได้ทั้งในส่วนของการซื้อขายและความเสี่ยง ในระหว่างการพัฒนา สิ่งที่ยากที่สุดที่จะทำคือ git Merge ระหว่างสองเวอร์ชัน เพื่อนร่วมงานของเรา Evgeniy Mazurenok ทำการผ่าตัดนี้ทุกสัปดาห์ และทุกครั้งที่เขาสาปแช่งเป็นเวลานาน
เมื่อเลือกระบบใหม่ เราต้องแก้ไขปัญหาการโต้ตอบทันที เมื่อเลือกบัสข้อมูล จำเป็นต้องตรวจสอบให้แน่ใจว่ามีความกระวนกระวายใจที่เสถียรและมีเวลาแฝงน้อยที่สุด เครือข่าย InfiniBand RDMA เหมาะที่สุดสำหรับสิ่งนี้: เวลาประมวลผลโดยเฉลี่ยน้อยกว่าในเครือข่าย 4 G Ethernet ถึง 10 เท่า แต่สิ่งที่ทำให้เราประทับใจจริงๆ คือความแตกต่างในเปอร์เซ็นไทล์ - 99 และ 99,9
แน่นอนว่า InfiniBand ก็มีความท้าทายเช่นกัน ประการแรก API อื่น - ibverbs แทนซ็อกเก็ต ประการที่สอง แทบไม่มีโซลูชันการส่งข้อความแบบโอเพ่นซอร์สที่ใช้กันอย่างแพร่หลาย เราพยายามสร้างต้นแบบของเราเอง แต่กลับกลายเป็นเรื่องยากมาก เราจึงเลือกโซลูชันเชิงพาณิชย์ - Confinity Low Latency Messaging (เดิมชื่อ IBM MQ LLM)
จากนั้นงานแบ่งระบบความเสี่ยงอย่างเหมาะสมก็เกิดขึ้น หากคุณเพียงแค่ลบ Risk Engine ออกและไม่สร้างโหนดระดับกลาง ธุรกรรมจากสองแหล่งก็สามารถผสมกันได้
โซลูชันที่เรียกว่า Ultra Low Latency มีโหมดการเรียงลำดับใหม่: ธุรกรรมจากสองแหล่งสามารถจัดเรียงตามลำดับที่ต้องการเมื่อได้รับ ซึ่งจะดำเนินการโดยใช้ช่องทางแยกต่างหากสำหรับการแลกเปลี่ยนข้อมูลเกี่ยวกับคำสั่งซื้อ แต่เรายังไม่ได้ใช้โหมดนี้: มันทำให้กระบวนการทั้งหมดซับซ้อนขึ้น และไม่มีการสนับสนุนในโซลูชันจำนวนหนึ่งเลย นอกจากนี้ แต่ละธุรกรรมจะต้องได้รับการประทับเวลาที่สอดคล้องกัน และในรูปแบบของเรา กลไกนี้เป็นเรื่องยากมากที่จะนำไปใช้อย่างถูกต้อง ดังนั้นเราจึงใช้รูปแบบคลาสสิกกับนายหน้าข้อความ นั่นคือกับผู้ส่งที่กระจายข้อความระหว่าง Risk Engine
ปัญหาที่สองเกี่ยวข้องกับการเข้าถึงไคลเอนต์: หากมีเกตเวย์ความเสี่ยงหลายเกตเวย์ ไคลเอนต์จำเป็นต้องเชื่อมต่อกับแต่ละเกตเวย์ และจะต้องมีการเปลี่ยนแปลงในเลเยอร์ไคลเอนต์ เราต้องการหลีกหนีจากสิ่งนี้ในขั้นตอนนี้ ดังนั้นการออกแบบ Risk Gateway ในปัจจุบันจึงประมวลผลสตรีมข้อมูลทั้งหมด สิ่งนี้จะจำกัดปริมาณงานสูงสุดอย่างมาก แต่ทำให้การรวมระบบง่ายขึ้นอย่างมาก
การทำสำเนา
ระบบของเราไม่ควรมีจุดล้มเหลวเพียงจุดเดียว นั่นคือ ส่วนประกอบทั้งหมดจะต้องทำซ้ำ รวมถึงตัวกลางข้อความด้วย เราแก้ไขปัญหานี้โดยใช้ระบบ CLLM โดยมีคลัสเตอร์ RCMS ซึ่งผู้มอบหมายงานสองคนสามารถทำงานในโหมดมาสเตอร์-สเลฟได้ และเมื่ออันหนึ่งล้มเหลว ระบบจะสลับไปยังอีกอันโดยอัตโนมัติ
การทำงานร่วมกับศูนย์ข้อมูลสำรอง
InfiniBand ได้รับการปรับให้เหมาะสมสำหรับการทำงานเป็นเครือข่ายท้องถิ่น กล่าวคือ สำหรับการเชื่อมต่ออุปกรณ์ที่ยึดเข้ากับชั้นวาง และไม่สามารถวางเครือข่าย InfiniBand ระหว่างศูนย์ข้อมูลที่กระจายตามภูมิศาสตร์สองแห่งได้ ดังนั้นเราจึงใช้บริดจ์/ดิสแพตเชอร์ ซึ่งเชื่อมต่อกับที่จัดเก็บข้อความผ่านเครือข่ายอีเทอร์เน็ตปกติ และถ่ายทอดธุรกรรมทั้งหมดไปยังเครือข่าย IB ที่สอง เมื่อเราต้องการย้ายจากศูนย์ข้อมูล เราสามารถเลือกศูนย์ข้อมูลที่จะใช้งานได้ในตอนนี้
ผลของการ
ทั้งหมดที่กล่าวมาข้างต้นไม่ได้ทำเสร็จในครั้งเดียว แต่ต้องทำซ้ำหลายครั้งในการพัฒนาสถาปัตยกรรมใหม่ เราสร้างต้นแบบขึ้นภายในหนึ่งเดือน แต่ต้องใช้เวลามากกว่าสองปีกว่าจะอยู่ในสภาพใช้งานได้ เราพยายามที่จะบรรลุการประนีประนอมที่ดีที่สุดระหว่างการเพิ่มเวลาในการประมวลผลธุรกรรมและการเพิ่มความน่าเชื่อถือของระบบ
เนื่องจากระบบได้รับการอัปเดตอย่างหนัก เราจึงนำการกู้คืนข้อมูลจากแหล่งข้อมูลอิสระสองแห่งมาใช้ หากที่เก็บข้อความทำงานไม่ถูกต้องด้วยเหตุผลบางประการ คุณสามารถนำบันทึกธุรกรรมจากแหล่งที่สอง - จาก Risk Engine หลักการนี้สังเกตได้ทั่วทั้งระบบ
เหนือสิ่งอื่นใด เราสามารถรักษา Client API ไว้ได้ ดังนั้นทั้งนายหน้าและใครก็ตามไม่จำเป็นต้องมีการปรับปรุงสถาปัตยกรรมใหม่อย่างมีนัยสำคัญ เราต้องเปลี่ยนอินเทอร์เฟซบางอย่าง แต่ไม่จำเป็นต้องทำการเปลี่ยนแปลงที่สำคัญกับรูปแบบการทำงาน
เราเรียกแพลตฟอร์มเวอร์ชันปัจจุบันว่า Rebus ซึ่งเป็นตัวย่อของนวัตกรรมที่เห็นได้ชัดเจนที่สุดสองประการในสถาปัตยกรรม นั่นคือ Risk Engine และ BUS
ในตอนแรก เราต้องการจัดสรรเฉพาะส่วนที่หักบัญชีเท่านั้น แต่ผลลัพธ์ที่ได้คือระบบแบบกระจายขนาดใหญ่ ขณะนี้ลูกค้าสามารถโต้ตอบกับ Trade Gateway, Clearing Gateway หรือทั้งสองอย่างได้
สิ่งที่เราประสบความสำเร็จในท้ายที่สุด:
ลดระดับความล่าช้า ด้วยธุรกรรมปริมาณน้อย ระบบจะทำงานในลักษณะเดียวกับเวอร์ชันก่อนหน้า แต่ในขณะเดียวกันก็สามารถรับภาระที่สูงกว่าได้มาก
ประสิทธิภาพสูงสุดเพิ่มขึ้นจาก 50 รายการเป็น 180 ธุรกรรมต่อวินาที การเพิ่มขึ้นเพิ่มเติมถูกขัดขวางโดยการจับคู่ลำดับเดียวเท่านั้น
มีสองวิธีในการปรับปรุงเพิ่มเติม: การจับคู่แบบขนานและการเปลี่ยนวิธีการทำงานร่วมกับเกตเวย์ ขณะนี้เกตเวย์ทั้งหมดทำงานตามรูปแบบการจำลอง ซึ่งหยุดทำงานตามปกติภายใต้ภาระดังกล่าว
สุดท้ายนี้ ฉันสามารถให้คำแนะนำแก่ผู้ที่กำลังสรุประบบองค์กรได้:
- เตรียมพร้อมสำหรับสิ่งที่เลวร้ายที่สุดตลอดเวลา ปัญหามักจะเกิดขึ้นโดยไม่คาดคิดเสมอ
- โดยปกติแล้ว เป็นไปไม่ได้เลยที่จะสร้างสถาปัตยกรรมใหม่อย่างรวดเร็ว โดยเฉพาะอย่างยิ่งหากคุณต้องการได้รับความน่าเชื่อถือสูงสุดจากตัวชี้วัดหลายตัว ยิ่งมีโหนดมากเท่าใด ก็ยิ่งมีทรัพยากรที่จำเป็นสำหรับการสนับสนุนมากขึ้นเท่านั้น
- โซลูชันแบบกำหนดเองและเป็นกรรมสิทธิ์ทั้งหมดจะต้องใช้ทรัพยากรเพิ่มเติมสำหรับการวิจัย การสนับสนุน และการบำรุงรักษา
- อย่าเลื่อนการแก้ไขปัญหาความน่าเชื่อถือของระบบและการกู้คืนหลังจากเกิดความล้มเหลว ให้นำมาพิจารณาในขั้นตอนการออกแบบเบื้องต้น
ที่มา: will.com