Сегментов на текущий момент около 2000 разных(пользователь одновременно находится в нескольких из них, но не во всех). Если хотите удалиться из сегментов -можете например пройти по этой: exebid.ru/optout.html ссылке.

dgstudio Jun 22 2015 at 16:50

Респект! Я делал похожую штуку, на несколько ином наборе инструментов.
Если позволите, несколько вопросов :)

— какой у вас роутинг в раббите? (директ, топик, фанаут?)
— как оно переживает деплой новой версии программного кода?
— что происходит в системе, если актор не справляется с обработкой сообщения и падает?
— данные о пользователях отдаются по явному запросу, или доставляются потребителям так же через очереди?

asash Jun 22 2015 at 17:04

— какой у вас роутинг в раббите? (директ, топик, фанаут?)
для этой системы мы не используем routing, все dispatchers читают из одной очереди
— как оно переживает деплой новой версии программного кода?
хорошо переживает :) мы не пробовали запускать несколько нод с разными версиями акки, а наш внутренний протокол мы делаем обратно совместимым
— что происходит в системе, если актор не справляется с обработкой сообщения и падает?
у акки есть механизм supervisors, в самом простейшем случае этот актор будет перезапущен(но есть варианты)

xbsd Jun 22 2015 at 17:32

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

meln1k Jun 22 2015 at 17:33

Рассматривали ли вы использование akka streams?

grossws Jun 22 2015 at 17:47

Они ж пока в rc

xbsd Jun 22 2015 at 17:48

нет, да и вроде как akka streams еще не стабильны

Manowar Jun 22 2015 at 18:13

А почему не подошел Spark Streaming? Как минимум есть два преимущества:
— готовая инфраструктура во всяких облаках
— нет потерь данных при фейлах из коробки (в akke надо делать руками persistent actors)

Тем более что вы сами ссылку на него даете.

asash Jun 22 2015 at 18:19

Мы были уверены что при помощи akka можно решить бизнес-задачу и умеем ею пользоваться. О спарке слышали(и проверили на собственном опыте) много отзывов насчет его глючности.

xbsd Jun 22 2015 at 18:54

Изначальная идея была взята из research.microsoft.com/en-us/projects/orleans, ну и да, акку мы тогда уже умели готовить :)

возможно в будущем посмотрим на возможность переезда на spark streaming, благо кода получилось не очень много

ImLiar Jun 22 2015 at 21:30

А что скажете про apache storm?

asash Jun 22 2015 at 22:13

Storm тоже хорошая система. Пробовал его на предыдущем месте работы, вполне себе работало. В общем вполне можно промышленные системы строить и на нем тоже, тут скорее дело вкуса. Нам понравилась именно идеалогия акторов, которая подходит не только для потоковой обработки данных, но и вообще для широкого класса задач распределенных систем.

rzykov Jun 23 2015 at 09:38

Да, Spark нужно уметь готовить. Не у многих компаний он в production работает, хотя с версии 1.1.1 все стало хорошо.

vvsh Jun 23 2015 at 01:48

Почему используется RabbitMQ, а не, например, Apache Kafka?

Ivanhoe Jun 23 2015 at 02:19

Проще в эксплуатации?

vvsh Jun 23 2015 at 09:39

Тут скорее дело в производительности, бенчмарк.

Ivanhoe Jun 23 2015 at 11:25

Нет, я имел в виду, что кролик проще в эксплуатации :)

vvsh Jun 23 2015 at 12:14

Возможно, в kafka приходится работать c offset'ами и partition'ами, но, например, для spark есть модуль spark-streaming-kafka, к хорошим API (в ввиде RDD).

xbsd Jun 23 2015 at 12:11

Кролик у нас уже был, а разворачивать в проде еще одну новую систему — это гарантированные грабли. Задача была как можно быстрее это запустить.

На текущий момент кролик вполне справляется с нагрузкой. Как только перестанет — посмотрим на kafkу.

vvsh Jun 23 2015 at 12:17

Это скорее вариант на будущее).

Kane Jun 23 2015 at 10:46

Использова ли вы akka-persistance?

afiskon Jun 23 2015 at 11:07

Да зачем он им там?

afiskon Jun 23 2015 at 11:19

Большое спасибо за интересную статью! Пользуясь случаем хотелось бы оставить для заинтересованных читателей ссылку на серию из трех статей об Akka Cluster.

Также, если позволите, несколько вопросов:

Как вы решили проблему обратной совместимости сообщений между разными версиями приложения и Akka?
Kryo или не Kryo? Kamon или не Kamon?
Не в облаках ли вы хоститесь? Не возникает ли у вас проблемы, что кластер время от времени разваливается и нужно поднимать его руками? В AWS такое иногда случается.
При падении одной машины остальной кластер детектит это не сразу. В результате акторы продолжают долбиться на упавшую машину, получать ask timeout'ы, вот это все. Из-за падения одной машины страдает весь кластер. Как вы с этим живете?

