содержание

задний план
- Понятия, связанные с синхронизацией инвентаря
- Процесс инвентаризации
план
воплощать в жизнь
Суммировать

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

Если у вас есть некоторые знания о системе электронной коммерции, это поможет вам понять бизнес, упомянутый ниже.

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

задний план

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

Понятия, связанные с синхронизацией инвентаря

Давайте сначала представим некоторые основные концепции платформ электронной коммерции.

Инвентарь - это фактическое количество определенной SKU (минимальной единицы хранения) на складе на складе.

НапримерОпределенная модель серого 8-ядерного ноутбука с памятью 16 ГБЭто SKU. На складе 100 SKU, поэтому его инвентарь равен 100.

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

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

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

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

Несколько магазинов и субдистрибьюция

Платформы электронной коммерции обычно имеют несколько магазинов, например, в категории 3C могут быть магазины Apple, Huawei, Samsung, Xiaomi и другие.

Инвентаризация в разных магазинах независима.

Иногда SKU продается в нескольких магазинах,iPhone X/серый космос/256 ГБсуществуетXXX Флагманский магазин платформы Apple,XXX Магазин мобильных устройств,XX Дисконтный магазин AppleЭто три разных инвентарных записи.

ЭтоИнвентарь в нескольких магазинах.

Как дистрибьютор, на его складах имеется продукция разных платформ и брендов. Например, вышеуказанный мобильный телефон доступен на складах в Шэньчжэне, Гуанчжоу и Шанхае и продан соответственно Tmall и Jingdong, тогда есть 6 инвентарных записей, а именно:

No.	склад	канал
1	Шэньчжэнь	Торговый центр
2	Шэньчжэнь	Цзиндон
3	Гуанчжоу	Торговый центр
4	Гуанчжоу	Цзиндон
5	Шанхай	Торговый центр
6	Шанхай	Цзиндон

ЭтоРазделить инвентарь.

Время подсчета запасов и время последнего обновления

В реальной работе, чтобы обеспечить точность данных, платформа будет проверять время инвентаризации.

Например, если на складе в 01:00 утра подсчитан запас SKU со значением 100, время подсчета запасов для этой записи запасов — 01:00.

Складской инвентарь после 01:00, завершенный в 02:00, получит возврат, он подтолкнет платформу к приращению +1.

При нормальных обстоятельствах сначала отправляется полная сумма, и платформа должна сначала получить полную сумму 100, затем приращение +1 и, наконец, 101.

Однако, если есть проблема с промежуточным звеном, сначала получен приращение +1, а полная сумма равна 100, то конечная инвентаризация будет 100. Полный инвентарь будет непосредственно охватывать текущий инвентарь платформы.

Следовательно, если есть время последнего обновления, а запись представляет собой приращение, полученное в 02:00, то при поступлении полной суммы в 01:00 платформа будет считать ее недействительной, поскольку она предшествует времени приращения.

Процесс инвентаризации

Фактический процесс потока данных инвентаризации часто представляет собой не такую короткую ссылку, как «склад -> платформа», а фактическая ссылка всегда очень длинная:

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

план

анализ проблемы

Чтобы решить проблему, вы должны сначала проанализировать проблему. Как технический директор платформы, я сначала подсчитал время синхронизации инвентаря платформы за последний месяц, что составляет около 150 минут, и оно будет увеличиваться на несколько минут каждые несколько дней.

Затем я посчитал изменения данных полного инвентаря за последний период, и всего за 10 дней он увеличился на 5 недель.

Определение проблемы: В настоящее время, с точки зрения платформы, с увеличением данных инвентаризации время обработки продолжает увеличиваться, а вся ссылка становится очень длинной, что приводит к плохой производительности полных данных инвентаризации в режиме реального времени.

Мозговой штурм

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

Обновите конфигурацию оборудования

Когда вы отчаянно бежите, чтобы избежать опоздания, вы можете решить проблему.

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

Изменить логику обработки сообщений

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

Оптимизировать логику обработки сообщений

Данные запасов единообразно обрабатываются центром сообщений, который обрабатывает различные типы данных, такие как заказы, товары, цены, членство и запасы, что неэффективно.

