Имя поля	Тип поля	Требуется ли	описывать
id	bigint	необходимые	первичный ключ
lg_order_code	varchar(128)	необходимые	номер отправления
trade_order_code	varchar(128)	Не требуется	номер транзакции
trade_sub_order_code	varchar(128)	Не требуется	Номер подзаказа транзакции
package_id	bigint	Не требуется	Идентификатор пакета
sku_id	bigint	Не требуется	skuid
sku_name	varchar(256)	Не требуется	Название SKU.
buyer_id	bigint	необходимые	Идентификатор покупателя
seller_id	bigint	Не требуется	Идентификатор продавца
shop_id	bigint	Не требуется	Идентификатор магазина
item_id	bigint	необходимые	идантификационный номер продукта
item_type	int	Не требуется	Типы продуктов
item_name	varchar(256)	Не требуется	наименование товара
item_num	int	необходимые	количество товара
item_weight	decimal	Не требуется	вес товара
item_volumn	decimal	Не требуется	Товарный объем
marking	varchar(128)	Не требуется	Информация на этикетке продукта
status	int	необходимые	государство
feature	varchar(1024)	Не требуется	нет
is_delete	int	необходимые	удалить или нет
version	int	необходимые	номер версии
gmt_created	datetime	необходимые	время создания
gmt_modified	datetime	необходимые	Изменить время

Дизайн указателя:

а), идентификатор первичного ключа

б) общие индексные поля: lg_order_code, buy_id

3. логистика_заказ_пакет

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

дизайн стола

дизайн индекса

первичный ключ: идентификатор

Уникальный индекс: unique_code

В-третьих, конструкция государственной машины

1. Проект конечного автомата форвардной логистики

А. Создать -> Отгрузка -> Подписать/Отклонить

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

б) Создать->Доставка->Заказ на доставку->Сбор доставки->Доставка и доставка->Подписать/Отклонить

Этот поток состояния связан со статусом потока логистики распределения.Как правило, после подключения деталей сторонней логистики будет получена информация о логистике и распределении.

c, Создание -> Доставка -> Склад заказов -> Библиотека хранения -> Распределение Lanshou -> Доставка Доставка -> Подписать/отказаться

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

2. Конечный автомат обратной логистики

Как видно из приведенного выше конечного автомата, существует 4 вида времени для отмены логистики:

1. Отменить после создания

2. Отмена после доставки

3. После того, как склад получит заказ, его можно отменить до освобождения склада.

4. Отмена перед подписанием после доставки

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

4. Дизайн интерфейса создания заказа в условиях высокой параллелизма

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

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

1. Генерация идентификатора логистического заказа

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

2. Создайте уникальный код дедупликации

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

3. Откройте транзакцию сообщения

Так как поток создания заказов очень большой, помимо необходимых операций по вставке данных, другие бизнес-операции должны быть асинхронными через сообщения. Чтобы убедиться, что сообщение может быть отправлено, мы будем использовать гарантию транзакции сообщения MQ. Принцип транзакции сообщения может относиться к этой статье:Генеральный директор woohoo.co.com/article/3rd…

4, открытые транзакции базы данных

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

5. Вставьте таблицу дедупликации

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

6. Вставьте данные заказа

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

7. Отправить сообщение

При отправке заказа на создание сообщения через mq на этом этапе возникает ошибка.Согласно введению в приведенной выше статье, MQ будет активно перезванивать системе, чтобы проверить, успешно ли вставлена ​​​​база данных и сообщение не было отправлено. Если это так, сообщение будет установлено как отправленное, чтобы гарантировать его успешную отправку.

Благодаря вышеуказанному процессу мы можем гарантировать высокое сопутствующее удостоверение IdEmpotent создание поручений логистики.

5. Заказать обновление дизайна интерфейса с высокой степенью параллелизма

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

1. Используйте блокировку версии, чтобы гарантировать, что данные не будут перезаписаны

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

2. Блокировка разделения

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

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

3. Сравнение данных

На практике мы обнаруживаем, что интерфейс обновления используется неправильно, например, данные полностью согласованы, а также вызывается интерфейс обновления.Эти вызовы только изменяют поле gmt_modified на уровне базы данных и не имеют никакого другого эффекта. Для этих ложных вызовов мы блокируем их, обновляя сравнение полей, что снижает нагрузку на часть базы данных.

6. Заказать дизайн интерфейса запросов с высокой степенью параллелизма

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

1. Оптимизация уровня базы данных

Во-первых, это оптимизация на уровне базы данных, подробности в этой статье:Краткое описание.com/afraid/Chengdu 033668…

2. Подбиблиотека и подтаблица

Библиотека логистических заказов неизбежно будет включать подбиблиотеку и подтаблицы.При работе с подбиблиотекой и подтаблицей необходимо обратить внимание на три момента:

а, глобальная генерация идентификатора заказа на логистику

Для глобального создания идентификатора логистического заказа обратитесь к алгоритму Snowflake или методу Ali TDDL.

б. Выберите соответствующие поля подтаблицы

Поле подтаблицы используется для маршрутизации, поэтому необходимо выбрать определенные поля, например идентификатор покупателя.

c, оператор sql, чтобы попытаться не пересекать таблицу

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

3. Разделение данных

Данные логистических заказов обычно делятся на горячие данные и холодные данные.Горячие данные – это недавно созданные заказы, и эти заказы все еще находятся в обороте.Холодные данные – это исторические данные, а общий объем запросов очень мал. Мы можем мигрировать исторические данные в Hbase для хранения по определенным правилам, оставляя в базе только горячие данные, тем самым уменьшая объем данных в базе. Для исторических данных нам необходимо предоставить интерфейс запроса для исторических данных.

4, оптимизация интерфейса запросов

Мы разработали интерфейс запроса, дизайн объекта объекта логистики, содержащий запрос, а также некоторые переключатели:

isIncludePackage: этот переключатель сообщает интерфейсу, следует ли проверять информацию о пакете.

isIncludeItems: этот переключатель сообщает интерфейсу, следует ли проверять элементы логистики.

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

5, кластер отдельных чтения и записи

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

7. Резюме

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

Для получения дополнительных статей, пожалуйста, посетите http://www.apexyun.com/

Контактный адрес электронной почты: public@space-explore.com

(Пожалуйста, не перепечатывайте без разрешения)