mmorpg เก็บข้อมูลอย่างไร


22

ฉันต้องการใช้ฐานข้อมูล sql ใน server.exe ของฉัน

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

แต่อย่างไร

ฉันคิดว่ามีสองวิธี:

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

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


11
คุณเคยทำการวัดประสิทธิภาพมาก่อนหรือไม่? อะไรทำให้คุณคิดว่าการทำงานของฐานข้อมูลจะเป็นปัญหาสำหรับเกมของคุณ?
congusbongus

3
หากสถานะเกมของคุณสัมพันธ์กันจริง ๆ ? คุณแน่ใจหรือว่าต้องการฐานข้อมูล SQL
หยุดทำร้ายโมนิก้า

6
นอกจากนี้โปรดอ่านวิธีจัดการกับรหัสผ่านโดยใช้แฮช หรืออย่างน้อยก็แจ้งให้ผู้ใช้ทราบว่ารหัสผ่านของพวกเขาถูกบันทึกเป็นข้อความธรรมดาดังนั้นพวกเขาจึงไม่ควรใช้รหัสผ่านที่ปลอดภัยอื่น
TomTsagk

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

1
คุณสามารถเขียน API ทั่วไปที่ไม่เชื่อเรื่องการจัดเก็บ จากนั้นเขียนอะแดปเตอร์ที่แคชข้อมูลใน RAM เพื่อการจัดเก็บล่าช้า หรือคุณสามารถเขียนอะแดปเตอร์ที่เก็บข้อมูลในไฟล์ชั่วคราวก่อนที่จะล้างมันใน SQL DB วิธีนี้คุณสามารถเปิดและปิดการแคชเพื่อค้นหาว่าแบบไหนดีที่สุด คุณไม่จำเป็นต้องเขียนรหัสพิเศษเพิ่มเติมด้วยหากสถาปัตยกรรมของคุณถูกสร้างขึ้นอย่างถูกต้อง
0xC0DEGURU

คำตอบ:


37

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

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

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

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

ฉันขอแนะนำให้คุณใช้วิธีแรก


10
เกี่ยวกับ "การปรับช่วงเวลาการบันทึก" MMO สุดท้ายที่ฉันทำงานมีช่วงเวลาการบันทึกตามจำนวนผู้เล่นที่ใช้งานอยู่ เรารู้ว่ามันสามารถจัดการกับการบันทึกข้อมูลของผู้เล่น X ได้ต่อวินาทีโดยไม่ต้องมีการเห็นคอขวดดังนั้นเราจึงให้มันช่วยผู้เล่น X ภายใต้การหมุนเพียงเล็กน้อย มักจะจบลงด้วยการบันทึกสำหรับผู้เล่นแต่ละคนทุกสองนาทีหรือในวันที่วุ่นวายและอาจสองครั้งต่อนาทีในช่วงเวลาที่ช้า
Meanbits

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

6
ปัญหาเหล่านี้ไม่ได้เกิดจากเกม MMO หรือวิดีโอเกมแม้แต่อย่างเดียว เกือบทุก ORM มีอยู่ให้กลไกการแคช / แบทช์ ไม่จำเป็นต้องม้วนโซลูชันของคุณเอง
BlueRaja - Danny Pflughoeft

3
หากคุณจบลงด้วยการบันทึกลงดิสก์ในช่วงเวลาหนึ่งฉันขอแนะนำให้ออกแบบระบบที่สามารถบันทึกสิ่งต่าง ๆ ได้ทันทีเมื่อผู้คนได้รับ drop / die / etc ที่หายาก ด้วยวิธีนี้หากเซิร์ฟเวอร์มีปัญหาหรือบางสิ่งบางอย่างคนที่ทำสิ่งที่ยิ่งใหญ่จะไม่รู้สึกผิดหวัง
Jon

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

15

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


ฉันมองไปที่ระบบฐานข้อมูลทำงานเกมที่ผู้คนจะเรียก MMO-Lite - อันที่ฉันจะไม่เปิดเผย - แต่ฉันสามารถบอกได้ว่ามันมีผู้เล่นมากกว่า 1,000 คนอย่างสม่ำเสมอนี่เป็นนามธรรม:

  • พวกเขาใช้ฐานข้อมูล "No-SQL" ตามเอกสารสำหรับข้อมูลอักขระส่วนตัว (สินค้าคงคลัง, อุปกรณ์, ที่คล้ายกัน)
  • พวกเขาใช้ฐานข้อมูลเชิงสัมพันธ์แบบดั้งเดิมมากขึ้นสำหรับข้อมูลตัวละครสาธารณะที่มีการปรับปรุงน้อยมาก (ชื่อความสำเร็จ ฯลฯ ... ) และสถิติ

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

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


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

ทีนี้เมื่อผู้เล่นทำธุรกรรมกับระบบ - พูดแลกเปลี่ยนไอเท็มอื่นด้วย NPC หรือสิ่งที่คล้ายกัน - นี่มีขั้นตอนเหล่านี้:

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

หมายเหตุ :

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

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


บางครั้งมีบางอย่างผิดปกตินี่เป็นผลลัพธ์ที่เป็นไปได้สองประการ:

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

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


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


ขอบคุณ แต่สิ่งที่เกี่ยวกับผู้เล่นเคลื่อนไหวตัวอย่างเช่นหากผู้เล่นย้ายจากตำแหน่งปัจจุบันของเขา: x:10,y:10,z:10ถึงx:11,y:11,z:11สิ่งนี้ควรถูกบันทึกไว้ในฐานข้อมูลทันทีหรือไม่ จะเกิดอะไรขึ้นถ้าผู้เล่นยังคงทำงานต่อไปซึ่งหมายความว่าเราช่วยรักษาตำแหน่งปัจจุบันของเขาทุก ๆ 1 วินาทีหรือน้อยกว่าและถ้ามีผู้เล่นนับพันคน มันเป็นวิธีการทำงาน?
dwix

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

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

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


