เซิร์ฟเวอร์เกม C ++ แบบกระจายซึ่งใช้ฐานข้อมูล


11

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

มีแบบฝึกหัด / หนังสือ / มาตรฐานทั่วไปบ้างไหมที่จะอธิบายวิธีการใช้วิธีที่ดีที่สุด?

คำตอบ:


8

คำศัพท์ MMO สำหรับ "ยังคงอยู่ในโลกของเกมเดียว" เป็นชิ้นส่วนเดียว EVE ออนไลน์เป็น MMO ที่สำคัญเพียงอย่างเดียวที่จะพยายามบรรจุผู้เล่นทุกคนให้กลายเป็นชิ้นเดียว

โชคดีสำหรับคุณที่พวกเขาตีพิมพ์บทความข้อมูลมากเกี่ยวกับวิธีที่พวกเขาทำ


(ที่มา: gamasutra.com )

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

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

แทนที่จะกระจายเซิร์ฟเวอร์เกมของคุณฉันขอแนะนำให้สำรวจช่องทางอื่น ๆ ของคุณก่อน

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

คุณกำหนด "หลัก" ได้อย่างไร อาณาจักรแห่งความชิงชังใช้เศษชิ้นเดียว ทุกคนใช้ Farmville ร่วมกัน Star Trek Online และ Champions Online ต่างก็ใช้โมเดลที่มีชิ้นเดียว

แทนที่จะใช้ฐานข้อมูล SQL คุณสามารถใช้โซลูชัน noSQL ซึ่งออกแบบมาสำหรับการทำคลัสเตอร์และการแบ่งส่วนเช่น MongoDB
Philipp

1
@JoeWreschnig webgames ไม่ใช่เกมเรียลไทม์ง่ายกว่า ... ฉันไม่แน่ใจว่ามีผู้เล่นกี่คนที่ Star Trek Online และ Champions Online มี ...
o0 '

4

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

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


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

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

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

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

3

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

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

  1. ฐานข้อมูล SQL มีมานานกว่า 40 ปีฐานข้อมูล NoSQL เหล่านั้นเพียงไม่กี่ปี ยังมีความรู้ไม่มากนักวิธีการใช้งานอย่างมีประสิทธิภาพสูงสุดและการพัฒนาของพวกเขากำลังก้าวหน้าอย่างรวดเร็ว มีผลิตภัณฑ์ที่แข่งขันและเข้ากันไม่ได้อย่างสมบูรณ์จำนวนมากในตลาดและไม่มีสัญญาณว่าพวกเขาจะอยู่รอดได้และจะล้าสมัยและหยุดในไม่กี่ปี ผู้เล่นขนาดใหญ่ส่วนใหญ่ต้องการข้อบกพร่องของ SQL ที่รู้จักกันมากกว่าความเสี่ยงที่ไม่ทราบของฐานข้อมูล NoSQL
  2. พวกเขาทำงานแตกต่างจากฐานข้อมูล SQL และต้องการทบทวนกลยุทธ์การคงอยู่ของคุณใหม่ทั้งหมด ซึ่งอาจส่งผลให้เกิดการเปลี่ยนแปลงอย่างมากในสถาปัตยกรรมซอฟต์แวร์ทั้งหมดของคุณ

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


0

ไม่นี่เป็นพื้นที่ที่ยากอย่างเหลือเชื่อที่ยังไม่ได้รับการแก้ไข


อาจจะมี "แม่แบบ" (ไม่ใช่เป็น "รูปแบบการออกแบบ C ++) ของมันได้หรือไม่มี MMORPGs มากมาย
Slav

2
MMO ส่วนใหญ่ได้รับการสนับสนุนจากภัยพิบัติที่แน่นอนสำหรับฐานข้อมูล

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

0

ฉันรู้ว่ามันเก่า แต่ ....

ที่จริงแล้วมีสองด้านที่จะให้ความสำคัญกับเรื่องนี้

คุณต้องกระจายแอปพลิเคชันของคุณไปยังเซิร์ฟเวอร์ต่างๆ คุณต้องกระจายฐานข้อมูลของคุณไปยังเซิร์ฟเวอร์ต่างๆ

และคุณต้องมีความซ้ำซ้อนสำหรับทั้งคู่

มีโซลูชั่นโอเพนซอร์ซบางส่วนสำหรับเรื่องนี้ Farmville เป็นตัวอย่างที่ดีในการใช้ MemSQL / Couchbase


1
การกระจายฐานข้อมูลข้ามเซิร์ฟเวอร์หลายเครื่องเป็นปัญหาที่แก้ไขได้อย่างแน่นอน น่าเสียดายที่มันไม่ได้เป็นข้อกำหนดที่สำคัญสำหรับเกมออนไลน์ที่ทำให้ DB ของพวกเขาเข้าถึงได้น้อยที่สุด ในทางตรงกันข้ามการกระจายการเล่นเกมที่แท้จริงไปยังเซิร์ฟเวอร์หลาย ๆ ตัวยังไม่ได้รับการแก้ไข
Kylotan
โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.