> ## Documentation Index > Fetch the complete documentation index at: https://www.helius.dev/docs/llms.txt > Use this file to discover all available pages before exploring further. # Đảm bảo phân phối > Tìm hiểu các đảm bảo phân phối của LaserStream, bao gồm phân phối đúng một lần, thứ tự thông báo, hành vi thông báo slot và cách xử lý fork. LaserStream cung cấp các đảm bảo phân phối hoàn toàn giống với các node Geyser. Hướng dẫn này trình bày những gì bạn có thể mong đợi từ cơ chế phân phối thông báo của các luồng LaserStream. Các đảm bảo này áp dụng cho **đăng ký tiêu chuẩn** (giao dịch, tài khoản, slot, block). [Giao dịch được xử lý trước](/docs/vi/preprocessed-transactions/overview) (một phần của Shred Delivery) hoạt động theo các đảm bảo phân phối riêng dựa trên nỗ lực tối đa. ## Phân phối đúng một lần LaserStream đảm bảo **phân phối đúng một lần**. Mỗi thông báo được phân phối đến luồng của bạn đúng một lần — bạn sẽ không bao giờ nhận được thông báo trùng lặp và không có thông báo nào bị bỏ qua. LaserStream thực hiện điều này bằng cách kết nối đồng thời với nhiều node Solana và loại bỏ dữ liệu trùng lặp trước khi chuyển tiếp dữ liệu đó đến luồng của bạn. Kiến trúc đa node này cũng loại bỏ các điểm lỗi đơn lẻ, đảm bảo thời gian hoạt động tối đa mà không làm giảm tính chính xác của việc phân phối. ## Thứ tự thông báo theo mức cam kết Thứ tự phân phối phụ thuộc vào mức cam kết của thông báo: ### Đã xác nhận và đã hoàn tất Tất cả thông báo **đã xác nhận** và **đã hoàn tất** đều được phân phối theo đúng thứ tự. Bạn có thể dựa vào các mức cam kết này để có chế độ xem trạng thái on-chain nhất quán và tuần tự. ### Đã xử lý Tất cả thông báo **đã xử lý** được phát theo thứ tự slot tăng dần, trừ khi xảy ra fork. Khi có fork, thứ tự slot có thể tạm thời sai lệch trong lúc mạng tái tổ chức quanh chuỗi chính tắc. Khi fork được giải quyết, thứ tự tăng dần sẽ tiếp tục. Ở mức cam kết đã xử lý, có một khả năng nhỏ là slot đã xử lý sau đó có thể bị bỏ qua hoặc bị loại do fork. Geyser **không** gửi thông báo hoàn tác rõ ràng cho các bản cập nhật bị loại do fork. Nếu ứng dụng của bạn sử dụng dữ liệu ở mức đã xử lý, bạn phải tính đến khả năng một số bản cập nhật có thể thuộc về các slot cuối cùng bị từ bỏ. Với các ứng dụng cần sự chắc chắn, hãy sử dụng mức cam kết **đã xác nhận** hoặc **đã hoàn tất**. ## Thứ tự trong một slot Trong một slot, LaserStream phân phối các bản cập nhật tài khoản và giao dịch với các đảm bảo sau: ### Bản cập nhật tài khoản trước giao dịch Với mỗi giao dịch, các bản cập nhật tài khoản do giao dịch đó tạo ra được phân phối **trước** chính giao dịch đó: ``` → → → ``` ### Thứ tự giữa các giao dịch LaserStream duy trì cùng thứ tự như [plugin Geyser của Agave](https://docs.solanalabs.com/validator/geyser#ordering-guarantees). Việc các bản cập nhật từ những giao dịch khác nhau có đến theo thứ tự xác định hay không phụ thuộc vào **khóa ghi** của chúng: * **Cùng khóa ghi** (ví dụ: ba giao dịch hoán đổi trên cùng một pool Raydium): luôn xác định. Agave thực thi các giao dịch này tuần tự vì chúng ghi vào cùng một tài khoản. * **Khóa ghi khác nhau** (ví dụ: hai giao dịch không liên quan): không nhất thiết xác định. Agave có thể thực thi các giao dịch này song song và các bản cập nhật của chúng có thể xen kẽ trong luồng. Để tái tạo thứ tự hoàn toàn xác định bất kể khóa ghi, hãy sử dụng **chỉ mục block/giao dịch** từ dữ liệu giao dịch. ### Chuẩn hóa phiên bản ghi LaserStream chuẩn hóa các phiên bản ghi trên toàn bộ kiến trúc đa node. Không giống Geyser hoặc Yellowstone thô — nơi phiên bản ghi là cục bộ đối với từng node và có thể khác nhau — LaserStream cung cấp các phiên bản ghi nhất quán mà bạn có thể dựa vào để sắp xếp các bản cập nhật tài khoản ở mức đã xử lý. **Ngoại lệ tạm thời:** Các tài khoản lớn hơn 512KB hiện được lưu vào bộ đệm trong plugin Geyser vì lý do hiệu suất, điều này có thể ảnh hưởng đến thứ tự xác định của các tài khoản đó. Giới hạn này sẽ sớm được loại bỏ. ## Thông báo slot **Thông báo slot đã xử lý** đến sau khi tất cả thông báo của slot đó đã được phân phối. Điều này có nghĩa là khi nhận được thông báo slot đã xử lý, bạn có thể tin chắc rằng toàn bộ dữ liệu giao dịch và bản cập nhật tài khoản liên quan đến slot đó đã được gửi đến luồng của mình. Bạn có thể dùng thông báo slot làm tín hiệu để xả hoặc giải phóng dữ liệu được lưu vào bộ đệm cho slot đó. ## Tính liên tục của dữ liệu khi mất kết nối LaserStream duy trì một bộ đệm dữ liệu slot gần đây, cho phép [phát lại dữ liệu lịch sử](/docs/vi/laserstream/historical-replay) trong tối đa **48 giờ** (\~691.200 slot theo tốc độ mạng hiện tại) của dữ liệu trước đó. Nếu ứng dụng bị ngắt kết nối, bạn có thể kết nối lại và tiếp tục từ slot được xử lý gần nhất mà không bỏ lỡ bất kỳ dữ liệu nào. Khi sử dụng [ứng dụng khách LaserStream SDK](/docs/vi/laserstream/clients), quá trình khôi phục này được xử lý tự động — ứng dụng khách theo dõi vị trí phát trực tuyến của bạn theo số slot và kết nối lại liền mạch. Bạn không cần triển khai logic kết nối lại thủ công. ## Tham chiếu mức cam kết | Mức | Mô tả | Độ trễ | Thứ tự | Rủi ro đảo ngược | | --------------- | ----------------------------------------------------------------------------------------------------- | ------------ | ---------------------------------------------------------- | ------------------------------------------------ | | **Đã xử lý** | Được đưa vào block gần nhất mà node biết; chưa có phiếu bầu trên toàn cluster | \~400ms | Thứ tự slot tăng dần (có thể bị gián đoạn khi xảy ra fork) | Khả năng nhỏ slot bị bỏ qua hoặc bị loại do fork | | **Đã xác nhận** | Đa số tuyệt đối cổ phần (≥66%) đã bỏ phiếu cho block (xác nhận lạc quan) | Vài giây | Thứ tự nghiêm ngặt | Không đáng kể | | **Đã hoàn tất** | Đã xác nhận và có ít nhất 31 block đã xác nhận khác được xây dựng ở phía trên (khóa sau 32 phiếu bầu) | \~12-15 giây | Thứ tự nghiêm ngặt | Gần như không thể đảo ngược |