Для крупных платформ электронной коммерции ежедневная работа с популярными товарами и рекламные акции стали нормой, и система флэш-продаж, которая их поддерживает, естественно, является неотъемлемой частью. В то же время огромный трафик флэш-продаж подобен дикому зверю, если его не контролировать должным образом, это может повлиять на всю торговую систему. Таким образом, система флэш-продаж играет жизненно важную роль в торговой системе.

с личной точки зрения,Процедура проектирования системы флэш-продаж часто применима к другим сценариям с высоким уровнем параллелизма и имеет высокую эталонную ценность.。в то же время,его особые проблемы и потребности,Требует от архитекторов учитывать компромиссы при проектировании, что также помогает развивать личные способности к компромиссам.。

Технические решения без потерь

Работа с высоким параллелизмом похожа на борьбу с наводнениями:

• Пусть притоки разделят давление путем отвода,Риск изоляции。Проектированию программного обеспечения соответствуетИзоляция системы,разделениепоток；
• Хранение паводковых вод путем строительства водохранилищ,медленно разряжаться,сглаживание пиков и заполнение впадин。Проектированию программного обеспечения соответствуетУстранение пиков без потерь；
• за счет расширения речных каналов,Удалите ил и увеличьте скорость потока воды. Что касается проектирования программного обеспечения, его часто называют оптимизацией производительности.,например УниверсальныйМногоуровневый кэш,Высокая производительность в конкретных сценарияхИнвентарные вычеты。

Поскольку последующие решения будут вращаться вокруг нескольких уровней, через которые проходит запрос.,Местокпрежде чем представить план,Сначала нам нужно понять основную ситуацию：Основная ссылка для запроса на сервер:：DNS->шлюз->внешний интерфейс/задняя часть,Среди них пиковое значение потока также должно быть уменьшено слой за слоем. Как показано на рисунке:

1. Изоляция системы

Распределенная система состоит из издательских подразделений. Независимый издательский блок может масштабировать емкость по требованию, а также может своевременно выполнять изоляцию сбоев при возникновении сбоев, чтобы гарантировать, что сбои отдельных служб не приведут к недоступности всей системы.

Мгновенные распродажи из-за их высоких пиковых характеристик.,Месток Обычно мы изолируем его,в независимую систему флеш-продаж (обычные услуги делятся по характеристикам домена),Но вот мы здесьСквозные по категориям,Товары с целями мгновенной продажи Воля Будет перенаправлен на независимую флэш-продажу.системакластер）。

Учитывая, что объем транзакций очень велик,,Если у вас есть одна копия всей сделки для категории флэш-распродажи,Эта стоимость была бы слишком велика。Месток Разделим зону изоляции нафизическая изоляцияиЛогическая изоляция:

• нуждаться Индивидуальная Возможности логики и те, у кого есть особые нефункциональные требования, убраны, чтобы сделать Графический изоляция
• Логическая изоляция используется для возможностей, которые стандартизированы и не имеют особых нефункциональных требований.

Архитектура развертывания рисуется следующим образом:

первый,насиспользоватьНезависимое доменное имя для флэш-продажииnginxкластер（физическая изоляция）。так：

• Можеткизоляцияпоток Большая голова,Предотвращение пиковых шоков торговой системы (нефункциональные требования);
• Его можно гибко расширять для оценки масштаба nginx и последующих сервисов на разные периоды времени (нефункциональные требования);
• Возможность гибко увеличивать или уменьшать частную логику предотвращения и контроля.,Не затрагивая исходную систему транзакций (Индивидуальная логика).

затем,нас ВоляСтраница сведений о компаниии Самостоятельное развертывание страницы заказа（внешний интерфейс+BFF,физическая изоляция）。Особенности игрового процесса, основанные на флэш-продажах,Большое количество пользователей будут неоднократно обновлять страницу сведений о компании перед началом мероприятия.,Когда действие начнется, оно будет мгновенно отправлено на страницу заказа.,Месток Обе страницы подлежатпотоквлияниеиз Большая голова,нуждатьсяизоляцияоткрыть（нефункциональные требования）。в то же времяпотому чтофлэш-распродажа Активностьизхарактеристика,Товар находится в ситуации, когда спрос превышает предложение.,Продавцы имеют преимущество,Месток Можетк ДелатьПонижение уровня сервиса для снижения потребления вычислительных ресурсов и повышения производительности（Индивидуальная логика）。например：

• Вы можете удалить ограничение по времени выполнения со страницы сведений о компании и больше не рассчитывать, в течение какого времени ожидается доставка. Вы также можете удалить информацию об оценке и больше не отображать оценку;
• Страница заказа больше не может рассчитывать сумму скидки, а продукты мгновенной распродажи не участвуют ни в каких наложенных скидках. Сохраняйте только необходимую информацию, такую ​​как информация о продукте, основное изображение продукта, кнопка покупки, кнопка заказа и т. д.
• Что касается расчетной страницы и кассы, то это зависит от ситуации.,еслипоток Не большое давление Можетк Не нужно Делатьфизическая изоляцияиз（платитьвычетв наличии Разместить заказиз Давление будет передано непосредственно в поселок,Но при оформлении заказа вычет платить одновременно не нужно.,Только пользователи, которые его захватили, должны соглашаться,Давления очень мало. С точки зрения сокращения площади, затрагиваемой стоком,Здесь предполагается, что заказ размещенвычет,В конце концов, продукты флэш-распродажи не боятся, что клиенты не заплатят после оформления заказа).
• …

