Làm thế nào để mmorpg lưu trữ dữ liệu?

Tôi muốn sử dụng cơ sở dữ liệu sql trong server.exe của tôi.

Hãy nói 1000 người dùng trực tuyến. Và người chơi sẽ thay đổi dữ liệu của họ khi họ chơi. Và máy chủ cần lưu các bản cập nhật này.

Nhưng bằng cách nào ?

tôi nghĩ có hai cách:

1) máy chủ sẽ lưu ram trong thời gian chạy và đôi khi hoặc hàng giờ máy chủ sẽ ghi dữ liệu (cập nhật) vào cơ sở dữ liệu sql từ ram. Nhưng nếu điện bị mất hoặc bằng cách nào đó máy chủ tắt, cập nhật sẽ không lưu. Tất nhiên tôi không muốn mất cập nhật.

2) máy chủ sẽ lưu các cập nhật trong cơ sở dữ liệu trong thời gian chạy. Nhưng điều gì sẽ xảy ra với tốc độ? Tôi nghĩ về một phương pháp. tôi sẽ chỉ cho bạn dưới đây với hình ảnh. Tôi có thể có đủ tốc độ cho 1000 người chơi trực tuyến bằng phương pháp này không?

Hầu hết các MMO (hoặc dự án sử dụng kiến ​​trúc tương tự) Tôi đã làm việc hoặc biết sử dụng phương pháp đầu tiên: máy chủ trò chơi hoạt động chủ yếu với RAM trên các máy chạy quy trình máy chủ và chỉ định kỳ tuần tự hóa dữ liệu trò chơi có liên quan đến cơ sở dữ liệu SQL để lưu trữ (nếu một trong tất cả được sử dụng).

Các vấn đề bạn lưu ý liên quan đến sự cố mất điện là hợp lệ, nhưng ít xảy ra hơn các sự cố như sự cố trong quá trình (độ tin cậy về thời gian hoạt động nói chung là một trong những điều bạn phải trả cho trung tâm dữ liệu). Nhưng vẫn. Bạn giảm thiểu các vấn đề đó thông qua những việc như điều chỉnh khoảng thời gian lưu (do đó, một sự cố chỉ tốn ít nhất vài phút tiến triển), phân phối hàng đợi lưu trên nhiều máy, tích cực phân bổ lượng dữ liệu cần lưu và thực hiện lưu lại có thể khởi động lại xếp hàng.

Nói chung, sử dụng chính máy chủ SQL làm bộ nhớ chính sẽ chậm một cách khó chịu (và cồng kềnh). Tôi không thấy đủ chi tiết trong đề xuất của bạn ở đó để có thể nói chắc chắn nếu nó chỉ hoạt động với khoảng 1000 người chơi - có lẽ sẽ ổn. Nhưng tôi không tin rằng bạn có thể làm cho nó có khả năng mở rộng mạnh mẽ.

Hơn nữa, nó không giải quyết vấn đề. Mất điện trong quá trình lưu sẽ vẫn bị mất hoặc hỏng dữ liệu trừ khi bạn thực hiện công việc để thực hiện cùng loại hàng đợi lưu có thể khởi động lại (điều đó thậm chí chỉ làm giảm nghiêm trọng khả năng mất dữ liệu thảm khốc, điều đó không ngăn chặn được) .

Tôi khuyên bạn nên đi với cách tiếp cận đầu tiên.

1000 người chơi có thể hoặc không thể là một vấn đề. Nó phụ thuộc vào tần suất bạn cần cập nhật cơ sở dữ liệu. Tuy nhiên, có một giải pháp đơn giản: đặt cơ sở dữ liệu trên máy chủ của chính nó.

Tôi đã xem qua cách hệ thống cơ sở dữ liệu hoạt động một trò chơi mà mọi người sẽ gọi là MMO-Lite - trò chơi mà tôi sẽ không tiết lộ - nhưng tôi có thể nói rằng nó luôn có hơn 1000 người chơi, đây là bản tóm tắt:

• Họ sử dụng cơ sở dữ liệu "No-SQL" dựa trên tài liệu cho thông tin ký tự riêng (kho, thiết bị, tương tự).
• Họ sử dụng một cơ sở dữ liệu quan hệ truyền thống hơn cho thông tin nhân vật công cộng được cập nhật hiếm khi (tên, thành tích, v.v ...) và số liệu thống kê.

Sử dụng một cơ sở dữ liệu dựa trên tài liệu hóa ra là một ý tưởng tốt cho hiệu suất trong trường hợp này. Nó là tốt để truy cập dữ liệu, mặc dù nó là xấu khi thực hiện tham gia và tổng hợp ... nhưng họ sẽ không làm điều đó với dữ liệu có trong đó.

