Khi một đơn hàng bị thiếu hàng ở một kho, hệ thống sẽ tạo một yêu cầu điều chuyển nội bộ để dịch tồn kho từ một địa điểm khác về. Luồng hiện tại publish một Kafka message cho mỗi đơn hàng, và mỗi message lại kích hoạt một yêu cầu điều chuyển riêng.

Vào giờ cao điểm, chỉ một kho thôi cũng có thể sinh ra hàng trăm message như vậy trong vài phút. Mỗi message lại đẻ ra một phiếu điều chuyển nhỏ. Cuối cùng đội kho phải xử lý hàng chục yêu cầu lắt nhắt cho cùng một điểm đến, trong khi chỉ cần một batch gộp lại là đủ.

Dù đã phê bình khá nhiều ở bài trước, mình vẫn cho rằng Redlock là một thuật toán đáng giá, vừa như một công cụ thực dụng, vừa như một cánh cửa để bước vào tư duy về hệ thống phân tán.

Theo kinh nghiệm của mình, những nhược điểm về mặt lý thuyết của nó ít khi biến thành thảm họa trong thực tế. Vì sao? Vì những engineer chọn Redis thường không đặt cược tất cả vào nó. Họ xem Redis là nhanh nhưng không hoàn hảo: một lớp cache, một rate limiter. Khi thiết kế với tâm thế đó, bạn tự nhiên sẽ dựng thêm các lớp bảo vệ, chẳng hạn ràng buộc unique ở database, idempotency key, hay các thao tác an toàn khi retry. Những kiểu lỗi mà Kleppmann mô tả là có thật, nhưng chúng vẫn sống được trong các hệ thống không mặc định rằng mọi thứ đều hoàn hảo.

Dài Quá Lười Đọc: Redis là một hệ thống AP, không phải CP. Nó không thể đảm bảo strong consistency. Với các use case có mức độ đồng thời cao, bạn nên lường trước khả năng xảy ra data race khi dùng Redis. Nếu cần đảm bảo chặt chẽ, hãy cân nhắc các hệ thống cung cấp strong consistency (ví dụ etcd, ZooKeeper).

Lock trên một Redis instance duy nhất

Ở bài trước, chúng ta đã tìm hiểu cách cài đặt một distributed lock bằng một Redis instance duy nhất. Chúng ta đã trả lời câu hỏi: điều gì xảy ra nếu client crash? Nhưng vẫn còn một câu hỏi quan trọng chưa được giải quyết: điều gì xảy ra nếu chính Redis gặp sự cố?

Lưu ý: Các ví dụ code trong bài viết này sử dụng Go. Các khái niệm áp dụng được cho mọi ngôn ngữ.

Tại sao cần lock?

Hãy tưởng tượng hai user cùng rút tiền từ một tài khoản ngân hàng. Nếu không có đồng bộ hóa, cả hai có thể đọc cùng một số dư, trừ số tiền riêng, rồi ghi lại, dẫn đến lost update. Một giao dịch rút tiền biến mất.

Là kỹ sư phần mềm, chúng ta hằng ngày đều làm việc với việc trừu tượng hóa dữ liệu. Cố gắng tìm hiểu các khái niệm mơ hồ trong thế giới thực và trừu tượng hóa chúng thành thông tin có cấu trúc như biến, hàm, lớp, struct, v.v. để phần mềm có thể xử lý. Làm việc với dữ liệu hầu như luôn liên quan đến việc lưu trữ chúng vào một loại kho lưu trữ dữ liệu nào đó, một trong những loại lưu trữ đó là cơ sở dữ liệu quan hệ, thường được gọi là cơ sở dữ liệu SQL. Trong bài viết này, chúng ta sẽ đi qua các dạng chuẩn của cơ sở dữ liệu quan hệ để tìm hiểu chúng là gì, tại sao chúng tốt và tại sao chúng có thể không tốt. Chúng ta sẽ chỉ đề cập đến ba dạng chuẩn đầu tiên vì chúng là phổ biến nhất trong thế giới kỹ thuật phần mềm hiện đại.