наконец,Успешная покупка товара также зависит от,Система заказа Создать заказ,в наличиисистемавычеттоварв наличии,Расчет, подтверждение оплаты и другие шаги. Добраться сюда поток прошел относительно гладко.,И нет логического спроса на кастомизацию (меньше давления),Нет необходимости настраивать производительность),Месток СразуиспользоватьКластеры, которые логически изолируют и повторно используют исходную торговую систему.。логикаизоляция Есть две идеи реализации：

• Первое - этоЗависит от текущих ограничивающих рамок,Например, в системе заказов источник настроен на создание запроса заказа на систему Flash Kill BFF.,TPS не может превышать 100,Количество одновременных подключений не может превышать 20;
• ВторойЗависит от платформы RPC,RPCрамка Можетк Настройка групп,Просто настройте некоторые сервисные узлы в кластере системы заказов как «группу мгновенных продаж».,Затем установите клиент сервиса флеш-продаж BFF как «вторую группу продаж».,Тогда поток системы флеш-продаж будет отправляться только на узлы, принадлежащие «группе флеш-продаж» в кластере системы заказов. Эта изоляция разделяет кластер,Меньше узлов кластера,В случае возникновения неисправности вероятность перегрузки возрастает.,Это может привести к недоступности системы флеш-продаж.

Почему при меньшем количестве узлов кластера увеличивается вероятность сбоя и перегрузки? Точно так же, как изначально было 4 полосы на километр, по которым могли параллельно проехать 4 транспортных средства, но теперь они разделены на две полосы для автомобилей и автобусов только в зависимости от типа транспортного средства. Если на одной из полос движения автомобиля произойдет дорожно-транспортное происшествие, то транспортный поток, изначально рассредоточенный по двум полосам движения, сойдётся на одной полосе, и первоначально ровное движение может сразу же начать заторяться.

2. Многоуровневый кеш

Многоуровневое кэширование — это не что иное, как кэширование данных на нескольких уровнях системы для повышения эффективности ответа. Это одно из наиболее часто используемых решений в архитектурах с высоким уровнем параллелизма.

Уровень DNS

Обычно мы подвешиваем статические ресурсы к CDN и используем CDN для разгрузки и повышения эффективности ответа. Если взять в качестве примера систему флэш-продаж, то страница сведений о компании и страница заказа фронтальной системы флэш-продаж кэшируются в сети CDN. Ссылка на запрос пользователя с использованием CDN выглядит следующим образом:

Если пользовательский терминал имеет страничный кэш, используйте локальный кэш терминала. Если нет, запросите имя домена удаленного CDN (статические ресурсы используют имя домена CDN). Запрос поступает на узел планирования DNS и назначает ближайший узел CDN. Если узел CDN имеет кэш страниц. Если нет, он инициирует отслеживание до граничной станции, и запрос пройдет по обычному каналу через систему продажи флэш-памяти к внешнему интерфейсу системы флэш-уничтожения.

уровень шлюза

Существует множество комбинаций шлюзов.,Самый простой из них — это шлюз уровня доступа плюс шлюз прикладного уровня.,например：ISV（четвертый этаж）-> Nginx (семь слоев). Если взять это в качестве примера, то оптимизация кэша здесь в основном зависит от алгоритма балансировки нагрузки уровня доступа, а также локального кэша и централизованного кэша памяти уровня приложения.

Из Местокобъяснятькэш Также упомяните алгоритм балансировки нагрузки.,Это потому чтоЭффективность локального кэша узла и алгоритма балансировки нагрузки строго связаны.。Обычно используетсяиз Алгоритм балансировки нагрузки имеет опрос(Также называется взятием формы)ипоследовательное хеширование。Опрос может сделать распределение запросов более сбалансированным,Однако запросы с одним и тем же кэш-ключом не могут быть перенаправлены на один и тот же уровень приложения Nginx.,Частота попадания в локальный кеш Nginx низкая。последовательное хешированиеМожетк Пусть то же самоекэшkeyМаршрут к тому же прикладному уровнюNginxначальство,Частота попадания в локальный кеш Nginx высока,Но этоНесбалансированное распределение запросов может привести к проблемам с точкой доступа на одном компьютере.。Есть вид Делать Закондаустановить порог,Переход к опросу, когда запрос одного узла превышает пороговое значение,Можетк Рассчитатьда Адаптивная балансировка нагрузкиизвариант。но Этот видна основепороговое суждениеиз Делать Закон在отвечать对真正из Высокий Эффект не идеален при использовании параллелизма.

