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

Bài viết này được đưa vào:

Series: Dự án DDD - vetautet.com có lượng đồng thời CAO (GO, JAVA, NestJS, NODEJS...)

Hôm nay tôi và các đại ca bàn luận về high concurrency nhằm giải toả thắc mắc của các bạn có những câu hỏi như "30.000 req/s" cũng được gọi là ĐỒNG THỜI CAO hả (bạn, anh , em)?

Và nhân tiện trong bài viết này tôi cũng nói thêm về một số trường hợp xử lý khi bạn bị mặc kẹt trong vấn đề này, thông qua một số biện pháp của tư duy backend mà đã nói ở những bài trước, bạn có thể đọc lại.

Đây là kinh nghiệm của tôi, và tất nhiên còn nhiều thiếu sót, không ai hoàn hảo, không có một phiên bản nào phù hợp với mọi tình huống. Chỉ là nó tốt hơn mỗi ngày mà thôi. Có gì sai sót, mong được góp ý từ các TRƯ VỊ VÕ LÂM.

Trích: Tồn kho trong JAVA

Khuyến nghị: DDD - Project: vetautet - Senior cũng phải lo lắng khi bắt đầu khấu trừ hàng tồn kho?

Đồng thời CAO là gì? What is high concurrency?

Trước tiên hiểu đơn giản về khái niệm này:

Tính đồng thời cao có nghĩa là nhiều người dùng truy cập cùng một API interface hoặc một URL api cùng một lúc. Thường xảy ra ở các ứng dụng có user hoạt động nhiều và tần suất cao.

Ví dụ: Con đường hằng ngày chúng ta đi làm khi đi vào TRUNG TÂM thì xảy ra hiện tượng kẹt xe, vì trên một cung đường (URL API) có quá nhiều user hoạt động và luôn chen lấn.

Tiếp theo tôi sẽ trả lời câu hỏi: "30.000 req/s" cũng được gọi là ĐỒNG THỜI CAO hả (bạn, anh , em)?

Trích: GO

Vì sao tôi nhận được câu hỏi này, bởi vì tôi đã triển khai xong bán vé tàu tết cho anh em tiếp cận với các hoạt động diễn ra như trên. high concurrency chính là khi bán vé được mở đúng ngày xxx và giảm giá yyy thì bạn biết đấy, đó là điều có lợi và tất nhiên mọi người đổ xô làm điều có lợi rõ ràng là đương nhiên.

Do đó api -> /v1/2024/ticket/item/xxx sẽ đón nhận lưu lượng truy cập lớn ngày từ lúc bán vé. Ở đây gọi là hoạt động DATA READ. Cũng không khó khăn lắm để cải thiện hiệu suất READ thừ 3000 req/s lên 30.000 req/s trong anh em bên GO, còn anh em bên JAVA thì từ 3000 req/s lên 25.000 req/s.

READ không khó để cải thiện hiệu suất, nhưng WRITE thì rât khó. WRITE ở đây có nghĩa là gì? Chính là việc hoạt động mua vé tàu. Khi mua là được WRITE vào order, sau đó sẽ check xem inventory còn vé hay không? Sau đó mới tiếp các active tiếp theo như send notification, send email. Chính vì vậy sẽ rất khó triển khai với hoạt động này.

Thứ 3 là đồng thời cao là sự đánh đổi với tính nhất quán dữ liệu. Tìm một cô vợ và vừa GIỎI vừa ĐẸP vừa TIỀN nhiều thì không thể (Đã nói trong TƯ DUY BACKEND thể hiện qua CAP)

Quay trở lại với câu hỏi: "30.000 req/s" cũng được gọi là ĐỒNG THỜI CAO hả (bạn, anh , em)?

Thật sự các bạn đang làm ở một ứng dụng lớn như game đánh bài chẳng hạn, hẳn đang nghĩ rằng nếu QPS không phải là hàng trăm nghìn hoặc hàng triệu thì không thể gọi là đồng thời cao được, đúng không?

Còn các anh chị đang mới bước vào xử lý với 2000 -> 3000 req/s thì không thể gọi là đồng thời cao được , đúng không?

Không có chuyện đó, giống như con đường ta đi, có người đi qua đường xxx, có người đi qua đường yyy, không có con đường nào giống nhau cả, nhưng có một điều vẫn giống chính là những lúc tắc đường. Ai cũng phải tắc mà thôi.

Bạn không thể đi trên con đường rộng 60m (QPS = 500.000 req/s) lại nói rằng: Ê, đường 4m (hệ thống) mày mới có 2000 req/s mà kẹt rồi mày. Không thể được, con đường bạn 60m được hỗ trợ rất nhiều nguồn lực, còn đường 4m vì chi phí ít cho nên chỉ hoạt động được từng đó, nhưng với chúng tôi đã là đủ với việc cải thiện rồi.

Với tôi thì Không có con số QPS cụ thể nào cho tính đồng thời cao. QPS = 1 triệu có cao không? Không... Chưa hề có chuyện đó. Núi này cao ắt hẳn có núi khác cao

Dân backend và Đồng thời CAO

Đối với các công ty như tôi nói ở trên thì việc QPS đạt tới 1.000.000 req/s là không phải là hiếm gặp. Do đó, khi anh em nói về tính đồng thời cao, thì ngay từ đâu xây dựng chưa cần phải nghĩ tới rằng có một tình huống đồng thời có quy mô cực lớn.

NO, nếu tối ưu ngay từ đầu thì bạn chết chắc rồi. Khi vấp phải chuyện đó mà hiện tại hệ thống không giải quyết được thì lúc đó hãy cân nhắc. Ở đây bạn phải hiểu rằng, không phải nước đến chân mới nhảy mà là hãy cố gằng tối ưu chi phí ngay cả khi công ty đang khó khăn nhất có thể.

Điều quan trọng là phải hiểu được lượng đồng thời cần xử lý trong một kịch bản kinh doanh cụ thể nào và trong những điều kiện nào(lập trình viên giỏi, khả năng sử dụng kỹ thuật cao, áp dụng thuật toán...) và sau đó xem các mục tiêu có vượt qua không?

Cũng giống như API - vetautet backend được viết bởi Go - TEAM BACKEND và Java, tiếp theo sẽ là NESTJS - TEAM BACKEND thì bạn thấy đấy với chi phí rẻ mạt chúng tôi có thể chống chọi được 30.000 req/s khi READ DATA và 10.000 req/s khi mua hàng mà dữ liệu vẫn nhất quán và chịu tải tốt.

Đó vậy thôi. Chúng ta cần học hỏi mỗi ngày và mỗi người đều cho ta một bài học đúng không?