Сравнить как равные альтернативы для решения одинаковых задач в общем нельзя.
Ну к примеру Hangfire без базы данных не работает в принципе. В базе данных он содержит очередь задач, вместе с непосредственно задачами и прочими инфраструктурными данными. То есть реально в базу данных записывается путь к исполняемому методу, название метода, типы параметров, сами параметры.
Абстрактный планировщик в вакууме может обойтись и без базы данных, но всё равно нужно будет где-то содержать расписание и историю исполнения.
Планировщик задач служит для того, чтобы можно было составить расписание (я хочу исполнять метод X каждое воскресенье в полночь с вот такими параметрами; хочу исполнять метод y через 10 минут после нажатия кнопки; и т.д), чтобы можно было посмотреть какое расписание есть на данный момент, и чтобы можно было посмотреть какие процессы уже исполнены и когда.
Акторы это грубо говоря модули, которые исполняются параллельно и бывает так, что взаимодействуют друг с другом (один актор, когда ему нужно, отсылает сообщение другому и тот другой обрабатывает сообщение в соответствии со своей логикой, не останавливая работу первого). Таким образом в процессе разработки планировщика задач вы скорее всего будете использовать модель акторов, это имеет смысл, это удобно.
Можно реализовать одинаковую функциональность с планировщиком и без планировщика, а можно сделать свой планировщик не зная что этот девайс так называется.
Пользуюсь этим планировщиком около года, но только для мелких процессов которые нужно выполнять непосредственно на сервере приложения. Для реальных вычислительных процессов пользуюсь Azure Batch с автоматическим масштабированием (вычислительная мощность непосредственно на веб-сервере дорого обходится).
Одна неприятная особенность hangfire — каждый heartbeat это запись в базу данных. Если ведётся аудит базы, то он разрастётся очень быстро и может стать почти неподъёмным. Ещё трудней, если приложение развёрнуто в десятке разных окружений и соответственно для каждого окружения своя база данных. Поэтому я сделал отдельную базу данных для hangfire и подключил к ней все приложения с уникальными идентификаторами. В руководствах это описывается нечасто, но отделяйте зёрна от плевел, впоследствии будет легче.
Ну к примеру Hangfire без базы данных не работает в принципе. В базе данных он содержит очередь задач, вместе с непосредственно задачами и прочими инфраструктурными данными. То есть реально в базу данных записывается путь к исполняемому методу, название метода, типы параметров, сами параметры.
Абстрактный планировщик в вакууме может обойтись и без базы данных, но всё равно нужно будет где-то содержать расписание и историю исполнения.
Планировщик задач служит для того, чтобы можно было составить расписание (я хочу исполнять метод X каждое воскресенье в полночь с вот такими параметрами; хочу исполнять метод y через 10 минут после нажатия кнопки; и т.д), чтобы можно было посмотреть какое расписание есть на данный момент, и чтобы можно было посмотреть какие процессы уже исполнены и когда.
Акторы это грубо говоря модули, которые исполняются параллельно и бывает так, что взаимодействуют друг с другом (один актор, когда ему нужно, отсылает сообщение другому и тот другой обрабатывает сообщение в соответствии со своей логикой, не останавливая работу первого). Таким образом в процессе разработки планировщика задач вы скорее всего будете использовать модель акторов, это имеет смысл, это удобно.
Можно реализовать одинаковую функциональность с планировщиком и без планировщика, а можно сделать свой планировщик не зная что этот девайс так называется.
Одна неприятная особенность hangfire — каждый heartbeat это запись в базу данных. Если ведётся аудит базы, то он разрастётся очень быстро и может стать почти неподъёмным. Ещё трудней, если приложение развёрнуто в десятке разных окружений и соответственно для каждого окружения своя база данных. Поэтому я сделал отдельную базу данных для hangfire и подключил к ней все приложения с уникальными идентификаторами. В руководствах это описывается нечасто, но отделяйте зёрна от плевел, впоследствии будет легче.