Месток Хотите использовать локальныйкэш Сильная зависимость от деловых операций,Необходимо иметь более точную оценку каждого горячего ключа продукта.,И искусственно объединить эти ключи продуктов,Затем контролируйте, чтобы поток равномерно распределялся на каждом уровне приложения Nginx (фактически сегментирование данных,Тогда каждая часть данных непротиворечива). это очень сложно,МестокАвтор считает, что проще и эффективнее использовать опрос и централизованное кэширование памяти.。

Ссылка запроса, начинающаяся с уровня доступа с локальным кешем и централизованным кешем памяти, выглядит следующим образом:

уровень обслуживания

Прикладной уровеньngnix->флэш-распродажасистемаBFF->Заказать услугу,Фактически сочетание двухиуровень шлюзада Такой жеизсцена。Прикладной уровеньngnixна основеngnixиз Балансировщик нагрузки перенаправляет запрос нафлэш-распродажасистемаBFF,флэш-распродажасистемаBFFна основеRPCрамкаиз Балансировщик нагрузки перенаправляет запрос на Заказать услугу。Стоят перед выбором стратегии балансировки нагрузкии Включить ли локальныйкэшизвопрос。不Такой жеиз Просто нажмитедакэшиздетализацияидавать возможностькэшиз Выбор стека технологий。

Инвалидация многоуровневого кэша

Многоуровневое кэширование. Поскольку кэш рассредоточен по нескольким уровням, сложно использовать один технологический стек для решения проблемы аннулирования кэша. Однако, если вы подождете, пока истечет срок действия кэша, такое обновление займет много времени. и могут быть не приняты предприятием. Поэтому я еще раз затрону эту тему здесь. Один из подходов основан на мониторинге бинлога БД. Каждый уровень отслеживает свою собственную соответствующую информацию бинлога. При изменении кэша кэш встроенной памяти сразу же становится недействительным. У локального кеша здесь тоже есть недостаток, то есть при сбое кеша его нужно транслировать на все узлы, что делает каждый узел недействительным. Для горячих клавиш, которые часто меняются, может возникнуть шторм сообщений.

3. Устранение пиков без потерь

Flash-продажи характеризуются мгновенным пиковым трафиком, похожим на возвышающийся шпиль, с большим количеством запросов, поступающих за короткий период времени. Для подготовки соответствующего кластера услуг к этому пику, во-первых, стоимость слишком высока, а затем простое горизонтальное расширение может оказаться невозможным (распределенная архитектура имеет проблему количественного изменения, вызывающего качественные изменения, если ресурсы расширяются до определенного уровня). уровень, оригинальное техническое решение не сможет достичь этого. Например, когда узлов кластера слишком много, регистрация службы может вызвать бурю сообщений, может возникнуть узкое место в пропускной способности входа и выхода; развертывание необходимо отклонить). Не говоря уже о том, что это пиковое значение также выходит из-под контроля. Если вы хотите расслабиться и отдохнуть, будет много избыточности и потерь.

Поэтому обычно мы будем использовать метод исключения пиков:

• Один из них — обезглавить напрямую,ПучокТрафик, превышающий нагрузку, отбрасывается напрямую.,также СразуданасобщийизОграничение тока,Также известно как устранение пика с потерями (если это крупный заказ на продвижение).,Все, что отрезано, может быть, это деньги.,Эта потеря – настоящая потеря);
• Другое - отвлечение,также называетсяУстранение пиков и заполнение впадин,Запрос на ошеломление техническими или деловыми средствами,Распространение на более длительный срок,тем самым уменьшая пик,общийизиметьАсинхронное потребление MQи Вопросы викторины по коду подтверждения。

Здесь мы сначала поговорим об устранении пиков без потерь, а об устранении потерь позже.

Асинхронное потребление MQ

MQ依赖三个характеристика Можетк Делатьприезжатьгладкийизокончательный консенсус,Они естьСообщения накапливаются, обрабатываются с постоянной скоростью и успешны хотя бы один раз.：

• Только когда новости накапливаются, можно добиться эффекта резервуара.,Когда скорость потока на выходе воды постоянна, он может улавливать мгновенный большой поток на входе воды;
• Только при равномерном потреблении давление нижестоящего кластера может быть постоянным и не подвергаться влиянию;
• Лишь добившись успеха хотя бы один раз, можно обеспечить окончательную последовательность вещей.

В качестве примера возьмем операцию заказа BFF системы флэш-продаж, чтобы создать заказ для службы заказов. Если нет очереди сообщений (MQ) и одновременно поступает 1 миллион запросов на создание, система заказов должна выдержать нагрузку 1 миллиона параллельных подключений. Однако если используется MQ, все давление 1 миллиона запросов на создание будет передано на сервер MQ, а системе заказов необходимо поддерживать только 64 параллельных соединения для стабильного потребления сообщений с сервера MQ.

