Нужен совет по поводу обработки большого количества почты

← →
Игорь Шевченко © (2016-03-23 11:17) [40]

Sha © (23.03.16 11:03) [39]

Я бы все-таки предпочел более простое решение. Почему: Хранить что-то в файловой системе я не могу, потому что проблемы с репликацией. Хранить в базе данных такую информацию как-то пока непонятно, за какую глубину.

Чем мне мое решение кажется проще - подключился к серверу, забрал письма, проверил, обработал, нужное удалил. Все просто и ясно. Если сломается, то рискуем одним письмом максимум (сломались на удалении, письмо будет прочитано и обработано еще раз).
Я почему в начале обратился к сообществу пнуть в плане протокола или еще чего - мне не очень нравится переделывать архитектуру, она учитывает много нюансов, которые не всегда возможно описать. Поэтому архитектуру я бы по максимуму хотел сохранить, а это значит, никаких дополнительных хранилищ и т.п.

← →
Sha © (2016-03-23 11:29) [41]

> Хранить что-то в файловой системе я не могу, потому что проблемы с репликацией.

Непонятно. Почему список Id+State нельзя положить в ФС?

> Хранить в базе данных такую информацию как-то пока непонятно, за какую глубину.

Это не вопрос.
Все Id, которых нет на почтовом сервере должны сразу удаляться из базы.

← →
Игорь Шевченко © (2016-03-23 13:03) [42]

Sha © (23.03.16 11:29) [41]

Потому что в файловую систему для постоянного хранения нельзя положить ничего.

← →
DayGaykin © (2016-03-23 13:57) [43]

Еще вариант - по одному письму обрабатывать не отключаясь.
Делаем LIST, затем RETR 1, обработали, DELE 1, затем RETR 2, ... . Обработали всё, отключаемся.
Если сервер в случае разрыва соединения откатывает изменения (этого я не знаю), то раз во сколько-нибудь писем переподключаться.

Можно передачу данных сделать в отельном потоке, а в основном обрабатывать письма.
Отдельный поток примерно так работает:
1. RETR 1
2. Отправили 1 на обработку основному потоку.
3. RETR 2
4. Ждем, когда основной поток обработает предыдущее письмо. Ждем, когда POP3 сервер вернет письмо 2.
5. Отправляем 2 на обработку основному потоку.
6. DELE 1
7. RETR 3
И так далее с 4ого пункта, пока письма не кончатся.
Если обработка письма осуществляется дольше, чем выборка из pop3 сервера, то простоев не будет.
Если обработка письма осуществляется намного больше, то этот алгоритм можно доработать до многопоточной обработки.

В случае сбоя есть риск обработать несколько писем несколько раз. Как я понял - это не критично.

← →
Владислав © (2016-03-23 15:11) [44]

DayGaykin © (23.03.16 13:57) [43]

Если после каждого письма ждать, то какой смысл в нескольких потоках?

Игорь же говорит как раз о том, что обработка асинхронная. Кроме всего прочего, прикладных обработчиков писем много, потоков выполнения тоже много.

← →
Игорь Шевченко © (2016-03-23 15:36) [45]

DayGaykin © (23.03.16 13:57) [43]

> В случае сбоя есть риск обработать несколько писем несколько
> раз. Как я понял - это не критично.

Критично. Я бы посоветовал почитать все мои посты. Я в одном не могу описать все нюансы.

> Можно передачу данных сделать в отельном потоке, а в основном
> обрабатывать письма.

Еще раз советую почитать - обработкой и валидацией занимаются внешние процессы.

Процесс, скорость работы которого в ряде случае меня не устраивает, занимается по сути только сортировкой писем на хорошие и плохие. Хороших 95%.
При этом он должен не терять письма в случае сбоев и повторных перезапусков и не отправлять письма на обработку повторно.

← →
Сергей Суровцев © (2016-03-23 16:47) [46]

>Игорь Шевченко © (23.03.16 10:36) [38]

