Nếu bạn bạn làm việc với Rails thì chắc hẳn bạn đã nghe đến cụm từ "background job". Nhưng thực tế thì nó nghĩa là gì? Làm sao bạn biết được công việc (tasks) nào là phù hợp để sử dụng với tiến trình chạy ngầm (processed in the background). Một khi bạn xác định được công việc đó vậy làm sao để chọn background job framework phù hợp cho ứng dụng của bạn.

Trong bài viết này. Tôi sẽ giới thiệu tất cả những điều nói ở trên dưới đây. Bạn có thể so sánh và đói chiếu một vài background job framework phù hợp với bạn.

Background job là gì nào?

Chúng ta hãy bắt đầu với một số thuật ngữ. Một background hay asynchronout(bất đồng bộ) or (task) là một tiến trình bên ngoài những workflow request/response thông thường.và là một phần trong bất kì ứng dựng web hiện đại hiện nay. Thông thường ứng dụng web nhận một request từ bên ngoài (tư người dùng), tiến hành một số processing (như query đến database) và ngay lập tức trả một response trong vòng vài mili giây. Đó là mô hình thông thường mà chúng ta đã quen thuộc khi phát triển ứng dụng web và nó được gọi là phương thức đồng bộ (synchronous).

Mặt khác các công việc bất đồng bộ (asynchronous), Chúng bắt đầu từ những request web bình thường nhưng yêu cầu phải xử lý trong một thời gian dài. Chính vì vậy những request đó không thể thực hiện và trả về ngay lập tức. Chúng được biết đến là bất đồng bộ. Để không làm gián đoạn luồng dữ liệu trong tiến trình đồng bộ thông thường tại một ứng dụng, công việc bất đồng bộ (asynchronous tasks) là tiến trình xử lý trên một luồng riêng biệt hoặc được sinh ra như một quá trình tách biệt hoàn toàn.

Khi nào chúng ta sử dụng background job?

Để đơn giản chúng ta cùng đi đến ví dụ cụ thể để hiểu hơn về một background job. Hãy tưởng tượng bạn có một Customer Relationship Management (CRM) trong ứng dụng Rails. Những chi tiết thực tế của ứng dụng không quan trọng nhưng hãy tưởng tượng tính năng chính của ứng dụng là phải gửi email đến cho customers (khách hàng) khi có một đợt đặt hàng từ người dùng hay khi một người nào đó yêu cầu hỗ trợ.

Bạn có thể triên khai tính năng đó như sau: thực hiện ngay một hành động gửi email. Hành động đó không thể hoàn thành (một response không thể được trả về cho user) cho đến khi email đó được gửi. Việc làm đó sẽ làm việc tuy nhiên hãy xem vấn đề gì xảy ra:

1. Điều gì xảy ra nếu server email của bạn bị hỏng hoặc email không được xử lý?
2. Điều gì xảy gì nếu dịch vụ email của bạn bị hỏng và không nhận email trong thời gian đó?
3. Điều gi xảy ra nếu thư của khác hàng đầy và không chấp nhận bất kì email nào?

Tất cả những rủi ro trên thường xuyên xảy ra với một ứng dụng thực tế đã từng thiết kế. Tất cả điều trên có nghĩa là ứng dụng web của bạn sẽ bị chặn thay vì trả lại phản hồi tức thời cho người dùng. Người dùng thì không thích chờ đợi từng phút thậm chí là từng giây nào cho ứng dụng không hồi đạp ngay lập tức. Một request mất nhiều thơi gian có thể gây ra vấn đề về dung lượng của máy chủ ứng dụng, trì hoãn thời gian phản hồi cho các yêu cầu từ người dùng khác dẫn đến rủi ro chồng chéo. Background jobs là một cách để giải quyết vấn đề đó. Hãy tưởng tượng lại quá trình làm việc khi sử dụng một background jobs. Một email được gửi đi. Một schedules hay một queues EmailSendJob chứa tất cả các thông tin được yêu cầu như người nhận, chủ đề, nội dùng .... Ứng dụng của bạn có một queues(hàng đợi) các công việc trước khi chúng được xử lý. Điều này cho phép công việc được xử lý trên "Background Thread" và không ảnh hưởng đến công việc đồng bộ thông thường của ứng dụng của bạn. Một lợi ích của việc sử dụng background jobs là chúng ta có thể làm lại nó. Trong rủi ro phía trên, email có thể không được chuyển đi vì một lý do nào đó. Tại thời điểm nào đó, server mail của bạn hoạt động trở lại hay customer clear hộp thư của họ và email có khả năng gửi thành công. Asynchronous jobs cho phép bạn gửi lại sau khoảng thời gian nào đó.

