วิวัฒนาการของสถาปัตยกรรมระบบการซื้อขายและการหักบัญชีของตลาดหลักทรัพย์มอสโก ส่วนที่ 1

สวัสดีทุกคน! ฉันชื่อ Sergey Kostanbaev ที่ตลาดแลกเปลี่ยน ฉันกำลังพัฒนาแกนกลางของระบบการซื้อขาย

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

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

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

ประวัติเล็กน้อย

ในปี 1994 ระบบ ASTS ของออสเตรเลียเปิดตัวที่ตลาดแลกเปลี่ยนเงินตราระหว่างธนาคารมอสโก (MICEX) และตั้งแต่นั้นเป็นต้นมา ก็สามารถนับประวัติศาสตร์การซื้อขายทางอิเล็กทรอนิกส์ของรัสเซียได้ ในปี 1998 สถาปัตยกรรมการแลกเปลี่ยนได้รับการปรับปรุงให้ทันสมัยเพื่อแนะนำการซื้อขายทางอินเทอร์เน็ต ตั้งแต่นั้นมา ความเร็วของการนำโซลูชันใหม่และการเปลี่ยนแปลงทางสถาปัตยกรรมในทุกระบบและระบบย่อยได้รับแรงผลักดันเท่านั้น

ในช่วงหลายปีที่ผ่านมา ระบบแลกเปลี่ยนทำงานบนฮาร์ดแวร์ระดับไฮเอนด์ - เซิร์ฟเวอร์ HP Superdome 9000 ที่มีความน่าเชื่อถือเป็นพิเศษ (สร้างขึ้นบน PA-RISC) ซึ่งทุกอย่างทำซ้ำอย่างแน่นอน: ระบบย่อยอินพุต/เอาท์พุต, เครือข่าย, RAM (อันที่จริงแล้วมีอาร์เรย์ RAID ของ RAM), โปรเซสเซอร์ (แบบถอดเปลี่ยนได้) สามารถเปลี่ยนส่วนประกอบเซิร์ฟเวอร์ได้โดยไม่ต้องหยุดเครื่อง เราอาศัยอุปกรณ์เหล่านี้และถือว่าอุปกรณ์เหล่านี้ไม่ปลอดภัยหากเกิดข้อผิดพลาด ระบบปฏิบัติการเป็นระบบ HP UX ที่มีลักษณะคล้าย Unix

แต่ตั้งแต่ประมาณปี 2010 ปรากฏการณ์ก็ได้เกิดขึ้นที่เรียกว่าการซื้อขายด้วยความถี่สูง (HFT) หรือการซื้อขายด้วยความถี่สูง หรือพูดง่ายๆ ก็คือ หุ่นยนต์แลกเปลี่ยนหุ้น ในเวลาเพียง 2,5 ปี ภาระงานบนเซิร์ฟเวอร์ของเราเพิ่มขึ้น 140 เท่า

เป็นไปไม่ได้เลยที่จะทนต่อภาระดังกล่าวด้วยสถาปัตยกรรมและอุปกรณ์แบบเก่า จำเป็นต้องปรับตัว

การเริ่มต้น

การขอเข้าระบบแลกเปลี่ยนแบ่งได้เป็น XNUMX ประเภท คือ

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

ตามแผนผัง แกนของระบบสามารถแบ่งออกเป็นสามระดับ:

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

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

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

เวอร์ชันแรกของระบบประกอบด้วยเกตเวย์สองระดับและเซิร์ฟเวอร์กลางของระบบการซื้อขาย ขั้นตอนการทำงานเป็นดังนี้:

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

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

เนื่องจากโค้ดเป็นแบบเธรดเดียว จึงใช้สคีมแบบคลาสสิกพร้อมส้อมกระบวนการเพื่อให้บริการลูกค้าจำนวนมาก อย่างไรก็ตาม การ Fork ฐานข้อมูลทั้งหมดมีราคาแพงมาก ดังนั้นจึงมีการใช้กระบวนการบริการที่ไม่ซับซ้อนเพื่อรวบรวมแพ็กเก็ตจากเซสชัน TCP และถ่ายโอนไปยังคิวเดียว (SystemV Message Queue) Gateway และ Trade Engine ทำงานกับคิวนี้เท่านั้น โดยรับธุรกรรมจากที่นั่นเพื่อดำเนินการ ไม่สามารถส่งการตอบกลับได้อีกต่อไป เนื่องจากยังไม่ชัดเจนว่าควรอ่านกระบวนการบริการใด ดังนั้นเราจึงใช้เคล็ดลับ: กระบวนการที่แยกแต่ละกระบวนการจะสร้างคิวการตอบกลับสำหรับตัวมันเอง และเมื่อมีคำขอเข้ามาในคิวที่เข้ามา แท็กสำหรับคิวการตอบกลับก็จะถูกเพิ่มเข้าไปทันที

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

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

ความทันสมัยครั้งแรก

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

ผลกระทบของการซื้อขายความถี่สูง