Таким образом,Размер кластера системы заказов можно значительно уменьшить.,и что еще более важно,Стабильность системы гарантирована。Из-за количества параллельных соединенийизуменьшать,Конкуренция за ресурсы также снизится.,Общая эффективность реагирования также будет повышена.,Это как стоять в очереди за едой в столовой,Организованная очередь более эффективна, чем суета. но,Пользовательский опыт может быть затронут,Потому что после нажатия кнопки «Купить покупку» вы можете получить приглашение встать в очередь (на самом деле дружеское напоминание).,Задержка результатов покупки занимает десятки секунд или даже минут.

Вопросы викторины по коду подтверждения

Представляем вопросы Викторины по коду подтверждения на самом деле имеет два уровня преимуществ.,Первый уровень – устранение пиков,События одновременного заказа пользователя в течение 0,5 секунды,Из-за личных различий в скорости рук,плавно разбивается на секунды или даже десятки секунд, другой слой — Печать;,Увеличение стоимости машинного мошенничества.

Проверочный код

Основные этапы реализации следующие:

• При поступлении запроса генерируется 6-значный случайный строковый код_проверки.
• Используйте определенный префикс, чтобы объединить идентификатор пользователя в качестве ключа и код проверки в качестве значения для хранения в Redis с тайм-аутом 5 секунд.
• Создайте изображение, напишите в него код проверки и верните его пользователю.
• Пользователь вводит строку в изображение
• Возьмите код проверки из Redis и сравните его. Если они совпадают, выполните операцию заказа.

нотакна самом деледа Можетк Используйте грубую силу, чтобы взломатьиз,например,Используйте машину для имитации действий пользователя.10Wзапросы несут разныеиз6немного случайные символы。Местокпроверять Проверочный Может использоваться, когда код GETDEL ,позволять Проверочный код проверь правильный он или нет, пусть Проверочный код недействителен.

вопросы викторины

Основные идеи реализациии Проверочный код почти тот же. Разница в том, что Банк вопросов для вопросов викторины должен быть сформирован заранее.,Получите набор вопросов из банка вопросов, когда поступит запрос.и Отвечать。Затем Пучок Отвечатьжитьredis,Поместите вопрос в картинкувозвращатьсяпользователю。

Проверочный кодивопросы викторина обладает хорошим эффектом устранения пиков. Особенно вопросы викторины, если вы хотите улучшить эффект исключения пиков, вам нужно только увеличить сложность вопроса. Например, автор однажды ошибся в вопросе 12306 более десяти раз подряд. викторины。нода这такжедапользователь体验иметь损из,Например,Хотя автор был расстроен, когда ему не удалось достать билеты.,Но этот волшебный банк вопросов все равно меня успешно рассмешил.

Никакой потери пиковой нагрузки, никакой потери трафика, но потери пользовательского опыта. В настоящее время технологический уровень постоянно совершенствуется, а количество решений увеличивается. Эти технические решения, которые вредят пользовательскому опыту, могут постепенно уйти со сцены истории, так же, как Taobao отменил предварительные продажи 618.

4. Инвентаризационные вычеты

Мы знаем, что пользователям необходимо вычитать запасы при покупке товаров. Для вычета запасов необходимо проверить, достаточен ли запас. Если его недостаточно, он вернет недостаточный запас (товар). Здесь не различается статус доступных, занятых, потребленных и т. д. запасов, и он объединяется в количество вычтенных запасов (упрощенный сценарий).

В параллельных сценариях,еслиЗапрос инвентаря и вычет инвентаря не являются атомарными.,Сразуиметь Можетспособныйперепроданность,Вероятность перепроданности в сценарии «Высокий параллелизм» увеличится.,Сумма перепроданности также увеличится. Решение проблем перепроданности — это хлопотно.,с одной стороны,система Полная чистка будет затруднительна (сотрудничество нескольких команд),Также потребуются дополнительные расходы на исходящие звонки в службу поддержки клиентов. Другой одной стороны,Это также основная причина,Клиент получил заказ, но затем его отменили.,Серьезно повлияет на качество обслуживания клиентов,Это может даже привести к жалобам клиентов и кризисам в отношениях с общественностью.

Реализуйте логику

Обычно используемое решение в отрасли — использовать redis+lua. С помощью Redis однопоточное выполнение+логика в скрипте lua может быть выполнена последовательно за одно выполнение для достижения атомарности (атомарность на самом деле не очень точна. Она может быть выполнена). точнее называть это эксклюзивностью. Потому что действия отката здесь нет, нештатные ситуации нужно откатывать самостоятельно).

Базовая реализация сценария Lua примерно следующая:

-- Получить кэшкей инвентаря KYES[1] = hot_{itemCode-skuCode}_stock
local hot_item_stock = KYES[1]
-- Получить оставшееся количество запасов
local stock = tonumber(redis.call('get', hot_item_stock)) 
-- Количество покупки
local buy_qty = tonumber(ARGV[1])
-- еслив наличиименьше, чем Количество покупки затем вернись 1, Экспресс-дефицит запасов
if stock < buy_qty then return 1 end
-- Достаточно запаса 
-- Обновить количество запасов 
stock = stock - buy_qty
redis.call('set', hot_item_stock, tostring(stock))
-- Вычет выполнен успешно затем вернись 2,Выражать Инвентарные вычетыуспех
return 2 end