Mặt khác, khi họ cần làm một việc gì đó như thay đổi một đối tượng với một đối tượng khác cho mọi người, thì cần phải chạy một kịch bản nền theo từng ký tự và cập nhật từng cái một, điều đó cần có thời gian đáng chú ý.

Dữ liệu của nhân vật tồn tại cả trên máy khách và máy chủ, và hệ thống được thiết kế để giữ chúng đồng bộ, thực hiện các hoạt động giống nhau ở cả hai bên.

Bây giờ, khi người chơi thực hiện giao dịch với hệ thống - giả sử trao đổi một mặt hàng cho người khác thông qua NPC hoặc tương tự - điều này có các giai đoạn sau:

• Các khách hàng kiểm tra nếu hoạt động là hợp lệ
• Máy khách gửi hoạt động đến máy chủ (hoạt động không đồng bộ)
• Máy khách cập nhật mô hình của nó trong RAM
• Máy chủ kiểm tra nếu hoạt động hợp lệ
• Máy chủ cập nhật mô hình của nó trong RAM
• Máy chủ cập nhật cơ sở dữ liệu (hoạt động không đồng bộ)
• Máy chủ cho khách hàng biết rằng sự thay đổi đã xảy ra

Ghi chú :

• Các cập nhật cơ sở dữ liệu, mặc dù không đồng bộ, được thực hiện ngay lập tức. Nếu vì lý do nào đó, máy chủ trò chơi ngừng hoạt động, không mất nhiều.
• Suy giảm hiệu suất không phải là vấn đề lớn nhờ đặt cơ sở dữ liệu trên máy chủ của riêng họ.

Giao dịch giữa những người chơi được xử lý tương tự, với các quy tắc bổ sung để ngăn người chơi lừa đảo người chơi khác và truy xuất nguồn gốc bổ sung trong trường hợp cần thực hiện giao dịch. Tôi nghe nói có những nhật ký đặc biệt của tất cả các giao dịch được lưu giữ một thời gian (để giải quyết vấn đề khi ai đó phàn nàn), tôi không biết thêm về cách thức hoạt động của phần đó.

Đôi khi có điều gì đó không ổn, điều này có hai kết quả có thể xảy ra:

• Nếu lỗi xảy ra ngay lập tức, máy chủ sẽ báo cho khách hàng biết, nó sẽ hoàn nguyên thao tác (người chơi sẽ thấy thao tác hoàn tác).
• Giao diện người dùng cho biết người chơi có một mục, nhưng máy chủ không đồng ý. Nếu người dùng cố gắng sử dụng nó, nó sẽ hỏi máy chủ và không thành công, khiến đối tượng giả không thể sử dụng được. Đối tượng sai sẽ biến mất khi kho được tải lại, được sử dụng như một cơ hội để đồng bộ hóa mô hình.

Trong cả hai trường hợp, khách hàng đều biết lỗi và sẽ ghi lại cùng với tất cả những gì người chơi đang làm. Đăng nhập phía khách hàng đang diễn ra tất cả các thời gian. Sau đó, khi đăng xuất, nếu có lỗi, máy khách sẽ gửi nhật ký đến máy chủ.

Trò chơi này không sử dụng thời gian bảo trì hàng ngày hoặc hàng tuần truyền thống mà hầu hết MMORPG có. Việc bảo trì theo lịch trình thường được sử dụng để thiết lập lại bộ đếm, bộ hẹn giờ, chạy các thủ tục cơ sở dữ liệu. Họ cũng là cơ hội để trao đổi các phiên bản máy chủ để cập nhật.

Cả hai phương pháp đều được sử dụng với MMORPG. Giữ mọi thứ trong bộ nhớ và kiểm tra định kỳ chỉ vào đĩa dường như là tùy chọn phổ biến nhất, ít nhất là đối với các trò chơi cũ. Nó có ưu điểm là khá đơn giản để thực hiện và nhân rộng khá tốt, nhưng làm cho nó đáng tin cậy hoàn toàn phụ thuộc vào nhà phát triển. Cơ sở dữ liệu SQL cung cấp các thuộc tính ACID giúp độ tin cậy dễ dàng hơn, nhưng nhìn chung phức tạp hơn để thực hiện tốt và có thể có vấn đề với việc mở rộng quy mô.

