thắc mắc Xử lý Async trong xây dựng hệ thống tải cao

Em chào mọi người ạ, em có một thắc mắc về xử lý async như sau ạ:
Em có đang làm một cái API để cung cấp service cho enduser. Khi user call cái api đấy thì sẽ có một chương trình, chương trình sẽ execute một tiến trình (job) dưới backend và job này có thể thực hiện mất từ 10' đến vài giờ tùy vào request body của user. Trong quá trình thực thi job đó thì chương trình sẽ tracking liên tục trạng thái của job để update trạng thái của job vào database ( để cung cấp thêm một API nữa cho enduser có thể theo dõi trạng thái job của họ dựa trên việc query vào database).
Mọi người cho e hỏi giả sử ở thời điểm tải cao ( có thể tầm 200-300 request trong một thời điểm, 1000 request trong một giờ ) thì chương trình có thể thực hiện async đc ko ạ (nghĩa là chương trình có thể theo dõi được trạng thái của nhiều job cùng một lúc). Em có tìm hiểu thì thấy @Async với @EvenListenner trong Spring boot có hỗ trợ việc async, nhưng chưa rõ với tải cao như thế có việc handle tracking có vấn đề gì không. Còn Kafka thì có vẻ hỗ trợ xử lý song song, nhưng mỗi request của user thì sẽ public một ID cho consumer, tuy nhiên khi nhiều request thì sẽ sinh ra quá nhiều partition (do mỗi request sẽ sinh ra một ID để dựa vào id đấy track state).
Vậy mình có thể tối ưu trường hợp này ko ạ , mong được anh chị giải đáp ạ. Em cảm ơn mn.

ducgiang99 said:

chương trình sẽ execute một tiến trình (job) dưới backend

Click to expand...

ducgiang99 said:

job đó thì chương trình sẽ tracking liên tục trạng thái của job để update trạng thái của job vào database

Click to expand...

bài toán b đang hỏi nghe giống như là background job, với cái yêu cầu b đang hỏi sẽ cần tập trung vào 2 thứ: storage để lưu job, và workers xử lý job
về storage, nếu b dùng các thư viện phổ biến thì nó sẽ thường là redis/db, b có thể query ra đc trạng thái của job
còn về tải cao như b nói ở trên, thì b phải tăng khả năng xử lý của workers lên, có thể là tăng số lượng, hoặc tăng tốc độ xử lý, tuỳ tình huống
còn kafka mục đích chính nó là streaming data giữa các component trong hệ thống, nên mình nghĩ nó ko phù hợp với bài toán này của bạn

Bạn cần queue chứ ko cần async

VD bạn có max 10 worker, thì request số 11 phải chờ để đc xử lý, thêm 1 trạng thái pending thôi

Love U So Much said:

Bạn cần queue chứ ko cần async

VD bạn có max 10 worker, thì request số 11 phải chờ để đc xử lý, thêm 1 trạng thái pending thôi

Click to expand...

Nhưng thực tế thì dưới hệ thống nó đang running bác ạ (thực thi một tiến trình dưới hệ thống mà), nên cần bao nhiêu job => số lượng thread để tracking tương ứng. Trường hợp queue trên program thì sẽ xảy ra trường hợp job đang chạy rồi nhưng khi user query thì vẫn ra pending

hold_on_never_leave said:

bài toán b đang hỏi nghe giống như là background job, với cái yêu cầu b đang hỏi sẽ cần tập trung vào 2 thứ: storage để lưu job, và workers xử lý job
về storage, nếu b dùng các thư viện phổ biến thì nó sẽ thường là redis/db, b có thể query ra đc trạng thái của job
còn về tải cao như b nói ở trên, thì b phải tăng khả năng xử lý của workers lên, có thể là tăng số lượng, hoặc tăng tốc độ xử lý, tuỳ tình huống
còn kafka mục đích chính nó là streaming data giữa các component trong hệ thống, nên mình nghĩ nó ko phù hợp với bài toán này của bạn

Click to expand...

