Trong quá trình thiết kế kiến trúc Skynet 2.0 gần đây, tôi đã hệ thống hóa lại một phương pháp quản lý vòng đời đối tượng từng được áp dụng trong thực tiễn. Cách tiếp cận cũ dựa trên cơ chế ánh xạ từ đối tượng sang ID số nguyên thường gặp phải các vấn đề về đồng bộ hóa, đặc biệt là trong môi trường xử lý song song.

Thiết kế gói tài nguyên

Thông thường, các trò chơi sẽ đóng gói toàn bộ dữ liệu tài nguyên thành một tệp tin lớn, cho phép truy cập các tệp bên trong như các tệp tin thông thường khi game đang chạy. Làm thế nào để đóng gói và cập nhật tài nguyên hiệu quả là trọng tâm thiết kế hệ thống này.

Hiện nay có nhiều gói tài nguyên sử dụng định dạng phổ biến như ZIP, tuy nhiên cũng có nhiều hệ thống tự xây dựng định dạng riêng để phục vụ nhu cầu đặc thù như xử lý quan hệ tham chiếu giữa các tài nguyên. Khi số lượng tài nguyên quá lớn, người ta thường áp dụng cơ chế hash tên tệp gốc để tạo chỉ mục nhằm tăng tốc độ tìm kiếm. Định dạng MPQ của Blizzard và Asset Bundle của Unity3D đều áp dụng nguyên lý này.

Tiếp nối bài viết trước, hôm nay chúng ta cùng bàn luận chi tiết hơn về những ý tưởng mới liên quan đến hàng đợi tin nhắn trong skynet.

Trước đây chúng ta đã đề cập rằng hàng đợi tin nhắn nhận của mỗi dịch vụ có thể thiết lập độ dài cố định và không cần quá dài. Lý do là bởi khi hệ thống vận hành bình thường, mọi dịch vụ nên tự xử lý trơn tru luồng tin nhắn đến, nếu không sẽ phản ánh vấn đề thiết kế từ tầng trên. Tuy nhiên, việc đơn giản loại bỏ tin nhắn khi hàng đợi đầy là hoàn toàn vô lý. Điều này đòi hỏi cơ chế lan truyền lỗi toàn diện hơn, để phía gửi không thành công có thể phát sinh lỗi và ngắt đứt quy trình nghiệp vụ. Việc cho phép lỗi khi gửi tin nhắn có thể khiến việc thiết kế tầng trên trở nên phức tạp hơn.

Vào tháng này, phiên bản 1.0 chính thức của skynet sẽ được phát hành. Bên cạnh việc duy trì phiên bản ổn định này, tôi đang cân nhắc thực hiện những thay đổi mạnh mẽ cho một số điểm còn chưa hài lòng (dĩ nhiên sẽ không áp dụng trên phiên bản ổn định hiện tại).

Vấn đề cốt lõi của skynet - cơ chế lập lịch đa dịch vụ và lan truyền tin nhắn nội bộ - chưa đạt được mức hiệu quả mong muốn. Tôi cho rằng nếu tiếp cận theo một hướng khác hoàn toàn có thể tối ưu hơn. Dưới đây là bản ghi chú chi tiết các ý tưởng mới này.

Khi sử dụng Lua như một ngôn ngữ nhúng trên cả phía máy khách lẫn máy chủ, người ta thường mong muốn tận dụng cơ chế đa luồng cho mã kịch bản Lua. Điều này đặc biệt cần thiết khi logic nghiệp vụ của bạn bao gồm nhiều luồng xử lý độc lập nhưng lại muốn chúng chạy chung trong cùng một máy ảo Lua.

Lua cung cấp sẵn coroutine - một công cụ mô phỏng đa luồng cực kỳ hiệu quả. Trên thực tế, chính Lua cũng gọi kiểu dữ liệu coroutine là “thread”. Trong quá trình xem xét lại cách đóng gói Lua trong Skynet gần đây, tôi nhận thấy một hạn chế quan trọng: luồng chính không được phép gọi các API chặn (blocking API). Nói cách khác, không thể yield trực tiếp trong mã xử lý chính. Điều này khiến tôi suy nghĩ về một phương pháp đóng gói tối ưu hơn, không chỉ giải quyết được hạn chế này mà còn đơn giản hóa nhiều phần mã nguồn liên quan.

Đã trì hoãn quá lâu, cuối cùng chúng tôi cũng quyết định đóng gói phiên bản 1.0.0 của Skynet. So với kế hoạch ban đầu, bản phát hành này đã chậm mất nửa năm trời, dù sao cũng đã khởi động dự án trong năm 2015. Thực tế, chúng tôi đã không thay đổi các tính năng hiện tại trong thời gian dài lắm rồi. Nếu bạn tham gia dự án từ phiên bản alpha 1.0 vào tháng 3 năm nay thì việc nâng cấp lên phiên bản mới nhất hiện tại sẽ không gặp nhiều khó khăn. Trong vài tháng gần đây, thay vì bổ sung tính năng mới, chúng tôi thậm chí còn đang lược bỏ một số thành phần ít người dùng (vì lý do tương thích, các API này đã được tách ra thành các module độc lập để dễ dàng gỡ bỏ sau này).