Skip to main content
Version: 0.7.4

Дизайн

Бизнес-аналитика#

Бизнес-границы#

Система включает в себя только оставшуюся часть управления билетами.То есть, чтобы проверить оставшиеся места, купить билеты, чтобы уменьшить место.

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

Бизнес-варианты использования#

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

Реализуем анализ трудностей#

Управление оставшимися билетами#

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

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

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

Теперь мы предполагаем, что есть один раз, который проходит через четыре станции a, b, c, d, и в то же время мы упрощаем сценарий, предполагая, что есть только одно место в автомобиле.

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

От конца до концаОставшиеся голоса
a,b1
a,c1
a,d1
b,c1
b,d1
c,d1

Если клиент покупает билет a,c сейчас.Так как есть только одно место, нет билетов, кроме c, d.Остаток голосов становится следующим:

От конца до концаОставшиеся голоса
a,b0
a,c0
a,d0
b,c0
b,d0
c,d1

Чтобы быть более прямой, если клиент покупает полный билет a, d, все оставшиеся билеты будут 0.Потому что пассажир всегда сидит на этом сиденье.

Это специфика билета на поезд:одно и то же место в том же поезде, количество оставшихся билетов в каждом пункте отсеи, зависит от происхождения и конца проданного билета.

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

Запрос остаточного билета#

Как отмечалось в предыдущем разделе, из-за специфики запасов оставшихся билетов.Для одного и того же транспортного средства a, b, c, d, есть 6 возможных вариантов покупки билетов.

И мы можем легко сделать вывод, что количество выбранных видов на самом деле рассчитывается как количество комбинаций, которые выбирают 2 на n сайтах, т.е. c(n, 2).

Тогда если у вас есть автомобиль, который проходит через 34 станции, его возможной комбинацией является c(34,2) — 561.

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

Дизайн тела Claptrap#

Train Ticketing System Design

Каждое место на одном и том же автомобиле было разработано как Claptrap - SeatGrain#

State этого Claptrap содержит основную информацию

ТипИмяописание
IList<int>StationsId-список станций маршрута начинается с начальной станции и заканчивается конечной станцией.Проверка при покупке билетов в основном.
Dictionary<int, int>StationDicОбратный словарь индекса для идентификатора станции пути.Stations — это список index-id, который является словарем соответствующего id-index для ускорения запросов.
List<string>RequestIdsКлючевые свойства.Идентификатор покупки билета, который был покупкой билета в каждом интервале.Например, индекс — 0, что означает идентификатор покупки билета от станции 0 до станции 1.Если он пуст, это означает, что нет билета на подписку.

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

Убедитесь, что вы можете приобрести его#

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

Например, текущая ситуация с Stations составляет 10, 11, 12, 13. В то время как RequestIds 0, 1, 0.

Ну, если вы хотите приобрести билет>10-12, это не так, так как второй интервал RequestIds уже куплен.

Однако, если вы покупаете билеты на 10->11, вы можете, потому что первый интервал RequestIds еще никто не покупает.

Купить#

Просто соотдайте конечную точку идентификатором покупки билета на всех настройках интервала в RequestIds.

Дизайн оставшихся билетов на все места на одном и том же автомобиле, как Claptrap-TrainGran#

State этого Claptrap содержит некоторую основную информацию

ТипИмяописание
IReadOnlyList<int>StationsId-список станций маршрута начинается с начальной станции и заканчивается конечной станцией.Проверка при основном запросе.
IDictionary<StationTuple, int>SeatCountКлючевые свойства.StationTuple представляет собой конечную точку.Коллекция содержит все возможные условия билета от конечной точки.Например, если автомобиль проходит через 34 места выше, словарь содержит 561 ключевой набор значений

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

Например, если a, c происходит покупка билета, вычитаете оставшиеся билеты a, c/a, b/b, c.

Это можно сделать с помощью механизма Minion, встроенного в эту платформу.

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

Id#

Train Ticketing System Id