Máy chủ trò chơi C ++ phân tán sử dụng cơ sở dữ liệu

Máy chủ trò chơi theo lượt C ++ của tôi (sử dụng cơ sở dữ liệu) không chống lại số lượng khách hàng trung bình hiện tại (người chơi), vì vậy tôi muốn mở rộng nó thành nhiều (nhiều hơn một) số lượng máy tính và cơ sở dữ liệu mà tất cả các máy khách vẫn sẽ ở trong thế giới trò chơi đơn (các máy chủ sẽ phải giao tiếp với nhau và sử dụng nhiều cơ sở dữ liệu).

Có một số hướng dẫn / sách / tiêu chuẩn chung giải thích làm thế nào để làm điều đó một cách tốt nhất?

Thuật ngữ MMO cho "vẫn còn trong một thế giới trò chơi" là một phân đoạn duy nhất . EVE trực tuyến là MMO lớn duy nhất cố gắng nhồi nhét mọi người chơi vào một mảnh vỡ duy nhất.

May mắn cho bạn, họ đã xuất bản một bài viết rất nhiều thông tin về cách họ làm điều đó.

_{(nguồn: gamasutra.com )}

Các tin xấu. Bạn không thể áp dụng các kỹ thuật của EVE trực tuyến nói chung. Các giải pháp của họ hoàn toàn phù hợp với thể loại và cách thực hiện cụ thể của họ.
LƯU Ý : Đối với tất cả các mạng phân đoạn đơn siêu ưa thích của EVE trực tuyến, họ sử dụng một cơ sở dữ liệu. Họ không thể thiết kế một giải pháp thời gian thực phù hợp, có thể mở rộng cho các cơ sở dữ liệu phân tán.

Dù bằng cách nào, họ đã làm như thế nào để giúp bạn thiết kế giải pháp của riêng bạn. Hãy coi chừng, tuy nhiên, bạn đang cố gắng giải quyết một vấn đề rất khó khăn.

Thay vì phân phối máy chủ trò chơi của bạn, tôi sẽ đề nghị khám phá những con đường khác của bạn trước.

• Hồ sơ máy chủ trò chơi của bạn.
  • Tối ưu hóa mã máy chủ của bạn để giảm gánh nặng CPU nếu đó là một vấn đề.
  • Tối ưu hóa giao thức giao tiếp giữa máy khách và máy chủ để cắt giảm cuộc trò chuyện mạng.
• Tối ưu hóa máy chủ game thủ để truyền thông cơ sở dữ liệu.
  • chạy trình tối ưu hóa truy vấn sau đó thực hiện các thay đổi khi thích hợp.
  • cắt giảm tương tác DB xuống mức tối thiểu
• Di chuyển DB sang một máy riêng.
  Điều này thường giúp một tấn. Giữ DB trên cùng một mạng cục bộ nếu có thể nhưng điều đó phải giúp máy chủ trò chơi của bạn trở nên mạnh mẽ hơn rất nhiều khi đó là thứ duy nhất chạy trên phần cứng máy chủ.

Bước đầu tiên của bạn là tách rời truy cập cơ sở dữ liệu trực tiếp từ máy chủ trò chơi và sử dụng phần mềm trung gian cụ thể sử dụng để chuẩn bị dữ liệu cho máy chủ của bạn (ví dụ: XML, JSON). Chúng có thể xử lý bất kỳ số lượng cơ sở dữ liệu nào và quan trọng hơn là có thể cung cấp cho bạn các tùy chọn bộ đệm cụ thể của ứng dụng. Cache bất cứ điều gì bạn có thể và cằn nhằn db chỉ khi bạn phải. Thực hiện các tìm nạp lớn và hiếm khi thay vì nhiều truy vấn nhỏ để đạt được hiệu suất tốt nhất có thể trong kịch bản của bạn.

Cơ sở dữ liệu bạn chọn cũng có thể cho phép bạn vận hành các cụm giúp dễ dàng mở rộng trên các tài nguyên cơ sở dữ liệu có sẵn và cung cấp kết quả của bạn nhanh hơn, nhưng đây là một chủ đề cần nhiều kinh nghiệm và quản trị viên cơ sở dữ liệu chuyên dụng để thiết lập và duy trì - và không hoàn toàn cho ngân sách độc lập.

Về máy chủ trò chơi: Một chiến lược phổ biến là sử dụng nhiều máy chủ trong đó mỗi máy chủ quản lý một phần của thế giới trò chơi. Mỗi người dùng thường chỉ cần biết về những gì đang xảy ra xung quanh nó, do đó, việc phân chia thế giới theo địa phương là điều hợp lý. Điều này không may trở nên phức tạp hơn rất nhiều khi bạn có một thế giới mở không có biên giới thay vì một thế giới bao gồm các khu vực kín và người chơi dịch chuyển tức thời giữa chúng. Khi bạn có một thế giới mở, bạn cần một cách để chuyển người chơi giữa các khu vực một cách liền mạch và một cách để đồng bộ hóa các khu vực gần biên giới giữa các máy chủ. Đó là một vấn đề khó khăn.

Về cơ sở dữ liệu: Cơ sở dữ liệu SQL thường có quy mô xấu. Chúng không được thiết kế để được phân phối. Nhưng hiện tại có một xu hướng khá mới về cơ sở dữ liệu NoQuery như MongoDB hoặc Cassandra được thiết kế để phân phối trên nhiều máy chủ. Chúng làm cho việc bổ sung dung lượng dễ dàng hơn nhiều chỉ bằng cách thêm nhiều máy chủ. Vậy tại sao tất cả các trò chơi lớn không chuyển sang chúng? Bởi vì:

1. Cơ sở dữ liệu SQL tồn tại hơn 40 năm, những cơ sở dữ liệu NoQuery đó chỉ trong một vài năm. Vẫn chưa có nhiều bí quyết về cách sử dụng chúng một cách hiệu quả nhất và sự phát triển của chúng đang tiến triển nhanh chóng. Có rất nhiều sản phẩm cạnh tranh và hoàn toàn không tương thích trên thị trường, và không có dấu hiệu nào trong số chúng sẽ tồn tại và sẽ bị lỗi thời và ngừng sản xuất trong một vài năm. Hầu hết những người chơi lớn thích những thiếu sót đã biết của SQL hơn những rủi ro chưa biết của cơ sở dữ liệu NoQuery.
2. Chúng hoạt động rất khác với cơ sở dữ liệu SQL và yêu cầu suy nghĩ lại toàn bộ chiến lược kiên trì của bạn. Điều này có thể dẫn đến những thay đổi mạnh mẽ trong toàn bộ kiến ​​trúc phần mềm của bạn.

Vì vậy, khi dự án của bạn đã rất tiến bộ, chuyển sang một giải pháp cơ sở dữ liệu khác có thể là một rủi ro lớn và đầu tư rất lớn về thời gian và năng lượng.

Không. Đây là một khu vực cực kỳ khó khăn chưa được giải quyết.

Tôi biết điều này đã cũ nhưng ....

Thực tế có hai lĩnh vực để tập trung vào việc này.

Bạn cần phân phối ứng dụng của bạn trên một số máy chủ. Bạn cần phân phối cơ sở dữ liệu của bạn trên một số máy chủ.

Và bạn cần phải có dự phòng cho cả hai.

Có một số giải pháp nguồn mở cho việc này. Farmville là một ví dụ điển hình khi sử dụng MemQuery / Couchbase.