สถาปัตยกรรมเซิร์ฟเวอร์ที่ดีที่สุดสำหรับเกมเรียลไทม์คืออะไร

ฉันกำลังพัฒนาเกมแบบเรียลไทม์ซึ่งควรมีผู้เล่นหลายพันคนในแบบเรียลไทม์ (FPS เช่นความล่าช้าสูงสุด 1 วินาที) อะไรจะเป็นโครงสร้างพื้นฐานที่ดีที่สุดสำหรับสิ่งนี้

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

คลัสเตอร์ฐานข้อมูลจะใช้การจำลองแบบฐานข้อมูลเพื่อความสอดคล้องระหว่างฐานข้อมูล

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

ฉันใช้. NET + MSSQL สำหรับเกม

ขอบคุณ!

server client-server .net

— โรมัน
แหล่งที่มา

เมื่อคุณพูดว่า "โครงสร้างพื้นฐาน" คุณหมายถึงซอฟต์แวร์ฮาร์ดแวร์บริการหรือคุณเพียงแค่ต้องการให้เราทำการวิพากษ์แผนที่คุณมีอยู่เดิม

— Tetrad

@Nate - เรากำลังวางแผนที่จะขยายขนาดไม่ซ้ำกันดังนั้นจึงควรปรับขนาดได้อย่างสมบูรณ์

— โรมัน

-1 เนื่องจากteddziuba.com/2008/04/im-going-to-scale-my-foot-up-y.html - คุณไม่ครอบคลุมความต้องการด้านความจุใด ๆ คุณพูดว่าเกมนี้ไม่ได้ถูกทิ้ง แต่จะเป็นส่วนหนึ่งหรือไม่ ฯลฯ ลักษณะของการเพิ่มประสิทธิภาพ - รวมถึงความสามารถในการปรับขยาย - ต้องใช้ข้อมูลที่เฉพาะเจาะจงและไม่มีสถาปัตยกรรมที่ดีที่สุด

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

— The Duck Communist

"ง่ายที่สุด" ก็เป็นอัตนัย ง่ายที่สุดสำหรับใครในกรอบเวลาใดให้ทรัพยากรอะไร การแลกเปลี่ยนสแต็กทำงานได้ดีที่สุดกับคำถามเฉพาะ - "ฉันสร้างเซิร์ฟเวอร์นี้โดยใช้ LINQ และ MSSQL แต่มันล้มเหลวหลังจาก 70 ธุรกรรม / วินาทีนี่คือธุรกรรมสองอันดับแรกของฉันคิดเป็น 73% ของรันไทม์ฉันจะเพิ่มปริมาณงานได้อย่างไร "

คำตอบ:

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

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

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

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

— Kylotan
แหล่งที่มา

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

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

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

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

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

ระดับ 1: บันทึกลงในฐานข้อมูลทุก ๆ สิบวินาทีรวมถึงข้อมูลที่สำคัญ:
- สุขภาพผู้เล่น
- รายการผู้เล่น / รถปิคอัพ
ระดับ 2: บันทึกลงในฐานข้อมูลทุกๆ 2 วินาทีรวมถึงข้อมูลขนาดกลาง:
- ตำแหน่งของผู้เล่น
- ตำแหน่งของ NPC
ระดับ 3: ทุกสิ่งทุกอย่างไม่บ่อยเท่าที่จะเป็นไปได้

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

สำหรับการอ่านข้อมูลคุณจะต้องโหลดหน่วยความจำให้มากที่สุดเท่าที่จะเป็นไปได้ในแอพพลิเคชั่นเทียร์ให้มากที่สุดจากนั้นตรวจสอบให้แน่ใจว่าโค้ดทั้งหมดของคุณใช้พูลหน่วยความจำนี้ ดังที่ Joe ชี้ให้เห็นจะมีบางครั้งที่คุณต้องการธุรกรรม "เรียลไทม์" คุณควรมี IO เพียงพอในฐานข้อมูลของคุณเพื่อทำธุรกรรมแบบเรียลไทม์เมื่อจำเป็นโดยสันนิษฐานว่ามีฮาร์ดแวร์เพียงพอบนเซิร์ฟเวอร์ฐานข้อมูล / คลัสเตอร์

— เนท
แหล่งที่มา

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

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

— เนท

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

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

— เนท

จริง แต่คุณได้ออกจากเทียร์กลางทั้งหมด มันเป็น RDB แฝงต่ำหรือไม่? ODB หรือไม่ ที่เก็บคีย์ / ค่า ไม่มี DB และยอมแพ้กับกรด? STM หรือล็อค? เพื่อความยุติธรรมมันเป็นเรื่องยากมากที่จะตอบว่าเพราะไม่มีข้อมูลมากนักในคำถาม แต่คำตอบทั้งหมดนี้ที่มีต่อแผนภาพสถาปัตยกรรมคือการใช้ "ฟอง" ฟองใหญ่อยู่ตรงกลาง ในนั้นและเชื่อมต่อสองบริการเพิ่มเติมกับมันไม่จริงกรอกในสิ่งที่ "?" คือ.