Ở bài viết trước, mình đã chia sẻ rằng hệ thống máy chủ game hoàn toàn có thể vận hành hiệu quả chỉ với mô hình yêu cầu-phản hồi (request/response). Tuy nhiên, một số bạn vẫn còn băn khoăn và cho rằng cần phải sử dụng mô hình xuất bản-theo dõi (publish/subscribe) để máy chủ chủ động đẩy dữ liệu tới client. Sau khi trao đổi kỹ, mình nhận thấy đây là vấn đề cần làm rõ.
Với sự ra mắt chính thức của phiên bản Lua 5.3.3, tôi đã quyết định không trì hoãn thêm nữa và dự kiến sẽ cố định phiên bản RC 1.0 của skynet vào tuần tới để chuẩn bị cho bản phát hành chính thức. Từ lâu nay, cộng đồng phát triển luôn mong mỏi một tài liệu hướng dẫn chi tiết về skynet, bởi vì bài viết tổng quan về kiến trúc skynet trước đây đã lỗi thời khi so sánh với những thay đổi và cải tiến đáng kể đã được tích hợp trong thời gian vừa qua.
Như đã đề cập trước đó, skynet chỉ là một khung nhẹ (lightweight framework), không phải là một engine sẵn sàng sử dụng ngay lập tức. Việc sử dụng hiệu quả hay không phụ thuộc vào việc người dùng có hiểu rõ mục tiêu của mình hay không. Nếu bạn định dùng skynet để xây dựng server game online, điều kiện tiên quyết là phải nắm rõ nguyên tắc thiết kế server game online.
Từ phiên bản Lua 5.2 trở đi, ngôn ngữ đã chuẩn hóa một cơ chế đặc biệt thông qua phương thức __pairs trong bảng meta. Hàm pairs trong thư viện chuẩn của Lua sẽ tận dụng cơ chế này để duyệt qua các phần tử của đối tượng. Đến phiên bản Lua 5.3, quyết định loại bỏ quy ước __ipairs tồn tại trước đó, thay thế bằng hàm lua_geti để truy cập các mảng chỉ số nguyên một cách đồng nhất.
Ngày hôm qua, lần đầu tiên chúng tôi mở thử nghiệm nhỏ cho tựa game MMO mới và đã phát sinh một số vấn đề bất ngờ. Sau 3 tiếng vận hành, bộ nhớ server đột ngột tăng vọt trong khi CPU không có biến động rõ rệt. Lúc đó, kỹ sư hệ thống SA đã nhận được cảnh báo qua email nhưng vì trùng giờ ăn trưa và các chức năng game vẫn hoạt động bình thường nên đã chậm xử lý nửa tiếng. Sự chậm trễ này khiến chúng tôi không thu thập đủ dữ liệu người chơi online trước khi server hoàn toàn tê liệt. Một nguyên nhân khác là quên cấu hình lưu file core dump.
Trong hệ sinh thái Skynet, việc thiết kế một dịch vụ đại lý trung gian để xử lý các yêu cầu trước khi đến đích thường là giải pháp tối ưu. Ví dụ, khi bạn muốn yêu cầu một dịch vụ hỗ trợ tính năng timeout mà không cần can thiệp trực tiếp vào logic nội tại của dịch vụ đó, việc bổ sung lớp đại lý sẽ giúp giảm độ phức tạp không mong muốn. Dịch vụ đại lý này sẽ đảm nhận vai trò thông báo cho bên gửi yêu cầu khi xảy ra sự cố, thay vì xử lý rườm rà tại điểm đích.