Concurrency

Mục lục Series | Chương tiếp theo: Phần 2: Distributed SQL ACID Latency → Answer-first: Sổ cái kế toán kép (Double-Entry Ledger) chuẩn Core Banking phải áp dụng mô hình Append-Only bất biến, lưu trữ số tiền bằng NUMERIC(18,4) hoặc cấu trúc 128-byte định dạng TigerBeetle, và kiểm soát số dư bằng Database Trigger cùng cơ chế khóa bi quan (SELECT FOR UPDATE). Double-Entry Ledger Database Schema Là Gì? Một database schema cho double-entry ledger yêu cầu tính bất biến (immutability), bảo đảm ACID, và cơ chế locking chính xác để tránh race conditions. Các hệ thống hiện đại như TigerBeetle loại bỏ pessimistic locking truyền thống bằng cách sử dụng single-threaded state machine, đạt mức 1,000,000 TPS trên một CPU core duy nhất. Khi scale lên distributed environment, xem thêm Phần 2 — Distributed SQL & ACID Latency cho so sánh TiDB, CockroachDB, và Spanner. ...

← Chương trước: Executive Summary: Tại Sao E-commerce Cần Agentic Search? | Mục lục Series | Chương tiếp theo: Phần 2: Data Ingestion & Atomic Chunking → Answer-first: Sử dụng Golang và CloudWeGo Eino thay thế Python trong hệ thống Agentic Search giúp loại bỏ nút thắt cổ chai GIL, đạt hàng chục nghìn goroutines đồng thời với độ trễ thấp, kiểm soát kiểu dữ liệu tĩnh nghiêm ngặt và tối ưu hóa tài nguyên phần cứng cho môi trường sản xuất quy mô lớn. ...

← Chương trước: Phần 1 — Order Fulfillment | Mục lục Series | Chương tiếp theo: Phần 3 — Thuật toán phân bổ → Answer-first: Quản lý tồn kho thời gian thực phân tách 4 trạng thái cốt lõi: Physical Stock, Reserved Stock, Safety Stock và ATP (Available to Promise). Bằng cách kết hợp Stock Reservation có thời hạn (TTL), Optimistic/Pessimistic Locking và kiến trúc Eventual Consistency, hệ thống ngăn chặn triệt để hiện tượng overselling trong các đợt flash sale tốc độ cao. ...

← Chương trước: Phần 2 — Nghiệp vụ Ngân hàng Lõi: CIF, CASA & Lending | Mục lục Series | Chương tiếp theo: Phần 4 — Kiến trúc Core Banking hiện đại và Event-Driven → Answer-first: Xử lý giao dịch tài chính yêu cầu tuân thủ 4 thuộc tính ACID và mức cô lập Serializable/Read Committed. Để ngăn chặn Lost Update và Double Spending, hệ thống áp dụng Pessimistic Locking (SELECT FOR UPDATE) theo thứ tự ID xác định chống Deadlock, kết hợp Idempotency Key bảo đảm an toàn khi mạng chập chờn. ...

← Chương trước: Kiến Trúc Hướng Sự Kiện (Event-Driven Architecture) & Kafka — Worker Pool, Backpressure & Exactly-Once | Mục lục Series | Chương tiếp theo: Thiết Kế API Lũy Đẳng (Idempotent API) — Khóa Lũy Đẳng, Middleware SetNX & Mẫu Stripe → Answer-first: Khóa phân tán (Distributed Locks) bảo vệ tài nguyên chia sẻ qua thuật toán Redlock (Redis) với công thức MIN_VALIDITY trừ trôi đồng hồ, hoặc giao thức đồng thuận etcd Raft lease. Cơ chế Quorum (N/2 + 1) và fencing token chống chia cắt mạng (split-brain) và xung đột ghi đồng thời. ...

Tech Radar: Deterministic Concurrency Testing with Go 1.25 testing/synctest Answer-First: The testing/synctest package in Go 1.25/1.26 eliminates flaky concurrency tests by isolating goroutines inside an event-driven “concurrency bubble” governed by a synthetic time clock. Virtual time advances instantaneously the moment all goroutines in the bubble are durably blocked, reproducing multi-step race conditions, backoff retries, and network timeouts in 2ms instead of waiting for 5–10s real-world time.Sleep() delays. 1. The Core Dilemma of Concurrency Testing: The time.Sleep Anti-Pattern In high-throughput Go microservices (Kafka stream consumers, Dapr actor sagas, gRPC retry circuits, distributed rate-limiters), testing timeouts, backoff strategies, and race conditions has historically suffered from flaky test instability. ...

🇬🇧 Read the English version of this article on tanhdev.com Answer-first: Quản lý đồng thời an toàn trong Go đòi hỏi các mẫu Goroutine Pool có giới hạn (bounded concurrency): errgroup cho tác vụ theo lô, semaphore có đệm cho I/O pipelines, và channel-based worker pools cho xử lý hàng đợi kèm backpressure, circuit breaking và graceful shutdown. Mọi kỹ sư Go cuối cùng đều viết cùng một sai lầm: một vòng lặp khởi chạy các goroutine vô điều kiện (unconditionally). Trong một bản demo với 10 mục, điều này hoạt động rất đẹp. Nhưng trong môi trường production (thực tế) với 50.000 sự kiện webhook đầu vào, nó sẽ sản sinh ra 50.000 goroutine cùng một lúc, làm cạn kiệt bộ nhớ và kích hoạt sát thủ diệt bộ nhớ (OOM killer). Kubernetes sẽ khởi động lại (restart) cái pod đó. Và rồi kỹ sư trực on-call nhận tiếng bíp gọi dậy lúc 3 giờ sáng. ...