Những kỹ thuật nào cho phép các trò chơi dựa trên web cập nhật tài nguyên của người chơi thường xuyên?

Cách đây rất lâu, có một trò chơi dựa trên web này có tên là Utopia (và tôi chắc chắn rằng nó vẫn còn tồn tại), mỗi lượt chơi là một giờ. Bạn chỉ nhận được vàng / gỗ mới hoặc những gì không phải mỗi giờ.

Một số trò chơi dựa trên web mới hơn có tài nguyên tăng dần ở độ phân giải tốt hơn, như mỗi phút. Vì vậy, giả sử một người chơi có tốc độ sản xuất thực phẩm là 5 mỗi phút - người chơi sẽ có lượng thức ăn tăng lên mỗi phút. Tôi không chắc chắn liệu có khôn ngoan không khi liên tục thiết lập một công việc CRON để cập nhật cơ sở dữ liệu SQL, mà tôi giả sử những gì họ đang sử dụng, vì nó dựa trên web. Có lẽ tôi sai, từng phút.

Những kỹ thuật nào làm cho các trò chơi dựa trên web sử dụng? Đã thêm vào Chỉnh sửa: Và cơ sở dữ liệu có thể thực sự xử lý tải không?

Dường như với tôi rằng bạn chỉ có thể lưu trữ tỷ lệ sản xuất, mức tài nguyên cơ sở và dấu thời gian được cập nhật lần cuối. Sau đó, bất cứ khi nào bạn cần biết mức tài nguyên thực tế, bạn có thể nhân tỷ lệ sản xuất với thời gian đã trôi qua.

Bất cứ khi nào mức tài nguyên thực tế thay đổi - chỉ cần cập nhật mức cơ sở. Bất cứ khi nào tốc độ sản xuất thay đổi, hãy cập nhật mức cơ sở lên mức thực tế và dấu thời gian theo thời gian hiện tại.

Bằng cách này, thay vì cập nhật mọi người chơi (có lẽ bao gồm cả những người hiện chưa đăng nhập) mỗi phút, bạn chỉ cập nhật các hàng thực sự đang được người chơi tích cực sử dụng.

(Nếu trò chơi của bạn "tích tắc" một lần một phút, tôi tưởng tượng một "số lần lượt" nào đó có thể tốt hơn dấu thời gian thực tế.)

Lợi ích phụ của hệ thống này là bạn có thể sử dụng cùng một logic được sử dụng để cập nhật cơ sở dữ liệu và dự đoán các giá trị mà không sửa đổi chúng - chỉ gửi thông tin cần thiết cho khách hàng (thay vì cập nhật một lần mỗi phút) và dự đoán các giá trị trên máy khách.

Các cơ sở dữ liệu SQL hiện đại thường được sử dụng (MySQL, Postgres, Oracle, MSSQL, v.v.) cho phép bạn lên lịch các thủ tục được lưu trữ để được chạy với các khoảng thời gian tùy ý. Đây là một phương pháp rất nhẹ để chạy các bản cập nhật như thế này và loại bỏ nhu cầu gọi chương trình hoặc chương trình bên ngoài để làm điều đó cho bạn.

Điều này cũng cho phép cơ sở dữ liệu tối ưu hóa truy vấn bạn chỉ chạy một lần, thay vì thực hiện nó mỗi khi tập lệnh bên ngoài gọi nó, vì vậy nó rất hữu ích từ quan điểm hiệu suất. Tất nhiên điều này chỉ áp dụng nếu các cập nhật của bạn đủ tầm thường để được lập trình bằng ngôn ngữ kịch bản lệnh của cơ sở dữ liệu của bạn. Cập nhật tài nguyên, đăng xuất khoảng thời gian tự động, thanh lọc hồ sơ và lượt thích là những ứng cử viên tuyệt vời cho các thủ tục lưu trữ theo lịch trình này.

Nhiều khả năng tải cơ sở dữ liệu của bạn gặp phải đến 99,9% từ tải trang, cập nhật công cụ trò chơi và tương tự, vì một trò chơi phổ biến có thể dễ dàng có hàng trăm ngàn truy vấn mỗi giây. So với tải phát sinh từ việc chạy một vài truy vấn (mặc dù các truy vấn chạm phần lớn của bảng) một lần một phút hoặc lâu hơn, tải không phải là một vấn đề. Đó là, trừ khi bạn cập nhật các giá trị được cơ sở dữ liệu lập chỉ mục. Bạn nên tránh cập nhật các cột được lập chỉ mục bằng mọi giá nếu bạn lo lắng về hiệu suất.

