ในเงื่อนไขใด (ถ้ามี) มันเป็นการดีหรือไม่ที่จะค้นหาเซิร์ฟเวอร์สองเครื่องและใช้การตอบสนองที่เร็วที่สุดเท่านั้น

ฉันถามว่าตอนนี้คำถามที่ถูกลบโดยชุมชนในSOว่าทำไมใครบางคนจะใช้จาวาสคริปต์Promise.raceและผู้ใช้ตัวแทนระดับสูงแสดงความคิดเห็นนี้:

หากคุณมีสองบริการที่คำนวณค่าบางอย่างคุณสามารถค้นหาทั้งสองแบบขนานและใช้ค่าที่เคยถูกส่งกลับมาก่อนแทนที่จะทำการสืบค้นหนึ่งรอความล้มเหลวจากนั้นทำการสอบถามครั้งที่สอง

ฉันได้ค้นหาเกี่ยวกับความซ้ำซ้อนและกรณีการใช้งานทั่วไป แต่ฉันไม่พบอะไรเลยและจาก POV ของฉันมันไม่ควรที่จะเพิ่มปริมาณงานไปยังเซิร์ฟเวอร์ / บริการหากคุณไม่ต้องการใช้การตอบสนอง

ฉันขอยืนยันว่านี่เป็นคำถามทางเศรษฐศาสตร์มากกว่า อย่างไรก็ตามนั่นเป็นคำพิพากษาที่วิศวกรควรจะสามารถทำได้ ดังนั้นฉันกำลังตอบ

ฉันแบ่งคำตอบออกเป็นสี่ส่วน:

• การจัดการความเสี่ยง
• กลยุทธ์
• ค่าใช้จ่าย
• ปรีชา

การบริหารความเสี่ยง

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

แต่ไม่เกินความรู้ของคุณ คุณต้องรู้:

• มันเกิดขึ้นบ่อยแค่ไหน
• มันมีผลกระทบอะไรบ้าง

ตัวอย่างเช่นหากความล้มเหลวและลองใหม่เกิดขึ้นเพียงประมาณ 2% ของเวลามันอาจไม่คุ้มที่จะจัดการกับมัน หากเกิดขึ้นประมาณ 80% ของเวลา ... ขึ้นอยู่กับ ...

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

กลยุทธ์

ดังที่ฉันได้กล่าวไว้ข้างต้นมีมากกว่าหนึ่งวิธีที่จะไปที่ปัญหานี้ ฉันจะสมมติว่าคุณได้ลองใช้ลูปลองล้มเหลวแล้ว ดังนั้นให้เราดู ...

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

ตอนนี้สังเกตฉันบอกว่าสิ่งเหล่านี้ยังคงล้มเหลว หากเราสมมติว่าการสืบค้นไปยังเซิร์ฟเวอร์นั้นมีโอกาส 80% ที่จะเกิดความล้มเหลวการสืบค้นแบบขนานกับเซิร์ฟเวอร์สองเครื่องจะมีโอกาส 64% ที่จะเกิดความล้มเหลว ดังนั้นคุณอาจต้องลองใหม่

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

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

บางมากขึ้น:

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

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

ค่าใช้จ่าย

มีสี่ค่าใช้จ่าย:

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

คุณต้องสมดุลพวกเขา

ตัวอย่างเช่นให้เราบอกว่าคุณได้รับเงินประมาณหนึ่งดอลลาร์ต่อผู้ใช้ที่พึงพอใจ ว่าคุณมีผู้ใช้ 3000 คนต่อวัน ว่าคำขอล้มเหลวประมาณ 50% ของเวลา และที่ 2% ของผู้ใช้ออกโดยไม่ต้องจ่ายเมื่อคำขอล้มเหลว ซึ่งหมายความว่าคุณกำลังสูญเสีย (3000 * 50% * 2%) 30 ดอลลาร์ต่อวัน ตอนนี้ให้เราบอกว่าการพัฒนาคุณสมบัติใหม่จะทำให้คุณเสียค่าใช้จ่าย 100 ดอลลาร์และการติดตั้งเซิร์ฟเวอร์จะทำให้คุณเสียค่าใช้จ่าย 800 ดอลลาร์ - และไม่สนใจค่าใช้จ่ายรันไทม์ - ซึ่งหมายความว่าคุณจะได้รับผลตอบแทนจากการลงทุน ((100 + 800) / 30 ) 30 วัน. ตอนนี้คุณสามารถตรวจสอบงบประมาณและตัดสินใจ

อย่าพิจารณาค่านิยมเหล่านี้ที่เป็นตัวแทนของความเป็นจริงฉันเลือกพวกเขาเพื่อความมั่นใจทางคณิตศาสตร์

แนบท้าย:

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

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

ปรีชา

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

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

ในกรณีนี้ฉันจะดูวิดีโอเกมออนไลน์ พวกเขามีหน้าจอโหลดพวกเขามีหลายเซิร์ฟเวอร์พวกเขาจะเลือกเซิร์ฟเวอร์ตามเวลาแฝงและพวกเขาอาจอนุญาตให้ผู้ใช้สลับเซิร์ฟเวอร์ เรารู้ว่าใช้งานได้

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

สิ่งนี้ยอมรับได้หากเวลาของไคลเอ็นต์มีค่ามากกว่าเวลาบนเซิร์ฟเวอร์

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

และแน่นอนว่าควรปรึกษาเจ้าของ / ผู้จัดการของเซิร์ฟเวอร์เสมอ

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

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

นี่คือหนึ่งในกระดาษ , และอื่น ๆ ฉันจำได้ว่าได้อ่านกระดาษของ Google ในการนำไปปฏิบัติเช่นกัน

ฉันเห็นด้วยกับคำตอบอื่น ๆ เป็นส่วนใหญ่ แต่ฉันคิดว่ามันควรจะหายากในทางปฏิบัติ ฉันต้องการแบ่งปันตัวอย่างทั่วไปที่สมเหตุสมผลและสมเหตุสมผลมากขึ้นเมื่อคุณจะใช้Promise.race()บางสิ่งที่ฉันเคยใช้เมื่อสองสามสัปดาห์ก่อน (เช่นเดียวกับ python)

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

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

นอกจากข้อพิจารณาทางเทคนิคแล้วคุณอาจต้องการใช้วิธีการนี้เมื่อเป็นส่วนหนึ่งของรูปแบบธุรกิจจริงของคุณ

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

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