---
title: "Sáu quy tắc cho một lượt đồng bộ chạy khi không ai theo dõi"
description: "Sáu quy tắc cho một quy trình đồng bộ dữ liệu tự động giữa hai công cụ SaaS, chạy theo lịch mà không ai theo dõi: con trỏ, khóa gửi, mỗi lúc một lượt chạy, số lần thử lại có giới hạn, cảnh báo khi im lặng và một quy tắc đã xuất bản mà mọi lượt chạy phải chứng minh. Mỗi quy tắc được đối chiếu với những gì bộ chạy đồng bộ của Tajo làm hiện nay, kể cả những chỗ nó còn thiếu."
url: https://tajo.io/vi/blog/six-rules-unattended-sync/
markdown: https://tajo.io/vi/blog/six-rules-unattended-sync.md
lang: vi-VN
author: "Set Noa"
author_url: https://tajo.io/vi/set-noa/
published: 2026-11-06
updated: 2026-11-06
alternates: {en-US: /blog/six-rules-unattended-sync.md, bg-BG: /bg/blog/six-rules-unattended-sync.md, cs-CZ: /cz/blog/six-rules-unattended-sync.md, de-DE: /de/blog/six-rules-unattended-sync.md, da-DK: /dk/blog/six-rules-unattended-sync.md, es-ES: /es/blog/six-rules-unattended-sync.md, fr-FR: /fr/blog/six-rules-unattended-sync.md, el-GR: /gr/blog/six-rules-unattended-sync.md, hi-IN: /hi/blog/six-rules-unattended-sync.md, id-ID: /in/blog/six-rules-unattended-sync.md, hr-HR: /hr/blog/six-rules-unattended-sync.md, hu-HU: /hu/blog/six-rules-unattended-sync.md, it-IT: /it/blog/six-rules-unattended-sync.md, ja-JP: /jp/blog/six-rules-unattended-sync.md, ko-KR: /kr/blog/six-rules-unattended-sync.md, ar-SA: /ar/blog/six-rules-unattended-sync.md, nl-NL: /nl/blog/six-rules-unattended-sync.md, no-NO: /no/blog/six-rules-unattended-sync.md, pl-PL: /pl/blog/six-rules-unattended-sync.md, pt-BR: /pt/blog/six-rules-unattended-sync.md, ro-RO: /ro/blog/six-rules-unattended-sync.md, ru-RU: /ru/blog/six-rules-unattended-sync.md, sv-SE: /se/blog/six-rules-unattended-sync.md, zh-CN: /zh-cn/blog/six-rules-unattended-sync.md, sl-SI: /sl/blog/six-rules-unattended-sync.md, sr-Latn-RS: /sr/blog/six-rules-unattended-sync.md, th-TH: /th/blog/six-rules-unattended-sync.md, tr-TR: /tr/blog/six-rules-unattended-sync.md, ur-PK: /ur/blog/six-rules-unattended-sync.md, sk-SK: /sk/blog/six-rules-unattended-sync.md}
---