Но у этого скрипта есть некоторые проблемы:

• Он не идемпотентен. Если один и тот же заказ выполняется несколько раз, возникает проблема повторных удержаний. Ручной откат не может определить, был ли он откатан, и возникает проблема повторного увеличения.
• Отслеживаемости нет, и неизвестно, кто из какого заказа списал запасы.

Объединив вышеуказанные проблемы, мы внесли некоторые улучшения в решение.

Расширенный сценарий Lua выглядит следующим образом:

-- получать Инвентарные вычеты Записыватькэшkey KYES[2] = hot_{itemCode-skuCode}_deduction_history
-- использовать Redis Cluster hash tag гарантировать stock и history в том же слоте
local hot_deduction_history = KYES[2]
-- Запросить идемпотентное суждение, вернуть 0, если существует, Сообщите, что запасы были вычтены
local exist = redis.call('hexists', hot_deduction_history, ARGV[2])
if exist = 1 then return 0 end

-- Получить кэшкей инвентаря KYES[1] = hot_{itemCode-skuCode}_stock
local hot_item_stock = KYES[1]
-- Получить оставшееся количество запасов
local stock = tonumber(redis.call('get', hot_item_stock)) 
-- Количество покупки
local buy_qty = tonumber(ARGV[1])
-- еслив наличиименьше, чем Количество покупки затем вернись 1, Экспресс-дефицит запасов
if stock < buy_qty then return 1 end
-- Достаточно запаса 
-- 1.Обновить количество запасов 
-- 2. Вставьте запись о вычете ARGV[2] = ${Уникальный ключ для запроса на вычет}-${тип вычета} Значение buy_qty
stock = stock - buy_qty
redis.call('set', hot_item_stock, tostring(stock))
redis.call('hset', hot_deduction_history, ARGV[2], buy_qty)
-- Если остаток запаса равен 0 затем вернись 2, Инвентарь выражений достиг 0
if stock = 0 then return 2 end
-- Оставшийся инвентарь не равен 0 возвращаться 3 Сообщите, что есть остатки
return 3 end

• Используйте хэш-тег Redis Cluster, чтобы гарантировать, что акции и история находятся в одном слоте, чтобы сценарий Lua мог выполняться нормально.
• Используйте hot_deduction_history, чтобы определить, был ли выполнен запрос на вычет для достижения идемпотентности.
• Используйте значение hot_deduction_history, чтобы определить источник ретроспективного вычета, например запрос на вычет по заказу транзакции A пользователя A или запрос на вычет по кредитному заказу B пользователя B.
• Логика отката сначала определит, есть ли ${уникальный ключ запроса удержания} в hot_deduction_history. Если да, то логика отката будет выполнена. Если нет, логика отката будет считаться успешной.

Однако в приведенной выше логике все же есть лазейки. Например (потребление сообщения вне очереди), тайм-аут списания запасов по заказу успешно запускает повторное списание запасов, но в то же время отмена заказа вызывает откат. Вычет инвентаря Сначала выполняется логика отката, а затем снова выполняется тайм-аут. Если инвентарь вычитается, «грязные» данные останутся в Redis.

Есть два варианта лечения,Один из нихДополнительная сверка,Регулярно проверяйте статус документов, соответствующих данным в hot_deduction_history.,Добавьте запрос на откат отмененного документа,Возникает задержка (которая может быть неприемлема для бизнеса) и дополнительные затраты вычислительных ресурсов.。Другой Что-то вроде,даиспользоватьзаказанное сообщение,позволятьвычетв наличиииоткатв наличии Все идут одинаковоMQ topicизиметь序队列,С помощьюMQинформацияизиметь序性гарантировать Действие отката должно быть ввычет Выполнить после действия,Но упорядоченная сериализация неизбежно приведет кухудшение производительности。

Высокая доступность

В конце концов, redis — это память. Как только служба будет прервана, данные полностью исчезнут. Поэтому необходимы дополнительные решения для защиты данных от потери.

Это реализовано с использованием решения «Высокая доступность», развернутого Redis. Решение выглядит следующим образом:

• Используйте кластер Redis (шардинг данных + множественные копии + синхронная множественная запись + автоматический выбор главного-подчиненного).
• Напишите несколько узлов и разделите их на несколько центров (в одном городе и в разных местах), чтобы предотвратить непредвиденные катастрофы.

Регулярно архивируйте холодные данные. Периодический + инвентаризация равна 0, чтобы запустить синхронизацию данных Redis с БД. Процесс выглядит следующим образом:

