Дизайн, оптимизация, анализ
Приложение для складских помещений — это платформа, на которой владельцы складских помещений могут связаться с клиентом, которому необходимо хранить свои товары и предметы в течение определенного периода времени.
Требования и цели системы
Давайте разработаем приложение со следующими требованиями:
Функциональные требования
Владелец пространства:
- Подключение нового пространства, склада к приложению
- Обновление информации о существующем пространстве. Возможно, вы захотите добавить или изменить область.
- Посмотрите, какие заказы на конкретный период времени.
Клиент:
- Поиск места для хранения в определенном месте с критериями поиска
- Забронируйте склад на определенный период времени. С минимальной продолжительностью, скажем, 15 дней.
- Проверить бронирование
Дополнительные требования:
- Владелец помещения для предоставления услуг по вывозу и доставке товаров
- Товары могут быть личными, деловыми, документальными, бытовыми или автомобилями.
- Возможность просмотра видео в прямом эфире (если видеонаблюдение установлено владельцем помещения). Это укрепляет доверие.
- Страхование товара за счет собственников помещений. Все приложения могут удерживать деньги от владельца пространства, полностью возмещать их и возвращать владельцам пространства после окончания срока действия контракта.
- Аналитика, чтобы проверить, какие места и области работают лучше всего.
Нефункциональные требования
- Низкая задержка
- Высокая доступность
- Высокая консистенция.
Оценка емкости
Предположим, что по всему миру имеется около 500 тысяч владельцев пространства и около 10 миллионов дискового пространства.
У этого приложения будет меньше активных пользователей, поскольку пользователи в основном будут использовать сервис один раз в определенный период времени.
Архитектура системы
Наше приложение в основном будет состоять из трех основных пользовательских интерфейсов:
- Пользовательский интерфейс/приложение для владельцев Space
- Пользовательский интерфейс / приложение для клиентов, чтобы делать заказы
- Общий пользовательский интерфейс/приложение для просмотра бронирований
Наше приложение будет состоять из следующих компонентов:
- Балансировщики нагрузки: они балансируют трафик на несколько серверов, поступающий со всех пользовательских интерфейсов, помогая масштабировать приложение.
- Служба хранения: эта служба позволит владельцам пространства сохранять информацию о своем пространстве для хранения, а также включать данные больших двоичных объектов, то есть изображения / видео места.
- Кластер NoSql: для сохранения метаданных пространства для хранения. Для этого мы можем использовать любую базу данных nosql.
- CDN: нам понадобится CDN для географического распределения информации
Вся информация будет в режиме реального времени обновляться для клиентов и владельцев помещений относительно нового хранилища, загруженного для поиска и сделанных бронирований. Для этого мы будем использовать очереди сообщений, такие как Kafka или Rabbit MQ.
- KAFKA: Для обеспечения потоковой передачи данных от производителей к потребителям.
- Потребитель поиска: данные о новом хранилище, обновленные в приложении, будут передаваться потребителям поиска, которые подключатся к Elastic Search.
- ЭЛАСТИЧНЫЙ поисковый кластер: в основном используется быстрый поиск, а также нечеткий поиск.
- Служба поиска: Служба поиска сможет получить результат эластичного поиска и предоставить пользовательскому интерфейсу клиента.
- Служба бронирования: службы бронирования позволяют клиентам заблокировать определенное хранилище на определенный период времени. Эти данные будут поступать в Kafka. Почему? Поскольку мы однажды забронировали место для хранения, мы не хотим, чтобы оно отображалось в поиске в течение этого конкретного периода времени.
- Служба бронирования свяжется с платежной службой для оплаты. После успешной оплаты мы можем сделать бронирование успешным в нашем кластере nosql.
- Архивная служба: для живых бронирований. Это в основном блокирует заказы и сохраняет данные в базе данных Casandra. Также можно использовать HBase.
- Служба уведомлений: для уведомления всех пользователей. Например, если заказ сделан клиентом, сообщите об этом владельцу помещения. В противном случае, если он будет отменен владельцем пространства, уведомите клиентов.
- Служба управления бронированием: эта служба будет общаться с клиентами и владельцами помещений, чтобы просмотреть бронирование. Бронирование происходит из кластеров NoSQL (со словами: «Отмена», «Выполняется», «Платеж не выполнен», «Успех») и осуществляется через базу данных Casandra для оперативных бронирований.
- Redis: чтобы уменьшить нагрузку на наш кластер базы данных и используется в качестве кеша для быстрого поиска.
- Кластер Hadoop: для потоков транзакций пространства и бронирования, и мы можем анализировать и управлять некоторыми M.L. над ним.
API и дизайн базы данных
У нас будет 4 основных API для загрузки и обновления хранилища:
POST /space (к новому встроенному хранилищу)
GET /space/:id (Чтобы получить определенное хранилище для просмотра информации и бронирования)
PUT /space/:id(Чтобы изменить информацию об определенном пространстве)
DELETE /space/:id (Чтобы удалить определенное пространство)
Для бронирования у нас будет:
POST /booking(Чтобы забронировать определенное хранилище в определенный интервал времени)
Для использования базы данных реляционная база данных подходит для этой бизнес-модели из-за ее гарантий ACID.
Космическая база данных
Space: {id, type, name, locality, dimensions, amenities, description, original_images, is_active, price_per_day}
SpaceType ENUMS: [PERSONAL, BUSINESS]
SpaceAmenities: {id, space_id, amenity_id, is_active}
SpaceLocality: {id, city_id, state_id, country_id, zipcode, is_active}
База данных бронирования
AvailableSpace: {space_id, date, initial_qty, available_qty > 0}
Booking: {booking_id, space_id, user_id, start_date, end_date, status, invoice_id, goods_type}
GoodsType ENUMS: [HOUSEHOLD, AUTOMOBILE, OFFICE_ITEMS]
Status ENUMS: [RESERVED, BOOKED, CANCELLED, COMPLETED]
Как API будет взаимодействовать от пользовательского интерфейса к серверу приложений, а затем, в конечном итоге, к базе данных:
POST /bookнапример, с этими параметрами{booking_id, space_id, user_id, start_date, end_date}
- Проверить наличие свободного места [каждое доступное место/комната]
- Вставьте в БД бронирования и уменьшите
available_qty - Поместите Redis с TTL (Time to Live), например, с 10-минутным бронированием в реальном времени, чтобы зарезервировать бронирование, а затем оно истечет. Redis уведомит об истечении срока действия токена. Мы займемся этим позже.
- Вставьте Кафку (очередь сообщений)
- Перенаправление на Платежи. При желании можно перенаправить в чат для одноранговой связи между владельцем и клиентом (обновите статус бронирования, чтобы опубликовать это)
Как обращаться с токеном Redis Expire Token?
Ключ Redis в конечном итоге истечет.
- Если срок действия ключа Redis истекает, а затем платеж проходит успешно, мы можем справиться с этим несколькими способами, например, либо вернуть платеж пользователю, уведомив его об истечении срока действия запроса. Или более разумный способ сделать это — проверить, доступно ли доступное хранилище, а затем забронировать его.
- Если платежи проходят успешно, мы можем игнорировать, если срок действия токена Redis истек.
Оптимизация
Если платеж прошел успешно, мы можем напрямую удалить ключ из Redis.
Мы также должны контролировать всю систему на предмет того, как работают процессор и память.
Во всей инфраструктуре нам нужно следить за процентом использования ЦП и процентом использования памяти и диска.
Мониторинг может осуществляться с помощью инструмента типа grifana, в котором мы можем настроить оповещения для определенного порога. Если какой-либо порог будет превышен, разработчик будет предупрежден.
Это очень важно для низкой задержки и высокой доступности.
Аналитика
Мы можем настроить журналы Kibana в нашем приложении и создать различные типы графиков на панели управления kibana, чтобы отслеживать, как и какое хранилище работает лучше всего, спрос и предложение в определенной области, а также каков процент успешных и неудачных заказов. .
Основываясь на этих данных, бизнес принимает решение о том, как и в каком направлении должно быть сфокусировано приложение.
Распределенные данные
Мы можем распределить наши данные географически, установив центры обработки данных в другой части региона, так как пространство хранения в основном будет установлено в одной конкретной области и не будет перемещаться.
Таким образом, пользователь из региона 1 говорит, что Индия должна получать данные из центра обработки данных в Индии, а пользователь из региона 2 говорит, что США должны получать данные из центра обработки данных в США.
Данные будут иметь узлы репликации. Это делается, если один из узлов выходит из строя, другой может занять его место для получения информации/данных. Репликация также может быть сопряжена с разбиением данных по регионам,
