Suica ở mốc 200ms: Cách thẻ giao thông IC của Nhật Bản đánh bại vòng lặp máy chủ

Mỗi lần một hành khách ở Tokyo chạm thẻ Suica vào cổng soát vé, một giao dịch tài chính hoàn chỉnh—xác thực, tính giá vé, trừ số dư—được thực hiện trong chưa đầy 200 mili giây. Không pin, không gọi máy chủ, không phụ thuộc mạng. Đó không chỉ là một mẹo hay; đó là một quyết định thiết kế đã định hình cách hàng triệu người di chuyển qua mạng lưới giao thông nhộn nhịp nhất thế giới.

Thẻ chính là cơ sở dữ liệu

Không giống hầu hết các hệ thống thanh toán, Suica lưu trữ cả ID thẻ và số dư trực tiếp trên chip. Đầu đọc tại cổng phát ra một trường điện từ cung cấp năng lượng cho thẻ chỉ đủ lâu để hoàn tất trao đổi. Thẻ và đầu đọc xác thực lẫn nhau, tạo một khóa mã hóa mới, và ghi lại số dư—tất cả đều cục bộ.

Tại sao không đồng bộ với máy chủ trung tâm mỗi lần chạm? Vì ở quy mô Tokyo, điều đó sẽ là thảm họa. Một vòng lặp máy chủ sẽ thêm độ trễ, và bất kỳ trục trặc mạng nào—mất gói tin, gián đoạn, tắc nghẽn—sẽ làm tê liệt các cổng soát vé trong giờ cao điểm. Thay vào đó, các cổng đồng bộ nhật ký giao dịch với máy chủ trung tâm theo chu kỳ, không theo thời gian thực.

Con đường đến Suica: từ bị từ chối đến cứu rỗi

Trước Suica, các nhà ga Tokyo là điểm nghẽn của những người bấm vé thủ công. JR East, được tư nhân hóa năm 1987, muốn hiện đại hóa nhưng hoài nghi về công nghệ IC không tiếp xúc chưa được kiểm chứng. Sony trình bày FeliCa, hệ thống không tiếp xúc độc quyền của mình, nhưng JR East nói không—công nghệ chưa đủ nhanh và đáng tin cậy.

Sony gần như từ bỏ FeliCa cho đến khi thẻ Octopus của Hồng Kông tìm đến. Sony chế tạo một thẻ có phạm vi đọc 10cm và thời gian phản hồi 100ms, thắng thầu, và Octopus ra mắt năm 1997 với thành công vang dội. Bằng chứng khái niệm đó đã đưa JR East trở lại bàn đàm phán.

Thử thách 200ms

JR East đặt ra một yêu cầu bất khả nhượng: toàn bộ giao dịch—từ phát hiện thẻ đến tính giá vé đến trừ số dư—phải hoàn tất trong chưa đầy 200 mili giây. Điều đó chặt chẽ hơn vẻ ngoài của nó. Mục tiêu 100ms của Octopus chỉ bao phủ giao tiếp vô tuyến; toàn bộ giao dịch từ đầu đến cuối được báo cáo mất khoảng 300ms. Mốc 200ms của Suica phải bao phủ mọi thứ.

Để đạt mục tiêu đó, thẻ và đầu đọc phải xử lý mọi thứ cục bộ. Cổng phát ra trường điện từ, thẻ thức dậy, chúng xác thực, tính giá vé, cập nhật số dư—tất cả trong tích tắc thẻ nằm trong phạm vi. Sony cũng mở rộng phạm vi giao tiếp của đầu đọc lên 85mm, gấp đôi đối thủ, để hành khách có thể đi qua mà không cần dừng lại để căn chỉnh thẻ hoàn hảo.

Suýt bị giết bởi một vấn đề giao diện

Các nguyên mẫu ban đầu là một thảm họa. Gần một nửa số người thử nghiệm không thể qua cổng. Một giám đốc phàn nàn về "tỷ lệ đánh trúng 20%." Ban lãnh đạo sẵn sàng rút phích cắm. Sửa chữa không nằm ở chip—mà ở thiết kế đầu đọc. Các tấm phẳng, không có dấu hiệu không gợi ý cách sử dụng. Mọi người quẹt quá nhanh hoặc lơ lửng quá cao, như quét mã vạch. Một thiết kế lại với tín hiệu rõ ràng cho động tác chạm đã cứu dự án.

Bài học cho kỹ sư hiện đại

Kiến trúc của Suica là một trường hợp kinh điển cho điện toán biên. Không phải là tránh máy chủ; mà là biết khi nào vòng lặp máy chủ là một gánh nặng. Đối với các tương tác quan trọng, độ trễ thấp, thông lượng cao, xử lý cục bộ với đồng bộ cuối cùng có thể là sự khác biệt giữa một chuyến đi suôn sẻ và một sự sụp đổ toàn ga.

Khi chúng ta xây dựng cho IoT, thanh toán, và hệ thống thời gian thực, ràng buộc 200ms của Suica là một lời nhắc nhở: đôi khi cuộc gọi mạng tốt nhất là cuộc gọi bạn không thực hiện.