Если Да, то может сделать так же удаление блоком, как и забирается? Накопился блок в 100 писем на удаление, подключаемся и удаляем все сразу.
Тут еще надо анализировать скорость работы по участкам системы. То есть взять, к примеру час или сутки, или другой промежуток, главное чтобы он отражал правильную усредненную картину и проверить сколько за это время
1) поступило
2) сколько ушло на обработку
3) сколько вернулось с обработки с пометкой "можно удалить".
4) сколько реально удалено

Если 3 < 1, копать надо не удаление, а обработку. Если 3 ~= 1, но > 4, то реально копать удаление.
Если удаляется меньше, чем приходит, то проблема будет только усугубляться с каждой итерацией- список писем растет, удаляется в нем еще медленнее. В идеале этот список вообще не должен разрастаться больше 100 ( размера забираемого блока ).

← →
Игорь Шевченко © (2016-03-23 17:52) [47]

Сергей Суровцев © (23.03.16 16:47) [46]

Я бы посоветовал прочитать еще раз мои посты. Я НЕ МОГУ УДАЛЯТЬ БЛОКОМ, ЕСЛИ ПРОИЗОЙДЕТ СБОЙ, ТО Я ЭТОТ БЛОК ПОТЕРЯЮ

← →
Сергей Суровцев © (2016-03-23 18:27) [48]

>Игорь Шевченко © (23.03.16 17:52) [47]

Что именно ты потеряешь?
Список из 50-10 писем, которые УЖЕ надо удалить, ибо они уже ранее успешно обработаны? То есть в худшем случае они пойдут на обработку повторно.

Какова вероятность сбоя?
Теоретическая и реальная, ибо система уже ведь работает, статистика есть.

То есть соотношение будет, думаю, приметно таково, что на несколько десятков миллионов писем будет повторный посыл 50-100 на обработку, но пропущено не будет ни одно.

И еще раз про пункт 3) это в первую очередь нужно проверять, возможно собака зарыта там, а не в 4).

← →
Игорь Шевченко © (2016-03-23 21:33) [49]

Сергей Суровцев © (23.03.16 18:27) [48]

"мне не очень нравится переделывать архитектуру, она учитывает много нюансов, которые не всегда возможно описать. Поэтому архитектуру я бы по максимуму хотел сохранить, а это значит, никаких дополнительных хранилищ и т.п.
"

> Список из 50-10 писем, которые УЖЕ надо удалить, ибо они
> уже ранее успешно обработаны? То есть в худшем случае они
> пойдут на обработку повторно.

Как ты думаешь, если повторно будет запущено на обработку снятие с твоего счета денег, это будет какой случай ?

← →
Владислав © (2016-03-23 22:06) [50]

Внезапно, в качестве бреда (или мозгового штурма). :) Собственный промежуточный сервер (возможно, с расширенным набором команд), в котором реализовано отложенное удаление писем.

DVM © (23.03.16 22:49) [51]

Нет. Но сервер может быть разный, в том числе и этот. Мне бы хотелось услышать решение (если есть), не зависящее от возможностей конкретного сервера. Впрочем, если есть какой-то сервер, который гарантировано будет быстро работать, это тоже интересно и может послужить канвой для рекомендаций. Но это уже не моя область.

> Игорь Шевченко © (23.03.16 23:02) [52]

Extended MAPI в связке с Exchange на мой взгляд - очень удобное решение для манипулирования большими количествами писем. Кроме всего прочего сервер сам уведомляет о новых письмах.

подобное сделал так
программа все письма обрабатывает и удаляет, пересылая валидные на другой ящик. Другая программа с другого ящика парсит и данные складывет куда надо, письма с "хорошими данными" пересылает на третий. Что уже не обязательно, в общем-то, но для разбора полетов пригодится

А.. валидных 95%..
у меня наоборот )

Нужен совет по поводу обработки большого количества почты Найти похожие ветки