EVE Online là một ví dụ về MMO nơi mọi thứ được lưu trữ trong cơ sở dữ liệu SQL. Tôi nghĩ rằng nó đã đạt đến đỉnh điểm vào khoảng 60.000 người dùng đồng thời và đã phải dành một số phần cứng đắt tiền cho các máy chủ cơ sở dữ liệu trong nhiều năm để theo kịp tải. Tuy nhiên EVE lưu trữ nhiều dữ liệu trên mỗi người dùng hơn so với hầu hết các MMORPG và có nhiều giao dịch thường xuyên và đa dạng hơn. Các thuộc tính ACID của cơ sở dữ liệu cho phép toàn bộ cơ sở dữ liệu lớn và phức tạp luôn được giữ ở trạng thái nhất quán.

Ví dụ, hãy xem xét trường hợp khi ai đó đưa vật phẩm cho người chơi khác. Cơ sở dữ liệu của EVE đảm bảo rằng ngay cả trong trường hợp xảy ra sự cố hoặc mất điện, vật phẩm đó chỉ tồn tại trong kho của một người chơi. Đó là, giao dịch cơ sở dữ liệu loại bỏ vật phẩm khỏi kho của một người chơi và thêm nó vào kho của người chơi khác là nguyên tử. Giao dịch hoàn toàn hoặc hoàn toàn không xảy ra. Bạn không thể kết thúc ở một trạng thái là vật phẩm tồn tại trong kho của người chơi hoặc cả hai.

Một MMORPG giữ dữ liệu người chơi trong bộ nhớ và định kỳ kiểm tra nó phải tự thực hiện nguyên tử này. Một cách để làm điều này sẽ là điểm kiểm tra dữ liệu của mọi người chơi cùng một lúc, đảm bảo rằng điểm kiểm tra mới được cam kết hoàn toàn vào đĩa trước khi được coi là điểm kiểm tra gần đây nhất. Trò chơi cũng sẽ phải đảm bảo rằng dữ liệu người chơi không thể thay đổi trong khi nó được kiểm tra. Với số lượng lớn người chơi tích cực, thử thách sẽ thực hiện tất cả điều này mà không gây ra sự chậm trễ đủ lâu để người chơi có thể nhận thấy.

Đừng đánh giá thấp sự nhất quán quan trọng như thế nào. Khi bạn đang phát triển trò chơi của mình, nó sẽ sụp đổ rất nhiều. Bạn không muốn phải theo dõi lý do tại sao các vật phẩm biến mất và / hoặc sao chép, không phải khi vấn đề là một lỗi không liên quan đang khiến trò chơi bị sập vào thời điểm xấu. Hơn nữa, khi trò chơi của bạn được phát hành, nó sẽ gặp sự cố nhiều hơn bạn mong đợi. Máy chủ của bạn đang hoạt động hoàn hảo đang được thử nghiệm, sẽ đột nhiên phát hiện ra nhiều lỗi trong khi tải đầy đủ và người chơi làm điều bạn không mong đợi.

Lưu ý rằng hầu hết các MMORPG sử dụng cơ sở dữ liệu SQL cho thông tin liên quan đến tài khoản ngay cả khi chúng không dành cho dữ liệu trò chơi thực tế. Thậm chí quan trọng hơn việc giữ trạng thái trò chơi ở trạng thái nhất quán là giữ trạng thái thanh toán nhất quán. Trường hợp xấu nhất cho cơ sở dữ liệu trò chơi bị hỏng là bạn phải khôi phục cơ sở dữ liệu từ bản sao lưu hàng ngày. Trường hợp xấu nhất cho cơ sở dữ liệu tài khoản bị hỏng là bạn phá sản vì tất cả các khoản bồi hoàn.

Đối với dự án của bạn, bạn có thể đi một trong hai cách. Có 1000 người dùng đồng thời có thể sẽ không vượt quá giới hạn của những gì máy chủ SQL có thể xử lý trên PC hàng hóa hiện nay, nhưng phần lớn sẽ phụ thuộc vào bản chất của các giao dịch. Nếu bạn quen thuộc với SQL và thiết kế cơ sở dữ liệu quan hệ thì điều này có thể làm việc cho bạn. Bạn sẽ muốn giảm thiểu các giao dịch càng nhiều càng tốt, đối với những thứ như điểm truy cập hiện tại của người chơi, bạn có thể chỉ muốn định kỳ lưu chúng vào cơ sở dữ liệu vì các số liệu thống kê như thế này không nhất thiết phải nhất quán. (Trong trò chơi PvP, họ có thể ...) Đừng lưu trữ những thứ như quái vật HP trong cơ sở dữ liệu, trong hầu hết các trò chơi, chỉ có dữ liệu liên quan đến người chơi là tồn tại.

