Một số bạn đồng nghiệp đã phản ánh với tôi rằng kể từ khi thư viện IO của Skynet được viết lại, hệ thống không thể khởi động được trên nền tảng Mac OSX. Sau khi kiểm tra kỹ lưỡng, nguyên nhân trực tiếp nằm ở phần triển khai kqueue chưa chính xác. Cần lưu ý rằng thiết kế API của kqueue và epoll có những điểm khác biệt quan trọng: epoll cho phép gộp chung sự kiện đọc/ghi trong khi kqueue yêu cầu tách biệt rõ ràng giữa đọc và ghi. Phiên bản mã nguồn này được viết vội mà chưa qua kiểm thử thực tế, nên tồn tại lỗ hổng từ trước, chỉ đến khi gặp vấn đề khác mới bộc lộ rõ.

Phiên bản cài đặt game Cuồng Kiếm do chúng tôi phân phối được đóng gói bằng công cụ NSIS thành một tệp tin thi hành đơn (exe) khoảng 1GB. Ban đầu, chúng tôi sử dụng dịch vụ đám mây của Upai và Qiniu để phân phối client, tốc độ tải về ổn định nhưng chi phí vận hành khá cao. Xuất phát từ nhu cầu tối ưu hóa chi phí, chúng tôi quyết định phát triển riêng một trình tải torrent - phương thức phổ biến trong việc phân phối client game MMORPG.

Thiết kế ban đầu của Skynet hoàn toàn chưa quan tâm đến vấn đề dừng hệ thống có kiểm soát. Về sau, để phục vụ mục đích gỡ lỗi rò rỉ bộ nhớ, hệ thống mới bổ sung lệnh ABORT có thể tiêu diệt toàn bộ dịch vụ đang hoạt động. Việc dừng an toàn một hệ thống phân tán luôn là một bài toán phức tạp. Phiên bản nội bộ của chúng tôi đã đầu tư rất nhiều công sức cho vấn đề này, tuy nhiên tôi cảm thấy cách tiếp cận còn chưa tinh gọn nên chưa sẵn sàng đưa lên phiên bản mã nguồn mở.

Skynet vừa trải qua một cuộc đại tu quy mô lớn, đánh dấu bước ngoặt quan trọng trong hành trình phát triển của hệ thống này. Bài viết này sẽ chia sẻ toàn bộ những suy tư đằng sau việc tái thiết kế kiến trúc nền tảng, cùng những bài học rút ra từ gần một thập kỷ đồng hành cùng Skynet.

Skynet không phải công trình thiết kế từ đầu mà là kết quả của quá trình tích lũy kinh nghiệm hơn 15 năm qua. Ý tưởng hạt nhân ban đầu xuất phát từ server game bài năm 2006, sau đó được định hình rõ ràng hơn nhờ tiếp thu tinh hoa từ Erlang trong giai đoạn 2008-2011. Tuy nhiên, chính những “người thầy” này cũng tạo nên những rào cản tư duy khiến nhiều quyết định thiết kế tưởng chừng hợp lý lại ẩn chứa bất cập về lâu dài.

Trong quá trình tìm hiểu mã nguồn Go, tôi đặc biệt quan tâm đến cơ chế bảng băm trong thư viện runtime. Mục tiêu ban đầu là so sánh cách triển khai bảng băm của Go với hệ thống bảng (table) trong Lua.

Kết luận rút ra là bảng băm của Go phức tạp hơn nhiều so với phiên bản Lua. Nếu như mã nguồn ltable.c của Lua chỉ khoảng dưới 600 dòng thì tệp hashmap.c của Go lại vượt quá 1500 dòng. Điểm khác biệt lớn nằm ở định hướng tối ưu không gian của Go. Bảng băm trong Go được thiết kế theo kiểu có kiểu dữ liệu cụ thể - cả khóa (key) và giá trị (value) đều có kiểu cố định được lưu trữ trong cấu trúc mô tả kiểu. Mặc dù kích thước khóa/giá trị không xác định được ở thời điểm biên dịch, nhưng đã được xác định rõ ràng khi khởi tạo.

Lua phân biệt giữa “light userdata” và “full userdata” ở nhiều khía cạnh quan trọng. Theo tài liệu chính thức, light userdata được đánh giá là nhẹ nhàng hơn về chi phí hệ thống. Để hiểu rõ sự khác biệt, ta cần phân tích từ nhiều góc độ:

Về mặt bộ nhớ, full userdata bản chất là một đối tượng chịu sự quản lý của garbage collector (GC), do đó tiêu tốn thêm một lượng nhỏ bộ nhớ meta. Tuy nhiên lượng bộ nhớ này thường không đáng kể trong hầu hết các ứng dụng thực tế. Ngược lại, light userdata chỉ là kiểu dữ liệu nguyên thủy lưu trữ địa chỉ con trỏ thuần túy, không có metadata bổ sung.