Jak najlepiej ograniczyć masową wysyłkę maili?

Cześć, chciałbym poznać Waszą opinię jak najlepiej podejść do następującego problemu :) Otóż mam skonfigurowane połączenie z gmailowym serwerem smtp, limit dzienny wynosi 2000 wiadomości. Tak wyszło, że ktoś zmienił konfigurację, nikt nie został poinformowany, na prodzie maile przestały się wysyłać i na bazie odłożyło się ich około 5000. Job cronowy do wysyłki maili jest odpalany co 15min i zaciąga on wszystkie maile ze statusem 'CREATED' a następnie kilka workerów je wysyła. I tu moje pytanie - co zrobić aby tego limitu teraz nie przekroczyć? Sytuacja, że 2000 maili pójdzie a później logi zapchane wyjątkami odpada ;p

1.) Ograniczyć pobieranie maili do 20 przy każdym wywołaniu joba? (limit 2000 maili, 80 maili na godzinę co da nam 1920 podczas 24h)
2.) Czy może nie ingerować w pobieranie maili tylko napisać jakiś mechanizm, który by pilnował dziennego limitu?
3.) ?????

@kkojot: myślałem nad kolejką (niekoniecznie nad całym systemem kolejkowania, tutaj jeszcze trzeba by było z biznesem to przegadać) jako właśnie podpunkt 2. Tylko jak miałoby to wyglądać? Ładuję te maksymalnie 2000 wiadomości do kolejki i co 15min ściągam z niej 20 kolejnych wiadomości do wysłania?

Może wystarczy zapiąć metrykę i czujkę. Jak chcesz twardy limit, to potrzebujesz po prostu jakiś licznik, który atomowo sprawdzasz i podbijasz. Oczywiście wpłynie to negatywnie na wydajność, bo będziesz musiał za każdym razem blokować się na sprawdzeniu licznika.

Zastanowiłbym się jednak jaka jest pierwotna potrzeba :)

Potrzeba jest taka, że trzeba szybko fixa walnąć na proda :D Też myślałem nad jakimś AtomicIntegerem i inkrementacji oraz dekrementacji o odpowiednią ilość, wyliczaną na podstawie okresu aczkolwiek tak jak wspomniałeś jest to raczej nieoptymalne :P Chciałem po prostu wymyślić jakiś sposób, który by chronił przed przekroczeniem limitu i walnął jakiegoś loga. Pewnie pójdziemy za opcją pierwszą bo wydaje się być najszybsza do zaimplementowania aczkolwiek chciałem poznać inne sposoby rozwiązania tego problemu tak aby uniezależnić się od fetchowania określonej ilości danych z bazy

A co się dzieje po przekroczeniu 2000 maili? Gmail zwraca błąd? Blokuje konto?
Bardzo dawno temu używałem rabbita (puszczałem przez niego na bramkę SMS), ale generalnie to wrzuciłbym wszystko na kolejkę, gmail jest consumerem i dopóki idzie to idzie, jak consumer zwraca błąd to robisz retry co np 15 minut. Taka kolejka może przetrwać także restart servera, wiec masz pewność ze maila pójdą.

Charles_Ray napisał(a):

Może wystarczy zapiąć metrykę i czujkę. Jak chcesz twardy limit, to potrzebujesz po prostu jakiś licznik, który atomowo sprawdzasz i podbijasz. Oczywiście wpłynie to negatywnie na wydajność, bo będziesz musiał za każdym razem blokować się na sprawdzeniu licznika.

No ale między "masowa wysyłka" a 2000 na dobę jest różnica i to dość znacząca. Dwa tysiące maili na dobę daje poniżej 100 na godzinę. Jeżeli jakiś serwer pocztowy taka ilość przerasta, albo dla jakiegoś serwera SQL problemem będzie 100 razy na godzinę zwiększenie licznika wysłanych wiadomości, to raczej nie wysyłka maili będzie tutaj kłopotem. Nawet jakby przyjąć, że ten limit jest limitem na dzień roboczy (np. 8-16) to zrobi się kilkaset wysyłek na godzinę. Nadal są to śmieszne wartości.

Rozumiem, że potrzebujesz na szybko ogarnąć, to co masz, czy rozwiązanie na lata? Jak to, co masz, to zmień w kolejce status z CREATED na coś w rodzaju SUSPENDED i tylko dl 2000 najstarszych zostaw CREATED i tak do wyczerpania kolejki przez 3 dni. Chyba ze ci szybciej przyrasta tych maili wiecej niż 2000 na dziń - bo to wtedy nie da się rozwiązać. Zawsze możesz numerować maile wysłane danego dnia (nie wiem, jak to Google liczy - na dzień, na 24 h, kiedy się licznik resetuje) i po przekroczeniu 2000 zaprzestać wysyłki i poczekać na przejście daty przez punkt zero i zresetowaniu licznika. Jak serwer zwraca jakiś konkretny błąd z informacją o przekroczeniu, licznika możesz zrobić coś w rdozaju czeka, który będzie sprawdzał jakimś mailem testowym, czy dalej możesz wysyłać maile i ustawiał odpowiednią flagę. To zabezpieczenie zadziała również, jak Google zmieni limity. No i twój wysyłacz maili nie powinien brać całej bazy na raz tylko np po 100.

Teraz na szybko ale przy kolejnym release chciałbym już wgrać takie eleganckie rozwiązanie ;p

Chyba ze ci szybciej przyrasta tych maili wiecej niż 2000 na dziń

Nieee ;p W momencie zgłoszenia incydentu minęło ok 5-6 dni od pierwszego faila, więc można przyjąć, że dziennie <= 1000 maili. Z tym checkiem ciekawy pomysł :)

Ja może nie do końca rozumiem, ale opcja tymczasowa zaproponowana przez @Tomek Pycia wydaje się być ok. A finalnie to chyba nie tu szukaj problemu. Problemem jest raczej serwer i jego ograniczenia jak pisał @cerrato . Nie wiem co tam w tych mailach jest, ale zakładam, że opóźnienie w wysyłce o 3 czy 5 dni może skutkować np. wysłaniem informacji o już wygasłej 24 godzinnej promocji. Jak zrobisz jakieś kolejki dzienne to okaże się, że ktoś wrzuci 10 tys. mail i do ostatniego adresata trafią po 5 dniach ( przy 2 tys. dziennie). W skrajnym przypadku takie opóźnienie będzie tylko narastać jeśli ilość maili do wysłania wzrośnie ponad limit dzienny.

To są maile w głównej mierze potwierdzające wykonanie kluczowych czynności w systemie np. zamknięcie programu badań, dodanie nowego obszaru badań itp. Biznes chciał aby te wiadomości zostały do nich wysłane, wcześniej pewnie walniemy do tych użytkowników wiadomość z informacją, że niektórzy mogą nagle oberwać 40 wiadomościami.

Skoq napisał(a):

To są maile w głównej mierze potwierdzające wykonanie kluczowych czynności w systemie np. zamknięcie programu badań, dodanie nowego obszaru badań itp. Biznes chciał aby te wiadomości zostały do nich wysłane, wcześniej pewnie walniemy do tych użytkowników wiadomość z informacją, że niektórzy mogą nagle oberwać 40 wiadomościami.

Może zasugerować w zespole wprowadzenie bulk maili? W sensie że zamiast wielu maili do jednego usera, jeden zbiorczy

Może zasugerować w zespole wprowadzenie bulk maili? W sensie że zamiast wielu maili do jednego usera, jeden zbiorczy

Dzięki, to może się przydać :)