Comments 15
Беда в том, что этот Hangfire не нужен.
Маленькое Singlethread приложение - семафоры.
Большие приложения - Akka. (https://getakka.net/articles/actors/dispatchers.html)
И все бесплатно :)
Просто появляется еще одна непонятная конфигурация (приложение, деплой, конфигурация контейнера, конфигурация Джобов(!))
Почему Akka, а не родной Orleans?
Слишком страшная документация
Получив сообщение подтверждения о запуске Silo , запустите клиент
silo:
an underground chamber in which a guided missile is kept ready for firing.
А вообще - а зачем мне состояние в акторах? (Grains)
А сохранять состояние акторов?
А я не устану это отлаживать?
upd:
нашел статью по DDD+Orleans, сейчас почитаю
Ну да, вроде как сервер надо запускать первым, а потом клиент. При этом потом сервер можно перезапускать и делать всё что угодно.
Про состояния не понял - если не нужно состояние, то и не сохраняйте.
С отладкой тоже не понятно в чём проблема.
Мороки много, для документооборота
1) Как искать документы (акторы/Grain, Rich Domain Model) не только по ID (как Id матчей и т.д)? Через другой актор?
У меня мой ConcurrentDictionary потянет 10к RPS, а потянет ли сеть до Silo? :)
2) Могу ли я добавить\изменить поле
3) Как делать транзакции
4) Что с дедлоками
5) Куда и как это сохраняется
6) И т.д
И надо книгу читать )
Вторая проблема не так очевидна — это так называемая цепная реакция. Когда пользователь поднимает какой-то грейн, а тот в свою очередь может неявно поднять другие грейны в системе. Как это происходит: пользователь получает свои состояния, а у пользователя есть друзья и он получает состояния своих друзей. Таким образом, вся система держит все свои грейны в памяти и если у нас 1000 пользователей, и у каждого 100 друзей, то 100 000 грейнов могут быть активны просто так. Такого случая тоже нужно избегать — как-то хранить стейты друзей в какой-то общей памяти.
В этом плане просто шины и кучи stateless обработчиков данных из шин гораздо проще в плане разработки\отладки\поддержки\масштабируемости.
Так вам, судя по всему, здесь и Акка не поможет никак.
Вряд ли кто будет это в вакансии писать. Обычно пишут общие требования.
У меня вот есть в проде 2 сервиса с Orleans и они отлично справляются с тем что надо и я не парюсь с синхронизацией доступа и распределением нагрузки и данных.
На самом деле он довольно простой и там не нужно каких-то специфических знаний, достаточно прочитать доки, благо они нормально написаны.
В акка состояние акторов не сохраняется (актор обрабатывает сообщения, отсылает сообщения). Т.е. в akka актор - прямо функция из ФП.
В Orleans - Grain это богатый обьект (есть Grain без состояния, почти как актор в Akka).
В Orleans нет индексирования (кроме полуофициального репозитория без Nuget пакета).
Т.е. работать с обьектами можно очень быстро (они в оперативной памяти), а так же сразу из нескольких мест, так же это все можно масштабировать.
Найти нужный обьект, кроме как по Id - нельзя :)
Поэтому просто взять и использовать Orleans в СЭД - нельзя, придется городить кучу костылей.
Ну так и в грейнах состояние не обязательно.
Да, индексирования нет, но ничего не мешает внутри грейна использовать, например, данные из базы. Так же ничего не мешает получить нужные Id из хранилища по условиям и потом уже использовать грейны.
Я делаю Select с нужными условиями в БД и вот уже есть нужные Id.
У меня есть пара грейнов с встроенным сохранением состояния т.к. знаю, что там не нужен поиск.
В Orleans - Grain это богатый обьект (есть Grain без состояния, почти как актор в Akka).
Нет - это просто объект с ключом и методами. Всё зависит от вашей реализации. Кстати, при получении грейна - ничего не происходит, вы просто получаете ссылку. Потом при обращении к нему да, если его нет, то он активируется, если уже есть, то просто вызывается нужный метод.
Да, индексирования нет, но ничего не мешает внутри грейна использовать, например, данные из базы
Тогда получается дублирование функций хранилища грейнов. И основной плюс (грейны могут обрабатывать БОЛЬШЕ событий из разных источников, чем чтение\запись в базу) исчезает.
Так же исчезает второй плюс - не нужно ручками ничего писать (никакой инфраструктуры, с сохранением индексов и проч).
И чем это лучше, чем просто кучи акторов, связанные персистентными шинами? Ничем.
Для Игрового Лобби, Miro, сервиса сокращения URL - да, отлично подходит.
Для ЭДО - абсолютно не подходит.
Наверно единого оптимального решения нет, если Hangfire уже используется и нет планов с него уходить, то можно и его более глубоко использовать.
Akka .NET интересен, но в нем нужно переходить на акторы, и он подходит для всего приложения. Выглядит так, что его удобно использовать для новых проектов, но для существующих требует время на переход.
Какая криповая КДПВ. Персонаж за тобой следит
Видимо, не совсем понял кейс: хотелось бы при добавлении в очередь не знать о наличии нод ClickHouse. Если уж мы говорим о балансировании.
Хороший вопрос, да, описано больше разделение ресурсов (ноды ClickHouse) средствами Hangfire, т.е. например, на CH1 не более 2 запросов, на CH2 — не более одного, и т.д.
Наверно описано больше не балансирование, а соблюдение ограничений для ресурсов, т.е. с предложенным подходом любое балансирование (которое также нужно имплементировать) будет валидным для ресурсов. Например, для CH1 не будет условно 3 запросов одновременно.
Выбор очереди (и по сути ClickHouse) при отправке тоже нужно имплементировать, это и будет формально балансирование. Например, можно для имплементации балансирования использовать информацию о работах в очередях через EnqueuedJobs и выбирать очередь с наименьшим количеством работ в ней, или простейший вариант балансирования — выбор случайной ноды ClickHouse, также может быть и другая логика балансирования с учетом настроек или приоритетов нод ClickHouse и т.д., т.е. описано только соблюдение ограничений на ресурсы средствами Hangfire
Балансирование нагрузки при разделяемых ресурсах при помощи очередей в Hangfire