Понимание шардинга кластера Akka

Question

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

Клиент делает запрос (отправляет сообщение) вашему актору шарда, чтобы вернуть его значение статуса. Это сообщение будет обработано сущностью и в результате будет возвращено его значение. Но если бы его лечил другой субъект, результат был бы другим. Но он должен быть одинаковым, потому что все сущности происходят от одного и того же актера, не так ли?

Answer 1

Кажется, вы неправильно понимаете концепцию сегментирования кластера Akka, позвольте мне объяснить на примере.

Допустим, ваша служба отвечает за ответы с профилями пользователей на запросы. А чтобы получить чрезвычайно низкую задержку, вы решаете использовать акторов Akka для кэширования профилей пользователей в памяти вместо того, чтобы запрашивать БД по запросу. KB, вы можете без проблем хранить все 10 пользовательских профилей в одном актере, и вам точно не понадобится сегментирование кластера. Однако, если у вас 10 миллионов пользователей, вероятно, 10 миллионов пользовательских профилей не поместятся в память одного актора, также это будет дорого, если актор выйдет из строя, поскольку это означает, что вам понадобится большой запрос к БД, чтобы вернуть эти данные. от настойчивости.

В этом сценарии сегментирование кластера подходит. У вас будет 10 миллионов акторов Akka, распределенных по вашему кластеру, и каждый актор хранит только 1 профиль пользователя. Таким образом, GetUserProfile(userProfileId = 123) не даст вам другого ответа - он всегда будет перенаправлен к действующему субъекту, который содержит профиль пользователя для пользователя 123, поэтому ответ всегда будет одинаковым.

Как работает маршрутизация? Отметьте extractShardId и extractEntityId в do c

Answer 2

В сегментировании кластера Akka каждый субъект должен иметь уникальное имя (обычно идентификатор объекта) и представлять уникальный объект. Когда субъект запускает / перезапускает объект, загруженный (обычно из базы данных) в состояние субъекта.

Если субъект получает сообщения для обновления объекта, он должен обновить базу данных и состояние субъекта, если субъект получает сообщения для чтения объекта тогда субъект должен читать объект только из состояния субъекта (гарантируется, что он будет таким же, как в базе данных, поскольку все операции обновления обрабатываются только одним субъектом).

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

Answer 3

Но [ответ на сообщение] должен быть одинаковым, потому что все объекты происходят от одного и того же актера, не так ли?

Нет, каждый субъект имеет собственное состояние и представляет что-то другое . Если бы у вас был класс Customer, вы бы не ожидали, что каждый объект Customer будет иметь одинаковые данные. Каждый объект клиента будет иметь собственное имя, id и т.д. c.

То же самое верно и для Актеров. Актеры имеют собственное состояние и представляют собой некую предметную область. Если вы отправляете актеру сообщение GetCustomerName, вы ожидаете, что каждый Актер даст вам другое имя.

Это особенно верно для кластерного разделения. Смысл кластерного сегментирования заключается в том, что вы можете масштабироваться за пределы одного узла: для масштабируемости, эластичности или устойчивости. Но они все еще Актеры, у каждого свое состояние. Отправка GetCustomerName даст (и должна) дать вам разный ответ от каждого актера. Шардинг просто дает вам возможность распределять этих актеров по нескольким машинам, а местоположение актера должно быть прозрачным для отправителя.