Kiến trúc máy chủ tốt nhất cho các trò chơi thời gian thực là gì?

Tôi đang phát triển một trò chơi thời gian thực, có thể chứa hàng ngàn người chơi trong thời gian thực (FPS như. Độ trễ tối đa 1 giây). Điều gì sẽ là cơ sở hạ tầng tốt nhất cho việc này?

Ý tưởng của tôi là sử dụng 2 cụm máy chủ - một cho Đầu cuối máy chủ (tất cả các mặt máy tính) và một cho đầu cuối Cơ sở dữ liệu, trong đó bộ cân bằng tải "chịu trách nhiệm" cho từng cụm. Một máy chủ chính sẽ nhận được yêu cầu từ người dùng và gửi lại địa chỉ IP của máy chủ có liên quan mà người dùng có thể làm việc này.

Cụm cơ sở dữ liệu sẽ sử dụng sao chép cơ sở dữ liệu để thống nhất giữa các cơ sở dữ liệu.

Cũng cần có một bộ cân bằng tải địa lý - vì vậy nó sẽ chỉ định bộ cân bằng tải khu vực cho mỗi người dùng để đáp ứng tốt nhất.

Tôi đang sử dụng .NET + MSSQL cho trò chơi.

Cảm ơn!

Không có kiến ​​trúc tốt nhất mà không biết nhiều hơn về các yêu cầu của bạn, ví dụ. loại tương tác giữa các nhân vật, bao nhiêu dữ liệu sẽ được duy trì liên tục, v.v.

Nếu bạn có thể đối phó với độ trễ 1 giây, bạn có thể lưu trữ 1000 người chơi trên một máy chủ mà không gặp vấn đề gì - nhưng điều đó thực sự mâu thuẫn với ý tưởng về FPS vì chúng thường yêu cầu độ trễ thấp hơn nhiều, ví dụ. dưới 100ms. Nhưng một hệ thống có thể xử lý độ trễ cao có thể đủ khả năng để thực hiện mọi thứ thông qua tin nhắn, điều này làm cho tính nhất quán trở nên khá nhỏ. Việc cung cấp logic của bạn khá đơn giản, đó là - logic phức tạp thậm chí còn tệ hơn khi bạn biến nó thành một hệ thống dựa trên thông báo thay vì hệ thống đối tượng bị khóa - nhưng tất cả phụ thuộc vào nhu cầu của ứng dụng của bạn.

Tương tự, nếu bạn không lưu giữ nhiều dữ liệu, bạn hoàn toàn không cần máy cơ sở dữ liệu, nhưng không biết điều đó, thật khó để nói. Nếu bạn đang duy trì một lượng nhỏ dữ liệu và có lẽ chỉ thực hiện ở cuối giải đấu hoặc thứ gì đó, một lần nữa bạn không cần một cơ sở dữ liệu riêng biệt, chắc chắn không phải là một cụm trong số đó. Mặt khác, nếu bạn không kiên trì nhưng đọc nhiều, đó là nơi cơ sở dữ liệu được nhân rộng có thể giúp bạn - nhưng nó cũng chỉ ra rằng cơ sở dữ liệu quan hệ có thể không phù hợp nhất cho vấn đề của bạn ngay từ đầu. Thông thường một bộ nhớ cache trong bộ nhớ là một giải pháp tốt hơn. Tương tự, nếu không có tương tác kiểu giao dịch giữa các ký tự, thì tính nhất quán trở nên ít quan trọng hơn. (Và nếu chỉ có một vài giao dịch như vậy, bạn có thể biến chúng thành một trường hợp đặc biệt.)

Trong thực tế, hãy cảnh giác khi áp dụng RDBMS chỉ vì đó là điều được thực hiện trong các hệ thống lớn. Mặc dù cá nhân tôi chấp nhận sử dụng chúng trong các trò chơi trực tuyến, tốt nhất bạn nên xem xét các yêu cầu của bạn và tìm ra chiến lược bền bỉ của bạn từ đó, thay vì lấy cơ sở dữ liệu ưa thích của bạn và sau đó cố gắng điều chỉnh nó bằng bộ nhớ cache và sao chép để phù hợp với nó ứng dụng. Bạn có thể thấy rằng tất cả những gì bạn cần là khả năng báo cáo ngoại tuyến, trong trường hợp đó có lẽ tốt nhất là ghi nhật ký quá trình nền từ cơ chế lưu giữ trò chơi của bạn vào RDBMS từ xa ở một nơi khác.

