Luồng tự động chạy trùng gần như luôn rơi vào một trong bốn nguyên nhân: sự kiện kích hoạt xảy ra hai lần thật, có hai luồng cùng nghe một sự kiện, công cụ tự thử lại sau khi tưởng đã thất bại, hoặc luồng đọc lại dữ liệu cũ như thể mới. Tìm đúng nguyên nhân rồi mới chặn, vì mỗi nguyên nhân cần một cách chặn khác.
Hậu quả của chạy trùng thường nhỏ lúc đầu, như một dòng đôi trong bảng, rồi lớn dần: báo cáo doanh số cao hơn thực tế, kho bị trừ gấp đôi, khách nhận hai tin nhắn cảm ơn và nghĩ cửa hàng làm ăn cẩu thả, tệ hơn là nhận hai yêu cầu thanh toán. Bài này dành cho người tự dựng luồng không viết mã, muốn hiểu vì sao trùng và chặn ở đâu.
Nhận diện: trùng thật hay chỉ trông như trùng
Bước đầu tiên là kiểm xem có đúng là luồng chạy hai lần không. Mở lịch sử lượt chạy, tìm hai lượt ứng với hai dòng trùng. Nếu có hai lượt riêng, mỗi lượt tạo một dòng, đó là chạy trùng. Nếu chỉ có một lượt mà vẫn ra hai dòng, vấn đề nằm ở bên trong luồng, thường là một bước lặp chạy qua danh sách hai phần tử, hoặc hai bước cùng ghi vào một bảng.
Cũng có khi dữ liệu trông trùng nhưng là hai sự việc thật. Khách bấm gửi biểu mẫu hai lần vì mạng chậm, khách đặt hai đơn giống hệt nhau thật vì muốn tặng người thân. Luồng không sai trong trường hợp này; câu hỏi là bạn muốn xử lý hai bản ghi đó ra sao, và câu trả lời là quyết định kinh doanh chứ không phải sửa lỗi kỹ thuật.
Ghi lại vài cặp dòng trùng cụ thể kèm thời điểm của từng dòng. Khoảng cách thời gian giữa hai dòng là manh mối rất tốt. Trùng cách nhau vài giây gợi ý thử lại tự động hoặc hai luồng song song. Trùng cách nhau đúng một chu kỳ, kiểu mười lăm phút hay một giờ, gợi ý luồng theo lịch đang đọc lại dữ liệu cũ. Trùng cách nhau ngẫu nhiên, vài phút đến vài giờ, thường là người dùng gửi lại.
Bốn nguyên nhân chạy trùng và dấu hiệu nhận ra
Bảng dưới gom bốn nguyên nhân hay gặp nhất ở luồng không viết mã, kèm dấu hiệu trong lịch sử lượt chạy giúp phân biệt.
| Nguyên nhân | Dấu hiệu | Hướng xử lý |
|---|---|---|
| Sự kiện xảy ra hai lần thật | Hai lượt chạy, dữ liệu đầu vào giống hệt, cách nhau vài giây đến vài phút | Chặn trùng theo mã định danh của khách hoặc đơn |
| Hai luồng cùng nghe một sự kiện | Hai lượt chạy gần như cùng lúc, nhưng thuộc hai luồng khác tên | Tắt hoặc gộp luồng thừa, thường là bản cũ quên tắt |
| Công cụ tự thử lại | Một lượt báo lỗi hết thời gian chờ ở bước ghi, lượt kế tiếp chạy lại cùng dữ liệu | Kiểm đích trước khi ghi, hoặc đổi bước ghi thành cập nhật nếu đã có |
| Luồng theo lịch đọc lại dữ liệu cũ | Lượt trùng cách nhau đúng một chu kỳ lịch | Đánh dấu bản ghi đã xử lý, chỉ đọc bản ghi chưa đánh dấu |
Nguyên nhân thứ hai phổ biến hơn người ta nghĩ. Khi dựng lại một luồng cho gọn, người dựng thường tạo luồng mới, chạy được, rồi quên tắt luồng cũ. Hai luồng cùng nghe biểu mẫu đăng ký, cùng gửi thư xác nhận, và khách nhận hai thư với nội dung hơi khác nhau. Một danh sách luồng đang bật, rà định kỳ, chặn được lỗi này từ gốc.
Vì sao tự thử lại lại sinh ra bản ghi đôi
Nhiều công cụ tự động hoá có cơ chế thử lại khi một bước thất bại, và đó là tính năng tốt: ứng dụng đích chậm một chút, lần thử thứ hai thành công, bạn không phải làm gì. Vấn đề xảy ra khi bước đó thật ra đã thành công nhưng công cụ không nhận được xác nhận kịp, ví dụ do mạng chậm hay ứng dụng đích phản hồi quá thời gian chờ. Công cụ tưởng thất bại, thử lại, và ứng dụng đích nhận yêu cầu ghi lần thứ hai.
Bạn có thể hình dung như gửi tiền qua ứng dụng ngân hàng lúc mạng chập chờn: màn hình quay mãi rồi báo lỗi, bạn bấm gửi lại, và hoá ra lần đầu đã đi. Nhiều hệ thống thanh toán chặn được chuyện này bằng cách gắn cho mỗi lệnh một mã riêng, gửi lại cùng mã thì bị từ chối. Luồng tự động của bạn cũng cần thứ tương tự.
Với bước ghi vào bảng tính hay tạo bản ghi trong ứng dụng bán hàng, cách chặn dễ nhất là đổi từ "thêm dòng mới" sang "tìm dòng có mã này, nếu chưa có thì thêm, nếu có rồi thì cập nhật". Nhiều công cụ kéo thả có sẵn kiểu bước tìm rồi thêm hoặc cập nhật như vậy, tên gọi mỗi nơi một khác. Với bước gửi thư hay tin nhắn, cần một cột đánh dấu đã gửi và điều kiện chỉ gửi khi ô đó còn trống.
Đặt khoá chống trùng bằng mã định danh
Nền tảng của mọi cách chống trùng là mỗi bản ghi có một mã không lặp lại. Các bước gợi ý cho luồng nhận đơn hoặc nhận đăng ký:
- Xác định mã định danh tự nhiên của bản ghi. Với đơn hàng là mã đơn do cửa hàng online sinh ra; với biểu mẫu là mã phản hồi mà nhiều công cụ biểu mẫu tự gắn; nếu không có, ghép địa chỉ thư với thời điểm gửi.
- Thêm cột "mã" vào bảng đích nếu chưa có, và cho luồng ghi mã đó ở mọi dòng.
- Trước bước ghi, thêm bước tìm trong bảng đích dòng có cùng mã.
- Thêm điều kiện: nếu đã có dòng cùng mã thì dừng hoặc chỉ cập nhật, không thêm dòng mới.
- Với bước gửi ra ngoài, thêm cột "đã gửi lúc" và chỉ gửi khi cột này trống, rồi ghi thời điểm ngay sau khi gửi.
- Chạy bộ ca thử có ca gửi trùng để chắc rằng khoá hoạt động.
Chú ý khi chọn mã: số điện thoại hay họ tên không phải mã định danh tốt. Hai khách khác nhau có thể trùng tên, một khách có thể đặt hai đơn thật. Dùng mã của chính hệ thống sinh ra bản ghi nếu có. Thêm bước tìm trước khi ghi sẽ làm mỗi lượt chạy tốn thêm một thao tác, và với gói tính phí theo số bước, chi phí có thể tăng nhẹ; đó thường là cái giá đáng trả.
Trùng do khách bấm gửi hai lần: chặn ở cả biểu mẫu lẫn luồng
Một nguồn trùng rất đời thường là khách bấm nút gửi biểu mẫu hai lần vì trang phản hồi chậm, hoặc quay lại trang trước rồi gửi lại. Với trang đặt hàng hay đăng ký trên điện thoại, mạng di động chập chờn làm chuyện này xảy ra thường xuyên hơn bạn nghĩ. Luồng không có lỗi gì; nó chỉ trung thành xử lý hai lần gửi.
Có hai lớp chặn. Lớp thứ nhất nằm ở biểu mẫu: nhiều công cụ biểu mẫu có tuỳ chọn giới hạn mỗi người một lần gửi, hoặc hiện trang cảm ơn rõ ràng ngay sau khi gửi để khách biết đã xong. Một câu ngắn kiểu "Cửa hàng đã nhận đăng ký, thư xác nhận sẽ đến trong vài phút" giúp khách bớt bấm lại. Tuỳ chọn cụ thể khác nhau theo công cụ, kiểm phiên bản bạn đang dùng.
Lớp thứ hai nằm ở luồng. Vì hai lần gửi có hai mã phản hồi khác nhau, khoá theo mã phản hồi không chặn được. Cần một quy tắc kinh doanh: ví dụ giả định, cùng địa chỉ thư đăng ký cùng một khoá học trong vòng mười phút thì coi là một. Luồng tìm trong bảng đích dòng thoả quy tắc đó, nếu có thì chỉ ghi chú thêm, không gửi thư xác nhận lần nữa. Ngưỡng thời gian do bạn chọn theo hiểu biết về khách của mình, và nên ghi rõ trong tài liệu của luồng để người sau không thắc mắc vì sao có đăng ký bị gộp.
Dọn dữ liệu đã trùng mà không xoá nhầm
Sửa nguyên nhân trước, dọn sau. Dọn bảng trong khi luồng còn đang sinh dòng trùng là làm việc hai lần. Chặn nguồn trước, theo dõi một ngày để chắc không còn dòng đôi mới, rồi mới dọn.
Sao lưu trước khi xoá. Tạo bản sao của bảng hoặc xuất ra tệp trước khi đụng vào. Xoá nhầm một đơn thật vì tưởng là dòng trùng là lỗi khó phát hiện và khó cứu.
Đánh dấu thay vì xoá ngay. Thêm cột "trùng với" và điền mã dòng gốc. Sau khi người phụ trách rà và đồng ý, mới lọc ra để xoá hoặc chuyển sang trang lưu trữ.
Kiểm hậu quả ở các hệ thống khác. Nếu luồng trùng đã trừ kho hai lần, gửi khách hai yêu cầu thanh toán hay tạo hai lịch hẹn, dọn bảng chưa đủ. Phải sửa cả số tồn kho, liên hệ khách giải thích và huỷ lịch thừa.
Nhờ AI gom nhóm nghi trùng, người quyết định. Có thể dán danh sách đã che thông tin cá nhân, chỉ còn mã, thời điểm, số tiền, rồi nhờ chatbot gom các dòng nghi trùng theo tiêu chí bạn đặt. Nhưng quyết định dòng nào là trùng thật vẫn do người làm, vì chatbot không biết khách nào cố ý đặt hai đơn.
Phòng trùng ngay từ lúc dựng luồng mới
Cách rẻ nhất để không phải dọn trùng là thiết kế chống trùng từ đầu. Mỗi khi dựng một luồng có bước ghi hay bước gửi, tự hỏi: nếu lượt này chạy hai lần với cùng dữ liệu thì chuyện gì xảy ra? Nếu câu trả lời là "khách nhận hai lần" hay "kho bị trừ hai lần", cần khoá chống trùng trước khi bật.
Nguyên tắc này có tên gọi trong giới kỹ thuật, nhưng bạn không cần nhớ tên, chỉ cần nhớ ý: chạy một lần hay chạy nhiều lần với cùng dữ liệu, kết quả phải như nhau. Bước "cập nhật trạng thái đơn thành đã giao" an toàn khi chạy lại, vì đơn đã giao vẫn là đã giao. Bước "cộng thêm một vào số lần mua của khách" không an toàn, vì chạy lại là cộng thêm lần nữa.
Cuối cùng, giữ một danh sách các luồng đang bật, mỗi luồng ghi sự kiện kích hoạt và đích ghi. Khi dựng luồng mới, nhìn danh sách xem đã có luồng nào nghe cùng sự kiện, ghi cùng đích chưa. Hai luồng cùng nghe một biểu mẫu không hẳn là sai, nhưng phải là cố ý, có ghi chép, và mỗi luồng làm một việc khác nhau.
Câu hỏi thường gặp
Vì sao luồng tự động ghi một đơn hàng thành hai dòng?
Thường do một trong bốn nguyên nhân: sự kiện xảy ra hai lần thật, hai luồng cùng nghe một sự kiện, công cụ tự thử lại sau khi tưởng thất bại, hoặc luồng theo lịch đọc lại dữ liệu cũ. Xem khoảng cách thời gian giữa hai dòng để đoán nguyên nhân.
Làm sao chặn luồng tự động ghi trùng mà không cần viết mã?
Ghi mã định danh của bản ghi vào bảng đích, thêm bước tìm dòng có cùng mã trước khi ghi, và chỉ thêm dòng mới khi chưa có. Nhiều công cụ kéo thả có sẵn kiểu bước tìm rồi thêm hoặc cập nhật cho việc này.
Khách nhận hai tin nhắn giống nhau thì xử lý thế nào?
Kiểm xem có hai luồng cùng gửi không, thường là bản cũ quên tắt. Nếu chỉ một luồng, thêm cột đánh dấu đã gửi kèm thời điểm và chỉ gửi khi ô đó trống. Với khách đã nhận trùng, một lời xin lỗi ngắn thường là đủ.
Có nên dùng số điện thoại làm mã chống trùng không?
Không nên. Một khách có thể đặt nhiều đơn thật, và nhiều người có thể dùng chung một số. Hãy dùng mã do hệ thống sinh ra như mã đơn, mã phản hồi biểu mẫu. Nếu không có, ghép địa chỉ thư với thời điểm gửi.
Dọn dòng trùng trong bảng tính nên làm thế nào cho an toàn?
Sửa nguyên nhân trước, sao lưu bảng, rồi đánh dấu các dòng nghi trùng thay vì xoá ngay. Sau khi người phụ trách rà lại và đồng ý mới xoá hoặc chuyển sang trang lưu trữ. Nhớ kiểm cả kho, lịch hẹn và yêu cầu thanh toán bị ảnh hưởng.
Tính năng tự thử lại của công cụ có nên tắt không?
Thường không nên tắt, vì nó giúp vượt qua lỗi tạm thời. Thay vào đó, làm cho bước ghi an toàn khi chạy lại bằng cách tìm trước khi ghi, hoặc dùng bước cập nhật thay cho bước thêm mới. Như vậy giữ được lợi ích mà không sinh dòng trùng.