Когда CDC распространяет данные о продуктах флэш-продажи, объем данных hot_deduction_history невелик и может быть синхронизирован полностью сразу. Но если это обычный продукт с большой продажей, вам необходимо добавить еще одно действие карты для его пакетной обработки, чтобы гарантировать, что объем данных для каждого выполнения CDC является постоянным, чтобы объем данных одновременно не был слишком большим и ООМ не произойдет. Конкретный код выглядит следующим образом:

/**
 * Распределяйте задачи
 * @param stockKey Ключевое значение целевого инвентаря
 */
public void distribute(String stockKey){
    final String historyKey = StrUtil.format("hot_{}_deduction_history", stockKey);
    // Получить указанный ключ инвентаря Ключи всех записей вывода (обычно получаются страницами, чтобы предотвратить слишком много данных и флуктуаций памяти, здесь я буду ленив)
    final List<String> keys  = RedisUtil.hkeys(historyKey, stockKey);
    // к 100 Разрезать все записи по размеру key
    final List<List<String>> splitKeys = CollUtil.split(keys, 100);
    // Воля Коллекция распространяется на каждый узел для выполнения.
    map(historyKey, splitKeys);
}
/**
 * Выполнение одностраничных задач
 * @param historyKey Ключевое значение целевого инвентаря
 * @param stockKeys  размер страницы для выполнения
 */
public void mapExec(String historyKey, List<String> stockKeys){
    // Получить указанный ключ инвентаря Укажите запись о вычете  карта
    final Map<String, String> keys = RedisUtil.HmgetToMap(historyKey, stockKeys);
    keys.entrySet()
        .stream()
        .map(stockRecordFactory::of)
        .forEach(stockRecord -> {
            // (Идемпотент + Удалить дубли) вычет + Ведите записи
            stockConsumer.exec(stockRecord);
            // Удалить в Redis key освободить место
            RedisUtil.hdel(historyKey, stockRecord.getRecordRedisKey());
        });
}

Почему бы не зайти в БД

Данные о запасах продукции в БД в конечном итоге попадут в одну строку данных в одной базе данных и одной таблице. Параллелизм запросов невозможно улучшить путем сегментирования баз данных и таблиц. В сценарии с одним узлом пропускная способность базы данных намного уступает Redis. Самая основная причина: эффективность ввода-вывода не одного порядка. БД — это дисковая операция, и может потребоваться несколько операций чтения с диска. Redis — это одноэтапная операция с памятью.

В то же время общая БД привязана к уровню изоляции чтения. Чтобы обеспечить атомарность и выполнить инвентаризацию, требуется блокировка, независимо от пессимизма или оптимизма. Это не только снижает производительность (вам придется подождать, если вы не можете захватить блокировку), но и склонно к истощению потоков из-за недобросовестной конкуренции. Redis — это однопоточная операция, и здесь нет проблем конкуренции общих переменных.

Существуют некоторые идеи оптимизации, такие как объединение выводов и пакетная обработка для уменьшения количества запрашиваемых параллельных соединений. Однако сопровождается задержкой комплектования заказов и требованием комплектования по складу, также происходит разделение складских строк. Запасы товара А100 разбиваются на 2 ряда запасов товара А50, а затем вычет. делается при раздаче запроса на улучшение количества параллельных подключений (несколько строк могут попасть в разные библиотеки для увеличения количества параллельных подключений).

Но это сопровождается сложным управлением разделением строк запасов (разделение строк запасов на какие склады и в какое время) и проблемой перепроданности некоторых строк запасов (оптимизация блокировки приведет к повторной сериализации без добавления общей суммы). вопрос о том, являются ли отдельные строки запасов недостаточными для того, чтобы допустить перепроданность на определенный коэффициент или возврат к недостаточным запасам, является вопросом принятия решения).

Некоторые ведущие компании электронной коммерции по-прежнему используют слабую защиту от чтения кэша (не недостаточный инвентарь, отсутствие обновлений в реальном времени) и решения по защите от записи в БД. Предпосылкой этого является то, что благодаря ряду технических решений поток трафика к инвентарю стал относительно низким и плавным (с этим можно мириться, и нет необходимости самостоятельно реализовывать атомарность операций).

Техническое решение с потерями

Флэш-распродажа имеет чрезвычайно высокий мгновенный поток.,ноТолько очень небольшой объем трафика может быть успешно запрошен。Этонас绕открыть海量计Рассчитать资源использовать一些特定方案达приезжать同样из Активность效果提供了空间。Потому что большая частьпоток Вседа Запрос не выполнениз,Является ли это реальной неспособностью купить инвентарь или неспособностью отфильтроваться правилами?,Это все провал,Для участниковобъяснятьда Такой жеиз Активность体验。Местокнас Не нужно耿直地去承接Местоиметьпоток,в серию фильтров,Честно и справедливо отфильтровать большую часть потока,仅保留иметьпределизвысокое качествопоток Можетк请求приезжать服务群即Может。

Основная идея заключается в том,,Блокировка недействительного потока посредством вмешательства бизнеса,Отменить перезарядку с помощью потока подавления пиковых значений с потерями,Блокировка нелегального потока с помощью Печать Контроль риска,Наконец, качественный и небольшой объем потока остается ниже по течению. Как показано на рисунке:

