Video học lập trình mỗi ngày

👉 Bài tech này được được vào: Series: Xây dựng hệ thống bán vé theo kiến trúc DDD - java với lượng đồng thời cao

👉 Source Code: JAVA DDD Source Code ~ 30.000 QPS: Bán Vé Từ Video Section 17 - 26 How to run()

👉 Link Discord: Discord

Trong bài viết nói về MVCC trong Database, chúng ta đã phân tích toàn diện về các cơ chế khoá trong Database (My

SQL). Tính nhất quán cuối cùng của hệ thống đó chính là dữ liệu phải chính xác. Hiểu đúng là, dù lỗi FULL toping hay lỗi 1/2 đi chăng nữa, thì dữ liệu chính xác, vì vậy đối với giao dịch đồng thời thì MySQL đã cung cấp rất trọn vẹn cho sự cách ly này.

Bạn có thể xem thực hành MVCC trong Database mà tôi đã triển khai...

Tiếp theo nó có liên quan gì đến section này, có liên quan đó là cách ly dữ liệu. Sơn Tùng MTP có thể nói là VIP (instance database), còn ca sĩ hạng C thuộc loại nằm vào Share Database đây chính là việc phải triển khai trong các hệ thống fintech, stock, ecommerce..

Các giao dịch đồng thời có thể được chia thành bốn loại: R-R, W-W, R-W, W-R (đọc-đọc, ghi-ghi, đọc-ghi và ghi-đọc). Bốn loại này tương ứng với bốn kịch bản khi các giao dịch đồng thời được thực thi, hãy xem lại bài viết trên về MVCC..

Vậy câu hỏi được đặt ra ở đây đó là: "Tại sao tôi không thể thấy dữ liệu mà bạn đã thay đổi trong database?" Có trường hợp này không?

OK bắt tay vào section này... Nhưng tôi muốn nói điều này có được không? Vì có nhiều bạn hỏi tôi rằng: "Anh ơi... Dự án có lượng đồng thời cao như DDD này, có dễ học không anh? Có thể join vào Team như vậy được không ạ?" Tôi không trả lời trực tiếp được, tôi có thể nói thế này:

Công việc nào cũng như nhau, không có tồi or tốt. Việc đi làm đó chính là kiếm tiền. Mà muốn kiếm tiền thì phải giải quyết vấn đề. Vì vậy bản chất công việc đó chính là giải quyết vấn đề càng khó thì lương càng cao, value càng cao thì rủi ro càng lớn và cũng như khả năng càng cao thì ắt sẽ gặp nhiều vấn đề hơn những người xung quanh. Hết....

‍

Quay trở lại với hệ thống bán vé..

Hệ thống bán vé DDD java đang "Bình ổn" nhưng rủi ro tiềm tàng

Nếu bạn là người mới xin vui lòng xem lại Section từ 1 - 29 tại: Series: Xây dựng hệ thống bán vé theo kiến trúc DDD - java với lượng đồng thời cao

Trong trạng thái hoạt động bình thường, hệ thống của chúng ta vận hành theo mô hình Shared Everything. Mọi thành phần từ Nginx đến Database đều dùng chung.

Sơ đồ 1: Kiến trúc Hiện tại (Shared Infrastructure)

Hiện tại chúng ta đang gom tất cả các đại lý vào chung một schema​ điều đó đến giờ trông rất ổn, thế nhưng một hôm Sơn Tùng MTP mở show và muốn setup bán trên hệ thống của xxxx.com.

Vì vậy ở đây nó sẽ không ổn định, chỉ vì Sơn Tùng MTPmà những agent khác đều bị ảnh hưởng nặng nề. Chúng ta không thể upgrade lên hết vì không thể mở đường cao tốc cho xe bò đi được.

Hãy dành được cao tốc đó cho những xe có vận tốc lớn hơn 60km/h, còn lại hãy đi đường khác.

Phân tích tình huống: Khi show Sơn Tùng MTP mở bán, 100.000 người dùng cùng đổ dồn vào Shared_Storage_Pool.

• Hệ lụy: Chỉ cần một câu truy vấn nặng từ show Sơn Tùng làm treo Table Lock, toàn bộ các show diễn khác (Đại lý nhỏ) ngay lập tức bị "liệt". Hệ thống không có khả năng tự vệ.

‍ OK, vậy giải pháp là gì? Ở đây chúng ta sẽ nói ngắn gọn, vì video sẽ trình bày kỹ thuật tốt hơn...

‍

Cách ly tài nguyên - Bảo vệ toàn vẹn hệ thống

Chúng ta thực hiện một cú "bẻ lái" kỹ thuật tại tầng Infrastructure và Controller để cô lập sự ảnh hưởng.

Sơ đồ 2: Kiến trúc Nâng cấp (Resource Isolation)

Phân tích sự thay đổi:

1. Giai đoạn Nhận diện (TI & RD): Hệ thống lập tức nhận ra yêu cầu này thuộc về "Chiến dịch Sơn Tùng MTP".
2. Giai đoạn Điều hướng (DSR): Thay vì đẩy vào DB chung, hệ thống lái toàn bộ traffic vào ​VIP_Data_Pool. Đây là cụm tài nguyên được "đắp" cấu hình cực cao, chỉ phục vụ riêng cho show này.
3. Kết quả: Dù show Sơn Tùng có "nóng" đến mức cháy server VIP, thì cụm Shared_Data_Pool (nơi chứa dữ liệu các đại lý khác) vẫn hoàn toàn mát mẻ và vận hành trơn tru.

Hệ thống cần thêm gì để hoàn thiện?

Nhìn vào kiến trúc nâng cấp, để thực sự "vận hành được" trong môi trường Product, chúng ta vẫn thiếu một số mảnh ghép quan trọng:

1. Dynamic Configuration (Nacos / Apollo): Để hệ thống biết khi nào một Agent được coi là VIP và cần "lái" sang Pool riêng mà ​không cần restart server. Chúng ta cần một bộ quản lý cấu hình động.
2. Data Migration Tools: Khi một show từ nhỏ bỗng dưng bùng nổ (Viral), chúng ta cần công cụ để di chuyển dữ liệu từ Shared_Pool​ sang VIP_Pool trong vài giây mà không làm gián đoạn bài thi/phiên đặt vé.
3. Circuit Breaker (Sentinel / Resilience4j): Ngay cả khi đã cách ly, nếu cụm VIP bị quá tải cực độ, chúng ta cần cơ chế "ngắt cầu dao" (ví dụ: hiển thị trang chờ) để bảo vệ chính cụm tài nguyên VIP đó, không để lỗi lan truyền ngược lên tầng Application.
4. Auto-Scaling Policy: Kết hợp với K8s để tự động tăng số lượng Pod cho cụm xxxx-start khi nhận diện traffic VIP đang tăng vọt.

‍

Tạm thời gác bút tại đây... Tại video sẽ có nhiều câu hỏi được đưa ra.

‍