สถาปัตยกรรมเวอร์ชันข้างต้นมีอยู่จนถึงปี 2010 ในขณะเดียวกัน เราไม่พอใจกับประสิทธิภาพของเซิร์ฟเวอร์ HP Superdome อีกต่อไป นอกจากนี้ สถาปัตยกรรม PA-RISC แทบไม่มีการใช้งานเลย ผู้ขายไม่ได้เสนอการอัปเดตที่สำคัญใดๆ ด้วยเหตุนี้ เราจึงเริ่มย้ายจาก HP UX/PA RISC ไปเป็น Linux/x86 การเปลี่ยนแปลงเริ่มต้นด้วยการปรับเซิร์ฟเวอร์การเข้าถึง

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

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

ที่ช่วงเวลา 50 ms นี้ ความเร็วเฉลี่ยจะอยู่ที่ประมาณ 16 ธุรกรรมต่อวินาที หากเราลดหน้าต่างลงเหลือ 20 ms เราจะได้ความเร็วเฉลี่ย 90 ธุรกรรมต่อวินาที โดยมีธุรกรรม 200 รายการที่จุดสูงสุด กล่าวอีกนัยหนึ่งโหลดไม่คงที่และมีการระเบิดกะทันหัน และคิวคำขอจะต้องได้รับการประมวลผลอย่างรวดเร็วเสมอ

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

วิวัฒนาการรอบใหม่

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

สีแดง - ทำงานกับคิวในเคอร์เนลปกติ สีเขียว - ทำงานในเคอร์เนลแบบเรียลไทม์

แต่การบรรลุเวลาแฝงที่ต่ำบนเซิร์ฟเวอร์ปกตินั้นไม่ใช่เรื่องง่าย:

• โหมด SMI ซึ่งในสถาปัตยกรรม x86 เป็นพื้นฐานสำหรับการทำงานกับอุปกรณ์ต่อพ่วงที่สำคัญรบกวนอย่างมาก การประมวลผลเหตุการณ์ฮาร์ดแวร์ทุกประเภทและการจัดการส่วนประกอบและอุปกรณ์นั้นดำเนินการโดยเฟิร์มแวร์ในโหมดที่เรียกว่า SMI แบบโปร่งใสซึ่งระบบปฏิบัติการจะไม่เห็นสิ่งที่เฟิร์มแวร์กำลังทำอยู่เลย ตามกฎแล้ว ผู้จำหน่ายรายใหญ่ทุกรายเสนอส่วนขยายพิเศษสำหรับเซิร์ฟเวอร์เฟิร์มแวร์ที่ช่วยลดปริมาณการประมวลผล SMI
• ไม่ควรมีการควบคุมความถี่ของโปรเซสเซอร์แบบไดนามิก ซึ่งจะนำไปสู่การหยุดทำงานเพิ่มเติม
• เมื่อล้างบันทึกระบบไฟล์ กระบวนการบางอย่างจะเกิดขึ้นในเคอร์เนลที่ทำให้เกิดความล่าช้าที่คาดเดาไม่ได้
• คุณต้องใส่ใจกับสิ่งต่างๆ เช่น CPU Affinity, Interrupt affinity, NUMA

ฉันต้องบอกว่าหัวข้อการตั้งค่าฮาร์ดแวร์และเคอร์เนล Linux สำหรับการประมวลผลแบบเรียลไทม์สมควรได้รับบทความแยกต่างหาก เราใช้เวลามากมายในการทดลองและค้นคว้าก่อนที่เราจะได้ผลลัพธ์ที่ดี

เมื่อย้ายจากเซิร์ฟเวอร์ PA-RISC เป็น x86 เราแทบไม่ต้องเปลี่ยนโค้ดระบบมากนัก เราแค่ปรับเปลี่ยนและกำหนดค่าใหม่เท่านั้น ในเวลาเดียวกัน เราได้แก้ไขข้อบกพร่องหลายประการ ตัวอย่างเช่น ผลที่ตามมาของข้อเท็จจริงที่ว่า PA RISC เป็นระบบ Big endian และ x86 เป็นระบบ Little endian ซึ่งปรากฏอย่างรวดเร็ว: ตัวอย่างเช่น ข้อมูลถูกอ่านไม่ถูกต้อง จุดบกพร่องที่ยากกว่านั้นคือ PA RISC ใช้ สม่ำเสมอสม่ำเสมอ (สม่ำเสมอตามลำดับ) การเข้าถึงหน่วยความจำ ในขณะที่ x86 สามารถเรียงลำดับการดำเนินการอ่านใหม่ได้ ดังนั้นโค้ดที่ถูกต้องอย่างแน่นอนบนแพลตฟอร์มหนึ่งจึงใช้งานไม่ได้บนอีกแพลตฟอร์มหนึ่ง

หลังจากเปลี่ยนมาใช้ x86 ประสิทธิภาพเพิ่มขึ้นเกือบสามเท่า เวลาในการประมวลผลธุรกรรมโดยเฉลี่ยลดลงเหลือ 60 μs

ตอนนี้เรามาดูกันดีกว่าว่ามีการเปลี่ยนแปลงสำคัญอะไรบ้างในสถาปัตยกรรมระบบ

มหากาพย์สำรองร้อนแรง

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

นอกจากนี้ยังมีข้อกำหนดอื่นๆ อีก:

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

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

ด้วยเหตุนี้เราจึงได้รูปแบบดังต่อไปนี้:

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

  

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

โครงการนี้ทำงานดังนี้

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

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

จะยังคง

ที่มา: will.com