Комментарии 14
А как вы работаете с конфигами? Я в разных проектах попробовал 2 разных способа
1) Все значения из конфига считываются в функции main. И потом раздаются всем необходимым классам. Недостаток: при сложной иерархии классов очень сложно докинуть каждую настройку до нужного класса
2) Каждый класс берет из конфига ровно те настройки, которые ему нужны. Пока склоняюсь к такому варианту, но, возможно в нем есть какието минусы
1) Все значения из конфига считываются в функции main. И потом раздаются всем необходимым классам. Недостаток: при сложной иерархии классов очень сложно докинуть каждую настройку до нужного класса
2) Каждый класс берет из конфига ровно те настройки, которые ему нужны. Пока склоняюсь к такому варианту, но, возможно в нем есть какието минусы
Есть единый реестр. Каждый модуль сам считывает из него свои настройки на страте и при релоаде. Если обновление настроек происходит чаще, то для наиболее дешевой синхронизации мы используем atomic_ptr на shared_ptr, в котором размещается либо variti::util::config, либо структура, куда уже вычитаны данные из variti::util::config (преобразованы в более удобный для работы вид).
А как с thread safety? Как я понимаю, libconfig не thread-safe даже на чтение. Или у вас разрешено перечитывание конфига только из основного потока?
Вся конфигурация зачитывается либо из главного потока на старте, либо из потока, в котором обрабатывается сигнал sighup. Если коротко про thread-safety, то:
1. что-то read-only
2. что-то зачитывается редко и может быть синхронизировано через mutex
3. что-то зачитывается часто и тогда mutex не подходит (я написал выше про atomic_ptr на shared_ptr)
1. что-то read-only
2. что-то зачитывается редко и может быть синхронизировано через mutex
3. что-то зачитывается часто и тогда mutex не подходит (я написал выше про atomic_ptr на shared_ptr)
<удалено>
мы конфиги из Монги вычитываем. Удобно и быстро, доступно сразу на всех серверах. Чем Ваш подход удобнее?
Из mongodb красиво и удобно, да… но:
1. так исторически сложилось
2. а сложилось, потому что нам важно перезагружать или релоадить сервис быстро и в 100% случаев (mongodb может быть не доступен по своим причинам)
1. так исторически сложилось
2. а сложилось, потому что нам важно перезагружать или релоадить сервис быстро и в 100% случаев (mongodb может быть не доступен по своим причинам)
1. ОК, понимаю
2. зачем релоадить сервис?
В монге админкой обновили конфиги и всё. И просто запросы в неё.
У нас в фоновом режиме периодически она запрашивается и обновляется хэш-мапа, из кот. потом получаются конфиги. Если недоступна (кот. происходит практически никогда), то хеш мапа не обновлена и всё.
2. зачем релоадить сервис?
В монге админкой обновили конфиги и всё. И просто запросы в неё.
У нас в фоновом режиме периодически она запрашивается и обновляется хэш-мапа, из кот. потом получаются конфиги. Если недоступна (кот. происходит практически никогда), то хеш мапа не обновлена и всё.
Релоад (sighup) или обновление в фоне по событию от mongodb — есть какая-то разница? У нас выглядит примерно так (к вопросу о том, насколько mongodb будет безотказно работать):
1. конфиги раскладываются админкой (часто)
2. конфиги раскладываются клиентом из личного кабинета (постоянно)
3. архитектура распределенная (несколько кластеров в нескольких странах)
1. конфиги раскладываются админкой (часто)
2. конфиги раскладываются клиентом из личного кабинета (постоянно)
3. архитектура распределенная (несколько кластеров в нескольких странах)
<удалено>
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Определение неиспользуемых настроек в библиотеке libconfig