Về các bản cập nhật:

Một số sử dụng các công việc CRON thường xuyên truy cập vào một trang PHP nhất định.

Một số sử dụng các công việc CRON, lần này chạy một quy trình nhất định.

Một cách tiếp cận khác là thực hiện cập nhật 'chỉ trong thời gian' - bất cứ khi nào bất kỳ trang nào được tải, hãy chạy qua mọi cập nhật đang chờ xử lý và thực hiện chúng tại thời điểm đó. Đây thường là những gì bạn phải làm nếu bạn không thể chạy các công việc CRON hoặc các quy trình dài.

Cuối cùng, những người khác đang chạy toàn bộ ứng dụng web dưới dạng một quy trình, vì vậy họ có thể cập nhật bất cứ khi nào họ thấy đó là thời gian.

Hệ thống cuối cùng là tốt nhất nếu bạn có sẵn tùy chọn đó vì bạn có thể lưu trữ dữ liệu trong bộ nhớ. Cập nhật vài nghìn người chơi mỗi phút một lần là chuyện nhỏ nếu bạn chỉ thay đổi dữ liệu trong RAM thay vì phải ghi vào cơ sở dữ liệu SQL truyền thống.

Nhưng nếu bạn không có sự sang trọng đó, bạn có thể sử dụng một số loại bộ đệm. Một cái gì đó như memcached có thể là một tùy chọn (phụ thuộc vào lưu trữ của bạn), đó là điểm nửa đường giữa bộ nhớ và cơ sở dữ liệu. Bạn có thể lưu trữ các giá trị nhất thời trong memcache và chỉ lưu chúng vào DB khi thực sự cần thiết.

Giữa memcache và cơ sở dữ liệu SQL truyền thống, có các tùy chọn khác, vd. các cửa hàng khóa / giá trị hoặc kho lưu trữ tài liệu khác nhau: những thứ như MongoDB , CouchDB , các dịch vụ của Amazon hoặc Google, v.v ... tức là. tất cả các hệ thống theo thuật ngữ ô NoQuery . Chúng thường không cung cấp cho bạn sức mạnh truy vấn chung cũng như luôn luôn đảm bảo an toàn giống nhau của cơ sở dữ liệu truyền thống nhưng thường hoạt động nhanh hơn nhiều. (Điều này không quá ngạc nhiên, vì họ đang làm ít hơn cho bạn.)

Nhưng đây là tất cả giả sử một cơ sở dữ liệu bình thường không thể xử lý tải. Trong thực tế, trong hầu hết các trường hợp nó có thể có thể. Nếu tôi phải phát hành 10.000 cuộc gọi CẬP NHẬT mỗi phút để tăng mức tài nguyên, thì điều đó không thể mở rộng được một khi bạn bắt đầu thêm mọi thứ khác lên trên. Nhưng nếu bạn thay đổi điều đó để cập nhật tài nguyên cho mọi người bằng 1 cuộc gọi SQL, đột nhiên mọi thứ có vẻ tích cực hơn rất nhiều. Vì vậy, đừng đánh giá quá cao một tính năng nhất định đắt tiền như thế nào, vì nó thường có thể được thực hiện ở dạng hiệu quả hơn.

Tôi ủng hộ KISS : "Giữ nó đơn giản, ngu ngốc!"

Tôi thấy không có lý do tại sao một công việc cron sẽ không hoạt động, và nhược điểm là các tùy chọn lưu trữ web giá rẻ thường không cho phép bạn trực tiếp chạy các lệnh, nhưng chúng cho phép bạn chạy các lệnh cron. Vì vậy, không cần một máy chủ chuyên dụng đắt tiền.

Bạn cũng có thể thực hiện mã cập nhật bằng PHP hoặc ngôn ngữ ưa thích của mình bằng cách sử dụng lệnh cron hoặc sử dụng trình duyệt văn bản. Các hướng dẫn tại Định cấu hình công việc cron có một số lệnh ví dụ mà bạn có thể sử dụng để ping trang của chính mình trong một khoảng thời gian.wget --spider http://yoursite.com/secretphppage.phplynx

Tôi nhớ có một cái nhìn vào mã của bản sao Planetarion. PHP của mọi thứ, nhưng mã đánh dấu là C thô - với các ràng buộc C MySQL. Bởi vì mô hình dữ liệu rất đơn giản, các cập nhật diễn ra rất nhanh.