1. Вмешательство бизнеса

Отчет

С помощью Отчетсистемы,商户открыть展高压力из Активность时Все提早报备接受审批иконтроль。так,Можетк Знайте продукт заранее、цена、Время начала мероприятия、Для какой области?、Предполагаемое количество участники, требования к членству и др. Информация. Помогите оценить примерную цену.,Поддержка действий по оркестрации и корректировка комбинаций действий.,Смещенное давление (также может постоянно сохранять горячие точки),гладкийпоток,Настройте компьютерные ресурсы, чтобы справиться с Высоким параллелизмом. Установите пороговые значения участия,Не допускайте участия нецелевых людей.

бронировать

С помощьюбронироватьсистема,Разогрейте мероприятие, помогите оценить примерное количество человек, участвующих в мероприятии, оцените возможности вычислительных ресурсов. Введение правила «Контроль рисков»,Отфильтруйте толпу кистей заранее。использовать Выдать квалификацию участия（Похожие игрыбронировать Тестовая квалификацияипроблема Тестовая квалификация）,Контролируйте количество участников. Объединение параметров Отчетсистемы,Отфильтровать нецелевые группы,и делать все возможное Можетспособный提高参与人员离散度（напримерсертификат участия1W,по 2500 для Южного Китая, Северного Китая, Восточного Китая и Западного Китая) (Предположим, что сфера влияния победителя представляет собой круг,Когда люди соберутся в этом кругу, произойдет пересечение.,Сфера влияния будет уменьшена,Местокхотелось бы быть более дискретным。нотакже不排除иметь故意集中проблема创造热点измаркетингозначает）。

член

С помощью членсистемы,Отфильтруйте высококачественных пользователей。готов купитьчлениз Относительная липкость пользователя Сразуотносительно высокий（Можетк С помощьючленсистема Делать Некоторые улучшают привязку пользователейизмеры,кредитных баллов,интеграл,членоценка,купоны и др.). В то же время размер пользователей также может помочь спрогнозировать участие в мероприятии.

Лимит покупки

С помощью Лимит покупкисистема,например Усиление охвата рынка в конкретных регионах,Запрещено из региона,Только Восточный Китай Можетк Участвовать в закупке；Предотвращение и контроль общественного мнения и связей с общественностью,Ограничение от пользователя,Запрещено закупать собственным сотрудникам (они не могут одновременно судить и играть в футбол), что увеличивает степень дисперсии;,От ограничений продукта,Одновременно можно приобрести только один товар,Один человек может совершать покупки только один раз в месяц.

2. Устранение пика потерь

Ранее мы говорили об устранении пиков без потерь при разделении. Здесь мы говорим об устранении пиков с потерями при прямом удалении головки. Традиционное решение состоит в использовании текущих методов ограничения и понижения версии, что также является необходимым методом для борьбы с высоким уровнем параллелизма.

Ограничение тока является методом низшего уровня самозащиты системы. Независимо от того, насколько мощна система, всегда существует верхний предел ее пропускной способности. Как только трафик превысит этот верхний предел, это приведет к простою экземпляра, а затем произойдет лавина системы с катастрофическими последствиями. Поэтому после достижения этого лимита трафика отвечать на запросы в любом случае уже невозможно, поэтому оптимальным решением является прямой сброс этих запросов и обеспечение возможности нормального взаимодействия с ограниченным трафиком.

Иерархическое ограничение тока

Мы знаем, что запрос пройдет несколько уровней.,最终才способныйприезжать达响отвечать请求изсервисный узел。Предположим, запрос пройдетшлюз->одиночная услугакластер->один сервисный узел->Уровни единого интерфейса,Учитывайте пропускную способность на каждом уровненачальствопределиз Размерыи Емкости разные,Местокв целом Все会иметь独立из Ограничение тока правила.

шлюзв целомдак Конфигурация маршрутизации или наборapiиз Показатели пропускной способности осуществляются Ограничение тока,Конкретная конфигурация примерно следующая:

одиночная услугакластерв целомдаквеськластер МестоиметьAPIи Местоиметьсервисный узел为Показатели пропускной способности осуществляются Ограничение ток (не часто используется),Конкретная конфигурация примерно следующая:

один сервисный узелв целомдаксервисный узелизусловия нагрузки Ограничение тока,например Нагрузка (полное расчетное значение), ЦП, память и т. д.

单接口в целомдаквеськластеризодинAPIизпоказатели пропускной способности Ограничение тока。

Ограничение тока параметра точки доступа

Помимо иерархического ограничения тока, существует также параметрическое ограничение тока.

Например, ограничение тока основано на показателе пропускной способности IP-адреса. Это измерение очень недружелюбно по отношению к корпоративным пользователям. Поскольку обычно у компаний есть только несколько IP-розеток и все подключены к Wi-Fi, можно легко активировать ограничение тока. Поэтому, участвуя в распродажах, обычно лучше переключиться обратно на собственную сеть 4G. Независимо от того, насколько быстрым является Wi-Fi, он не выдерживает ограничений.