[Đồng bộ dữ liệu](https://tajo.io/vi/blog/?category=data-sync)

# Sáu quy tắc cho một lượt đồng bộ chạy khi không ai theo dõi

Sáu quy tắc cho một quy trình đồng bộ dữ liệu tự động giữa hai công cụ SaaS, chạy theo lịch mà không ai theo dõi: con trỏ, khóa gửi, mỗi lúc một lượt chạy, số lần thử lại có giới hạn, cảnh báo khi im lặng và một quy tắc đã xuất bản mà mọi lượt chạy phải chứng minh. Mỗi quy tắc được đối chiếu với những gì bộ chạy đồng bộ của Tajo làm hiện nay, kể cả những chỗ nó còn thiếu.

đồng bộ dữ liệu tự động

Một quy trình đồng bộ dữ liệu tự động cần gì để chạy an toàn khi không ai theo dõi nó?

Một quy trình đồng bộ chạy không người giám sát cần sáu quy tắc. Đọc từ một con trỏ và chỉ dời nó sau khi cả lô đã đến nơi. Gán cho mỗi lượt ghi một khóa mà lần thử lại suy ra lại được, và giữ các khóa đã hoàn tất trong bảy ngày. Để một lượt chạy sở hữu đồng bộ và chứng minh điều đó trước mỗi lượt ghi. Thử lại một lượt chạy thất bại năm lần với thời gian chờ tăng dần, và tạm dừng đồng bộ sau năm lượt chạy thất bại liên tiếp. Cảnh báo khi không có gì thành công trong 24 giờ. Bắt mỗi lượt chạy chứng minh nó là phiên bản đã được xuất bản. Bộ chạy của Tajo tuân thủ trọn vẹn năm quy tắc trong số này. Ngoại lệ là sự im lặng: một nguồn trả lời rỗng trong khi lượt đọc của nó lẽ ra phải thất bại chỉ được phát hiện một phần.

[Tìm hiểu thêm](https://tajo.io/vi/blog/six-rules-unattended-sync/#1-%C4%91%E1%BB%8Dc-t%E1%BB%AB-m%E1%BB%99t-d%E1%BA%A5u-trang-v%C3%A0-ch%E1%BB%89-d%E1%BB%9Di-n%C3%B3-khi-l%C3%B4-%C4%91%C3%A3-%C4%91%E1%BA%BFn-n%C6%A1i)

Ngày 8 tháng 10 năm 2026, Lance Martin và CJ Avilla đăng [một bài hướng dẫn về một agent](https://claude.dev/blog/building-effective-agent-automations/) mỗi sáng đọc Slack và GitHub rồi đăng một bản tóm tắt lên Slack. Không ai theo dõi nó chạy. Đoạn hữu ích nhất của họ nói về một lỗi trông giống như thành công. Khi máy chủ của một nguồn bị sập hoặc token của nó đã hết hạn, “agent không thấy gì từ nguồn đó và báo cáo ‘không có gì mới.’”

Một quy trình đồng bộ liên hệ từ Shopify sang Brevo cũng có lỗi y như vậy. Mọi quy trình đồng bộ theo lịch giữa hai công cụ SaaS cũng thế. Một lượt đọc thất bại trong im lặng trông y hệt một cửa hàng mà hôm nay không ai đăng ký.

Bài viết của họ kết thúc bằng sáu quy tắc cho một agent chạy không người giám sát. Hãy đọc chúng dưới góc nhìn của người vận hành các quy trình đồng bộ, và mỗi quy tắc đều là một quy tắc [reverse ETL](https://tajo.io/vi/blog/what-is-reverse-etl/). [Worker đã chết. Đồng bộ thì không.](https://tajo.io/vi/blog/worker-died-sync-didnt/) theo dấu một liên hệ qua một sự cố sập. Trang này là danh sách kiểm tra ở tầng trên: sáu quy tắc cho một quy trình đồng bộ dữ liệu tự động, bộ chạy của Tajo hiện làm gì với từng quy tắc, và nó còn thiếu ở đâu. Phía bộ chạy được mô tả trong [Khôi phục đồng bộ bị treo hoặc thất bại](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/).

## 1. Đọc từ một dấu trang, và chỉ dời nó khi lô đã đến nơi

Quy tắc đầu tiên của họ: “Đọc mỗi nguồn từ một dấu trang, không theo một khung thời gian cố định.” Một khung “24 giờ qua” để lại khoảng trống khi lượt chạy bắt đầu muộn và lặp lại bản ghi khi nó bắt đầu sớm.

Một quy trình đồng bộ của Tajo đọc nguồn theo từng lô từ [một con trỏ đã lưu](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor). Con trỏ dời đi ở cuối một lô, và chỉ khi mọi bản ghi trong lô đó đã đến nơi. Một lượt chạy thất bại giữ nguyên vị trí sạch cuối cùng, nên lượt chạy tiếp theo đọc lại lô bị gián đoạn [thay vì bỏ qua nó](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor).

Đơn hàng có dấu trang riêng. [Một quy trình đồng bộ đơn hàng Shopify theo lịch](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/) bắt đầu từ lượt chạy theo lịch đầu tiên và gửi những gì đã thay đổi kể từ lượt trước. Đơn hàng cũ chỉ được gửi khi có người chạy đồng bộ. Các lượt chạy theo lịch và các lượt chạy do người khởi động giữ con trỏ riêng, nên một lần nạp lịch sử hay một lô thử nghiệm không thể tua ngược con trỏ theo lịch.

Cái giá là một lô bị gián đoạn sẽ được đọc hai lần. Quy tắc 2 là thứ làm điều đó trở nên an toàn.

## 2. Gán cho mỗi lượt ghi một khóa sống sót qua sự cố sập

Quy tắc thứ tư của họ chỉ tính một bài đăng là đã gửi “khi Slack xác nhận”, và chỉ khi đó mới cập nhật dấu trang và sổ ghi. Thư bảo đảm hoạt động theo cách này. Thư được coi là đã giao khi phiếu báo nhận có chữ ký quay về, không phải khi nó rời quầy.

Trước khi Tajo ghi một bản ghi, bản ghi đó nhận [một khóa gửi](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Khóa là giá trị băm của đồng bộ, nguồn, con trỏ trang, vị trí trên trang và chính bản ghi, nên nó không chứa dữ liệu cá nhân. Khóa được giành trước khi gọi đích và được đánh dấu hoàn tất khi lượt ghi thành công. Các khóa đã hoàn tất được [giữ trong bảy ngày](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger). Một lần thử lại, hay một lượt chạy theo lịch sau đó, suy ra cùng khóa cho cùng bản ghi, thấy nó đã hoàn tất và [không gọi đích lần nữa](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger).

Đi kèm là hai cái giá. [Sau bảy ngày sổ cái quên](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#limits), và một lần phát lại từ một con trỏ cũ hơn có thể ghi lại lần nữa. Còn một lượt ghi bị hết thời gian chờ để lại một nghi ngờ chính đáng: hệ thống kia có thể đã lưu nó mà không trả lời. Tajo thử lại lượt ghi đó ở một lần thử sau thay vì ghi nhận nó là thất bại trong bảy ngày. Một connector trao cho đích một khóa idempotency của riêng nó sẽ xóa được nghi ngờ đó. Connector nào không làm được thì vẫn còn khả năng xảy ra một bản trùng.

## 3. Một lượt chạy sở hữu đồng bộ, và chứng minh điều đó trước mỗi lượt ghi

Quy tắc thứ ba của họ: “Kiểm tra lại từng mục ngay trước khi đăng.” Với một quy trình đồng bộ, thứ dễ thay đổi nhất giữa lượt đọc và lượt ghi là ai được phép ghi.

Mỗi quy trình đồng bộ của Tajo có [một quyền giữ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease), với token riêng và thời hạn 15 phút được gia hạn mỗi năm phút. Một lượt chạy kiểm tra rằng nó vẫn còn giữ quyền này trước khi gọi đích, và kiểm tra lại trước khi dời con trỏ. Một lượt chạy đã mất quyền giữ sẽ dừng lại, và [trang của nó hiển thị](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#failures) “Lần chạy mất suất của nó giữa chừng và đã dừng để tránh ghi hai lần.” Một lượt chạy thứ hai va phải một lượt đang chạy sẽ [kết thúc thay vì xếp hàng phía sau](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries).

Các bản ghi cũng được kiểm tra. Giữa lượt đọc và lượt ghi, các bản ghi đi qua [bộ lọc đồng thuận](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/). Một liên hệ được ghi vào tệp đối tượng marketing mà không có bằng chứng đồng thuận sẽ bị từ chối thay vì phỏng đoán. Theo [lời của trang trợ giúp](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/), chế độ thất bại luôn là “quá thận trọng”, không bao giờ là “gửi quá mức”.

## 4. Thử lại thứ sẽ qua được, dừng thứ không qua được

Sáu quy tắc của họ không nói gì về tần suất thử lại. Một quy trình đồng bộ cần quy tắc đó, vì các lỗi thường gặp nhất của nó là giới hạn tốc độ và một phút trục trặc của nhà cung cấp.

Một lượt chạy Tajo trong hàng đợi bị thất bại sẽ có [năm lần thử](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries). Thời gian chờ giữa các lần là 60, 120, 240 và 480 giây, tổng cộng khoảng mười lăm phút. Một số lỗi [không bao giờ được thử lại](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries), vì thử lại không thể sửa được chúng. Một lượt chạy va phải một lượt đang chạy sẵn thì không được thử lại, và một lượt chạy mà phiên bản đã xuất bản hoặc các kết nối của nó không còn hợp lệ cũng vậy.

Một chuỗi thất bại khác với một trục trặc thoáng qua. Nếu năm lượt chạy đã kết thúc gần nhất kể từ lần cuối đồng bộ được thay đổi đều thất bại, Tajo [tạm dừng đồng bộ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause) và hiển thị lỗi cuối cùng trên trang của nó. Một lần thành công sẽ đặt lại bộ đếm. [Không có gì tự khởi động lại một đồng bộ đang tạm dừng](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause); một người sửa nguyên nhân và xuất bản lại nó. Bài viết về worker đã chết kể lại sự cố đã sinh ra quy tắc này.

## 5. Coi sự im lặng là một phát hiện

“Báo cáo một lượt đọc thất bại là không đọc được, đừng bao giờ coi đó là một ngày yên ắng.” Đây là quy tắc khó nhất trong sáu quy tắc, và là quy tắc duy nhất chúng tôi chỉ đáp ứng được một phần.

Chỗ nó đúng: một lượt đọc báo lỗi làm lượt chạy thất bại. Một token bị từ chối hay một máy chủ không phản hồi sẽ không gửi gì đến đích, để [con trỏ ở nguyên chỗ cũ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) và được tính vào [việc tạm dừng sau năm lượt chạy thất bại](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause). Và [mỗi giờ, vào phút thứ 13](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check), Tajo kiểm tra mọi workspace có đồng bộ đang hoạt động. Nó cảnh báo đội ngũ của chính mình khi không có lượt chạy thành công nào trong 24 giờ qua, kể cả workspace không ghi nhận lượt chạy nào. Đó là [phép kiểm tra hằng giờ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check).

Chỗ nó không đúng: lượt đọc im lặng mà các tác giả mô tả là một lượt đọc trả lời “OK” mà không có bản ghi nào. Bộ chạy của chúng tôi tính đó là thành công. Với các nguồn như khách hàng Shopify, một phép kiểm tra riêng cảnh báo đội ngũ Tajo sau mười lượt chạy thành công liên tiếp với không bản ghi nào, nếu trước đó đồng bộ đã từng tạo ra bản ghi. Đơn hàng Shopify được đọc theo thời gian cập nhật, nên một lượt chạy rỗng ở đó là bình thường và phép kiểm tra đó không chạy. Một nguồn trả về một số bản ghi, nhưng ít hơn mức lẽ ra phải có, hoàn toàn không bị phát hiện.

Lời phản bác thế này: “Mười lượt chạy rỗng là hai tiếng rưỡi với lịch chạy 15 phút. Sao không cảnh báo ngay lượt đầu tiên?” Các đồng bộ liên hệ đúng là [mặc định chạy mỗi 15 phút](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/). Và một cửa hàng không có khách hàng mới trong mười lăm phút là chuyện bình thường. Một cảnh báo ở lượt chạy rỗng đầu tiên sẽ kêu mỗi đêm, và một cảnh báo lúc nào cũng kêu thì chẳng ai đọc. Ngưỡng đó đổi tốc độ lấy sự tin cậy. Nó vẫn là một phỏng đoán về sự im lặng, không phải quy tắc của các tác giả.

## 6. Quyết định một lần đồng bộ được ghi gì, và bắt mọi lượt chạy chứng minh điều đó

Quy tắc thứ năm của họ giữ các tùy chọn của agent “trong một kho mà agent không thể sửa”. Quy tắc thứ sáu chỉ cho agent quyền chỉ đọc ở mọi nơi nó chỉ đọc, và giới hạn mức chi tiêu của mỗi lượt chạy. Cả hai tồn tại vì agent đọc văn bản do người khác viết, và văn bản đó có thể tìm cách ra lệnh cho nó.

Với một quy trình đồng bộ, phiên bản tương ứng của tệp tùy chọn là quy tắc đã xuất bản. Xuất bản một đồng bộ Tajo sẽ [gắn nó với một bản tóm lược (digest)](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/) của chính quy tắc đã được xem trước. Chỉnh sửa nó sẽ [đưa nó về bản nháp](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/), và nó phải qua bước xem trước lần nữa trước khi chạy lại. Mỗi lượt chạy, trước khi thay đổi bất cứ thứ gì, kiểm tra rằng nó đang chạy đúng phiên bản đã xuất bản đó với các kết nối mà nó được xuất bản cùng. Một lượt chạy không qua được phép kiểm tra đó [không được thử lại](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries). Chiều ghi cũng cố định: một quy tắc đồng bộ [chỉ ghi một chiều](https://tajo.io/vi/resources/help/getting-started/understanding-data-sync/) và không bao giờ ghi ngược vào Shopify.

Giới hạn chi tiêu thì không có tương ứng. Các lượt chạy đồng bộ của chúng tôi không có giới hạn chi tiêu cho mỗi lượt. Giới hạn thử lại và việc tạm dừng giới hạn thời gian một lỗi có thể kéo dài, chứ không giới hạn chi phí của một lượt chạy.

## Những gì đã xây dựng, và những gì chưa

Đã xây dựng, tính đến thời điểm viết bài:

- [Một con trỏ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#cursor) chỉ dời đi sau một lô mà mọi bản ghi đều đã đến nơi, và một con trỏ đơn hàng theo lịch mà các lượt chạy do người khởi động không thể tua ngược.
- [Một khóa gửi cho mỗi bản ghi](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#ledger), được đối chiếu với sổ cái các lượt ghi đã hoàn tất, lưu trong bảy ngày.
- [Một quyền giữ cho mỗi đồng bộ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#lease), được kiểm tra trước lượt ghi và trước khi con trỏ dời đi.
- [Năm lần thử cho mỗi lượt chạy](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#retries), chờ 60 giây rồi 120, 240 và 480, không thử lại khi va chạm hoặc khi bản xuất bản không hợp lệ.
- [Tạm dừng sau năm lượt chạy thất bại liên tiếp](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#pause), hiển thị trên trang của đồng bộ.
- [Một cảnh báo hằng giờ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check) khi không có lượt chạy nào thành công trong 24 giờ qua.
- Một bộ lọc đồng thuận lúc chạy cho các liên hệ được ghi vào tệp đối tượng marketing, và một phép kiểm tra ở mỗi lượt chạy rằng đó là phiên bản đã xuất bản.

Chưa xây dựng, và đáng biết trước khi bạn dựa vào nó:

- Một lượt đọc thành công với không bản ghi nào không được báo cáo là không đọc được. Cảnh báo sau mười lượt chạy che được một phần. Nó không che đơn hàng Shopify hay một nguồn trả về quá ít bản ghi.
- [Cảnh báo 24 giờ đến với Tajo](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#hourly-check), không đến với bạn, và cảnh báo sau mười lượt chạy cũng vậy. Còn việc tạm dừng thì có hiển thị trên trang của đồng bộ.
- [Phép kiểm tra hằng giờ theo dõi workspace](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#limits), không theo dõi từng đồng bộ. Một đồng bộ khỏe mạnh che khuất một đồng bộ im lặng bên cạnh.
- Không có giới hạn chi tiêu cho mỗi lượt chạy.
- Không có gì khởi động lại một đồng bộ đang tạm dừng. Một người làm việc đó.
- [Việc tạm dừng sau năm lần thất bại và phép kiểm tra 24 giờ](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/#limits) được đặt cho toàn bộ hệ thống Tajo, không phải cho từng đồng bộ.

Khi một trong những điều này xuất hiện ở đồng bộ của chính bạn, [Khôi phục đồng bộ bị treo hoặc thất bại](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/) cho biết bạn sẽ thấy gì và cần làm gì.

Các tác giả viết sáu quy tắc cho một bản tóm tắt mà một người đọc mỗi sáng. Một quy trình đồng bộ hoàn toàn không có người đọc buổi sáng, vì thế nó càng cần những quy tắc đó hơn. Các quy tắc từ một đến bốn và quy tắc sáu [đã là mã trong bộ chạy của chúng tôi hiện nay](https://tajo.io/vi/resources/help/troubleshooting/recover-a-stuck-or-failed-sync/). Quy tắc năm mới viết được một nửa: một quy trình đồng bộ không đọc được nguồn của mình thì nên nói ra điều đó.

## Câu hỏi Thường gặp

**Một quy trình đồng bộ dữ liệu tự động cần gì để chạy an toàn khi không ai theo dõi nó?**

Sáu điều. Một con trỏ chỉ dời đi sau khi cả lô đã đến nơi. Một khóa gửi cho mỗi bản ghi mà lần thử lại suy ra lại được, được đối chiếu với sổ cái các lượt ghi đã hoàn tất. Mỗi đồng bộ chỉ một lượt chạy tại một thời điểm. Số lần thử lại có giới hạn, rồi tạm dừng khi các lượt chạy cứ thất bại. Một cảnh báo khi cả ngày không có gì thành công. Và một quy tắc đã xuất bản mà mọi lượt chạy phải chứng minh mình đang thực thi.

**Vì sao một quy trình đồng bộ không nên đọc theo một khung thời gian cố định như 24 giờ qua?**

Vì các lượt chạy không đúng giờ. Một lượt chạy bắt đầu muộn để lại một khoảng trống mà khung thời gian không bao giờ phủ tới, còn một lượt chạy bắt đầu sớm đọc bản ghi hai lần. Một con trỏ đã lưu bắt đầu mỗi lượt chạy đúng tại chỗ lô sạch cuối cùng kết thúc, bất kể lượt chạy bắt đầu lúc nào.

**Tajo ngăn một lượt đồng bộ được thử lại ghi cùng một bản ghi hai lần như thế nào?**

Mỗi bản ghi nhận một khóa gửi, là giá trị băm của đồng bộ, nguồn, con trỏ trang, vị trí trên trang và chính bản ghi đó. Khóa được giành trước khi gọi đích và được đánh dấu hoàn tất khi lượt ghi thành công; các khóa đã hoàn tất được giữ trong bảy ngày. Một lần thử lại hoặc một lượt chạy sau suy ra cùng khóa đó và không gọi đích lần nữa.

**Tajo có nhận ra khi một nguồn không trả về gì vì lượt đọc đã thất bại trong im lặng không?**

Chỉ một phần. Một lượt đọc báo lỗi làm lượt chạy thất bại, và lượt chạy đó được tính vào việc tạm dừng sau năm lượt chạy thất bại liên tiếp. Một lượt đọc thành công với không bản ghi nào được tính là thành công. Với các nguồn như khách hàng Shopify, đội ngũ Tajo được cảnh báo sau mười lượt chạy thành công liên tiếp với không bản ghi nào, nếu trước đó đồng bộ đã từng tạo ra bản ghi. Với đơn hàng Shopify, được đọc theo thời gian cập nhật, phép kiểm tra đó không chạy.

## Bài viết liên quan

### [Worker đã chết. Đồng bộ thì không.](https://tajo.io/vi/blog/worker-died-sync-didnt/)

5 thg 11, 2026 · 11 phút đọc

6 phần

### [Tích hợp Brevo: chọn kết nối bạn có thể kiểm chứng](https://tajo.io/vi/blog/brevo-connector-guide/)

19 thg 8, 2026 · 5 phút đọc

6 phần

### [Cách nhập danh bạ CSV hoặc Excel vào Brevo bằng script (Python, Node.js, cURL)](https://tajo.io/vi/blog/import-csv-contacts-to-brevo-with-a-script/)

30 thg 4, 2026 · 6 phút đọc

CSV → Brevo