Tính dự đoán được mới là chiều sâu ẩn của hiệu năng mạng
Những người làm mạng ở tầng thấp thường thích bàn về TPS, độ trễ, băng thông. Những chỉ số đó đương nhiên quan trọng, nhưng chúng chỉ trả lời một câu hỏi: Chạy nhanh được đến mức nào?—trong khi lại rất ít khi trả lời một câu hỏi quan trọng hơn: Khi chạy thì có ổn định không?
Giao thức Kadcast của Dusk đã khiến tôi nghĩ lại vấn đề này. Nó không đi theo lộ trình lan truyền tin đồn ngẫu nhiên phổ biến, mà thay vào đó dùng một mạng phủ có cấu trúc để cố định các đường truyền. Kết quả không phải là nhanh hơn ở từng lần đơn lẻ, mà là mỗi lần đều gần như nhanh như nhau. Độ trễ từ chỗ là một phân bố xác suất đã trở thành một hằng số xấp xỉ.
Sự khác biệt này vừa truyền lên tầng trên thì tác động là cực kỳ lớn. Một mạng không thể dự đoán được tương đương với việc nói với các nhà phát triển: Tôi có thể không đáng tin, các bạn tự liệu mà xử lý. Thế là các cơ chế như timeout, retry, backoff lũy thừa, cache dự phòng… toàn bộ một loạt độ phức tạp lẽ ra thuộc về tầng nền cuối cùng lại bị đẩy lên tầng ứng dụng. Tệ hơn nữa là những đoạn code đó thường lại là phần khó kiểm thử nhất và cũng dễ sinh bug nhất.
Vì vậy, hiện tại tôi muốn định nghĩa hiệu năng theo cách khác: Một mạng tốt không phải là giúp nhà phát triển viết ra mã chạy nhanh hơn, mà là để họ viết ít đi một đống code vốn dĩ chẳng nên tồn tại.
Điều này đặc biệt chí mạng trong các kịch bản tài chính. Trong hệ thống giao dịch, thứ đắt nhất không phải là máy móc—mà là gánh nặng nhận thức: khi năng lực tinh thần của bạn bị;liệu mạng có bị chập chờn hay không chiếm hết, thì sẽ không thể tập trung vào những phần thực sự tạo ra giá trị như logic khớp lệnh, chiến lược kiểm soát rủi ro. Giá trị lớn nhất của tính dự đoán được chính là nó giúp nhà phát triển loại bỏ các giả định khỏi chính mã nguồn.
Hạ tầng tốt nhất là thứ mà sau khi bạn triển khai xong, gần như bạn quên luôn rằng nó vẫn đang chạy.
@Dusk #dusk $DUSK
Những người làm mạng ở tầng thấp thường thích bàn về TPS, độ trễ, băng thông. Những chỉ số đó đương nhiên quan trọng, nhưng chúng chỉ trả lời một câu hỏi: Chạy nhanh được đến mức nào?—trong khi lại rất ít khi trả lời một câu hỏi quan trọng hơn: Khi chạy thì có ổn định không?
Giao thức Kadcast của Dusk đã khiến tôi nghĩ lại vấn đề này. Nó không đi theo lộ trình lan truyền tin đồn ngẫu nhiên phổ biến, mà thay vào đó dùng một mạng phủ có cấu trúc để cố định các đường truyền. Kết quả không phải là nhanh hơn ở từng lần đơn lẻ, mà là mỗi lần đều gần như nhanh như nhau. Độ trễ từ chỗ là một phân bố xác suất đã trở thành một hằng số xấp xỉ.
Sự khác biệt này vừa truyền lên tầng trên thì tác động là cực kỳ lớn. Một mạng không thể dự đoán được tương đương với việc nói với các nhà phát triển: Tôi có thể không đáng tin, các bạn tự liệu mà xử lý. Thế là các cơ chế như timeout, retry, backoff lũy thừa, cache dự phòng… toàn bộ một loạt độ phức tạp lẽ ra thuộc về tầng nền cuối cùng lại bị đẩy lên tầng ứng dụng. Tệ hơn nữa là những đoạn code đó thường lại là phần khó kiểm thử nhất và cũng dễ sinh bug nhất.
Vì vậy, hiện tại tôi muốn định nghĩa hiệu năng theo cách khác: Một mạng tốt không phải là giúp nhà phát triển viết ra mã chạy nhanh hơn, mà là để họ viết ít đi một đống code vốn dĩ chẳng nên tồn tại.
Điều này đặc biệt chí mạng trong các kịch bản tài chính. Trong hệ thống giao dịch, thứ đắt nhất không phải là máy móc—mà là gánh nặng nhận thức: khi năng lực tinh thần của bạn bị;liệu mạng có bị chập chờn hay không chiếm hết, thì sẽ không thể tập trung vào những phần thực sự tạo ra giá trị như logic khớp lệnh, chiến lược kiểm soát rủi ro. Giá trị lớn nhất của tính dự đoán được chính là nó giúp nhà phát triển loại bỏ các giả định khỏi chính mã nguồn.
Hạ tầng tốt nhất là thứ mà sau khi bạn triển khai xong, gần như bạn quên luôn rằng nó vẫn đang chạy.
@Dusk #dusk $DUSK