คำถามติดแท็ก distributed-computing

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

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

8
การคำนวณแบบกระจายคืออะไร [ปิด]
ปิด คำถามนี้จะต้องมีมากขึ้นมุ่งเน้น ไม่ยอมรับคำตอบในขณะนี้ ต้องการปรับปรุงคำถามนี้หรือไม่ อัปเดตคำถามเพื่อให้มุ่งเน้นที่ปัญหาเดียวโดยแก้ไขโพสต์นี้ ปิดให้บริการใน5 ปีที่ผ่านมา อะไรคือการคำนวณแบบกระจายและอะไรคือความแตกต่างจากการคำนวณแบบขนาน / แบบพร้อมกัน? การใช้ mutexes และ semaphores ในหลายเธรดแบบขนานพยายามซิงโครไนซ์สำหรับการเข้าถึงทรัพยากรเป็นปัญหาในโดเมนของการคำนวณแบบกระจายหรือไม่?

2
รูปแบบสำหรับการรักษาความสอดคล้องในระบบเหตุการณ์ที่แจกจ่ายแบบกระจาย?
ฉันได้อ่านเกี่ยวกับการจัดหากิจกรรมเมื่อเร็ว ๆ นี้และชอบความคิดที่อยู่เบื้องหลัง แต่ติดอยู่กับปัญหาต่อไปนี้ สมมติว่าคุณมีกระบวนการที่เกิดขึ้นพร้อมกัน N กระบวนการซึ่งรับคำสั่ง (เช่นเว็บเซิร์ฟเวอร์) สร้างเหตุการณ์เป็นผลลัพธ์และเก็บไว้ในที่จัดเก็บส่วนกลาง สมมติว่าสถานะแอพพลิเคชั่นชั่วคราวทั้งหมดนั้นถูกเก็บรักษาไว้ในหน่วยความจำของแต่ละกระบวนการโดยการใช้เหตุการณ์ตามลำดับจากที่จัดเก็บ ตอนนี้สมมติว่าเรามีกฎเกณฑ์ทางธุรกิจดังต่อไปนี้ผู้ใช้แต่ละคนต้องมีชื่อผู้ใช้ที่ไม่ซ้ำกัน หากทั้งสองกระบวนการได้รับคำสั่งการลงทะเบียนผู้ใช้สำหรับชื่อผู้ใช้ X เดียวกันพวกเขาทั้งคู่ตรวจสอบว่า X ไม่ได้อยู่ในรายการชื่อผู้ใช้กฎจะตรวจสอบความถูกต้องของกระบวนการทั้งสองและพวกเขาทั้งสองเก็บเหตุการณ์ "ผู้ใช้ใหม่ . ขณะนี้เราได้ป้อนสถานะโกลบอลที่ไม่สอดคล้องกันเนื่องจากละเมิดกฎธุรกิจ (มีผู้ใช้สองรายที่แตกต่างกันด้วยชื่อผู้ใช้เดียวกัน) ในเซิร์ฟเวอร์ N แบบดั้งเดิม <-> 1 ระบบสไตล์ RDBMS ฐานข้อมูลจะใช้เป็นจุดศูนย์กลางของการซิงโครไนซ์ซึ่งช่วยป้องกันความไม่สอดคล้องดังกล่าว คำถามของฉันคือโดยทั่วไปแล้วเหตุการณ์ที่มาจากระบบจะแก้ไขปัญหานี้ได้อย่างไร พวกเขาเพียงแค่ประมวลผลทุกคำสั่งตามลำดับ (เช่น จำกัด จำนวนของกระบวนการที่สามารถเขียนไปยังร้านค้าถึง 1)?

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

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

