Đây là một thuộc tính của sự cô lập giao dịch. Có rất nhiều bài viết về nó và tôi thực sự muốn giới thiệu tổng quan trong Thiết kế dữ liệu chuyên sâu Các ứng dụng . Tôi thấy đây là phần mô tả hữu ích nhất trong việc nâng cao hiểu biết cá nhân của mình.
Cấp postgres mặc định là ĐỌC CAM KẾT điều này cho phép mỗi giao dịch đồng thời này thấy một trạng thái tương tự (trạng thái tiền khả dụng) mặc dù chúng phải phụ thuộc.
Một cách để giải quyết vấn đề này là đánh dấu mỗi giao dịch trong số này là tính nhất quán "SERIALIZABLE".
Điều này sẽ thực thi tính đúng đắn của ứng dụng của bạn với chi phí phù hợp với tính khả dụng, tức là trong trường hợp này, giao dịch thứ hai sẽ không được phép sửa đổi hồ sơ và sẽ bị từ chối, điều này sẽ yêu cầu thử lại. Đối với POC hoặc ứng dụng có lưu lượng truy cập thấp, đây thường là bước đầu tiên hoàn toàn có thể chấp nhận được vì bạn có thể đảm bảo tính chính xác cho ngay bây giờ.
Cũng trong cuốn sách được đề cập ở trên, tôi nghĩ rằng có một ví dụ về cách xử lý khả dụng của ATM. Họ cho phép điều kiện cuộc đua này và người dùng rút tiền nếu họ không thể kết nối với ngân hàng tập trung nhưng ràng buộc mức rút tối đa để giảm thiểu bán kính vụ nổ!
Một cách kiến trúc khác để giải quyết vấn đề này là thực hiện các giao dịch ngoại tuyến và làm cho chúng không đồng bộ, để mỗi giao dịch do người dùng gọi được xuất bản vào một hàng đợi và sau đó bằng cách có một người tiêu dùng hàng đợi, bạn tự nhiên tránh được bất kỳ điều kiện chủng tộc nào. Sự cân bằng ở đây cũng tương tự như vậy, có một thông lượng cố định có sẵn từ một công nhân, nhưng nó sẽ giúp giải quyết vấn đề về tính đúng đắn ngay bây giờ:P
Khóa giữa các máy (như sử dụng redis trên postgres / grpc) được gọi là khóa phân tán và có nhiều bài viết về nó https://martin.kleppmann.com/2016/02/08/how-to-do-distributed-locking.html
