Pull to refresh

Comments 50

Aerospike сколько серверов используете, если не секрет? Или одного хватает?
Не секрет. на текущий момент 6 серверов.
То есть с каждым акка-сервером крутится инстанс? Или это отдельно?
Спасибо за статью! Скажите, какое количество сегментов и могут ли пользователи из них удаляться?
Сегментов на текущий момент около 2000 разных(пользователь одновременно находится в нескольких из них, но не во всех). Если хотите удалиться из сегментов -можете например пройти по этой: exebid.ru/optout.html ссылке.
Респект! Я делал похожую штуку, на несколько ином наборе инструментов.
Если позволите, несколько вопросов :)

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

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

Тем более что вы сами ссылку на него даете.
Мы были уверены что при помощи akka можно решить бизнес-задачу и умеем ею пользоваться. О спарке слышали(и проверили на собственном опыте) много отзывов насчет его глючности.
Изначальная идея была взята из research.microsoft.com/en-us/projects/orleans, ну и да, акку мы тогда уже умели готовить :)

возможно в будущем посмотрим на возможность переезда на spark streaming, благо кода получилось не очень много
Storm тоже хорошая система. Пробовал его на предыдущем месте работы, вполне себе работало. В общем вполне можно промышленные системы строить и на нем тоже, тут скорее дело вкуса. Нам понравилась именно идеалогия акторов, которая подходит не только для потоковой обработки данных, но и вообще для широкого класса задач распределенных систем.
Да, Spark нужно уметь готовить. Не у многих компаний он в production работает, хотя с версии 1.1.1 все стало хорошо.
Почему используется RabbitMQ, а не, например, Apache Kafka?
Нет, я имел в виду, что кролик проще в эксплуатации :)
Возможно, в kafka приходится работать c offset'ами и partition'ами, но, например, для spark есть модуль spark-streaming-kafka, к хорошим API (в ввиде RDD).
Кролик у нас уже был, а разворачивать в проде еще одну новую систему — это гарантированные грабли. Задача была как можно быстрее это запустить.

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

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

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

2. офф. что за система рисует график «Alive Users»?
1. Aгрегации в скриптах нет, все скрипты выполняются для одного пользователя

2. Метрики пишем в graphite, из graphite графики рисует grafana
Очень интересная статья!
Скажите, пожалуйста, а есть ли оценки затрат вычислительных ресурсов? Сейчас же практически всё в облаках, сколько стоила бы обработка N пользователей по первой схеме и сколько по real-time, насколько возрастают затраты? Каков сравнительный объем хранимых данных? создалось ощущение, что во втором случае не хранится большой массив сырых данных.
А сколько серверов понадобилось бы на 1 млрд юзеров и 20 млрд событий в сутки (примерно 500к/с в пике)?
Сложно сказать. На таком потоке вероятно вылезут какие-то дополнительные ограничения, которые не видно сейчас. Например у меня серьезные подозрения что RabbitMQ пришлось бы заменить на что-то другое.
Актор на каждого юзера создается для того чтобы инкапсулировать в себя всю информацию про этого юзера, чтобы вся нужная информация нужная для обработки была доступна локально.
Хм, а почему бы всю необходимое информацию не сохранить в message и иметь 1 актор на всех юзеров?
Да в общем зачем, если акторы достаточно легковесны? Размазывать по кластеру, опять же, можно.
Размазывать то, можно но стоит ли. Это опять же лишние затраты на общение между нодами.
Наоборот, цель такого подхода — сократить взаимодействие между нодами в системе, которая на одной ноде работать не может. Актор содержит весь необходимый стейт и в состоянии сам выдать необходимую информацию о себе.
Стоп, а что мне мешает создать 1 actor и засунуть state в message? Тем самым мы не создаем миллион actors и опять же message будет процесситься от и до на одной node, которая успела его поймать.
Подождите, источником стейта является не сообщение а актор.
Около 400 байт памяти «стоит» один актор
В документации по Akka постоянно встречаются отсылки к Erlang-реализации
Это не означает, что акторы зародились в сообществе эрланга.
Акторы зародились не в сообществе Erlang, но как раз в Erlang появилась одна из первых реализаций модели акторов, которую можно использовать в реальных системах на больших нагрузках. В целом же, почему в доках по акка идет постоянная отсылка к Erlang? Ответ очень прост, авторы акка в первых версиях пытались просто портировать модель Erlang на Scala. Позже же появились некоторые улучшения, которых нет в Erlang.
Все эти доводы не являются достаточным оправданием для подмены понятия «первая реализация используемая в реальных системах» на «зародились в сообществе».

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

А можно два слова про это? Что это за запросы, почему это не отдельный сервер, который берет данные из aerospike?
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
datacentric.ru
Employees
51–100 employees
Registered