Например, ограничение тока основано на показателях пропускной способности горячих товаров. При отсутствии текущего ограничения измерения продукта предположим, что одновременный текущий предел кластера интерфейса заказа флэш-продажи равен 100, и в мгновенной продаже одновременно участвуют 10 продуктов. Продукт А мгновенно захватывает 80 одновременных подключений. , а остальные 9 продуктов могут использовать только 20 одновременных подключений, что серьезно повлияет на его работу.

Существует множество различных калибров ограничения потока, и, к счастью, их можно комбинировать. Это гарантирует, что службы имеют надежную базовую защиту в различных сценариях.

3.Печать Контроль рисков

Дисбаланс спроса и предложения в флэш-распродажах,также会吸引黑产пользователь С помощьюнетрадиционныйозначаетспешу купить。например,С помощью мастера физического или программного ключа,чем обычные пользователиболее высокая скоростьспешу купить；Имитируйте запросы заказов через интерфейс анализа,Инициировать десятки миллионов запросов одновременно,чем обычные пользователиболее высокая частотаспешу купить。Такое поведение не только подрывает справедливость мероприятия.,Угрожать Пратту и Уитниидискретные требования,Это также выводит на новый уровень вызов пику Высшего параллелизма системы.,Серьезно влияют на здоровое развитие деятельности.

Печать

С точки зрения более высокой скорости трудно отличить обычных пользователей от нелегальных пользователей.,Но более высокие частоты легко уловить,Ведь нормальные люди не могут1Тысячи раз в секундуиз Нажмите на него。Местокнас Можетк Постройте несколько для высокочастотного сценария Печатьозначает。

Текущее ограничение на основе userID

нас Можеткиспользовать Ограничение тока параметра точки доступ способ сделать Ограничение на основе метрик пропускной способности идентификатора пользователя тока。Например,Предусмотрено, что каждый идентификатор пользователя может инициировать только два запроса в секунду. и,насотвечать Воляэтот Ограничение тока Примите все меры Можетспособный地置于请求链路изначальствотур,Например, шлюз приложений,к Только на самом внешнем слое Сразуизоляция Потерять главноепоток,Тем самым сокращая трату вычислительных ресурсов. Цель такого типа ограничения тока немного отличается от обычного устранения пиковых потерь.,Он предназначен не только для защиты стабильности сервиса.,Мы также предотвращаем атаки со стороны чернокожих пользователей.,кэтот维护Активностьизсправедливость。

Ограничение трафика по черному списку

все ещедаиспользовать Ограничение тока параметра точки путь доступа. Но дело уже не в показателях пропускной способности, а в том, попадет ли она в черный список для достижения Ограничения. тока。Внутри черного спискаизсписок,с одной сторона полагается на некоторый внутренний поведенческий анализ,например Находите пользователя каждую секунду Можетк Запросите десятки миллионов раз, чтобы идентифицировать（Сразу像тур戏里面发现外挂封号）。Другойс одной стороны Сразуда Внешне Контроль данные о рисках были импортированы.

Контроль рисков

Контроль Риск занимает важное место в системе защиты, но его установление довольно сложно. звуковой контроль Система рисков должна опираться на большой объем данных и пройти строгую проверку реальных бизнес-сценариев. Проще говоря, Контроль Риск подобен рисованию портрета пользователя, который требует сбора статической информации пользователя, такой как удостоверение личности, IP-адрес, номер устройства (например, параллельные покупки нескольких учетных записей для одного и того же устройства или одного и того же IP-адреса), кредитные записи, информация социального страхования, рабочая информация и другая многомерная информация. Также обратите внимание напользовательиз Динамическая информация,Например, существует ли ситуация, когда в секунду инициируются десятки миллионов запросов?,Или активен ли пользователь только во время определенных действий и т. д.

краткое содержание

Высокий параллелизмиз Основной задачей являетсяВнезапный всплеск пользовательских запросов требует одновременного использования большого количества вычислительных ресурсов.。Чтобы решить эту проблему,Интернет-приложения пошли по пути развития горизонтального масштабирования.,то есть распределенная архитектура,Увеличьте вычислительную мощность за счет постоянного масштабирования узлов кластера. Большинство перечисленных нами решений прямо или косвенно основаны на проектировании распределенной архитектуры.,МестокОсвоение распределенной архитектуры фактически эквивалентно овладению основами проектирования систем с высоким уровнем параллелизма.。

Отличная архитектура уделяет больше внимания компромиссам, а не стремлению к крайностям. Мы должны начать с бизнес-сценария и фактической ситуации на предприятии, чтобы найти подходящее решение с высокой отдачей от инвестиций, а не переусердствовать или искать самое экстремальное решение. Мы также не должны слепо следовать так называемым «лучшим практикам» из страха отстать или воспользоваться возможностями.