seregamorph Jun 23 2015 at 11:36

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

2. офф. что за система рисует график «Alive Users»?

xbsd Jun 23 2015 at 12:16

1. Aгрегации в скриптах нет, все скрипты выполняются для одного пользователя

2. Метрики пишем в graphite, из graphite графики рисует grafana

ayakovlev Jun 23 2015 at 20:51

Очень интересная статья!
Скажите, пожалуйста, а есть ли оценки затрат вычислительных ресурсов? Сейчас же практически всё в облаках, сколько стоила бы обработка N пользователей по первой схеме и сколько по real-time, насколько возрастают затраты? Каков сравнительный объем хранимых данных? создалось ощущение, что во втором случае не хранится большой массив сырых данных.

ilnarb Jun 24 2015 at 17:52

А сколько серверов понадобилось бы на 1 млрд юзеров и 20 млрд событий в сутки (примерно 500к/с в пике)?

asash Jun 28 2015 at 09:45

Сложно сказать. На таком потоке вероятно вылезут какие-то дополнительные ограничения, которые не видно сейчас. Например у меня серьезные подозрения что RabbitMQ пришлось бы заменить на что-то другое.

gurinderu Jun 25 2015 at 19:21

а зачем на каждого юзера создаётся по актору?

asash Jun 28 2015 at 09:46

Актор на каждого юзера создается для того чтобы инкапсулировать в себя всю информацию про этого юзера, чтобы вся нужная информация нужная для обработки была доступна локально.

gurinderu Jun 28 2015 at 20:02

Хм, а почему бы всю необходимое информацию не сохранить в message и иметь 1 актор на всех юзеров?

Ivanhoe Jun 28 2015 at 20:56

Да в общем зачем, если акторы достаточно легковесны? Размазывать по кластеру, опять же, можно.

gurinderu Jun 29 2015 at 10:06

Размазывать то, можно но стоит ли. Это опять же лишние затраты на общение между нодами.

Kane Jun 29 2015 at 11:33

Наоборот, цель такого подхода — сократить взаимодействие между нодами в системе, которая на одной ноде работать не может. Актор содержит весь необходимый стейт и в состоянии сам выдать необходимую информацию о себе.

gurinderu Jun 29 2015 at 11:50

Стоп, а что мне мешает создать 1 actor и засунуть state в message? Тем самым мы не создаем миллион actors и опять же message будет процесситься от и до на одной node, которая успела его поймать.

Kane Jun 29 2015 at 12:02

Подождите, источником стейта является не сообщение а актор.

Kane Jun 28 2015 at 23:19

Около 400 байт памяти «стоит» один актор

Ivanhoe Jun 28 2015 at 20:56

Doggy Jun 28 2015 at 23:05

На заметку: модель Акторов зародилась не в сообществе эрланга.

Модели акторов 40 лет!

Kane Jun 28 2015 at 23:16

В документации по Akka постоянно встречаются отсылки к Erlang-реализации

Doggy Jun 28 2015 at 23:19

Это не означает, что акторы зародились в сообществе эрланга.

HDDimon Jun 29 2015 at 09:46

Акторы зародились не в сообществе Erlang, но как раз в Erlang появилась одна из первых реализаций модели акторов, которую можно использовать в реальных системах на больших нагрузках. В целом же, почему в доках по акка идет постоянная отсылка к Erlang? Ответ очень прост, авторы акка в первых версиях пытались просто портировать модель Erlang на Scala. Позже же появились некоторые улучшения, которых нет в Erlang.

Doggy Jun 29 2015 at 09:54

Все эти доводы не являются достаточным оправданием для подмены понятия «первая реализация используемая в реальных системах» на «зародились в сообществе».

Я просто оставил ссылку, чтобы пытливые умы могли более детально посмотреть историю акторов при желании. В интернетах порой бывает трудно найти первоисточник и выяснить истинное положение вещей. Мне кажется надо придерживаться фактов и стараться избегать искажения информация при повествовании.

ratatosk Jul 29 2015 at 14:37

Кстати итоговая архитектура стала чем-то похожа на так называемые Lambda и Kappa архитектуры; radar.oreilly.com/2014/07/questioning-the-lambda-architecture.html

Sherman81 May 5 2016 at 21:39

>Также данные о сегментах и действиях пользователях доступны по API, подключенным напрямую к акторам.

А можно два слова про это? Что это за запросы, почему это не отдельный сервер, который берет данные из aerospike?

Only those users with full accounts are able to leave comments. Log in, please.