1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/chanjarster-artemis-disruptor-miaosha

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
README.md 12 КБ
Копировать Редактировать Web IDE Исходные данные Просмотреть построчно История
Отправлено 07.03.2025 09:02 e49f86d

артемис-дискраптор-мияоша

Без Redis также можно обеспечить решение для проведения акций «все в продаже» "Мицухас событие в Индии против Амазона".

Xiaomi установила несколько рекордов в Индии:

  1. В течение четырёх минут было продано более 250 000 единиц. --- OPS: 1042 покупки/с
  2. Самый быстрый мобильный телефон Flash Sale.
  3. Перед началом Flash Sale мы получили 1 миллион "уведомлений о доставке".
  4. Amazon получал более 5 миллионов кликов в минуту.
  5. Amazon получала 1500 заказов в секунду во время этого события (это самый высокий показатель среди всех продаж в Индии). --- OPS: 1500 заказов/с

Проявление производительности

Сначала поговорим о проявлении производительности, так как это интересует многих.

Хардварная среда (Tomcat, Artemis, JMeter, Oracle, backend находится на этом компьютере):

  • MacBook Pro (Retina, 15-дюймовый, середина 2014 года)
  • 2.2 ГГц Intel Core i7
  • 16 ГБ 1600 МГц DDR3
  • 512 ГБ SSD

Программная среда:

  • Java версия "1.8.0_131"
  • Artemis 1.5.4
  • Oracle XE 11g (Docker)
  • Tomcat 8.5.14 (1 шт.)

Дополнительные конфигурации см. в разделе Как подготовить среду

Тестовые сценарии JMeter см. в разделе Как провести benchmark:

  • 300 потоков, цикл 1000 раз, всего 300 000 запросов

Процесс benchmark был проведен дважды, поскольку JIT влияет на производительность.

Результат первого теста

  • QPS: 300 000 за 00:01:57 = 2569.8/с Среднее значение: 108 Минимальное значение: 0 Максимальное значение: 41102 Ошибки: 164 (0.05%)
  • TPS: 299 836 заказов / 121 секунды = 2477 заказов/сПС. Производительность базы данных была проанализирована по логам бэкэнд-программы.

Результат второго теста

Не перезапуская Tomcat и Artemis, восстанавливая данные базы данных и перезапуская бэкэнд-программу,

  • QPS: 300 000 за 00:00:35 = 8527.8/с Среднее значение: 20 Минимальное значение: 0 Максимальное значение: 4515 Ошибки: 2 (0.00%)
  • TPS: 246 873 заказа / 46 секунд = 5366 заказов/с

Количество записей в базе данных меньше из-за того, что очередь Artemis заполнилась, и некоторые сообщения были отброшены.

Обзор архитектуры

По топологии развертывания, архитектура состоит из четырёх частей:

  1. Webapp, который может быть распределён в кластере, работает в контейнере Tomcat
  2. ActiveMQ Artemis, отвечает за коммуникацию между webapp и бэкендом
  3. Бэкенд, который может быть запущен только один раз, работает автономно, использует Disruptor
  4. База данных Oracle

ActiveMQ Artemis

ActiveMQ Artemis — это проект, переименованный JBoss после передачи HornetQ Apache Foundation. Сейчас это подпроект ActiveMQ.

HornetQ был известной высокопроизводительной системой для обмена сообщениями, поэтому ActiveMQ Artemis также имеет отличную производительность. Этот проект использует его для сообщений между webapp и бэкендом.

DisruptorDisruptor — это высокопроизводительная памятная очередь, созданная компанией LMAX. Disruptor позволяет разработчикам писать однопоточный код и достигать отличных показателей производительности, при этом избегая сложностей параллельной программы. Основная идея состоит в том, что многопоточность не всегда приводит к более быстрой работе.Backend использует его для сериализации запросов, получаемых от ActiveMQ Artemis, проверяет наличие достаточного количества товара на складе, обновляет количество оставшихся товаров и асинхронно записывает данные в базу данных.

Использование памяти и избежание IO

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

