Анализ: разработка системы мгновенных распродаж
При разработке системы мгновенных распродаж мы постоянно размышляли о том, как создать такую систему на основе существующих технологий и знаний, чтобы она была максимально эффективной. При этом мы стремились максимально использовать существующие корпоративные промежуточные программные продукты для реализации системы.
Мы знаем, что реализация системы мгновенных распродаж для веб-приложений требует одинаковой важности как для обработки на стороне клиента, так и для обработки на сервере. На стороне клиента обычно используется CDN (сеть доставки контента), а на стороне сервера — распределённое развёртывание, ограничение трафика, оптимизация производительности и другие операции. Кроме того, поскольку текущая система основана на WeChat Mini Program, оптимизация на стороне клиента выполняется в основном в коде, и использование CDN становится ненужным.
Дополнительные размышления о системе мгновенных распродаж:
На основе существующей архитектуры системы мгновенных распродаж были добавлены новые решения.
-
Существующее решение: контроль конечного запаса с помощью распределённой блокировки и управление заказами, которые могут быть отправлены в очередь для последующей обработки.
-
Новое решение: после получения запроса выполняется проверка активности и повторная проверка мгновенной распродажи, после чего сообщение помещается в очередь сообщений. Затем в очереди сообщений выполняются операции по проверке запасов и другие действия. Это позволяет достичь эффекта сглаживания пиковых нагрузок через очередь сообщений.
Фактически, оба решения кажутся подходящими, но они предназначены для разных сценариев использования. Существующее решение больше подходит для платформ с относительно небольшим трафиком и более простым процессом. Новое решение часто используется на крупных платформах и предназначено для сглаживания пиковых нагрузок с использованием очередей сообщений. Оба решения ограничивают количество запросов, которые действительно могут быть обработаны, используя атомарное увеличение счётчика в Redis для записи количества запросов. Когда количество запросов достигает определённого кратного размера запасов, последующие запросы будут возвращать сообщение о том, что активность слишком популярна.
-
Архитектура: серверная часть проекта основана на микросервисной архитектуре SpringCloud + SpringBoot. Клиентская часть работает в магазине WeChat Mini Programs.
-
Основные компоненты:
- Сервисный шлюз Zuul;
- Регистрация и обнаружение сервисов Eureka + Ribbon;
- Централизованная аутентификация и авторизация Spring Security OAuth2, JWTToken;
- Фреймворк сервисов Spring MVC/Boot;
- Отказоустойчивость сервисов Hystrix;
- Распределённая блокировка Redis;
- Вызов сервисов Feign;
- Очередь сообщений Kafka;
- Файловый сервис на частном облачном диске;
- Компонент форматированного текста UEditor;
- Запланированные задачи xxl-job;
- Центр конфигурации apollo.
-
Особенности сценариев мгновенных распродаж:
- Мгновенные распродажи обычно сопровождаются большим количеством одновременных покупок пользователями, что приводит к резкому увеличению трафика на сайте;
- В большинстве случаев мгновенные распродажи имеют гораздо больший объём запросов, чем доступный запас, и только небольшая часть пользователей может успешно совершить покупку;
- Процесс мгновенных распродаж относительно прост и обычно включает в себя оформление заказа;
-
Принципы проектирования системы мгновенных распродаж:
- Ограничение трафика: учитывая, что только небольшое количество пользователей может совершать покупки во время мгновенных распродаж, необходимо ограничить большую часть трафика и разрешить доступ только небольшому количеству трафика (в настоящее время не обрабатывается);
- Сглаживание пиковых нагрузок: для мгновенных распродаж характерны резкие всплески трафика. Распространённым методом сглаживания является использование кеша или очередей сообщений;
- Асинхронная обработка: асинхронная обработка может значительно повысить пропускную способность высоконагруженных систем. Асинхронная обработка также является одним из методов сглаживания пиковых нагрузок;
- Кеширование памяти: основной узким местом системы мгновенных распродаж является чтение и запись базы данных, особенно дисковый ввод-вывод, который может привести к снижению производительности. Если большая часть бизнес-логики перенесена в кеш, производительность может значительно улучшиться;
- Масштабируемость: если требуется поддержка большего числа пользователей или более высокой нагрузки, система должна быть спроектирована таким образом, чтобы её можно было легко масштабировать. Если трафик увеличивается, можно добавить дополнительные машины.
-
Идеи проектирования мгновенных распродаж:
- Поскольку клиентская сторона основана на Mini Program, нет проблем с нагрузкой на стороне клиента.
-
- Все интерфейсы, связанные с активностью, должны быть кэшированы с использованием Redis.
-
- Вся информация о реальном запасе, блокировке запасов, ограничении покупок и оформлении заказов должна храниться в Redis.
-
- Когда поступает запрос, сначала используется атомарное приращение Redis для записи текущего количества запросов. После превышения определённого порога последующие запросы возвращают сообщение о чрезмерной популярности активности. Запросы, которые могут участвовать в мгновенных распродажах, сначала проходят проверку на повторяемость с использованием распределённой блокировки с гранулярностью активности. Если условия соблюдены, запрос переходит к следующему шагу, в противном случае возвращается сообщение о том, что заказ уже сделан.
-
- Во-вторых, проверяется, превышает ли доступный запас количество покупок. Если условие выполнено, запрос переходит к следующему этапу, в противном случае возвращается сообщение об отсутствии товаров.
-
- В-третьих, текущий запрос на покупку блокирует доступный запас. Запрос на оформление заказа помещается в очередь сообщений Kafka.
-
- В-четвёртых, ключ polling добавляется в Redis для опроса интерфейса, чтобы определить, был ли заказ успешно оформлен. После успешного оформления заказа ключ polling должен быть удалён, а также должен быть создан ключ с идентификатором активности и идентификатором пользователя для предотвращения повторных покупок.
-
- В-пятых, сообщения обрабатываются в очереди, и после успешного оформления заказа реальный запас уменьшается, а ключ polling удаляется. Если в процессе оформления заказа возникает ошибка, ключ ограничения покупок удаляется, запас разблокируется, и пользователю отправляется сообщение о неудачной попытке оформления заказа.
-
- В-шестых, предоставляется интерфейс опроса, который позволяет клиенту проверять успешность оформления заказа после завершения процесса мгновенных распродаж. Основной критерий — состояние ключа polling в Redis.
-
- Весь процесс будет перехватывать все запросы, поступающие на серверную часть, на уровне кэша Redis, за исключением взаимодействия с базой данных для окончательного оформления заказа. Таким образом, нагрузка на базу данных сводится к минимуму.
-
Ограничение трафика:
SpringCloud Zuul предоставляет эффективные механизмы ограничения трафика, которые помогают предотвратить злонамеренные запросы от одного и того же пользователя. Пример конфигурации ограничения трафика в Zuul:
zuul:
ratelimit:
key-prefix: your-prefix #对应用来标识请求的key的前缀
enabled: true
repository: REDIS #对应存储类型（用来存储统计信息）
behind-proxy: true #代理之后
default-policy: #可选 - 针对所有的路由配置的策略，除非特别配置了policies
limit: 10 #可选 - 每个刷新时间窗口对应的请求数量限制
quota: 1000 #可选- 每个刷新时间窼口对应的请求时间限制（秒）
refresh-interval: 60 # 刷新时间窗口的时间，默认值 (秒)
type: #可选 限流方式
- user
- origin
- url
policies:
myServiceId: #特定的路由
limit: 10 #可选- 每个刷新时间窗口对应的请求数量限制
quota: 1000 #可选- 每个刷新时间窗口对应的请求时间限制（秒）
refresh-interval: 60 # 刷新时间窗口的时间，默认值 (秒)
type: #可选 限流方式
- user
- origin
- url
-
Распределение нагрузки и балансировка трафика:
Когда активность получает очень большой объём трафика, возможно, потребуется рассмотреть возможность использования нескольких IP-адресов для одного домена и их сопоставления с несколькими высокодоступными серверами Nginx в DMZ. Также можно рассмотреть возможность использования кластера Redis для обеспечения распределённого хранения и SpringCloud Hystrix для обеспечения отказоустойчивости сервисов.
Кроме того, важно оптимизировать параметры Nginx, Tomcat, Zuul и других компонентов для повышения производительности системы.
Следует также отметить, что даже если клиентская часть основана на Mini Program, ресурсы изображений, связанные с активностью, размещаются на собственном облачном сервисе, поэтому размещение ресурсов изображений на CDN также имеет решающее значение. В противном случае даже при наличии 1G пропускной способности канала трафик может быть быстро исчерпан.
Комментарии ( 0 )