Система не падает (хотя, что вы имеете ввиду под словом "падает?"), тут есть несколько моментов:
За время оформления заказа товар по акционной цене мог закончиться, тогда заказ уже не может быть сформирован - вернется ошибка. Количество товара именно по акционной цене ограничено, при этом на складах его может быть гораздно больше, но может быть и равно количеству акционного стока.
Стоки дейстительно могут быть на разных складах, и на них могут быть разные ограничения на доставку. С одного склада есть доставка в ваш регион, а с другого нет.
Могут быть отмены заказов, которые уже были оформлены по акционной цене, тогда доступные стоки по акционной цене будут расти.
Идея с gossip-like прикольная, но мне кажется, не самое простое и оптимальное решение по прогреву in-memory, хотя все зависит от того, что представляет из себя система в целом)
Под профитом я тут имею ввиду в первую очередь повышение хитрейтов. А он у нас и с текущим подходом около 100% по тем ключам, где возможно легко заменить удаление на обновление.
Но я согласна, что в этом есть смысл и это позволило бы не делать лишней работы. И если бы начинали с нуля, я бы так и сделала)
P. S.: имхо, странно, что в статье делается много акцента на инвалидации кешей, а не на их актуализации. Хотя это намного более приятная процедура.
У нас была мысль сделать так, чтобы при получении ивента об изменениях из кафки мы не просто инвалидировали кэш, а сразу писали новое значение. Но мы прикинули, что: 1) существенного профита относительно текущего подхода нам это не даст, поэтому пока не стали переделывать. По всем ключам, по которым это возможно, у нас хитрейт итак сейчас около 100%. 2) не для всех ключей у нас это возможно, так как, например, доступность товара у нас кэшируется по локации пользователя. Доступность товара напрямую зависит от неё.
Но вполне возможно, что в какой-то момент часть инвалидации мы заменим обновлением.
Если вы знали о схеме с размазыванием ключей, но выбрали другую, то какие критичные для себя минусы вы увидели в схеме с размазыванием?
Критичных минусов в этой схеме для себя не видели, а решили идти таким путем, чтобы заодно снять немного нагрузки с сети. Сеть у нас была "ближайший ботлнек" на наших серверах. Это связано с тем, что мемкешам мало требуется CPU для работы, а данных гоняется очень много. В итоге сетевой интерфейс - это было первое, во что мы уперлись бы.
Словосочетание "утилизация CPU" сейчас достаточно устойчиво в профессиональной среде, оно используется в публичных докладах на IT конференциях, поэтому посчитала, что для большинства людей оно будет понятным. А если нет, то станет понятным из содержания статьи.
Уточните пожалуйста, речь идет о прихранивании набора активных запросов на стороне инстанса сервиса, который выполняет запрос? В рамках одного инстанса так проблема решается, но если инстансов тысяча... или я не уловила идею?
Сейчас такой вариант не рассматриваем. А чем лучше относить затраты на инфраструктурый сервис, а не на бизнесовый? У нас кстати не чисто инфраструктурный сервис же, у нас довольно мудреная логика по расчету доступности товара для пользователя, которая зависит от многих факторов и условий доставки.
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
Такой способ действительно есть, спасибо за дополнение. Конечно это не учебник и не методичка по системному дизайну, тут не раскрыты все распрастраненные подходы. Но на выбор оптимального решения могут влиять разные факторы, поэтому я бы не стала утверждать, что топик кафки во всех случаях будет лучшим решением. Наример, если на проекте уже используется redis, как основное хранилище, а локальный кэш должен сбрасываться при изменениях в redis.
Система не падает (хотя, что вы имеете ввиду под словом "падает?"), тут есть несколько моментов:
За время оформления заказа товар по акционной цене мог закончиться, тогда заказ уже не может быть сформирован - вернется ошибка.
Количество товара именно по акционной цене ограничено, при этом на складах его может быть гораздно больше, но может быть и равно количеству акционного стока.
Стоки дейстительно могут быть на разных складах, и на них могут быть разные ограничения на доставку. С одного склада есть доставка в ваш регион, а с другого нет.
Могут быть отмены заказов, которые уже были оформлены по акционной цене, тогда доступные стоки по акционной цене будут расти.
Не очень поняла вопроса, не могли бы переформулировать, о каком сопоставлении идет речь?
Спасибо за отзыв!
Идея с gossip-like прикольная, но мне кажется, не самое простое и оптимальное решение по прогреву in-memory, хотя все зависит от того, что представляет из себя система в целом)
Очень мотивируют такие комментарии писать ещё, спасибо!)
Спасибо за отзыв и за дополнение!
Действительно не упомянула про сжатие, и зря, это отдельная очень интересная тема. Мы его используем, в частности библиоткеку github.com/golang/snappy
это уже не очень интересно сейчас, просто потому, что сейчас есть в работе более интересные проекты, от которых мы ждем серьёзного выхлопа)
Под профитом я тут имею ввиду в первую очередь повышение хитрейтов. А он у нас и с текущим подходом около 100% по тем ключам, где возможно легко заменить удаление на обновление.
Но я согласна, что в этом есть смысл и это позволило бы не делать лишней работы. И если бы начинали с нуля, я бы так и сделала)
Спасибо!
У нас была мысль сделать так, чтобы при получении ивента об изменениях из кафки мы не просто инвалидировали кэш, а сразу писали новое значение.
Но мы прикинули, что:
1) существенного профита относительно текущего подхода нам это не даст, поэтому пока не стали переделывать. По всем ключам, по которым это возможно, у нас хитрейт итак сейчас около 100%.
2) не для всех ключей у нас это возможно, так как, например, доступность товара у нас кэшируется по локации пользователя. Доступность товара напрямую зависит от неё.
Но вполне возможно, что в какой-то момент часть инвалидации мы заменим обновлением.
Спасибо за дополнение!
Критичных минусов в этой схеме для себя не видели, а решили идти таким путем, чтобы заодно снять немного нагрузки с сети. Сеть у нас была "ближайший ботлнек" на наших серверах. Это связано с тем, что мемкешам мало требуется CPU для работы, а данных гоняется очень много. В итоге сетевой интерфейс - это было первое, во что мы уперлись бы.
Словосочетание "утилизация CPU" сейчас достаточно устойчиво в профессиональной среде, оно используется в публичных докладах на IT конференциях, поэтому посчитала, что для большинства людей оно будет понятным. А если нет, то станет понятным из содержания статьи.
Оценить дистанционно откуда конкретно у вас возникли такие проблемы, к сожалению, не представляется возможным.
У нас ведется постоянный мониторинг TTLB, TTFB, LCP, SpeedIndex метрик, и все случаи деградации расследуются для установки причин и их устранения.
Опечатка в вопросе. Хотела спросить, чем лучше относить затраты на бизнесовый сервис, а не инфраструктурный?
Возможно, вы хотите к нам на проект поработать, реализовать лучшие решения? Нам как раз пора думать над подготовкой к следующему сезону)
Спасибо за дополнение!
Уточните пожалуйста, речь идет о прихранивании набора активных запросов на стороне инстанса сервиса, который выполняет запрос? В рамках одного инстанса так проблема решается, но если инстансов тысяча... или я не уловила идею?
Сейчас такой вариант не рассматриваем.
А чем лучше относить затраты на инфраструктурый сервис, а не на бизнесовый?
У нас кстати не чисто инфраструктурный сервис же, у нас довольно мудреная логика по расчету доступности товара для пользователя, которая зависит от многих факторов и условий доставки.
К java вопросов нет, в озоне она тоже есть) Конкретно на нашем проекте исторически сложилось так, инфраструктура наиболее развита под go.
Радостно очень, что понравилось!
Спасибо за фидбек! А можно пожалуйста развернуть мысль, в чем NIH?
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
Такой способ действительно есть, спасибо за дополнение. Конечно это не учебник и не методичка по системному дизайну, тут не раскрыты все распрастраненные подходы. Но на выбор оптимального решения могут влиять разные факторы, поэтому я бы не стала утверждать, что топик кафки во всех случаях будет лучшим решением. Наример, если на проекте уже используется redis, как основное хранилище, а локальный кэш должен сбрасываться при изменениях в redis.