Trong quá trình phát triển thư viện socket cho Hive gần đây, tôi đã gặp phải một vấn đề kinh điển mà mình nhớ đã từng đối mặt trước đó. Đây là một trải nghiệm đáng ghi lại để chia sẻ.

Thực tế底层 socket tồn tại một API poll thu thập các sự kiện thông qua epoll/kqueue/select. Làm thế nào để bao bọc (wrap) cơ chế này bằng Lua một cách hiệu quả?

Dự án Hive đã chính thức được tích hợp thư viện socket không đồng bộ. Tính năng này cho phép Hive có thể triển khai các chức năng liên quan đến kết nối TCP như module gate trong Skynet chỉ với ngôn ngữ Lua.

Điểm đáng chú ý nhất trong quá trình phát triển là thiết kế API lắng nghe kết nối (listen). Mô hình truyền thống gồm các bước bind → listen → accept không thực sự phù hợp với kiến trúc actor. Một giải pháp từng được áp dụng trong Skynet là mô hình gate, nơi mỗi kết nối mới được chuyển hướng đến một cell (đơn vị xử lý độc lập) mới. Tuy nhiên, để tăng tính linh hoạt, tôi đã quyết định giao quyền kiểm soát chuyển tiếp kết nối cho hàm callback - đây chính là điểm mạnh của Lua trong việc xử lý luồng thực thi.

Trong những ngày qua, các diễn đàn về Lua và LuaJIT như danh sách email cộng đồng đã sôi nổi thảo luận về chủ đề quản lý luồng hợp tác. Đặc biệt, một trường hợp đáng chú ý được ghi nhận từ hệ thống Skynet - framework xử lý game server phổ biến. Khi một dịch vụ Skynet xử lý đến 60,000 lần timeout, lượng bộ nhớ đã tăng vọt lên 50MB và chỉ giảm xuống sau khi garbage collection (GC) được kích hoạt.

Khoảng thời gian trước, tôi đã hoàn thành việc xây dựng thư viện driver MongoDB cho Lua. Sau khi hoàn tất những công việc nền tảng ban đầu, do bận rộn với công việc chính nên dự án tạm thời bị gác lại.

Một vài ngày gần đây, có thành viên trong nhóm thông báo rằng họ đã bắt đầu sử dụng thư viện này và phát hiện một lỗi (bug). Điều này khiến tôi vừa ngạc nhiên vừa vinh dự, nên tôi quyết định tích hợp thư viện này vào hệ sinh thái Skynet một cách nghiêm túc.

Hôm nay mình vừa thực hiện một số cải tiến đáng kể cho thư viện socket của skynet nhằm tối ưu hóa khả năng kết nối và xử lý dữ liệu. Mục tiêu ban đầu là để thử truy cập một API HTTP bên ngoài từ hệ thống skynet, qua đó phát hiện ra một số hạn chế trong phiên bản socket mới viết gần đây.

Trong quá trình kiểm thử, mình gặp phải vấn đề khi URL dùng để test bị chặn (firewall). Sự cố này đã phơi bày điểm yếu của hàm connect hiện tại đang hoạt động ở chế độ blocking. Khi xảy ra tình trạng kết nối đến server không ổn định, toàn bộ tiến trình có thể bị treo trong thời gian dài. Để khắc phục, mình đã dành thời gian chuyển đổi cơ chế connect sang dạng non-blocking. Đây là một kỹ thuật tương đối phức tạp do bản chất bất đồng bộ của nó, đặc biệt với những ai chưa từng xử lý trường hợp này trước đây. Mình đã tham khảo một số tài liệu kỹ thuật tiêu chuẩn để triển khai, nhưng vẫn rất mong nhận được sự phản hồi từ các bạn có kinh nghiệm sâu hơn về skynet để review patch mới này trước khi chính thức áp dụng.

Cuối tuần vừa rồi, tôi dành thời gian suy ngẫm về hành trình phát triển hơn một năm qua với skynet. Từ kinh nghiệm thực tế này, tôi nhận thấy nếu không còn những gánh nặng từ thiết kế ban đầu của Erlang và thiếu kinh nghiệm khi xây dựng skynet ngày xưa, liệu ta có thể tạo ra một phiên bản skynet tối giản hơn, bỏ đi những tính năng thừa thãi?