В моем случае акции могут быть изменены в любую секунду. Заводятся акции как правило заранее, но изменяться могут когда угодно. Инстансов сервиса несколько, они ничего не знают друг о друге. Задержки в сети могут быть неопределенных размеров. Если инстанс A стянул обновления, затем кто-то отключает акцию (по каким либо причинам), и сразу после, инстанс B стягивает обновления, то инстансы будут находиться в неконсистентном состоянии (и пробудут в нем, вплоть до следующей удачной синхронизации).
Рассылка общей последовательности тоже не идеальна (и в целом страдает от схожих проблем, именно поэтому я упомянул вариант с координатором), но в данном случае имеется один источник истины и на деле худшее что может случиться это разрыв соединения с БД у слушателя, с последующим переподключением, без какого либо ручного вмешательства. На практике же такое случается крайне редко.
В том случае когда время создания/обновления акций можно согласовать с временем синхронизации (ввести мораторий на определенные часы), ваш вариант вполне себе применим.
Одним из главных недостатков в подходе который вы предлагаете, это то, что если во время синхронизации отдельных инстансов сервиса, произойдет изменение каких либо акций, то инстансы будут находиться в неконсистентном состоянии вплоть до следующей удачной синхронизации. В совокупности с большим TTL это не очень хорошо. В итоге результат расчета скидок будет зависеть от того, на какой инстанс "упадет" запрос.
Выше вы предлагали кэшировать посчитанные скидки для каждой корзины. Я описал, почему такой кэш при текущей вариативности будет не эффективен.
Теперь вы говорите про кеширование акций, они и так кешируются, в уже "разобранном" виде. Знать заранее какие акции потребуются невозможно, для этого надо посчитать их для конкретной корзины.
Акции меняются не часто, но чаще чем раз в сутки/час и желательно реагировать на изменения как можно быстрее. Если я вас правильно понял, то вы предлагаете вариант с "ленивой" первой инициализацией и последующими синхронизациями по истечению TTL, как в самом обычном кэше. В моем случае TTL будет небольшим, тянуть каждую минуту все акции по сети, выполнять парсинг и последующее полное обновление кэша не хотелось бы. Частичное обновление, с таким подходом, возможно только если ходить в БД на каждый N-ый запрос и смотреть акции которые изменились (чтобы не тянуть все). Вариант рабочий, но не без недостатков, кому то он может подойти больше в силу своей простоты.
В одной лишь позиции, находящейся в корзине более 15 параметров, на каждый из которых можно настроить условие. Да, какие-то корзины с течением времени будут повторяться, но при достаточно большом кол-ве sku такой кэш вряд-ли будет эффективен. Процент попадания в него будет ничтожен. 99% RAM будет израсходовано впустую (если ее вообще хватит).
Даже если представить, что у нас всего 1000 sku, максимальное кол-во каждого товара в корзине равно единице и всегда выбирается 5 позиций, то уже имеется C из 1000 по 5 = 8'250'291'250'200 вариантов выбора 5 позиций. Понятное дело что статистически большая часть из этих вариантов выбора никогда не случится, но даже этот простой пример дает понять размах всего множества состояний, поэтому как такое можно закэшировать я не понимаю.
Потому что конечный результат зависит от состояния корзины, а это состояние неизвестно до запроса. Всевозможных состояний корзины огромное множество. Акции могут применяться совместно. Более того, результат применения одной акции может изменить дальнейший ход действий (решая одну подзадачу мы влияем на результаты еще не решенных), динамическое программирование тут не поможет (если намек был на него).
Если речь про иерархию узлов и Visitor , то голые указатели используются по дизайну, но их можно заменить на std::shared_ptr + std::enable_shared_from_this расплатившись производительностью (точных чисел не назову, но замеры делал в свое время).
Это упрощенный пример кода, чтобы не раздувать его лишними вспомогательными функциями которые не имеют отношения к сути, в реальном коде таких выражений a->b->c как правило нет.
machdep.cpu.brand_string: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHz
Версию ядра на момент замеров не могу точно сказать (это было достаточно давно), скорее всего 10.12.
Сейчас понимаю, что возможно не стоило добавлять этот пункт в статью (как минимум мне следовало указать спецификацию машины на которой выполнялись замеры). Но снижение производительности (RPS) было стабильным, в 4-5 раз, эта стабильность меня и смутила, возможно дело было как раз таки в моем специфичном (на то время) сетапе.
Так как скорость парсинга вряд ли станет узким местом (в нашем случае), то я это расцениваю просто как формат передачи данных и я выбрал тот формат который был мне ближе и удобнее (не исключено, что старая реализация оставила неизгладимый след в моей голове). Но вариант с префиксной нотацией хорош
Замеры производились локально, ограничений по CPU/RAM у него не было, это первое, что я проверил. С чем это в действительности связано - не знаю. Если найду время, то попробую предоставить больше деталей.
Если вы имели ввиду процесс настройки акций и под пользователем подразумевался пользователь админ-панели, то для этого используется адаптер. Клиенты для которых считаются скидки ничего не знают о DSL. Вот фрагмент из статьи по этому поводу:
Было принято решение спроектировать его с нуля, при этом написав адаптер, чтобы условия в БД продолжали храниться в старом формате и в админ-панели не пришлось ничего дорабатывать.
Насчет JSON, тут дело вкуса, можно конечно оптимизировать формат для более быстрого парсинга, но это того не стоит (на мой взгляд), парсинг DSL происходит только на моменте вставки или обновления акции (а это происходит относительно нечасто, и в данный момент с этим нет проблем). JSON естественный для JS формат, к тому же, у нас не чистый JS, а TypeScript и хотелось бы иметь типизацию. "Голую" строку же, почти невозможно типизировать средствами TS.
В моем случае акции могут быть изменены в любую секунду. Заводятся акции как правило заранее, но изменяться могут когда угодно. Инстансов сервиса несколько, они ничего не знают друг о друге. Задержки в сети могут быть неопределенных размеров. Если инстанс A стянул обновления, затем кто-то отключает акцию (по каким либо причинам), и сразу после, инстанс B стягивает обновления, то инстансы будут находиться в неконсистентном состоянии (и пробудут в нем, вплоть до следующей удачной синхронизации).
Рассылка общей последовательности тоже не идеальна (и в целом страдает от схожих проблем, именно поэтому я упомянул вариант с координатором), но в данном случае имеется один источник истины и на деле худшее что может случиться это разрыв соединения с БД у слушателя, с последующим переподключением, без какого либо ручного вмешательства. На практике же такое случается крайне редко.
В том случае когда время создания/обновления акций можно согласовать с временем синхронизации (ввести мораторий на определенные часы), ваш вариант вполне себе применим.
Одним из главных недостатков в подходе который вы предлагаете, это то, что если во время синхронизации отдельных инстансов сервиса, произойдет изменение каких либо акций, то инстансы будут находиться в неконсистентном состоянии вплоть до следующей удачной синхронизации. В совокупности с большим TTL это не очень хорошо. В итоге результат расчета скидок будет зависеть от того, на какой инстанс "упадет" запрос.
Выше вы предлагали кэшировать посчитанные скидки для каждой корзины. Я описал, почему такой кэш при текущей вариативности будет не эффективен.
Теперь вы говорите про кеширование акций, они и так кешируются, в уже "разобранном" виде. Знать заранее какие акции потребуются невозможно, для этого надо посчитать их для конкретной корзины.
Акции меняются не часто, но чаще чем раз в сутки/час и желательно реагировать на изменения как можно быстрее. Если я вас правильно понял, то вы предлагаете вариант с "ленивой" первой инициализацией и последующими синхронизациями по истечению TTL, как в самом обычном кэше. В моем случае TTL будет небольшим, тянуть каждую минуту все акции по сети, выполнять парсинг и последующее полное обновление кэша не хотелось бы. Частичное обновление, с таким подходом, возможно только если ходить в БД на каждый N-ый запрос и смотреть акции которые изменились (чтобы не тянуть все). Вариант рабочий, но не без недостатков, кому то он может подойти больше в силу своей простоты.
В одной лишь позиции, находящейся в корзине более 15 параметров, на каждый из которых можно настроить условие. Да, какие-то корзины с течением времени будут повторяться, но при достаточно большом кол-ве sku такой кэш вряд-ли будет эффективен. Процент попадания в него будет ничтожен. 99% RAM будет израсходовано впустую (если ее вообще хватит).
Даже если представить, что у нас всего 1000 sku, максимальное кол-во каждого товара в корзине равно единице и всегда выбирается 5 позиций, то уже имеется
C из 1000 по 5 = 8'250'291'250'200вариантов выбора 5 позиций. Понятное дело что статистически большая часть из этих вариантов выбора никогда не случится, но даже этот простой пример дает понять размах всего множества состояний, поэтому как такое можно закэшировать я не понимаю.Потому что конечный результат зависит от состояния корзины, а это состояние неизвестно до запроса. Всевозможных состояний корзины огромное множество. Акции могут применяться совместно. Более того, результат применения одной акции может изменить дальнейший ход действий (решая одну подзадачу мы влияем на результаты еще не решенных), динамическое программирование тут не поможет (если намек был на него).
Если речь про иерархию узлов и
Visitor, то голые указатели используются по дизайну, но их можно заменить наstd::shared_ptr+std::enable_shared_from_thisрасплатившись производительностью (точных чисел не назову, но замеры делал в свое время).Это упрощенный пример кода, чтобы не раздувать его лишними вспомогательными функциями которые не имеют отношения к сути, в реальном коде таких выражений
a->b->cкак правило нет.machdep.cpu.brand_string: Intel(R) Core(TM) i9-9880H CPU @ 2.30GHzВерсию ядра на момент замеров не могу точно сказать (это было достаточно давно), скорее всего 10.12.
Сейчас понимаю, что возможно не стоило добавлять этот пункт в статью (как минимум мне следовало указать спецификацию машины на которой выполнялись замеры). Но снижение производительности (RPS) было стабильным, в 4-5 раз, эта стабильность меня и смутила, возможно дело было как раз таки в моем специфичном (на то время) сетапе.
Спасибо за информацию, попробую сделать более адекватный "бенчмарк".
Не поверите, но все так. Это какие то известные проблемы с версией docker desktop под macOS?
Так как скорость парсинга вряд ли станет узким местом (в нашем случае), то я это расцениваю просто как формат передачи данных и я выбрал тот формат который был мне ближе и удобнее (не исключено, что старая реализация оставила неизгладимый след в моей голове). Но вариант с префиксной нотацией хорош
Замеры производились локально, ограничений по CPU/RAM у него не было, это первое, что я проверил. С чем это в действительности связано - не знаю. Если найду время, то попробую предоставить больше деталей.
Если вы имели ввиду процесс настройки акций и под пользователем подразумевался пользователь админ-панели, то для этого используется адаптер. Клиенты для которых считаются скидки ничего не знают о DSL. Вот фрагмент из статьи по этому поводу:
Насчет JSON, тут дело вкуса, можно конечно оптимизировать формат для более быстрого парсинга, но это того не стоит (на мой взгляд), парсинг DSL происходит только на моменте вставки или обновления акции (а это происходит относительно нечасто, и в данный момент с этим нет проблем). JSON естественный для JS формат, к тому же, у нас не чистый JS, а TypeScript и хотелось бы иметь типизацию. "Голую" строку же, почти невозможно типизировать средствами TS.