Комментарии 6
Странно, что к вашим статьям так мало комментариев.
Во многих их нет вообще. Пожалуй, оживлю немного ситуацию, хоть это и некрофильство.
В ходе прочтения вашего цикла статей у меня возник вопрос: вы говорите, что IO-агент из предыдущих статей является stage-агентом, потому как он занимается только IO операциями. Следуя этой логике можно было бы заметить, что остальные агенты, для обработки частей email'а тоже занимаются только своим делом. Но почему же тогда они не являются stage-агентами?
Во многих их нет вообще. Пожалуй, оживлю немного ситуацию, хоть это и некрофильство.
В ходе прочтения вашего цикла статей у меня возник вопрос: вы говорите, что IO-агент из предыдущих статей является stage-агентом, потому как он занимается только IO операциями. Следуя этой логике можно было бы заметить, что остальные агенты, для обработки частей email'а тоже занимаются только своим делом. Но почему же тогда они не являются stage-агентами?
Странно, что к вашим статьям так мало комментариев.Видимо, скучные и не формат.
Но почему же тогда они не являются stage-агентами?Если я правильно понимаю staging из SEDA, то stage-компонент (агент) выполняет одну и ту же операцию для разных транзакций. Соответственно, stage-компонент живет дольше, чем одна конкретная транзакция.
У меня же в предыдущей статье агенты вроде email_headers_checker и email_body_checker выполняют всего одну операцию всего для одной транзакции. Соответственно, когда конкретный агент email_headers_checker свою работу для своей транзакции завершает, он уничтожается, а эту же операцию для другой транзакции будет делать другой экземпляр email_header_checker.
Если бы email_header_checker был stage-агентом, он бы выполнял свою операцию для разных транзакций и не исчезал бы после обслуживания очередной транзакции.
Наоборот, статьи довольно интересные. Затрагиваются реальные проблемы, доходчиво объясняются их причины и решения на итерационных примерах улучшения кода. Это очень круто и почитать статьи интересно даже в отрыве от SObjectizer. Хочется надеяться, что комментариев нет только потому, что людям нечего добавить, а просто писать «спасибо за статью» на хабре не принято. :)
Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни. Эдакий синглтон.
Теперь стало понятнее. Спасибо за пояснение!
Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни. Эдакий синглтон.
Теперь стало понятнее. Спасибо за пояснение!
Наоборот, статьи довольно интересные.Если хоть кому-то нравится, то значит не напрасно все было. Мы, кстати, открыты: есть интересно о чем-то еще узнать, то скажите о чем, постараемся выбрать время и рассказать.
Итого, выходит что разница между обычным агентом и stage-агентам только во времени жизни.На самом деле не только. Разница в сроке жизни это уже следствие. Принципиальный момент в том, что stage-агент должен уметь обрабатывать операции сразу для N транзакций. Это усложняет его реализацию.
Ведь если email_body_checker проверяет только одно тело сообщения, то его реализация будет достаточно простой. А вот если он может _одновременно_ проверять сразу несколько сообщений, то это уже совсем другое дело.
Хотя email_body_checker — это не самый хороший здесь пример. Можно взять пример агента, который что-то с СУБД делает. Например, пусть в каждом email-е есть уникальный message-id и нам нужно сохранять эти message-id в БД для истории. Если агент message_id_saver рассчитан только на один email, то у него все просто: ему дали message-id, он получил коннект к БД, выполнил сохранение, отчитался о выполнении.
Но если мы будем создавать сразу 100500 таких простых message_id_saver, то наша работа не будет хорошо масштабироваться. Т.к. все эти агенты будут конкурировать за доступ к БД. И выполнять сохранение данных в БД построчно, что так же не эффективно.
А вот если мы сделаем stage-агента mass_message_id_saver, который может принять кучу message-id и все их вставить в БД одной bulk-операцией, то масштабирование у нас будет лучше. Но сама логика mass_message_id_saver станет сложнее, т.к. он должен быть накапливать у себя группу message-id, затем делать bulk-операцию, затем должен уметь обрабатывать негативные результаты buld-операции (например, что делать если из M message-id один все-таки оказался неуникальным?), должен уметь раздавать результаты разным агентам-инициаторам и т.д. и т.п.
В итоге получается, что каждый stage-агент оказывается заметно сложнее, чем простые агенты вроде email_body_checker. Но приложение из stage-агентов собрать проще и следить за ним проще, чем в случае кучи простых мелких агентов.
Эдакий синглтон.На самом деле для балансировки нагрузки можно сделать сразу несколько однотипных stage-агентов для одной и той же операции. Но это уже совсем другая история ;)
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Из опыта использования SObjectizer: акторы в виде конечных автоматов – это плохо или хорошо?