Проектирование системы логистики на основе идеи Чжунтай (3): построение адресных возможностей логистики

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

Описание: Четырехуровневая адресная таблица.

Структура таблицы:

Имя поля	Тип поля	может быть пустым	описывать
id	bigint	нет	первичный ключ
name	varchar(128)	нет	название
code	varchar(32)	нет	кодирование
level	int	нет	Уровни: 1, 2, 3, 4
parent_code	varchar(32)	да	Улучшенный адресный код
country	varchar(16)	да	Общее имя по умолчанию
language	varchar(16)	да	ZH_CN по умолчанию
status	int	нет	1 нормальный, 2 заброшенный
post_code	varchar(16)	да	почтовый индекс
longititude	varchar(32)	да	долгота
latitude	varchar(32)	да	измерение
version	int	нет	номер версии
feature	varchar(1024)	да	нет
gmt_created	datetime	нет	время создания
gmt_modified	datetime	нет	Изменить время

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

Адрес уровня 4 Уровень 1:

Код провинции состоит из двух цифр, начиная с 1 до 34, представляющих 34 административных района провинциального уровня (23 провинции + 4 муниципалитета + 5 автономных районов + 2 специальных административных района), взяв в качестве примера Чжэцзян, это 8

Адрес уровня 4 Уровень 2:

Код города состоит из двух цифр, увеличивающихся с 01. Провинция + город составляют вторичный адрес.В качестве примера возьмем Ханчжоу, это 801.

Адрес уровня 4 Уровень 3:

Код города состоит из двух цифр, увеличивающихся с 01. Провинция + город + регион составляют трехуровневый адрес.В качестве примера возьмем район Сиху, Ханчжоу, это 80103.

Адрес уровня 4 Уровень 4:

Код улицы состоит из двух цифр, начиная с 01. Провинция + город + регион + улица составляют четырехуровневый адрес.В качестве примера возьмем улицу Гуданг, район Сиху, город Ханчжоу, провинция Чжэцзян, это 8010301.

Каждый уровень адреса выше связан с адресом предыдущего уровня через parent_code, поэтому, если вы знаете какой-либо адрес уровня 1, вы можете проверить весь адрес уровня 4.

Описание: Таблица адресов пользователей

Структура таблицы

Имя поля	Тип поля	может быть пустым	описывать
id	bigint	нет	первичный ключ
user_id	bigint	нет	ID пользователя
user_name	varcahr(64)	да	имя пользователя
shop_id	bigint	да	Идентификатор магазина
user_type	int	нет	Тип пользователя: 1 покупатель, 2 продавца
telephone	varchar(16)	да	Телефонный номер
phone	varchar(16)	да	Номер наземной линии связи
country	varchar(16)	да	страна, Китай по умолчанию
province	varchar(16)	да	название провинции
province_code	varchar(32)	да	код провинции
city	varchar(32)	да	название города
city_code	varchar(32)	да	код города
area	varchar(32)	да	название области
area_code	varchar(32)	да	код города
street	varchar(32)	да	название улицы
street_code	varchar(32)	да	код улицы
detail_address	varchar(1024)	нет	Адрес
address_code	varchar(32)	нет	минимальный код
is_default	int	нет	по умолчанию, 1 по умолчанию, 2 не по умолчанию
language	varchar(16)	да	Язык, по умолчанию ZH_CN
post_code	varchar(16)	да	почтовый индекс
version	int	нет	номер версии
feature	varchar(1024)	да	нет
gmt_created	datetime	нет	время создания
gmt_modified	datetime	нет	Изменить время

показатель:

user_id обычный индекс

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

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

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

Учитывая, что адресные данные четвертого уровня не могут обновляться несколько раз в год, мы в итоге выбрали второе решение: кеш на основе in-memory базы данных H2. Мы инкапсулируем файл данных H2, SQL базы данных H2 и интерфейс Mybatis в клиентский пакет.Внешние системы напрямую полагаются на этот клиентский пакет для получения возможностей библиотеки адресов четвертого уровня. Когда данные базы данных адресов будут обновлены, мы переупакуем клиент, и другие приложения смогут получить последние адресные данные четвертого уровня, обновив пакет клиента.

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

Мы используем Redis GEO API для сопоставления адресов с широтой и долготой Общая архитектура выглядит следующим образом:

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

Мы используем Redis Geo API в основном с двумя командами:

1.GEOADD

Команда: ключ GEOADD долгота широта член [долгота широта член ...]

Описание команды: Добавить указанное геопространственное местоположение (широта, долгота, имя) к указанному ключу.

Возвращаемое значение: количество элементов, добавленных к отсортированному набору, за исключением элементов, оценка которых была обновлена.

2.GEORADIUS

Команда: ключ GEORADIUS долгота широта радиус м|км|фут|ми [WITHCOORD] [WITHDIST] [WITHHASH] [COUNT count]

Описание команды:

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

Диапазоны могут использовать одну из следующих единиц измерения:

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

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

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