Thiết kế 1 hệ thống gửi mail sao cho hiệu quả ? - Page 2 - vozForums
vozForums
Go Back   vozForums > Học tập và công việc > Ngành CNTT > Phát triển Phần mềm
Reply
 
Thread Tools
  #11  
Old 01-10-2015, 15:36
Robin Phan Persie Robin Phan Persie is offline
Senior Member
 
Join Date: 05-2013
Posts: 207

Quote:
Originally Posted by RPG29 View Post
Dùng message queue như RabbitMQ, Gearman... etc làm middle để dispatch job cho worker. Trên frontend cứ push message vào queue, việc còn lại queue nó sẽ tự dispatch cái message đó cho con worker nào rảnh
+1

Quote:
Originally Posted by catchimthangnaobantao View Post
mình hình dung ý bạn như sau:
Khi user đăng ký thành công thì mình sẽ viết code push cái message vào queue của Rabit (giả sử message chứa thông tin email của user), còn việc thật hiện hàm SendMail() thì nó nằm ở worker hả bạn ? Worker có phải là 1 app riêng không, nếu đúng vậy tức là có 2 app ( 1 cái web, 1 cái worker). Mình hiểu như vậy có đúng không bạn ?
Win thì có sẵn MSMQ, không thích dùng thì tự đẩy vào db của bạn mà xử lý. Worker thì dùng windows service, lấy thông tin từ queu rồi xử lý SendMail(). Mình nghĩ đăng ký thì cùng 1 thời điểm xử lý không nhiều, thời gian xử lý SendMail() cũng không lâu nên có thể chưa cần quan tâm tới processes và threads. Nếu bài toán của bạn cần xử lý nhiều và nhanh (VD cùng lúc gửi mail cho 100000 thằng) thì cần tính toán hơn. Windows service mình cũng không được chuyên sâu, nhưng ngày trước team mình làm thì buộc phải dùng timer để quét db => không real-time + lãng phí tài nguyên hệ thống

// Còn khi minhf xử lý thì mình dùng webservice, khi nào db của mình có dữ liệu mới nó tự gọi thằng webservice, có vẻ real-time hơn

Last edited by Robin Phan Persie; 01-10-2015 at 15:45.
Reply With Quote
  #12  
Old 01-10-2015, 16:06
bi ban lien tuc bi ban lien tuc is offline
K.I.A
 
Join Date: 06-2013
Posts: 352

web service ko ngon bằng cái queue ở trên, vì gọi nhiều mà ko xử lý hết được (như gửi email là lâu) thì ko chết cũng bị timeout. mỗi lần gọi webservice thì server lại cho request vào thread để xử lý nhỉ.
Reply With Quote
  #13  
Old 05-10-2015, 16:45
Robin Phan Persie Robin Phan Persie is offline
Senior Member
 
Join Date: 05-2013
Posts: 207

Sao lại gọi nhiều hả bạn!? Vì mỗi lần insert vào queu là 1 lần xử lý gần như tức thì rồi, nên queu hiếm khi nào tồn tại tới 2 bản ghi. Hơn nữa bài toán này xử lý dữ liệu đồng thời không nhiều nên chơi webservice được.

Còn vì mình gà nên không biết cách đẩy sự kiện insert cho thằng window service chạy, nên ngoài nghĩ tới timer để tự quét db ra mình không nghĩ được cách nào cả
Reply With Quote
  #14  
Old 05-10-2015, 23:03
fire_water fire_water is offline
Senior Member
 
Join Date: 01-2010
Posts: 495

Ôi vãi queue =))
Reply With Quote
Đang tải...
  #15  
Old 05-10-2015, 23:13
Robin Phan Persie Robin Phan Persie is offline
Senior Member
 
Join Date: 05-2013
Posts: 207

Quote:
Originally Posted by fire_water View Post
Ôi vãi queue =))
Chi tiết hơn đi để mình còn có hướng học tập. Đợt vừa rồi sợ không control được websocket nên dự án đấy phải chơi ws 2 chiều

Còn bài toán này mình nghĩ cho vào queu cũng được, để còn xử lý lại những thằng fail. Để nó chạy độc lập hẳn, khỏi chỉnh sửa động chạm những cái đang chạy ngon lành, dự án đang chạy ngon lành mà thêm nếm chỉnh sửa là không khoái
Reply With Quote
  #16  
Old 05-10-2015, 23:20
fire_water fire_water is offline
Senior Member
 
Join Date: 01-2010
Posts: 495

Quote:
Originally Posted by Robin Phan Persie View Post
Chi tiết hơn đi để mình còn có hướng học tập. Đợt vừa rồi sợ không control được websocket nên dự án đấy phải chơi ws 2 chiều

Còn bài toán này mình nghĩ cho vào queu cũng được, để còn xử lý lại những thằng fail. Để nó chạy độc lập hẳn, khỏi chỉnh sửa động chạm những cái đang chạy ngon lành, dự án đang chạy ngon lành mà thêm nếm chỉnh sửa là không khoái
Bản chất queue cũng chỉ là cái hàng đợi, cứ push vào 1 đầu rồi pop từ đầu còn lại. Tùy vào queue implementation thì nó xử lý khác nhau trong các tình huống khác nhau. Ví dụ queue đầy thì có thằng hang lại, đợi khi queue ko còn đầy nữa thì cho push tiếp vào, có thằng thì lại refuse luôn... Nên thực tế số lượng item trong queue thì hên xui, tùy vào hệ thống nữa.
Reply With Quote
  #17  
Old 05-10-2015, 23:31
kendynguyen113 kendynguyen113 is offline
Junior Member
 
Join Date: 04-2012
Posts: 23

Up ip up up up
Reply With Quote
  #18  
Old 06-10-2015, 08:28
Robin Phan Persie Robin Phan Persie is offline
Senior Member
 
Join Date: 05-2013
Posts: 207

Quote:
Originally Posted by fire_water View Post
Bản chất queue cũng chỉ là cái hàng đợi, cứ push vào 1 đầu rồi pop từ đầu còn lại. Tùy vào queue implementation thì nó xử lý khác nhau trong các tình huống khác nhau. Ví dụ queue đầy thì có thằng hang lại, đợi khi queue ko còn đầy nữa thì cho push tiếp vào, có thằng thì lại refuse luôn... Nên thực tế số lượng item trong queue thì hên xui, tùy vào hệ thống nữa.
Đúng vậy, nhưng áp dụng vào bài toán này thì thế nào? Không ổn ở chỗ nào hay có cách nào ổn hơn vậy? Mình nhớ là các diễn đàn có tính năng này tự động, tùy mình kích hoạt, nhưng cũng chưa bao giờ thử mò xem cách nó xử lý thế nào (mà khả năng xử lý của nó cũng chỉ gửi được 80% mail chính xác thì phải, 20% còn lại là tạch)
Reply With Quote
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump

All times are GMT +7. The time now is 08:03.
Chịu trách nhiệm nội dung: Bạch Thành Trung © 2019 Công ty TNHH Thật Vi Diệu
ĐC tầng 4, số 6-8 Đường D2, Bình Thạnh, Hồ Chí Minh, Việt Nam - SĐT 0981323799 - MST 0313906593
Giấy phép thiết lập MXH số 334/GP-BTTTT, Ký ngày: 19/08/2019