ทำไมฐานข้อมูลเป็นคิวไม่ดี? [ปิด]


33

ฉันเพิ่งอ่านบทความนี้และฉันสับสน

ลองจินตนาการ 1 webapp และ 1 แอพลิเคชันที่แตกต่างกันทำหน้าที่เป็น "คนงาน" ทั้งสองร่วมกันฐานข้อมูลเดียวกัน

โอ้ฉันพูดว่า "การแบ่งปัน" .. แต่บทความจะเตือนอะไร :

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

=> ไม่เห็นด้วย มีบางกรณีที่แอปพลิเคชันที่แตกต่างยังคงเป็นส่วนหนึ่งของหน่วยเดียวกันดังนั้นแนวคิดของ "ปัญหาการมีเพศสัมพันธ์" จึงไม่มีเหตุผลในกรณีนี้

มาดำเนินการต่อ: เว็บแอปจัดการคำขอ HTTP ของไคลเอ็นต์และอาจอัปเดตเมื่อใดก็ได้ที่มีการรวม (คำศัพท์ DDD) เพื่อสร้างกิจกรรมโดเมนที่สอดคล้องกัน
เป้าหมายของผู้ปฏิบัติงานคือการจัดการกิจกรรมโดเมนเหล่านั้นโดยการประมวลผลงานที่ต้องการ

ประเด็นก็คือ:

ข้อมูลเหตุการณ์ควรส่งผ่านไปยังผู้ปฏิบัติงานอย่างไร

วิธีแรกในการส่งเสริมการอ่านบทความคือการใช้ RabbitMQ เป็นมิดเดิลแวร์ที่มุ่งเน้นข้อความ

เวิร์กโฟลว์จะง่าย:

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

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

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

แต่ทำไมต้องมีตัวกำหนดตารางเวลาพิเศษในฝั่งเว็บแอปและโดยวิธี: ทำไมต้องมี RabbitMQ ในกรณีนี้

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

ดังนั้นฉันจึงสงสัยว่าทำไมบทความมากมายบนเว็บจึงไม่สามารถจัดคิวฐานข้อมูลได้ยากขณะที่ส่งเสริมมิดเดิลแวร์ที่เน้นข้อความ

ข้อความที่ตัดตอนมาจากบทความ:

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

และความสอดคล้องทันทีละเว้น?

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

ฉันคิดถึงความคิดที่สำคัญบ้างไหม?

ขอบคุณ


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

คำตอบ:


28

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

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

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

สิ่งที่ควรพิจารณาอีกประการหนึ่งคือระบบคิวส่วนใหญ่มักจะไม่ใช้เทคนิคการทำโพล (บางตัวอนุญาตสำหรับ HTTP แต่แนะนำให้หลีกเลี่ยงการใช้สำหรับฝั่งรับ) RabbitMq ใช้โปรโตคอลเครือข่ายที่ออกแบบมาโดยเฉพาะสำหรับรถโดยสารข้อความเช่นAMPQ

แก้ไข: การเพิ่มกรณีการใช้งาน

วิธีที่ฉันใช้ Rabbit คือฉันมีจุดสิ้นสุด API ที่ยอมรับการเปลี่ยนแปลงซึ่งต้องใช้ตารางฐานข้อมูลที่ใช้งานหนัก ตารางนี้อยู่ภายใต้การโต้แย้งอย่างต่อเนื่องและในบางครั้งจะไม่สามารถบันทึกการเปลี่ยนแปลงในเวลาที่เหมาะสมจาก API สิ่งที่ฉันทำคือเขียนคำขอเปลี่ยนแปลงไปยังคิวแล้วมีบริการที่จัดการข้อความเหล่านี้ตามที่พวกเขาสามารถ หากการช่วงชิงฐานข้อมูลเกิดขึ้นคิวจะขยายตัวและการประมวลผลข้อความจะล่าช้า โดยทั่วไปเวลาในการประมวลผลลงในช่วง 14ms แต่ในช่วงเวลาของการต่อสู้สูงเราได้ถึง 2-3 วินาที


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

คุณเขียนว่า: "ไม่จำเป็นต้องกังวลกับการล็อค" แต่แน่นอนว่ามีการล็อคเพื่อให้มั่นใจว่าลำดับเหตุการณ์ (ตามเวลาที่กำหนด) จากมากไปหาน้อย (ตรงไปยังผู้ปฏิบัติงาน) ไม่ใช่หรือ?
Mik378

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

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

1
@ Mik378 - ฉันได้เพิ่มกรณีการใช้งานให้กับคำตอบของฉัน ฉันหวังว่ามันจะช่วย!
brianfeucht
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.