предисловие
Многие мелкие партнеры сообщают, что они так долго изучали тему высокого параллелизма, но когда они фактически работают над проектом, они все еще не знают, как работать с бизнес-сценариями с высоким параллелизмом! Даже многие небольшие партнеры все еще находятся на стадии простого предоставления интерфейсов (CRUD) и не знают, как применить полученные знания о параллелизме в реальных проектах, не говоря уже о том, как построить систему с высокой степенью параллелизма!
Какая система считается системой с высокой степенью параллелизма? Сегодня мы расшифруем архитектуру типичной системы seckill в бизнес-сценариях с высоким параллелизмом в сочетании с другими статьями по теме высокого параллелизма и применим то, что узнали.
Архитектура системы электронной коммерции
В сфере электронной коммерции существуют типичные бизнес-сценарии seckill, так что же такое сценарий seckill? Проще говоря, количество покупателей продукта намного больше, чем запасы этого продукта, и этот продукт будет распродан за очень короткий период времени. Например, ежегодное продвижение 618, Double 11, продвижение новых продуктов Xiaomi и другие бизнес-сценарии являются типичными бизнес-сценариями всплеска.
Мы можем упростить архитектуру системы электронной коммерции, как показано на рисунке ниже.
Как показано на рисунке, мы можем просто разделить базовый уровень системы электронной коммерции на: уровень балансировки нагрузки, прикладной уровень и уровень сохраняемости. Далее мы оцениваем параллелизм каждого слоя.
-
Если уровень балансировки нагрузки использует высокопроизводительный Nginx, мы можем оценить, что максимальный параллелизм Nginx составляет: 10 Вт+, где единица равна 10 000.
-
Предположим, мы используем Tomcat для прикладного уровня, и максимальный параллелизм Tomcat можно оценить примерно в 800, здесь единица сотен.
-
Предполагая, что кеш слоя сохраняемости использует Redis, а база данных использует MySQL, максимальный параллелизм MySQL можно оценить примерно в 1000 тысяч. Максимальный параллелизм Redis можно оценить примерно в 5 Вт в единицах по 10 000.
Следовательно, параллелизм уровня балансировки нагрузки, прикладного уровня и уровня сохраняемости различен Итак, какие решения мы обычно можем принять, чтобы улучшить общий параллелизм и кэш системы?
(1) Расширение системы
Расширение системы включает расширение по вертикали и расширение по горизонтали, увеличение конфигурации оборудования и машин и является эффективным в большинстве сценариев.
(2) Кэш
Локальный кеш или централизованный кеш, сокращение сетевого ввода-вывода и чтение данных на основе памяти. Работает в большинстве сценариев.
(3) Разделение чтения и записи
Используйте разделение чтения и записи, разделяйте и властвуйте и увеличивайте возможности параллельной обработки данных на машине.
Особенности системы seckill
Для системы seckill мы можем начать сБизнес и технологииДва ракурса, чтобы проиллюстрировать некоторые из его собственных характеристик.
Бизнес-характеристики системы seckill
Здесь мы можем использовать в качестве примера веб-сайт 12306. Каждый год во время Праздника Весны трафик веб-сайта 12306 очень велик, но трафик веб-сайта относительно медленный.То есть каждый год во время Праздника Весны. , трафик веб-сайта 12306 будет выше.Это явление резко возросло.
Другим примером является система мгновенного уничтожения Xiaomi, которая начинает продавать товары в 10:00 утра.Объем трафика до 10:00 относительно ровный, а также будет мгновенное внезапное увеличение одновременного объема в 10:00.
Поэтому мы можем использовать следующий рисунок для представления трафика и параллелизма системы seckill.
Из рисунка видно, что параллелизм системы всплесков имеет характеристики мгновенного пика, который также называют явлением всплеска трафика.
Мы можем резюмировать бизнес-характеристики системы seckill следующим образом.
(1) Ограничено по времени, ограничено и ограничено по цене
Это будет осуществлено в течение указанного времени, количество товаров в событии seckill ограничено, цена товара будет намного ниже первоначальной цены, то есть в событии seckill товар будет продан по гораздо более низкой цене, чем первоначальная цена.
Например, деятельность seckill ограничена с 10:00 до 10:30 в определенный день, количество товаров составляет всего 100 000, а цена на товары очень низкая, например: покупка за 1 юань и другие виды бизнеса. сценарии.
Ограничение по времени, ограничение и ограничение по цене могут существовать по отдельности или в комбинации.
(2) Активная разминка
Событие должно быть настроено заранее; до начала события пользователи могут просматривать соответствующую информацию о событии; до начала события seckill энергично рекламировать событие.
(3) Короткая продолжительность
Количество покупателей огромно, товары быстро раскупаются.
В представлении системного трафика будет явление всплеска.В это время одновременный трафик очень высок.В большинстве сценариев всплеска продукты будут распроданы за очень короткое время.
Технические характеристики шиповой системы
Мы можем резюмировать технические характеристики системы seckill следующим образом.
(1) Мгновенный параллелизм очень высок
Большое количество пользователей будет хватать элементы одновременно; мгновенные всплески параллелизма очень велики.
(2) Больше читайте и меньше пишите
Количество посещений страниц товаров в системе огромно, количество товаров, которые можно купить, очень мало, количество посещений инвентарного запроса намного больше, чем количество купленных товаров.
Некоторые меры по ограничению тока часто добавляются на страницы продуктов. Например, на странице продукта ранней системы seckill будет добавлен проверочный код, чтобы сгладить трафик внешнего доступа к системе. Страница сведений о недавнем продукте системы seckill будет предлагать пользователю войти в систему, когда пользователь открывает страницу. Все это меры по ограничению текущего доступа к системе.
(3) Процесс прост
Бизнес-процесс системы seckill, как правило, относительно прост; в целом бизнес-процесс системы seckill можно резюмировать следующим образом: размещение заказа и сокращение запасов.
Для такой системы с большим трафиком за короткий промежуток времени нецелесообразно использовать расширение системы, потому что даже если система будет расширена, расширенная система будет использована за очень короткий промежуток времени, доступ к ней возможен в обычном режиме. без расширения. Итак, какие решения мы можем предпринять, чтобы улучшить производительность системы seckill?
Системное решение Seckill
В соответствии с характеристиками системы seckill мы можем принять следующие меры для повышения производительности системы.
(1) Асинхронная развязка
Весь процесс разбирается, а основной процесс контролируется очередью.
(2) Ограничение тока и защита от щеток
Контролируйте общую посещаемость сайта, повышайте порог запросов и избегайте истощения системных ресурсов.
(3) Контроль ресурсов
Контролируйте планирование ресурсов в общем процессе, чтобы максимизировать сильные стороны и избежать слабых сторон.
Потому что уровень параллелизма, который может поддерживать прикладной уровень, намного меньше, чем у кэша. Следовательно, в системе с высокой степенью параллелизма мы можем напрямую использовать OpenResty для доступа к кешу с уровня балансировки нагрузки, избегая потери производительности при вызове прикладного уровня. каждый может прийтиopenresty.org/cn/Приходите узнать больше об OpenResty. В то же время, поскольку количество продуктов в системе seckill относительно невелико, мы также можем использовать технологию динамического рендеринга и технологию CDN для ускорения доступа к веб-сайту.
Если параллелизм слишком высок в начале Lightning Deal, мы можем поместить запрос пользователя в очередь для обработки и открыть страницу очереди для пользователя.
Картинка с Мейзу
Диаграмма последовательности операций системы Seckill
Многие seckill-системы и решения для seckill-систем в интернете не являются настоящими seckill-системами, они используют только схему обработки запросов синхронно, как только параллелизм действительно увеличится, производительность их так называемых seckill-систем резко упадет. Давайте сначала посмотрим на диаграмму последовательности работы системы seckill при синхронном размещении заказа.
Синхронизированный процесс заказа
1. Пользователь инициирует запрос seckill
В синхронном процессе заказа сначала пользователь инициирует запрос seckill. Службе торгового центра необходимо последовательно выполнить следующие процессы, чтобы обработать бизнес-запрос seckill.
(1) Проверьте правильность кода подтверждения
Служба торгового центра определяет, верен ли код подтверждения, отправленный, когда пользователь инициирует запрос seckill.
(2) Определить, закончилась ли деятельность
Убедитесь, что текущая молниеносная сделка завершена.
(3) Проверьте, находится ли запрос доступа в черном списке.
В области электронной коммерции существует много злонамеренной конкуренции, то есть другие продавцы могут злонамеренно запрашивать систему seckill ненадлежащим образом, занимая большую часть полосы пропускания и другие системные ресурсы системы. В настоящее время необходимо использовать систему контроля рисков для реализации механизма черного списка. Для простоты перехватчик также можно использовать для подсчета частоты доступа для реализации механизма черного списка.
(4) Убедитесь, что реальных запасов достаточно
Системе необходимо проверить, достаточно ли реальных запасов продукта и может ли она поддерживать запасы продукта в этой операции seckill.
(5) Вычесть инвентарь в тайнике
В бизнесе seckill такая информация, как запасы товаров, часто хранится в кеше.В это время также необходимо проверить, достаточно ли запасов товаров, используемых в деятельности seckill, и количества товаров, необходимых для деятельности seckill. быть вычтены.
(6) Рассчитайте цену шипа
Поскольку существует разница между ценой вторичной продажи товара и реальной ценой товара в деятельности секьюрити, необходимо рассчитать цену вторичной продажи товара.
Примечание: Если бизнес, связанный с системой, является более сложным в сценарии seckill, будет задействовано больше бизнес-операций.Здесь я просто перечисляю некоторые общие бизнес-операции.
2. Отправьте заказ
(1) Ввод заказа
Сохраните информацию о заказе, отправленную пользователем, в базу данных.
(2) Вычет реальных запасов
После того, как заказ размещен на складе, количество товара, успешно размещенного на этот раз, необходимо вычесть из реального запаса товара.
Если мы используем описанный выше процесс для разработки системы seckill, когда пользователь инициирует запрос seckill, поскольку каждый бизнес-процесс системы выполняется последовательно, общая производительность системы не будет слишком высокой. мы будем Следующая страница очереди всплывает для пользователя, чтобы предложить пользователю подождать.
Картинка с Мейзу
Время ожидания в это время может быть 15 секунд, может быть 30 секунд или даже дольше. Есть проблема: в период с момента, когда пользователь инициирует запрос seckill до сервера, возвращающего результат, соединение между клиентом и сервером не будет разорвано, что займет большое количество ресурсов сервера.
Этот метод используется во многих статьях в Интернете, рассказывающих о том, как реализовать систему seckill. Итак, можно ли использовать этот метод в качестве системы seckill? Ответ заключается в том, что это можно сделать, но уровень параллелизма, поддерживаемый этим методом, не слишком высок. На этом этапе некоторые пользователи сети могут спросить: «Вот что делает наша компания с системой шипов! Я использую его с тех пор, как я вышел в интернет, никаких проблем! Что я хочу сказать, так это то, что использование метода синхронного упорядочения действительно может сделать систему шипов, но производительность синхронного упорядочения не будет слишком высокой. Причина, по которой ваша компания использует метод синхронизации заказов для создания системы seckill без серьезных проблем, заключается в том, что параллелизм вашей системы seckill не достиг определенного порядка, то есть параллелизм вашей системы seckill невысок. .
Поэтому многие так называемые seckill-системы имеют seckill-бизнес, но их нельзя назвать настоящими seckill-системами, поскольку они используют синхронный процесс заказа, который ограничивает параллельный трафик системы. Причина, по которой после подключения к сети не возникает серьезных проблем, заключается в том, что параллелизм системы недостаточно высок, чтобы перегрузить всю систему.
Если 12306, Taobao, Tmall, JD.com, Xiaomi и другие крупные торговые центры будут иметь такую систему seckill, то их системы рано или поздно убьют, а их системщиков не уволят! Поэтому в системе seckill такое решение синхронной обработки бизнес-процесса размещения заказа нежелательно.
Выше приведен весь процесс синхронного заказа.Если процесс заказа более сложный, будет задействовано больше бизнес-операций.
Асинхронный процесс заказа
Поскольку систему seckill синхронного процесса заказа нельзя назвать настоящей системой seckill, то нам необходимо принять асинхронный процесс заказа. Асинхронный процесс заказа не будет ограничивать большой одновременный трафик системы.
1. Пользователь инициирует запрос seckill
После того, как пользователь инициирует запрос seckill, служба торгового центра выполнит следующий бизнес-процесс.
(1) Проверьте правильность кода подтверждения
Когда пользователь инициирует запрос seckill, код подтверждения будет отправлен вместе, и система проверит, является ли код подтверждения действительным и правильным.
(2) Ограничен ли ток
Система будет судить, является ли запрос пользователя ограниченным или нет.Здесь мы можем судить, оценивая длину очереди сообщений. Поскольку мы помещаем запрос пользователя в очередь сообщений, а очередь сообщений накапливает запрос пользователя, мы можем судить о необходимости ограничения запроса пользователя в соответствии с количеством ожидающих запросов в текущей очереди сообщений.
Например, в действии seckill мы продаем 1000 предметов, и в это время в очереди сообщений находится 1000 запросов.Если все еще есть пользователи, которые инициируют запросы seckill, мы больше не можем обрабатывать последующие запросы и напрямую возвращать проданные предметы. пользователю Готово напоминание.
Следовательно, после использования троттлинга мы можем быстрее обрабатывать запросы пользователей и освобождать ресурсы соединения.
(3) Отправить MQ
После того, как запрос пользователя seckill пройдет предыдущую проверку, мы можем отправить параметры запроса пользователя и другую информацию в MQ для асинхронной обработки и в то же время ответить пользователю информацией о результате. В службе торгового центра будет специальный модуль обработки асинхронных задач, который будет обрабатывать запрос в очереди сообщений и обрабатывать последующий асинхронный процесс.
Когда пользователь инициирует запрос seckill, асинхронный процесс заказа обрабатывает меньше бизнес-операций, чем синхронный процесс заказа.Он отправляет последующие операции в модуль асинхронной обработки через MQ для обработки и быстро возвращает результат ответа пользователю для освобождения запроса. связь.
2. Асинхронная обработка
Мы можем асинхронно обрабатывать следующие операции процесса заказа.
(1) Определить, закончилась ли деятельность
(2) Определите, находится ли запрос в черном списке системы.Чтобы предотвратить злонамеренную конкуренцию между партнерами в области электронной коммерции, в систему можно добавить механизм черного списка, и вредоносные запросы могут быть помещены в черный список системы. Этого можно добиться, используя перехватчики для подсчета частоты посещений.
(3) Вычтите инвентарное количество продуктов seckill в тайнике.
(4) Создайте токен seckill, привязанный к текущему пользователю и текущему действию seckill.Только запросы, генерирующие токен seckill, имеют право на действие seckill.
Здесь мы вводим механизм асинхронной обработки,При асинхронной обработке можно контролировать, сколько ресурсов использует система и сколько потоков выделяется для обработки соответствующих задач.
3. Короткие всплески результатов опроса
Здесь вы можете принять решение короткого опроса на стороне клиента, чтобы проверить, подходит ли он для Lightning Deal. Например, клиент может опрашивать сервер запросов каждые 3 секунды, чтобы проверить, подходит ли он для seckill.Здесь наша обработка на сервере заключается в том, чтобы определить, есть ли у текущего пользователя токен seckill.Если сервер генерирует токен seckill для текущий пользователь, текущий пользователь Есть квалификация всплеск. В противном случае продолжайте опрос до тех пор, пока не истечет время ожидания или сервер не вернет информацию, например, о том, что продукт распродан или seckill не соответствует требованиям.
Когда для запроса результатов seckill используется короткий опрос, мы также можем предложить пользователю поставить очередь для обработки на странице, но в это время клиент будет опрашивать сервер каждые несколько секунд, чтобы запросить статус приемлемости seckill. синхронный процесс заказа, нет необходимости удерживать соединение запроса в течение длительного времени.
В настоящее время,Некоторые пользователи сети могут спросить: можно ли узнать, подходит ли он для всплеска, пока не истечет время ожидания, используя метод короткого опроса? Ответ: это возможно!Вот, давайте представим реальную сцену seckill.Суть мерчантов, участвующих в seckill деятельности, заключается не в заработке денег, а в увеличении продаж товаров и популярности торговцев, а также в привлечении большего количества пользователей к покупке собственных товаров. Поэтому мы не обязаны гарантировать, что пользователи смогут на 100 % узнать, имеют ли они право на seckill.
4. Поселение шипов
(1) Подтвердить токен заказа
Когда клиент отправляет расчет seckill, он вместе отправляет токен seckill на сервер, и служба торгового центра проверяет, является ли текущий токен seckill действительным.
(2) Добавить в корзину для шипов
После проверки того, что токен Lightning Deals является законным и действительным, служба торгового центра добавит продукты, которые были убиты пользователем, в корзину покупок Lightning Deals.
5. Отправьте заказ
(1) Заказать складирование
Сохраните информацию о заказе, отправленную пользователем, в базу данных.
(2) Удалить токен
После того, как заказ продукта seckill будет успешно помещен на склад, удалите токен seckill.
Здесь можно задуматься над вопросом: почему мы используем асинхронную обработку только в розовой части асинхронного процесса заказа, но не принимаем мер по срезанию пиков и заполнению впадин в других частях?
Это связано с тем, что при разработке асинхронного процесса заказа, будь то в дизайне продукта или в дизайне интерфейса, мы ограничиваем поток пользовательских запросов на этапе, когда пользователь инициирует запрос seckill.Можно сказать, что текущая операция ограничения система очень вперед. Когда пользователь инициирует запрос seckill, текущее ограничение реализуется, и пиковый трафик системы плавно разрешается.Если мы пойдем дальше, параллелизм и системный трафик системы не очень высоки.
Поэтому при внедрении системы seckill во многих статьях и постах в интернете говорится, что асинхронное пиковое шейвинг используется для выполнения каких-то операций по ограничению тока при оформлении заказа, что все ерунда! Поскольку операция заказа является относительно поздней операцией во всем системном процессе seckill, текущая операция ограничения должна быть предварительно обработана, и выполнять текущую операцию ограничения в процессе, лежащем в основе бизнеса seckill, бесполезно.
Высокопараллельная «черная технология» и выигрышные приемы
Предположим, в системе seckill мы используем Redis для реализации кэширования и предположим, что объем одновременного чтения и записи Redis составляет около 50 000. Наш бизнес вторичного убийства в торговом центре должен поддерживать около 1 миллиона параллелизма. Если весь 1 миллион параллелизма будет помещен в Redis, Redis, скорее всего, зависнет Итак, как мы решим эту проблему? Далее мы вместе обсудим этот вопрос.
В системе с высокой степенью параллелизма, если Redis используется для кэширования данных, возможность параллельной обработки кэша Redis является ключевым моментом, поскольку многим префиксным операциям требуется доступ к Redis. Асинхронное сглаживание пиковых нагрузок — это только базовая операция, и главное — обеспечить возможность параллельной обработки Redis.
Ключевая идея для решения этой проблемы: разделяй и властвуй, разделяй товарные запасы.
Тьма Ченкан
Когда мы храним инвентарь продуктов seckill в Redis, мы можем «разделить» инвентарь продуктов seckill, чтобы увеличить параллелизм чтения и записи Redis.
Например, id исходного продукта seckill — 10001, запас — 1000 штук, а хранилище в Redis — (10001, 1000), исходный запас делим на 5 штук, а запас каждой штуки — 200 штук. В настоящее время в Redia хранится следующая информация: (10001_0, 200), (10001_1, 200), (10001_2, 200), (10001_3, 200), (10001_4, 200).
На этом этапе, после того как мы разделим инвентарь, каждый разделенный инвентарь сохраняется с использованием идентификатора товара плюс цифровой идентификатор Таким образом, когда операция хеширования выполняется для каждого ключа, в котором хранится товарный инвентарь, полученные результаты хэширования будут разными. Да, это означает, что существует высокая вероятность того, что ключ для хранения товарных запасов находится не в том же слоте Redis, что может повысить производительность и параллелизм обработки запросов Redis.
После разделения инвентаря нам также необходимо сохранить отношение сопоставления между идентификатором продукта и ключом после разделения инвентаря в Redis, В настоящее время ключом отношения сопоставления является идентификатор продукта, который равен 10001, а value — это ключ для хранения информации об инвентаре после разделения инвентаря. , то есть 10001_0, 10001_1, 10001_2, 10001_3, 10001_4. В Redis мы можем использовать List для хранения этих значений.
При фактической обработке информации об инвентаризации мы можем сначала запросить все ключи разделенного инвентаря, соответствующие продукту seckill, из Redis, использовать AtomicLong для записи текущего количества запросов и использовать количество запросов для запроса из Redia. выполняется на длинах всех ключей после деления инвентаря, и результат равен 0, 1, 2, 3, 4. Затем, вставив идентификатор продукта впереди, можно получить ключ реального кэша инвентаря. На этом этапе вы можете напрямую получить соответствующую информацию об инвентаризации от Redis в соответствии с этим ключом.
прививка
В бизнес-сценариях с высокой степенью параллелизма мы можем напрямую использовать библиотеку сценариев Lua (OpenResty) для прямого доступа к кешу с уровня балансировки нагрузки.
Здесь давайте рассмотрим сценарий: если в бизнес-сценарии seckill продукты seckill раскупаются в одно мгновение. В этот момент, когда пользователь инициирует очередной запрос seckill, если система запрашивает каждую службу прикладного уровня из уровня балансировки нагрузки, а затем обращается к кешу и базе данных из каждой службы прикладного уровня, по сути, это бессмысленно. , т. к. товар распродан. , а то через прикладной слой системы выполнять послойную проверку особого смысла нет! ! Объем одновременного доступа прикладного уровня исчисляется сотнями, что в определенной степени снижает параллелизм системы.
Для решения этой проблемы в настоящее времяМы можем извлечь идентификатор пользователя, идентификатор продукта и идентификатор действия seckill, который несет пользователь при отправке запроса на уровне балансировки нагрузки системы, и напрямую получить доступ к информации об инвентаризации в кеше с помощью таких технологий, как сценарий Lua. Если запас продукта мгновенного уничтожения меньше или равен 0, будет возвращено непосредственное сообщение о том, что продукт пользователя продан, вместо того, чтобы проходить послойную проверку уровня приложения.Для этой архитектуры мы можем обратиться к архитектурной схеме системы электронной коммерции в этой статье (первая диаграмма в начале текста).
Ну вот и все на сегодня! Не забывайте ставить лайки, смотреть и пересылать дальше, чтобы больше людей могли видеть, учиться и прогрессировать вместе! !
напиши в конце
Если вы считаете, что Бинхэ пишет неплохо, выполните поиск в WeChat и подпишитесь на "Ледниковая технология«Официальная учетная запись WeChat, изучите технологии высокого параллелизма, распределенных микросервисов, больших данных, Интернета и облачных технологий от Glacier»,Ледниковая технология«Официальный аккаунт WeChat обновил большое количество технических тем, и каждая техническая статья полна галантереи! Многие читатели уже прочитали »Ледниковая технология«Статья официального аккаунта WeChat успешно дошла до крупного завода; также есть много читателей, которые совершили технологический скачок и стали техническим костяком компании! Если вы тоже хотите улучшить свои способности, как они, совершить скачок в технических возможностях, поступить на большой завод, получить повышение и прибавку к зарплате, то обратите внимание на "Ледниковая технология«Официальная учетная запись WeChat, ежедневно обновляйте галантерею суперхардкорных технологий, чтобы вы больше не запутались в том, как улучшить свои технические способности!