Tuyên bố miễn trừ trách nhiệm: trải nghiệm lập trình trò chơi của tôi dựa trên các trò chơi một người chơi phía khách, nhưng tôi có nền tảng về các ứng dụng web (cụ thể là trên Microsoft stack), vì vậy đó là nơi tôi đến từ câu trả lời này, tôi cảm thấy rằng sẽ rất nhiều áp dụng, nhưng không thử nghiệm thực tế một máy chủ trò chơi thực sự rất khó để nói nó sẽ áp dụng như thế nào, nhưng ở đây sẽ đi. Biết điều này: Tôi chưa triển khai một máy chủ trò chơi, chỉ có ứng dụng web.

Tôi sẽ đề nghị một cách tiếp cận hai (máy chủ). Một tầng cơ sở dữ liệu và một tầng "ứng dụng"; với tầng thứ ba (thuyết trình) là khách hàng trò chơi của bạn.

Cơ sở dữ liệu quan hệ, rất tốt trong việc truy vấn dữ liệu và khá giỏi trong việc ghi dữ liệu. Điều quan trọng là tuần tự hóa cơ sở dữ liệu của bạn ghi vào các khối kích thước có thể quản lý mà cụm của bạn có thể xử lý. Các phiên bản nâng cao hơn (Trung tâm dữ liệu / Doanh nghiệp) của SQL Server hỗ trợ phân cụm và sao chép. Tôi sẽ bắt đầu bằng cách xây dựng một cụm nhỏ và chạy một số truy vấn để xem nó hoạt động như thế nào.

Trong tầng ứng dụng, nếu bạn đang thực hiện "khoanh vùng" hoặc một cái gì đó tương tự, bạn có thể thoát khỏi mà không cần thiết lập bất kỳ cụm nào, và chỉ cần thiết lập một máy chủ cho mỗi vùng. Nếu các vùng của bạn trở nên lớn, bạn có thể thiết lập một cụm cho từng vùng.

Bạn sẽ muốn xây dựng một quy trình tuần tự hóa để gửi dữ liệu từ tầng ứng dụng -> tầng cơ sở dữ liệu. Điều quan trọng là có nhiều cấp độ tuần tự hóa đang diễn ra. Một cái gì đó như thế này:

• Cấp 1: Lưu vào DB mỗi X giây, bao gồm dữ liệu quan trọng:
  • Sức khỏe cầu thủ
  • Vật phẩm / Pickup của người chơi
• Cấp độ 2: Lưu vào DB cứ sau 2 lần, bao gồm dữ liệu trung bình:
  • Địa điểm người chơi
  • Địa điểm NPC
• Cấp độ 3: Mọi thứ khác, không thường xuyên nhất có thể

Điều này sẽ giữ cho bài viết của bạn nhất quán và có thể dự đoán được, tùy thuộc vào bản chất của trò chơi của bạn, bạn có thể có cơ sở dữ liệu ghi không thường xuyên. Điều quan trọng là nhận ra rằng nếu máy chủ ứng dụng của bạn bị sập, bạn phải quay lại trực tuyến từ trạng thái trong cơ sở dữ liệu của mình, do đó việc tuần tự hóa kho của người chơi cứ sau 90 phút có thể khiến người chơi khó chịu.

Để đọc dữ liệu, bạn sẽ muốn tải càng nhiều càng tốt vào bộ nhớ trong tầng ứng dụng càng tốt, sau đó đảm bảo rằng tất cả mã của bạn sử dụng nhóm bộ nhớ này, trong nền bạn có thể đồng bộ hóa nhóm bộ nhớ với cơ sở dữ liệu. Như Joe chỉ ra, sẽ có lúc bạn cần giao dịch "thời gian thực". Bằng cách tuần tự hóa hầu hết các ghi của bạn, bạn vẫn nên có đủ IO ​​trên cơ sở dữ liệu của mình để thực hiện các giao dịch thời gian thực khi cần thiết, giả sử đủ phần cứng trên máy chủ / cụm cơ sở dữ liệu.