Mặt khác, nếu bạn không phải là một trình hướng dẫn SQL, bạn có thể thấy việc giữ tất cả dữ liệu trong bộ nhớ đơn giản hơn nhiều để hoạt động đáng tin cậy. Cơ sở dữ liệu SQL làm cho tính nhất quán và độ tin cậy dễ dàng hơn, nhưng nó không tự động. Một cơ sở dữ liệu được thiết kế tồi có thể hoạt động kém và dẫn đến sự không nhất quán. Giao dịch sẽ không phải là nguyên tử trừ khi bạn thực hiện chúng. Nếu bạn không sử dụng các câu lệnh được tham số hóa một cách tôn giáo, bạn sẽ tự mở các cuộc tấn công SQL SQL.

Trò chơi khác nhau lưu trữ mọi thứ theo những cách khác nhau. Thông thường, các công ty trò chơi tạo ra một số cách để làm điều này và hầu hết các trò chơi của họ sử dụng cùng một cách. Tất nhiên, các hãng phim khác nhau thường sử dụng những cách khác nhau. SQL chắc chắn được sử dụng cho các trò chơi, ví dụ như ĐCSTQ (EVE) có (hoặc ít nhất là có) một mạng lưới các máy chủ SQL, tôi không chắc họ làm thế nào bây giờ. Những người khác, chỉ cần sử dụng nhiều tập tin.

Có thể bắt đầu bằng cách tạo ra một "cơ chế môi giới dữ liệu" bất khả tri, để xử lý các giao dịch dữ liệu trò chơi khác nhau? Vì bạn chỉ đang thử nghiệm mọi cách, hãy tạo một cơ chế cho phép bạn không cần quan tâm quá nhiều đến việc lưu trữ, từ quan điểm của chính trò chơi. Có nghĩa là, tập trung vào làm thế nào, từ ứng dụng máy chủ, bạn sẽ xử lý việc này.

Cá nhân tôi nghĩ rằng nó sẽ là một tài sản tuyệt vời nếu bạn có thể chuyển đổi cửa hàng thực tế, mà không phải viết lại trò chơi và chính nhà môi giới. Chỉ cần chuyển sang một mô-đun khác có cùng giao diện để người môi giới nói chuyện.

Bản thân việc lưu trữ dữ liệu có thể sẽ không thành vấn đề. Vận chuyển dữ liệu hiệu quả, đến / từ cửa hàng đó, giữa máy chủ và tất cả khách hàng, có thể phức tạp hơn. Tôi có gửi toàn bộ tập dữ liệu người chơi không, hoặc nếu tôi chia nó thành nhiều phần, tôi sẽ chọn mức độ chi tiết nào để phân vùng, v.v. Cái nào tốn nhiều tài nguyên hơn trong tình huống nào, v.v.

Một định dạng để gửi dữ liệu vào, có thể là XML. Bằng cách đó bạn có thể dễ dàng năng động hơn trong cách bạn có thể chia nhỏ nó. Một ký tự so với nhiều ký tự hoặc một mục so với một tập hợp các mục, v.v. Sau đó, bạn có thể "lưu trữ" XML dưới dạng XML (bằng SQL) và / hoặc SQL phân phối nó theo kiểu giao dịch hơn từ XML, để Làm thế nào bạn muốn dữ liệu thực sự được lưu trữ.

Một cách khác là nhị phân, hiệu quả hơn về mặt vận chuyển, nhưng có thể phải chịu nhiều chi phí hơn trong các tình huống khác.

Với 1.000 khách hàng, bạn có thể bắt đầu và dễ dàng lưu trữ 10 MB cho mỗi khách hàng và chỉ sử dụng 10 GB RAM hiệu quả + thêm một số RAM quản trị hệ thống để quản lý dữ liệu đó, giả sử thêm một hoặc hai GB. Bạn có thể giữ RAM trong máy chủ đã có cấu trúc dữ liệu sẵn sàng để sử dụng. Và tải / lưu động, tùy thuộc vào người trực tuyến, ở các tần số khác nhau tùy thuộc vào hoạt động, v.v.

Bạn thậm chí có thể lưu trữ thông tin của từng khách hàng trong một tệp riêng biệt, v.v.

Giữ người chơi * trực tuyến * trong ram và đẩy em đến cơ sở dữ liệu (SQLite? MySQL?) Khi họ đăng xuất. Nếu bạn lo lắng về việc IO bị đình trệ trong quá trình đăng xuất, hãy cung cấp cho mỗi lần đăng xuất đó là luồng riêng, đừng thực hiện trong luồng chính / trò chơi (thực ra tôi giữ một luồng trình phát chuyên dụng cho mọi người chơi trực tuyến, nó giúp mã mạng dễ dàng hơn nhiều hơn là thực hiện phương pháp io mạng async)