7

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

EVE Online เป็นตัวอย่างของ MMO ที่ทุกอย่างถูกเก็บไว้ในฐานข้อมูล SQL ฉันคิดว่ามันถึงจุดสูงสุดที่ผู้ใช้ประมาณ 60,000 คนพร้อมกันและต้องอุทิศฮาร์ดแวร์ราคาแพงให้กับเซิร์ฟเวอร์ฐานข้อมูลในช่วงหลายปีที่ผ่านมาเพื่อให้ทันกับการโหลด อย่างไรก็ตาม EVE เก็บข้อมูลมากขึ้นต่อผู้ใช้มากกว่า MMORPG ส่วนใหญ่และมีการทำธุรกรรมที่บ่อยและหลากหลายมากขึ้น คุณสมบัติ ACID ของฐานข้อมูลช่วยให้ฐานข้อมูลขนาดใหญ่และซับซ้อนทั้งหมดจะถูกเก็บไว้ในสถานะที่สอดคล้องกันเสมอ

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

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

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

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

สำหรับโครงการของคุณคุณอาจจะไปทางใดทางหนึ่ง การมีผู้ใช้ 1,000 คนพร้อมกันอาจจะไม่ผลักดันขีด จำกัด ของสิ่งที่เซิร์ฟเวอร์ SQL สามารถจัดการได้บนพีซีแบบ Commodity ในปัจจุบัน แต่ส่วนมากจะขึ้นอยู่กับลักษณะของธุรกรรม หากคุณคุ้นเคยกับ SQL และการออกแบบฐานข้อมูลเชิงสัมพันธ์สิ่งนี้สามารถใช้ได้กับคุณ คุณจะต้องการลดทอนธุรกรรมให้มากที่สุดเท่าที่จะเป็นไปได้สำหรับบางสิ่งเช่นจุดกระแสของผู้เล่นคุณอาจต้องการบันทึกเป็นระยะ ๆ ในฐานข้อมูลเนื่องจากสถิติเช่นนี้ไม่จำเป็นต้องสอดคล้องกันเสมอไป (ในเกม PvP พวกเขาอาจจะ ... ) อย่าเก็บสิ่งต่าง ๆ เช่นสัตว์ประหลาด HP ในฐานข้อมูลเลยในเกมส่วนใหญ่จะมีเพียงข้อมูลที่เกี่ยวข้องกับผู้เล่นเท่านั้น

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


0

เกมต่าง ๆ เก็บสิ่งต่าง ๆ ด้วยวิธีต่าง ๆ บ่อยครั้งที่ บริษัท เกมสร้างวิธีการทำเช่นนี้และเกมส่วนใหญ่ใช้วิธีเดียวกัน แน่นอนว่าสตูดิโอต่าง ๆ มักใช้วิธีที่ต่างกัน SQL ใช้สำหรับเกมอย่างแน่นอนเช่น CCP (EVE) มีเครือข่ายของเซิร์ฟเวอร์ SQL (หรืออย่างน้อยก็มี) ฉันไม่แน่ใจว่าพวกเขาทำได้อย่างไร อื่น ๆ เพียงใช้ไฟล์จำนวนมาก

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

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

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

รูปแบบหนึ่งที่จะจัดส่งข้อมูลอาจเป็น XML ด้วยวิธีนี้คุณสามารถมีพลวัตได้ง่ายขึ้นในวิธีที่คุณสามารถทำให้เป็นก้อนขึ้น ตัวละครตัวหนึ่งกับตัวละครหลายตัวหรือหนึ่งรายการกับชุดของรายการ ฯลฯ จากนั้นคุณสามารถ "เก็บ" XML เป็น XML (ใน SQL) และ / หรือให้ SQL กระจายออกไปในรูปแบบการทำธุรกรรมจาก XML เพื่อ วิธีที่คุณต้องการจัดเก็บข้อมูลจริง

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

ด้วย 1,000 ลูกค้าคุณสามารถเริ่มต้นด้วยและเก็บ 10 MB ต่อลูกค้าได้อย่างง่ายดายและใช้ RAM ที่มีประสิทธิภาพ 10 GB + เพิ่ม RAM สำหรับผู้ดูแลระบบสำหรับการจัดการข้อมูลกล่าวอีก GB หรือสองรายการ คุณสามารถเก็บมันไว้ใน RAM บนโฮสต์แล้วในโครงสร้างข้อมูลที่พร้อมใช้งาน และโหลด / บันทึกแบบไดนามิกขึ้นอยู่กับว่าใครออนไลน์ในความถี่ต่าง ๆ ขึ้นอยู่กับกิจกรรม ฯลฯ

คุณสามารถจัดเก็บข้อมูลลูกค้าแต่ละรายในไฟล์แยกต่างหากและอื่น ๆ


0

รักษาผู้เล่น * ออนไลน์ * ในหน่วยความจำและส่งไปยังฐานข้อมูล (SQLite? MySQL?) เมื่อพวกเขาออกจากระบบ หากคุณกังวลเกี่ยวกับการปิดกั้น IO ระหว่างการออกจากระบบให้แต่ละการออกจากระบบของตัวเองไม่ได้ทำในหัวข้อหลัก / เกม (อันที่จริงฉันเก็บเธรดผู้เล่นเฉพาะสำหรับผู้เล่นออนไลน์ทุกคนมันทำให้รหัสเครือข่ายง่ายขึ้นมาก กว่าทำตามแนวทางเครือข่าย async io)

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