1
แนวทางปฏิบัติที่ดีที่สุดสำหรับการจัดการการสื่อสารระหว่างแบบอะซิงโครนัส?
เพิ่งเสร็จสิ้นโครงการสำหรับจัดการการประมวลผลบัตรเครดิต หนึ่งในปัญหาที่ฉันเผชิญคือการจัดการความล่าช้า / ความล้มเหลวที่เป็นไปได้ของข้อความแจ้งเตือน ตัวอย่างที่ซับซ้อนที่สุดคือ: ระบบภายนอกส่งการร้องขอการชำระเงิน ระบบของฉันเปลี่ยนคำขอนั้นเป็นคำขอไปยังเกตเวย์การชำระเงิน ส่งผู้ใช้ไปยังเกตเวย์ รอให้ผู้ใช้ชำระเงิน ผู้ใช้กลับไปที่ระบบของฉัน แต่ถูกระงับจนกระทั่งระบบได้รับการแจ้งเตือนของความสำเร็จ / ความล้มเหลว การส่งผู้ใช้กลับไปยังระบบภายนอกขึ้นอยู่กับความล้มเหลว ยิ่งยากขึ้นคือความจริงที่ว่าเมื่อล้มเหลวในการส่งการแจ้งเตือนเกตเวย์จะพยายามส่งการแจ้งเตือนทุก ๆ 15 นาทีเป็นเวลาหลายชั่วโมง ฉันแก้ไขมันโดยใช้บันทึกฐานข้อมูลของธุรกรรมที่ค้างอยู่จากนั้นตรวจสอบความสำเร็จและความล้มเหลวจากการส่งคืนรวมทั้งฟังการหน่วงเวลาสำหรับการแจ้งเตือนและการจัดการธุรกรรม ... ยากพอสมควร! แต่สิ่งนี้จะต้องได้รับการแก้ไขเป็นพันล้านครั้งก่อนดังนั้นวิธีปฏิบัติที่ดีที่สุดคืออะไร? ฉันสามารถเห็นอนาคตของฉันกำลังจะเขียนการจัดการระหว่างระบบทั้งหมดเหล่านี้และการจัดการความล่าช้าของเวลาและความล้มเหลวของเครือข่ายที่เป็นไปได้ดังนั้นฉันจึงต้องการปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุด คำแนะนำหนังสือ / บทความจะดีมาก ขอบคุณล่วงหน้า!

3
เรามาเต็มวงกลมด้วย microservices ย้อนกลับไปยังโรงเรียนเก่า
ในแง่ของสถาปัตยกรรมซอฟต์แวร์และการออกแบบ microservices "stack up" (เล่นสำนวนเจตนา) กับมิดเดิลแวร์อย่างไร ฉันมาจาก Java และดูเหมือนว่าเมื่อคุณย้ายออกจาก REST แบบตรงเป็น API และแยกแยะเลเยอร์และพารามิเตอร์การเชื่อมต่อต่าง ๆ อย่างน้อยที่สุดใน Java คุณเกือบจะกลับมาที่ความคิดเก่า ๆ . เราได้กลับมาสู่การจำลองเสมือน ... ซึ่ง JVM นั้นเสมือนจริงอยู่แล้ว ด้วยวิธีที่ไม่เชื่อเรื่องพระเจ้าคุณสามารถและฉันจะเถียงข้อได้เปรียบที่เป็นนามธรรม, สงบเงียบ API กับ CORBA หรือในทางที่มีจาวาเป็นศูนย์กลางมากกว่า JMS หรือ MDB ในครั้งเดียว EJB เป็นเรื่องใหญ่ใน Java แล้วมันได้รับการยอมรับว่าเป็นกลุ่มของคลัสเตอร์ แต่ตอนนี้เรากลับไปที่จุดเริ่มต้นหรือไม่? หรือ microservices เสนอสิ่งที่ CORBA หรือดีกว่า MDB ขาดหรือไม่ เมื่อฉันอ่าน (TLDR) มาร์ตินฟาวเลอร์อธิบายการใช้ไมโครไซต์มันจะทำให้ฉันเป็นทางออกที่ดีสำหรับปัญหาที่ไม่ดีถ้าคุณต้องการ หรือค่อนข้างเป็นวิธีการปิดที่เปิดใจซึ่งนำเสนอระดับของความซับซ้อนเพียงผลักดันปัญหาไปรอบ …
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.