Являются ли актеры AKKA хорошим решением для оптимизации моей установки?

Я работаю над проектом, в котором большая часть одновременного чтения и записи в БД снижает производительность. Представьте, что мне нужно время от времени переиндексировать всю БД, поэтому самый простой способ — установить флаг «грязный» в значение true и позволить нескольким машинам захватывать «грязные» элементы, выполнять некоторую обработку и затем снова установите их состояние на «чистое». Как вы понимаете, это рай для тупиков.

Я хочу оптимизировать это и оставить операции ввода-вывода БД на одну координирующую машину, а остальные возможные параллельные вычисления — на другие машины. Я подумал, что Akka с ее распределенной моделью акторов может быть идеальным для этого. Моя идея состоит в том, чтобы координирующий актор читал пакеты «грязных» элементов из БД, запускал множество обрабатывающих акторов, передавая элемент каждому из них. Идея состоит в том, что акторы обработки будут располагаться на разных машинах, но ни координатор, ни процессоры не должны об этом знать. Кажется, это стало возможным благодаря большим преимуществам использования Akka. Я хочу сделать это проблемой конфигурации развертывания, чтобы сделать возможным масштабирование по желанию.

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

Я иду в правильном направлении с этой настройкой?


person Preslav Rachev    schedule 10.12.2014    source источник


Ответы (1)


Вы можете использовать Cluster Singleton в качестве координатора. Обратите внимание, что актор координации будет обрабатывать все запросы последовательно, поэтому он должен быть довольно легким. По крайней мере, вы можете захотеть разделить массовое чтение и обратную запись. И, возможно, (если у вас нет триггеров) также читать грязные блоки с нумерацией страниц, чтобы не блокировать актера на долгое время. Я использовал итератор, определенный для ResultSet (драйверы Oracle JDBC автоматически выполняют разбиение на страницы) — и что-то вроде case ScheduledBulk if previousBulkFinished => future {getIterator(...).foreach(coordinator ! _)}}.

Если вам нужна быстрая запись в БД, вы можете использовать маршрутизатор фиксированного размера распределять записи между многими участниками (количество ‹ размер вашего пула подключений к БД)

person dk14    schedule 10.12.2014