mình thấy db thì ko vấn đề gì, còn về tải cao thì đúng là cần tăng số lượng thread sao cho số lương thread tương ứng với số lượng job bác ạ để tracking state, Ko biết có solution nào giải quyết được không =(

ducgiang99 said:

mình thấy db thì ko vấn đề gì, còn về tải cao thì đúng là cần tăng số lượng thread sao cho số lương thread tương ứng với số lượng job bác ạ để tracking state, Ko biết có solution nào giải quyết được không =(

Click to expand...

tracking state của thím nó đang khá mơ hồ, nếu có storage job thì query thẳng ra luôn chứ cần làm gì nữa, còn custom thêm thì là bài toán khác r, thím nên đưa ra thím cần tracking cụ thể metrics nào thì sẽ tốt hơn

ducgiang99 said:

mình thấy db thì ko vấn đề gì, còn về tải cao thì đúng là cần tăng số lượng thread sao cho số lương thread tương ứng với số lượng job bác ạ để tracking state, Ko biết có solution nào giải quyết được không =(

Click to expand...

Mình dự rằng bạn đang tư duy sai về việc tracking đối với các hệ thống batch job
Giả sử bạn có 100k job chạy một lúc, bạn phải tạo ra 100k threads để monitor?
Bạn cần phải để worker chủ động push log về storage, khi worker lấy task, thực thi task, hoàn thành task thì sẽ cần 1 node xử lý việc cập nhật state.
Bạn xem thêm các hệ thống batch job

via theNEXTvoz for iPhone

TTN_vOz said:

Mình dự rằng bạn đang tư duy sai về việc tracking đối với các hệ thống batch job
Giả sử bạn có 100k job chạy một lúc, bạn phải tạo ra 100k threads để monitor?
Bạn cần phải để worker chủ động push log về storage, khi worker lấy task, thực thi task, hoàn thành task thì sẽ cần 1 node xử lý việc cập nhật state.
Bạn xem thêm các hệ thống batch job

via theNEXTvoz for iPhone

Click to expand...

worker ý a nói đến ở đây có phải chính là các

TTN_vOz said:

Mình dự rằng bạn đang tư duy sai về việc tracking đối với các hệ thống batch job
Giả sử bạn có 100k job chạy một lúc, bạn phải tạo ra 100k threads để monitor?
Bạn cần phải để worker chủ động push log về storage, khi worker lấy task, thực thi task, hoàn thành task thì sẽ cần 1 node xử lý việc cập nhật state.
Bạn xem thêm các hệ thống batch job

via theNEXTvoz for iPhone

Click to expand...

Cũng ko hẳn là cần từng đấy thread bạn, nhưng thread có khả năng quản lý đồng thời nhiều job dưới server cùng lúc. Batch job ở đây là tầm 300-400 job spark chạy cùng lúc, mà job spark chạy dưới server thì nó ko cập nhật state của nó lên database được, nó chỉ có chức năng run task thôi bạn. Nên mới cần thread gọi API để làm việc đấy và cập nhật vào db. Thế mới đặt ra bài toán tracking state này

State đây chỉ là pending, running, done hay cần cả thêm số % nữa thế

ducgiang99 said:

worker ý a nói đến ở đây có phải chính là các

Cũng ko hẳn là cần từng đấy thread bạn, nhưng thread có khả năng quản lý đồng thời nhiều job dưới server cùng lúc. Batch job ở đây là tầm 300-400 job spark chạy cùng lúc, mà job spark chạy dưới server thì nó ko cập nhật state của nó lên database được, nó chỉ có chức năng run task thôi bạn. Nên mới cần thread gọi API để làm việc đấy và cập nhật vào db. Thế mới đặt ra bài toán tracking state này

Click to expand...

Vậy bạn tạo table lưu list job và trạng thái đi, xong viết 1 con cron job thỉnh thoảng cho nó gọi API spark của từng job để xem trạng thái của nó mới nhất là gì rồi update là xong mà, cái nào done rồi thì thôi ko gọi API nữa

Làm đi, xong cho chạy test, mới có số liệu mà test

Nếu job chạy từ "10p - vài tiếng" thì sao bác không đẩy vào Message Queue cho 1 service khác nó chạy Job, xử lý Job nào, đến đâu thì bắn Message xử lý job đấy? Sao cứ phải chạy bên dưới background và thực hiện gọi API liên tục làm gì nhỉ? Logic bác gọi API đấy có thể bỏ vào bên trong phần xử lý Job để bắn message được mà?

Làm lab test đi là biết bác.