Home » Scala » Bài toán tối ưu performance và memory cùng với Akka (Phần I)

Bài toán tối ưu performance và memory cùng với Akka (Phần I)

Đây là bài toán thực tế trong project của mình

Có lẽ cũng nhiều bạn cũng đã gặp trường hợp tương tự

Có khi chúng ta thường tặc lưỡi bỏ qua, hay đổ tội cho “con server”,.. but NOT TODAY


Problem


(đã được lược giản cho phù hợp)

1 con batch chạy hàng ngày để crawl dữ liệu rồi insert vào Database

Đây là data lược giản khi crawl


Code hiện tại của batch


Điểm qua các vấn để của code hiện tại:

  • Blocking code
  • Chỉ sử dụng 1 Thread
  • Không có cơ chế khi Failure

=> Performance thấp, không tận dụng được tài nguyên của server, độ ổn định không cao

Và quan trọng nhất là số lượng accounts sắp tới sẽ tăng lên gấp nhiều lần…

Solution


Akka — Chiếc Ferrari 812 động cơ V12


Nhưng tại sao….?

  • Akka dựa trên Actor model cung cấp cơ chế xử lý trên Multi-thread với bộ sậu Actor, Dispatcher, Routing, Mailboxes,… mà không cần quan tâm đến các vấn đề thường gặp khi xử lý Multi-thread
  • A clustered, high-availability architecture

Đây là cách Akka hoạt động:


First design



Let The Code Speak For Itself


Kết quả


  • Tất cả đều là non-blocking code, xử lý liên tục mà không cần đoạn trên hoàn thành
  • Tận dụng tối đa tài nguyên server, Dispatcher sẽ phân các actor vào từng thread, càng thêm CPU càng nhanh
  • Dễ dàng điều chỉnh số lượng actor
  • Code decoupling, mỗi Actor gói gọn 1 business

Nhược điểm


Tuy nhiên, với design này lộ ra 1 nhược điểm: out of memory

Tưởng tượng cứ như việc tắc đường ở hiện tượng thắt cổ chai:


Lý do bởi vì Actor xử lý message thông của Mailbox của chính nó một cách tuần tự.

Account process xử lý rất nhanh do không có IO process, nó đổ messages liên tục vào Mailbox của Campaign Actor, tượng tự với Campaign actor đổ messages vào mailbox của Keyword actor. Mà không cần quan tâm process sau mình đang xử lý ở tốc độ nào.

Với việc Mailbox tăng nhanh, mà actor ở process đấy có hạn(đang busy xử lý) => memory dùng cho Mailboxs tăng cao một cách không cần thiết.

Cũng như con đường 5 làn oto đổ vào con đường chỉ chịu được 2 làn oto! Cuối con đường thì chỉ có từng ấy oto ra được mà thôi!

Vậy thì sao nhỉ?


Đây là bài toán cân băng về performance và memory giữa Publisher và Subscriber

  • bao nhiêu subscriber là đủ?
  • Publisher push data với rate cao hơn Subscriber có thể process thì sao?
  • Publisher push data với rate thấp hơn Subscriber có thể process thì sao?

Có 2 cách xử lý trong trường hợp này

  • Work pulling pattern
  • Akka streams

Trong phần tiếp theo mình sẽ phân tích 2 cách làm trên và cách project mình implement như nào!!!

Tagged width:, , ,