Когда backend запускается, он загружает данные о наличии товаров в память, проверка наличия товаров и обновление колич�数字需要翻译成数字形式。

当后端启动时,它将库存数据加载到内存中,商品存在检查和剩余数量更新都在内存中进行。这有助于避免与并行程序相关的内存可见性、同步和锁定问题,从而提高性能。

有些人可能会认为由于担心OOM(内存不足),在内存中存储商品信息是不现实的。然而,这取决于具体的情况。

在这个项目中,商品信息在内存中的表示由Item.java类提供。使用jol-cli下载此处)查看内存内部结构后发现,对象大小为24字节: me.chanjar.jms.server.memdb.Item object internals: OFFSET SIZE TYPE DESCRIPTION VALUE 0 12 (объектный заголовок) Н/Д 12 4 int Item.amount Н/Д 16 4 long Item.id Н/Д 20 4 (потерянное место из-за выравнивания следующего объекта) Instance size: 24 байта Space losses: 0 байт внутри + 4 байта вне = 4 байта всегоРазмер объекта типа Long также равен 24 байтам:

java.lang.Long object internals:
OFFSET  SIZE  TYPE DESCRIPTION                    VALUE
   0     12    (объектный заголовок)              Н/Д
   12     4    (выравнивание/заполнение)           Н/Д
   16     8    long Long.value                     Н/Д
Instance size: 24 байта
Space losses: 4 байта внутри + 0 байта вне = 4 байта всего

Если у вас есть 1 миллион товаров, которые нужно продать за секунду, то потребляемая память будет равна 1,000,000 * (24 байта + 4 байта + 24 байта) = 52,000,000 байт = 49 мегабайт. То есть всего лишь 49 мегабайт.

Улучшения

Оптимизация архитектуры:

  1. Запрос на оформление заказа обрабатывается асинхронно; запрос возвращает ID текущего запроса, клиент использует этот ID для получения информации о результате запроса через отдельный запрос.
  2. В период распродаж товарные остатки хранятся в памяти; проверка наличия товаров и списание остатков производится в оперативной памяти, после чего данные синхронизируются с базой данных асинхронно.
  3. Используется Disruptor для последовательной обработки параллельных запросов, что позволяет избежать сложностей многопоточного программирования.
  4. Отказ от использования транзакций базы данных в пользу конечной согласованности.

Оптимизации связанные с JMS:1. Перезапуск JMS Connection, Session, MessageProducer, MessageConsumer вместо создания новых объектов каждый раз (Spring's JmsTemplate работает именно так).

  1. Установка JMS Session как transacted=false, AUTO_ACKNOWLEDGE.

  2. При отправке JMS сообщений установка DeliveryMode=NON_PERSISTENT.

  3. Отключение повторной отправки Artemis и механизма доставки сообщений.Оптимизации связанные с JDBC:

  4. Использование JDBC Batch Update для снижения количества сетевых операций ввода-вывода с базой данных.

  5. Оптимизация операций обновления остатков товаров в базе данных, объединение нескольких update запросов в один при высоконагруженной работе (с использованием Disruptor).

Оптимизации связанные с Tomcat:

  1. Увеличение параметра maxThreads.

Описание процесса

Проект предоставляет два интерфейса:

  1. Интерфейс оформления заказа. Используется для оформления заказа.
  2. Интерфейс для проверки результата оформления заказа. Используется для проверки успешности оформления заказа.

Умные читатели наверняка уже догадались, что весь процесс распродажи является асинхронным.

Процесс оформления заказа

Процесс оформления заказа

Процесс проверки результата оформления заказа

Процесс проверки результата оформления заказа

Как это сделать

Опубликовать ( 0 )

Вы можете оставить комментарий после Вход в систему

1
https://api.gitlife.ru/oschina-mirror/chanjarster-artemis-disruptor-miaosha.git
git@api.gitlife.ru:oschina-mirror/chanjarster-artemis-disruptor-miaosha.git
oschina-mirror
chanjarster-artemis-disruptor-miaosha
chanjarster-artemis-disruptor-miaosha
master