Формирование заказа это резервация товара, фактически флажек в базе.
Да, все именно так, обработка заказа — это другая система.
Модель должна быть сделана так, чтобы при обновлении появлялся diff
Админка, которую разрабатывали, самая сложная ее часть — ровно про это — как генерить diff в данных подготовленных для сайта используя только diff по исходным данным. При этом схема трансформаций — это 100+ узлов и в 2 раза больше связей между ними (в среднем 1,9 связей на 1 узел). Чтоб с этим справиться в плане поддержки/доработки — был составлен движок. Внутренности этого движка активно производят вычисления и дают основную нагрузку по админке. Сложности с кешированием — словили как раз для промежуточных результатов этих вычислений.
Об этом проекте — будет отдельный пост.
1. На первых порах взяли IMap с репликацией 1, в кластере из 4 узлов. То есть, для каждого шарда в кластере есть 2 узла, на которых он представлен. Но, когда узел «отваливался» из кластера — вот на нем то данных и не хватало.
Сейчас перешли на ReplicatedMap.
2. Здесь я указал данные по админке, которые нужны в ETL-расчетах — в основном для обеспечения вычислений по дельтам данных (флаги, что где проходило ранее). Немного про эту систему будет в следующей части статьи. И, возможно, подробно расскажу про наш дельта-процессор отдельным постом. Но это объемно и не скоро )
Остатки распределены, и по складам и по магазинам (выступают в роли складов). Но отображать на сайте требуется не только остатки, но и условия доставки (уровень сервиса) — а на это влияют еще характеристики самого товара (крупно/мелко-габаритный, группы). В итоге, расчетов достаточно.
Как обстоят дела с распределением запросов по товарам на сайте именно сейчаc — не знаю, не могу сказать есть ли ярко выраженные пики (или наоборот, long-tail). Раньше не было.
в данных, которые использует сайт — достаточно активно обновляются остатки товара, из-за чего происходит пересчет доступности.
Все данные, которые отображаются на сайте и не являются хардкодом — попадают через базу, и почти все кешируются. Это и банеры, плашки, публикации, меню, настройки и все-все-все.
Профиль нагрузки в задачах админки того времени: put/get запросы в любой пропорции и за объектами любого размера.
Точной картинки спектра не сохранилось, но примерно:
* пропорция put/get в основном попадает в диапазон от 1:2 до 1:10, но есть несколько пиков в районе 1:100 и 1:10 000
* размер объектов — от небольших с 2-5 полями, до слонопотамов с 15 этажами вложенности (в сериализованном виде 10Кб, и несколько объектов поболее 100Кб)
на этом этапе Hazelcast кое-как устраивал. То есть, было плохо, в заданные рамки 10^5 RPS мы совершенно не укладывались, но была надежда, что можно что-то подкрутить, что-то вынести в специальный «горячий» кеш в памяти (тех самых итоговых слонопотамов, которых генерили в ETL). Была надежда, что потом еще что-нибудь в логике оптимизируем и будет нормально.
Но условия поменялись.
Добавилось очень, очень много запросов, когда по ключу нужно хранить только true/false.
И вот здесь стало совсем плохо.
То, что должны были выполнять за 10 минут — работало более 30 часов. То есть, через 30 часов тест прекратили, за сколько он отработал бы — осталось не известно.
В чем конкретно это выражалось на клиентской и серверной частях и как долго продолжалось?
На проде мы такой неприятности не ловили. Подготовились благодаря тестам на uat.
Для Hazelcast версий 6-ти летней давности, при запуске в сетевом окружении того времени — узлы довольно часто теряли друг друга из вида, из-за чего кластер перестраивался. Потом кластер восстанавливался, но на некоторое время узел мог остаться без части данных. Потребовалось время, чтоб разобраться в настройках. Сейчас такой проблемы нет.
для админки к товарному контуру, в 2017 было требование прогонять все данные за 10 минут. Прогреть кеш — в нашем случае можно было только запустив ETL на всех данных. Это порядка 30Гб сериализованных данных для результатов промежуточных вычислений.
Сайт Спортмастер работает на платформе, которую написали самостоятельно, «с нуля».
Есть еще два-три десятка торговых марок, которые принадлежат компании и для которых есть сайты разного уровня — от визитки до интернет-магазина. Сейчас переводим на свое решение, перевели практически все.
В компании есть отдел с очень сильной компетенцией по Delphi. Есть круг задач, которые очень хорошо с помощью Delphi научились решать, что ценно для внутренних заказчиков, которые привыкли и любят решения на этом продукте. Это все, что могу подсказать. Возможно, ребята из отдела Oracle смогут рассказать подробней.
Для онлайн-проектов стек технологий — Java ecosystem.
Ребята, кто сейчас допиливает Hazelcast на проде, обозначили поинты, которые сыграли важную роль:
Когда использовать распределенный кэш (hazelcast), а когда достаточно локального (caffeine) с инвалидацией данных через тот же hazelcast.
Разобрались когда использовать IMap + NearCache, а когда ReplicatedMap.
Отказались от дефолтной сериализацию в пользу Cryo
Провели мелкую донастройку.
Например, проставили hazelcast.map.invalidation.batch.enabled=false
Без этой настройки были проблемы на тестовом (не нагруженном) окружении — ломались seleinum тесты.
с Hazelcast история особая — с острыми сюжетами в проде, с заявками к разработчикам Hz, и как минимум двумя серьезными патчами с нашей стороны. Но это в 2014-2015.
Сейчас, или, собственно после того как научились его готовить, Hazelcast показывает себя отлично, никаких технически проблем с ним нет и отказываться от него не планируем. Удобный инструмент под свои задачи.
Мы именно «подхватили» работы над сайтом — взяли дизайн который тогда крутился в проде. Новый дизайн пришел уже в виде готовых макетов.
То есть, согласовывали — здесь не про то, что мы предложили и подали на согласование, но наоборот — дизайн, который был разработан для всей компании (розница, маркетинг, все коммуникации) в том числе содержал предложение для сайта, проработанное до каждой кнопочки и плашки. Нам досталась только проверка на полноту и непротиворечивость контента.
Нет не хайбрис.
Сумма сделки при покупке Hybris официально не раскрыта. А вот по «самой дорогой платформе» — сумма очень круглая, можно найти в Топ-15 крупнейших сделок интернет-проектов.
скорее, это практики, предложенные в книге Антихрупкость, в которой действительно, Н.Талеб очень много опирается на стоиков
В любом случае, с доброй улыбкой, рад услышать такой комментарий, Спасибо!
Да, все именно так, обработка заказа — это другая система.
Админка, которую разрабатывали, самая сложная ее часть — ровно про это — как генерить diff в данных подготовленных для сайта используя только diff по исходным данным. При этом схема трансформаций — это 100+ узлов и в 2 раза больше связей между ними (в среднем 1,9 связей на 1 узел). Чтоб с этим справиться в плане поддержки/доработки — был составлен движок. Внутренности этого движка активно производят вычисления и дают основную нагрузку по админке. Сложности с кешированием — словили как раз для промежуточных результатов этих вычислений.
Об этом проекте — будет отдельный пост.
Сейчас перешли на ReplicatedMap.
2. Здесь я указал данные по админке, которые нужны в ETL-расчетах — в основном для обеспечения вычислений по дельтам данных (флаги, что где проходило ранее). Немного про эту систему будет в следующей части статьи. И, возможно, подробно расскажу про наш дельта-процессор отдельным постом. Но это объемно и не скоро )
Как обстоят дела с распределением запросов по товарам на сайте именно сейчаc — не знаю, не могу сказать есть ли ярко выраженные пики (или наоборот, long-tail). Раньше не было.
Все данные, которые отображаются на сайте и не являются хардкодом — попадают через базу, и почти все кешируются. Это и банеры, плашки, публикации, меню, настройки и все-все-все.
Профиль нагрузки в задачах админки того времени: put/get запросы в любой пропорции и за объектами любого размера.
Точной картинки спектра не сохранилось, но примерно:
* пропорция put/get в основном попадает в диапазон от 1:2 до 1:10, но есть несколько пиков в районе 1:100 и 1:10 000
* размер объектов — от небольших с 2-5 полями, до слонопотамов с 15 этажами вложенности (в сериализованном виде 10Кб, и несколько объектов поболее 100Кб)
на этом этапе Hazelcast кое-как устраивал. То есть, было плохо, в заданные рамки 10^5 RPS мы совершенно не укладывались, но была надежда, что можно что-то подкрутить, что-то вынести в специальный «горячий» кеш в памяти (тех самых итоговых слонопотамов, которых генерили в ETL). Была надежда, что потом еще что-нибудь в логике оптимизируем и будет нормально.
Но условия поменялись.
Добавилось очень, очень много запросов, когда по ключу нужно хранить только true/false.
И вот здесь стало совсем плохо.
То, что должны были выполнять за 10 минут — работало более 30 часов. То есть, через 30 часов тест прекратили, за сколько он отработал бы — осталось не известно.
На проде мы такой неприятности не ловили. Подготовились благодаря тестам на uat.
Для Hazelcast версий 6-ти летней давности, при запуске в сетевом окружении того времени — узлы довольно часто теряли друг друга из вида, из-за чего кластер перестраивался. Потом кластер восстанавливался, но на некоторое время узел мог остаться без части данных. Потребовалось время, чтоб разобраться в настройках. Сейчас такой проблемы нет.
Очень подробный и точный ответ дан в предыдущем комментарии, от miksir
Добавлю только, что прогрев кеша на продакшн-объемах данных — в редкой системе не приведет к выходу даунтайма за рамки SLA.
Доклад был раньше
Спасибо!
Есть еще два-три десятка торговых марок, которые принадлежат компании и для которых есть сайты разного уровня — от визитки до интернет-магазина. Сейчас переводим на свое решение, перевели практически все.
Для онлайн-проектов стек технологий — Java ecosystem.
Например, проставили
hazelcast.map.invalidation.batch.enabled=falseБез этой настройки были проблемы на тестовом (не нагруженном) окружении — ломались seleinum тесты.
Сейчас, или, собственно после того как научились его готовить, Hazelcast показывает себя отлично, никаких технически проблем с ним нет и отказываться от него не планируем. Удобный инструмент под свои задачи.
То есть, согласовывали — здесь не про то, что мы предложили и подали на согласование, но наоборот — дизайн, который был разработан для всей компании (розница, маркетинг, все коммуникации) в том числе содержал предложение для сайта, проработанное до каждой кнопочки и плашки. Нам досталась только проверка на полноту и непротиворечивость контента.
Сумма сделки при покупке Hybris официально не раскрыта. А вот по «самой дорогой платформе» — сумма очень круглая, можно найти в Топ-15 крупнейших сделок интернет-проектов.