Framework nào bạn nên sử dụng?

Hy vọng rằng bây giờ bạn thấy làm thế nào để bạn có thể sử dung một background job framework cho ứng dụng. Nhưng bạn nên chọn cái nào?? Giống như không có một ngôn ngữ lập trình nào có thể giải quyết mọi vấn đề của mọi người. điều đó có nghĩa không có framework nào là hoàn hảo nhất. Tất cả chỉ là bạn chọn cái nào phù hợp cho việc sử dụng của bạn.

Delayed::Job

Delayed::job là một background job framework của Ruby. Delayed::Joc làm việc bằng cách duy trì một bảng job trong cơ sở dữ liệu để theo dõi các nhiện vụ và vị trí của nó trong vòng đời công việc. (theo lịch trình, chạy, hoàn thanh hay thất bại ...). Nó dễ dàng tích hợp và Rails và ActiveRecod.

Daylayedjob rất ổn định có thể quanh năm. Sự thật rằng nó giúp Shopify chạy các sản phẩm cốt lõi của nó bằng cách xử lý các tác vụ như thay đổi kích thước hình ảnh, gửi bản tin, cập nhật tìm kiếm làm cho nó thâm chí còn nhiều hơn một đối thử theo ý kiến của tôi. Trong trường hợp hệ thống gặp sự cố, Delayed:Job có thể khởi động lại miễn là công việc đã được duy trì thành công trong database. Đây có thể là một lợi ích to lớn khi làm việc trong một hệ thống phân phối. Nhược điểm là sử dụng database phụ thuộc vào chính nó. Nếu bảng jobs của bạn nằm trong cùng một database nó có thể gây xung đột và gây ra xử lý lượng lớn các hàng đợi. Database càng dễ trở thành nút cổ chai của ứng dụng càng nhiều khi phụ thuộc vào nó.

Sidekiq

Sidekiq là một background job Ruby nổi tiếng nhất vì độ tin cậy và hiệu năng của nó. Sidekiq hỗ trợ bở Redis, một bộ lưu trữ dữ liệu trong bộ nhớ cực kỳ phổ biến cung cấp nhiều ứng dụng web phổ biến hiện nay. Redis giống như một cơ sở dữ liệu chạy trên một tiến trình riêng biệt và thường xuyên so với máy chủ của bạn. Lợi ích chính của Redis là tốc độ bởi vì nó hoàn toàn trong bộ nhớ tạo và truy xuất dữ liệu rất nhanh.

Những vấn đề cần xem xét.

Chúng ta phải xem xét khi chọn một background jobs

1. Bạn cần giải quyết rủi ro của công việc của bạn như thế nào?
2. Có bao nhiêu phụ thuộc bạn có thể thêm vào hệ thống?
3. Bạn cần bao nhiêu hộ trợ trong tương lai?
4. Bạn quan tâm đến việc chia sẻ tài nguyên với ứng dung hiện tại của bạn như thế nào?
5. Bạn yêu cầu như thế nào với sự ổn định của API?
6. Bạn cần tính năng nâng cao như giới hạn tốc độ, batching ...?

Bài viết còn nhiều thiếu xót. Các bạn có thể tham khảo bài gốc ở đây. http://blog.scoutapp.com/articles/2016/02/16/which-ruby-background-job-framework-is-right-for-you