Оптимизация полной синхронизации запасов

Оптимизирован кодовый процесс обработки данных платформы.

установить стратегию

Для схемы 1 спонсор должен одобрить деньги, а схема 2 требует множественных модификаций системы, которые трудно обсуждать; схема 3 требует изменения общей структуры, и объем работы огромен.

Для решения неотложных задач Вариант 4 наиболее осуществим, с наименьшим количеством изменений и наименьшей сферой влияния.

План уточнения

Вариант 4 оптимизирует синхронизацию всей инвентаризации, которая конкретизируется в следующих трех аспектах.

Оптимизация бизнеса и стандартизация
Высокопроизводительная обработка данных
Высокая производительность операций очереди

Ниже приводится подробное описание реализации.

воплощать в жизнь

Оптимизация бизнеса и стандартизация

Оптимизация и стандартизация бизнеса подразделяются на следующие аспекты:

полная изоляция

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

полоса бревна

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

раздеть новый

В настоящее время, прежде чем синхронизировать инвентарь, сначала определите, существует ли продукт.Если он существует, то определите, есть ли запись о товаре в таблице инвентаризации.Если нет, создайте новую запись и обновите инвентарь, если он есть.

По мере увеличения объема данных доля вновь создаваемых записей (от 1k до 3k в день) становится все меньше и меньше, поэтому вновь созданные операции также выделяются в очередь для обработки.

Оптимизировать логику обработки сообщений

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

Для использования пулов потоков вы можете обратиться к этой статье:Используйте ThreadPoolExecutor для создания пула потоков

//构造线程池
private static ExecutorService executorService = new ThreadPoolExecutor(
16,
32,
10L,
TimeUnit.MINUTES,
new LinkedBlockingQueue<Runnable>(
                2048),new ThreadFactoryBuilder()
                     .setNameFormat("BatchSyncFullInventory-Pool-%d").build(),
                     new ThreadPoolExecutor.CallerRunsPolicy());

После вышеуказанной оптимизации текущее время обработки значительно сократилось:

Высокая производительность операций очереди

После приведенной выше оптимизации обнаружено, что для каждых 2k обработанных сообщений время обработки находится в пределах 1 с, а время удаления из очереди близко к 15 с.

Поэтому следующие оптимизации направлены на повышение производительности очереди.

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

Вот как Spring Data Redis использует каналы:

//从队列中循环取出消息, 使用管道, 减少网络传输时间
List<Object> msgList = redisTemplate.executePipelined(new RedisCallback<Object>() {
    @Override
    public Object doInRedis(RedisConnection connection) throws DataAccessException {
        for (int i = 0; i < batchSize; i++) {
            connection.rPop(getQuenueName().getBytes());
        }
        return null;
    }
});

Теоретически это так, и это должно быть подтверждено фактическими данными, поэтому необходимо проверить действие схемы экспериментальным путем.

Во-первых, в тестовой среде сравнивается производительность трех различных методов удаления из очереди, а именно: удаление из очереди однопоточного цикла, удаление из очереди многопоточного цикла и удаление из очереди однопоточного конвейера.

Тест показал, что использование конвейера для удаления из очереди 2000 раз занимает всего около 70 миллисекунд.

Наконец, при использовании каналов + многопоточность время обработки сообщений инвентаризации сократилось примерно до 30 минут:

Для использования труб вы можете обратиться к этой статье:Конвейерная технология Redis

Загрузка ЦП слишком высока

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

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

//如果消息的内容为空, 则休眠[10]秒钟以后再继续取数据，防止大批量地读取redis造成CPU消耗过高
if (CollectionUtils.isEmpty(messageList)) {
    Thread.currentThread().sleep(10 * 1000);
    continue;
}

Суммировать

Разработка схемы: мозговой штурм и оценка осуществимости
Упрощение логики: убрать ненужные операции
Стандартизация процессов: разобраться в процессе объединения бизнеса
Пул потоков для высокопроизводительного параллелизма: Executor Service
Конвейеры реализуют высокопроизводительные очереди: Redis Pipelining

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

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