Điều Hướng Dữ Liệu Socket

Thật sự phức tạp

Để dữ liệu trở thành các đối tượng thuần tuý cho lập trình viên kiểu:

class TransferRequest {
    private String to;
    private BigDecimal amount;
}

Thì dữ liệu đã phải trải qua rất nhiều quá trình với đủ các queue và thread. Chính vì thế mà lập trình socket mới là một lĩnh vực thú vị và đầy thách thức. Chúng ta cùng xem ezyfox-server hay các framework socket khác đã làm thế nào để làm đơn giản hoá sự phức tạp mà vẫn đảm bảo hiệu năng một cách tối đa nhé.

Tư duy thông thường

Nếu không có gì đặc biệt có lẽ chúng ta cũng chỉ cần sử dụng 1 luồng để đọc các byte từ socket, deserialize nó thành đối tượng request và xử lý đối tượng socket này mà thôi. Nhưng dễ thế thì đã chẳng nên chuyện, sẽ có rất nhiều vấn đề ở đây.

Xử lý request là một trong những công việc nặng nề nhất mà 1 server phải làm, nó bao gồm các công việc xử lý logic, đọc ghi db, xử lý lỗi ... nó có thể mất từ vài mili giây đến vài chục giây là chuyện hết sức bình thường. Thế nên nếu chúng ta chỉ có 1 luồng việc xử lý 1 request quá lâu sẽ làm nghẽn cả hệ thống
Dữ liệu đến từ socket sẽ được buffer tạm vào trong RAM, nếu không sớm đọc dữ liệu từ trong RAM để xử lý và giải phóng RAM sẽ bị đầy lên rất nhanh
Nếu sử dụng đa luồng để xử lý thì bao nhiêu luồng là đủ? Và làm sao đưa được dữ liệu vào cho các luồng này?

Đây chỉ là 3 trong số rất nhiều các câu hỏi hóc búa cần phải trả lời ngay khi chúng ta định làm một socket server.

Byte Channel

Để nhanh chóng giải phóng dữ liệu ra khỏi RAM thì cũng đồng nghĩa chúng ta phải nhanh chóng biến dữ liệu dạng byte[] về dạng đối tượng request để xử lý sớm nhất có thể.

Một kỹ thuật mà ezyfox-server học hỏi được từ hệ thống dẫn nước hay hệ thống truyền hình đó là sử dụng nhiều channel (kênh) để nhận và truyền dữ liệu, mỗi kênh này sẽ tương ứng với 1 luồng. Ưu điểm của nó là:

Nhiều channel sẽ có cơ hội tiêu thụ được nhiều dữ liệu hơn 1 channel
Trong trường hợp 1 channel bị lỗi thì các channel khác vẫn hoạt động bình thường, hệ thống sẽ không bị gián đoạn
Tận dụng được toàn bộ sức mạnh của đa luồng

Dữ liệu từ socket đi vào các channel, sau đó được chuyển thành dạng đối tượng DTO và sau đó được đừa vào request queue. Dữ liệu dạng DTO có thể là map, list, string hoặc byte wrapper.

Queue và Event Loop

Bởi vì việc xử lý request là rất chậm nên chúng ta cần phải dùng Queue để quản lý và định lượng được số lượng request tối đa mà server có thể xử lý. Trong trường hợp server bị quá tải, chúng ta sẽ drop hết các request nằm ngoài khả năng của queue. Ví dụ khả năng của queue là 100.000 thì các request thứ 100,001 sẽ bị từ chối phục vụ để đảm bảo sự sống còn của server.

Đã có queue thì phải có Event Loop đã là điểu hiển nhiên. Event loop sẽ lấy các request từ trong queue và chuyển cho các luồng xử lý.

Để đảm bảo khả năng phân phối đều và tránh quá tải thì các response cũng sẽ được đưa vào queue, nếu có quá nhiều dữ liệu cần được ghi xuống socket và quá tải với server nó cũng sẽ drop bớt đi. Các response sẽ ở dạng byte[], lý do tại sao bạn có thể tham khảo bài viết về luồng dữ liệu nhé.

Response sẽ được Event Loop bốc ra khỏi queue và phân phối đều vào các channel để khả năng ghi và giải phóng dữ liệu ra khỏi RAM là nhanh nhất.

Bức tranh toàn cảnh

Sau khi kết hợp các channel, queue và event loop với nhau, chúng ta sẽ có được một bức tranh toàn cảnh tương đối phức tạp.

Dữ liệu sẽ đến các channel, đến queue, đến event loop, đến các luồng xử lý, rồi lại đến queue, đến event loop và cuối cùng thông qua các channel để gửi xuống client.

Các phần màu đỏ và màu cam trong hình là những thành phần phải hoạt động tương đối vất vả, đặc biệt vất nhất đó là các luồng xử lý request. Phần này sẽ do các dev code nên framework sẽ không thể kiểm soát được.

Tổng kết

Mặc dù phức tạp nhưng đây vẫn chưa phải là mô hình cuối cùng mà một socket server phải dựng lên, nó còn rất nhiều vấn đề liên quan đến việc phân phối đều tài nguyên, quản lý phiên, anti-flooding, mình sẽ viết ở những bài kế tiếp nhé.