Hãy bắt đầu bằng phần dễ bị bỏ lỡ nhất khi đọc phần còn lại: không có đồng tiền nào bị lấy đi. Không ví nào bị trừ hai lần, không thẻ nào bị tính phí, không hạn mức gói đăng ký nào bị tiêu cho công việc chưa hề diễn ra.
Thứ hỏng là một con số trên màn hình. Ở một số tài khoản, phần phân tích mức sử dụng trên trang tài khoản của chính bạn hiển thị cao hơn — ở tài khoản tệ nhất chúng tôi đo được, cao gấp 2,4 lần sổ cái mà nó lẽ ra phải tóm tắt. Sổ cái luôn đúng suốt thời gian đó. Các trần chi tiêu hàng tháng cũng vậy, chúng được đọc từ một nơi hoàn toàn khác. Đây là lỗi hiển thị, đã được sửa, và đây là nguyên nhân.
Một khóa đi tìm thứ chưa ai từng ghi
Công việc phát sinh từ thao tác của bạn — cập nhật bản tóm tắt sử dụng hằng ngày, ghi có một khoản giới thiệu, phát tán một thông báo — không diễn ra bên trong yêu cầu của bạn. Yêu cầu ghi một thông điệp, và một consumer nền nhặt nó lên ngay sau đó; chính điều này giữ cho một tác dụng phụ chậm không làm chậm một trang nhanh.
Nguy cơ của cách bố trí ấy là làm cùng một việc hai lần, bởi broker sẵn lòng giao lại đúng thông điệp đó sau một trục trặc. Hàng phòng ngự là một hộp thư đến: trước khi xử lý, consumer giành lấy thông điệp bằng cách ghi một dòng mang khóa của thông điệp đó, và một chỉ mục duy nhất khiến lần giành thứ hai trở nên bất khả thi.
Bên chúng tôi giành theo một cặp — tenant mà thông điệp thuộc về, cộng với khóa thông điệp — và tra cặp đó với mã tenant do phong bì thông điệp mang theo, vốn có giá trị.
Các dòng giành lại hoàn toàn không mang mã tenant nào. Mọi dòng đều rỗng, và đã rỗng ngay từ đầu. Chính tài liệu của thực thể khẳng định, đúng từng chữ, rằng framework đóng dấu giá trị này khi chèn. Nó chưa bao giờ làm vậy. Đo trên môi trường thật đúng ngày phát hiện: cả 3.344 dòng hộp thư đến đều rỗng, trong khi 1.174 trên 1.451 dòng ở phía sinh ra thông điệp lại mang tenant thật — đó chính xác là lý do không ai nghi ngờ phía đọc.
Vậy là truy vấn hỏi (tenant, khóa), dòng đã lưu là (không gì cả, khóa), và chúng không bao giờ khớp được.
Không có gì thất bại, và vì thế nó chạy suốt nhiều tuần
Một truy vấn không bao giờ khớp được nghe như thứ phải báo lỗi ngay lần đầu. Nó làm điều ngược lại.
Bước giành quyết định thông điệp là mới. Lệnh chèn sau đó đụng chỉ mục duy nhất và bị từ chối vì trùng lặp — hoàn toàn đúng, vì dòng đó đã có sẵn. Một nhánh dự phòng bắt lấy lần từ chối ấy và diễn giải một cách rộng lượng: chắc một lần giao khác đã giành nó rồi, ở đây không có gì để làm. Phong bì nằm nguyên ở trạng thái "vẫn cần xử lý", và vì vẫn cần xử lý, lần giao tiếp theo lại nhặt nó lên và làm lại công việc.
Mỗi consumer xử lý lại tồn đọng của chính mình, khoảng bốn mươi lăm giây một lần, không có điểm dừng. Hai mươi sáu consumer đang làm vậy. Một dòng trên môi trường thật hoàn tất 333 giờ sau khi đến, và đã hoàn tất đi hoàn tất lại trong phần lớn quãng thời gian đó.
Nó thực sự làm hỏng cái gì
Trong hai mươi sáu consumer đó, bốn cái tích lũy thay vì ghi đè. Bốn cái ấy chính là các hình chiếu tính phí mà trang sử dụng đọc, và đó là nơi chuyện này lộ ra.
Chúng đã có một lớp bảo vệ rõ ràng chống đúng tình huống này, được viết sau sự cố hồi tháng Tám khi một sự kiện duy nhất được áp chín lần lên một đồng hồ đo. Lớp bảo vệ này đánh dấu một dòng là thành công trước khi xử lý, để một lần giao lại tìm thấy dấu ấy và dừng lại. Dấu luôn được ghi đúng mỗi lần. Rồi lần giành kế tiếp đi tìm nó bằng chính khóa hỏng đó và không thấy. Sự bảo đảm ấy đã rỗng kể từ ngày nó được phát hành.
Những thứ chuyện này không đụng tới đáng được liệt kê chính xác, bởi "hình chiếu tính phí" nghe đáng báo động còn sự thật thì không:
- Sổ cái đúng. Mỗi lệnh gọi AI ghi đúng một bản ghi tính phí kèm ảnh chụp giá của chính nó, và không gì trên đường đi này ghi vào đó.
- Không ví nào dịch chuyển. Số dư lấy từ sổ cái, không bao giờ từ một bản tóm tắt.
- Không trần nào dịch chuyển. Bộ gác ngân sách đọc một bộ đếm riêng, và đó là nguồn sự thật duy nhất về số bạn đã tiêu trong tháng. Không ai bị cắt sớm vì một con số bị thổi phồng, và không ai lọt qua khi lẽ ra không được.
Thứ duy nhất đọc bản tóm tắt bị ảnh hưởng là lịch sử sử dụng trên trang tài khoản của chính bạn — tổng của bạn, và phân tích xem nó đi vào đâu. Đó là toàn bộ bán kính ảnh hưởng, và việc nó làm là hiển thị cao hơn.
Nửa còn lại mà không ai nhìn tới
Cùng truy vấn hỏng ấy còn nằm ở một chỗ thứ hai: đường chạy khi một thông điệp thất bại. Ở đó nó không bao giờ tìm được dòng cần cập nhật, và ngay bên dưới là một nhánh mang bình luận "không thể chạm tới trong thực tế" — nhánh trả về "thất bại này là chung cuộc" ở mọi lần thất bại.
Thế nên bộ đếm thử lại không bao giờ nhích lên và không thông điệp độc nào từng tới được hàng đợi thư chết. Cả một tầng xử lý lỗi đã bị tắt, nấp sau một bình luận bảo với mọi người đọc nó rằng ở đây chẳng có gì để kiểm tra.
Cách sửa
Cả hai truy vấn giờ đều dùng khóa thông điệp trong phạm vi nhóm consumer, vốn là thứ mà chỉ mục duy nhất áp đặt sẵn. Khóa thông điệp được dẫn xuất từ mã của chính đối tượng sinh ra chúng, nên về mặt cấu trúc không thể va chạm giữa các tenant.
Tài liệu khẳng định chuyện đóng dấu đã được sửa lại chứ không bị xóa. Chính câu đó là cái bẫy, và xóa nó đi sẽ chẳng để lại gì nói rằng cuối cùng cũng có người đi kiểm tra.
Chín bài kiểm thử ghim hành vi này. Sáu trong số đó thất bại trên mã cũ, điều chúng tôi đã xác nhận bằng cách đặt mã cũ trở lại.
Dọn dẹp sau đó
Các dòng bị thổi phồng tự sửa. Một worker dựng lại các bản tóm tắt hằng ngày từ sổ cái mỗi giờ, trên cửa sổ hai ngày. Nó vẫn chạy suốt thời gian đó và vẫn thua: một giờ một lần đấu với một consumer áp lại mỗi bốn mươi lăm giây thì không phải cuộc đua công bằng.
Khi consumer không còn chạy lại, worker thắng. Hai ngày vẫn nằm trong cửa sổ đó đã được dựng lại từ sổ cái ngay khi bản sửa lên môi trường thật. Hai ngày trước đó đã rơi ra ngoài cửa sổ, và thứ còn sót trên chúng là một tài khoản của chính chúng tôi cộng với một chênh lệch không đáng kể ở chỗ khác — nên chúng tôi để nguyên thay vì nới rộng cửa sổ trên môi trường thật để đuổi theo, điều đó có vẻ tốt hơn là ngụ ý rằng đợt quét đã trọn vẹn.
Điều chúng tôi rút ra
Một khóa chống trùng lặp phải phản chiếu thứ mà chỉ mục thực sự áp đặt, chứ không phải thứ mà mã tin rằng đã được ghi. Hai nửa của khóa này được nuôi từ hai trường khác nhau, và chưa nửa nào từng được đo đối chiếu với nửa kia. Giờ cả hai đều đã được đo, và bài kiểm thử chứng minh điều đó chuyển đỏ trên phiên bản đã sai.