Railwayclub.info main
Welcome, Guest. Please login or register.
Did you miss your activation email?
20.03.19 , 11:03

Login with username, password and session length
Home | Help | Search | Login | Register | References | Blogs | Contact Information

railwayclub.info: train travel answers, travel deals

  discussion

    Other questions about railways

      Система продажи он-лайн билетов УЗ booking.uz.gov.ua

Pages: 1 ... 189 190 191 192 193 194 195 196 197 198 199 200 [201] 202 203 204 205 206 207 208 209 210 211 212 213
Reply | Print
Author Topic: Система продажи он-лайн билетов УЗ booking.uz.gov.ua  (Read 644465 times)
Sergio
Active user

Posts: 4253


View Profile
« Reply #2000 on: 07.12.18 , 20:12 »
Share Reply with quote

Поясніть, хто знається краще на мережевих технологіях: чи можна було б ГІОЦу для "спілкування" з платіжними системами виділити окремий логічний (чи навіть фізичний більшої гарантії) комунікаційний канал, щоб система Букінг могла отримувати підтвердження (квитанції) про успішну оплату тих замовлень, які системі вдалося дотягнути до етапу "на оплату". Тобто, якщо вже потенційному пасажиру так пощастило, що він дійшов до етапу "оплата", то наступний етап (отримання підтвердження платіжної системи) повинен бути хоча б в 10 раз гарантованіший, тобто канал зв'язку повинен бути в 10 раз менш зайнятий... а щоб це гарантувати, то краще прокласти окремий "кабельок" (в т.ч. оптичну жилу)... і тоді не потерпатимуть ті, хто сплатив за замовлення... і отримають квитки. Правильний хід думки?
Не зовсім. яким би не був кабель - імовірність помилки є. Ну тобто канал можна покращити, але головне - тримати інформацію про квитки корисувача навіть між сесіями, прив'язану до ідентифікатора користувача. Тоді не важливо - чи не відповів сервер оплати, чи пропав інтернет, чи пристрій покупця перезавантажився, можна зайти в свій кабінет, побачити статус квитків і залишок часу для оплати. В такому випадку неуспішну операцію легко повторити. (до речі приблизно так у ПКП).

п.м. Зараз модель вибудувана так, як в передових магазинах часів застою (в СРСР), тільки в "електронному еквіваленті": покупець стояв у черзі на оформлення покупки, йому називали суму, він йшов до касира, стояв теж у черзі, називав номер відділу і суму, давав готівку, касир видавала чек, потім знову стояв у черзі, аби той чек обміняти на відкладений для нього товар... тільки в нашому випадку з Букінгом "людині з чеком" потрібно ставати ще раз в ту первинну чергу, але регламент каже "15хв і допобачення"... тобто "людина з чеком" стоїть хоча б 16хв, і "все пропало".
Зараз модель приблизно така сама - продаж квитків окремо, оплата окремо. Єдине, інтернет дозволяє сховати це від користувача. Дійсно, підхід УЗ це вчорашній день, і не дуже гарне usability. Хорошим тоном вважається показувати покупцю за що він платить. Тобто - крім даних картки і кнопки "оплатити" - коротенький текстовий опис - у випадку квитка - маршрут, прізвище, дата. І не переадресовувати на сервер оплати, а використовувати його як API, а покупець взаємодіє тільки з сервером УЗ.

Також можна подумати про організацію веб-черги. Бачив схоже на УЄФА при купівлі квитків, можливо суміщене з балансуванням. Як працює - користувач заходить на сайт, а по факту - на сервер черги. Якщо сервер продажу вільний (або імовірніше - є вліьний кластер) - користувача одразу переадресують на сайт купівлі. Якщо ж сервер/кластери купівлі завантажені - видається повідомлення, що за пару хвилин він користувач потрапить на сайт купівлі. Коли з'являться ресурси - перенаправля на вільний (або єдиний) сервер. Тут перевага в тому, що сайт купівлі не буде перевантажений неуспішними операціями. Наприклад, позавчора, чи коли там, я купив квитки з 8 разу, тобто сім спроб - це пусте завантаження.

Можливо спеціалісти з devops більше скажуть.
Logged
Iwan
Active user

Posts: 4229


View Profile
« Reply #2001 on: 07.12.18 , 22:12 »
Share Reply with quote

Тобто отримання інформації про вдалий платіж через інший канал зв'язку (навіть іншим кабелем) хіба б не врятував ситуацію? Як я зрозумів, ці "квитанції" про успішну оплату намагались прорватися в ті ж самі "двері", що й мільйони користувачів зі своїми множинними запитами (тут наявність черги доступу до сервісу була б дуже доречною), а тому упродовж тієї регламентної 15-хвилинки залишались "за бортом".
Logged
Emblaze
Active user

Posts: 3507


View Profile
« Reply #2002 on: 07.12.18 , 22:12 »
Share Reply with quote

Проблема C10К в классическом виде, уровень университетского курса "Введение в теорию распределенного программирования". Хоть сейчас в учебники заноси.

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

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

« Last Edit: 07.12.18 , 22:12 by Emblaze » Logged
ЛиС
Active user

Posts: 9707


View Profile
« Reply #2003 on: 07.12.18 , 23:12 »
Share Reply with quote

Emblaze, там ещё и "железо" сильно "так себе". Даже на грузовом серевере (АСКВП УЗ) периодически случаются глюки, особенно в "пиковое" время (15-30 - 17-30), а ему всего пару лет отроду...
Logged
Sergio
Active user

Posts: 4253


View Profile
« Reply #2004 on: 08.12.18 , 00:12 »
Share Reply with quote

Тобто отримання інформації про вдалий платіж через інший канал зв'язку (навіть іншим кабелем) хіба б не врятував ситуацію? Як я зрозумів, ці "квитанції" про успішну оплату намагались прорватися в ті ж самі "двері", що й мільйони користувачів зі своїми множинними запитами (тут наявність черги доступу до сервісу була б дуже доречною), а тому упродовж тієї регламентної 15-хвилинки залишались "за бортом".
Допомогло, але ж проблема не завжди у пропускнній здатності. Просто система повинна бути більш толерантна до збоїв. І недоставка квитанції про успішну оплату була не єдиною проблемою. Я всі свої сім разів просто не потрапив на сервер оплати, причому одразу (тобто скоріше не тайм-аут а сервер відбивав запити бо перевантажений).
« Last Edit: 08.12.18 , 00:12 by Sergio » Logged
Volotar
Active user

Posts: 521


View Profile
« Reply #2005 on: 08.12.18 , 02:12 »
Share Reply with quote

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

Необов'язково саме на Erlang. Erlang – це звісно круто, але УЗ – це не Фейсбук і не WhatsApp, і Erlang в їхньому випадку буде, як з гармати по горобцях. А Erlang-спеціалістів на ринку ще піди знайди. У мене на минулій роботі з певного моменту >5 млн. Daily Active Users (більшість, з яких заходили протягом коротких 2-годинних проміжків) стали в порядку речей. І теж була проблема в масштабуванні, поки компанія не найняла толкових DevOps та BackEnd-інженерів, які ітеративно перепроектували систему під Kubernetes кластер, та промігрували шматки, що залишались з часів PHP на Go. Все – проблем як не було.

Я думаю що УЗ до 5 млн. DAU ще трохи далеко (з розрахунку що 227 тис. купило квитки протягом доби і прикидки, що це зробив кожен десятий користувач системи). Але поки вони не усвідомлять, що в них проблема з масштабуванням, і що під це треба виділяти гроші та шукати людей з відповідним досвідом (яким ще потім потрібно надати можливість працювати та втілювати свої ідеї без перешкод та мізкограйства з боку нетехнічного керівництва УЗ), доти ситуація буде лише погіршуватись.

І ще одне – в 2018 розміщувати бекенд високонавантаженої системи на одному (двох, трьох…) серверах, коли на ринку доступно так багато сloud-рішень (в тому числі для корпоративного сектору з власною інфраструктурою), і коли вже навіть інертні німецькі корпоративні монстри переїхали в сloud – це як дивитись на запуск ракети Falcon до Марсу по чорно-білому телевізору. 
Logged
Emblaze
Active user

Posts: 3507


View Profile
« Reply #2006 on: 08.12.18 , 09:12 »
Share Reply with quote

Ну да, про Go тоже хотел упомянуть, но отвлекся. Или Rust вот еще можно, да?
« Last Edit: 08.12.18 , 09:12 by Emblaze » Logged
Sergio
Active user

Posts: 4253


View Profile
« Reply #2007 on: 08.12.18 , 10:12 »
Share Reply with quote

ой панове, я вас умоляю. Эрланги-шмерланги, система, сделанная прямыми руками на бесплатных инструментах из Java стека вполне покрыла бы потребности УЗ.

А с другой стороны ядро быстро не переделаешь, а оно тоже может быть источником ограничений.
Logged
Emblaze
Active user

Posts: 3507


View Profile
« Reply #2008 on: 08.12.18 , 11:12 »
Share Reply with quote

А сколько ему примерно лет от роду с учетом всех наслоений, 15-20?
Logged
jbond989
Active user

Posts: 1321


View Profile
« Reply #2009 on: 08.12.18 , 11:12 »
Share Reply with quote

Левова частка запитів до БД - це запити про наявність місць між заданими станціями на задану дату. Рік тому було кілька невдалих спроб зменшити навантаження шляхом кешування результатів таких запитів.
Але є ще інший шлях: змінити логіку самих запитів з метою зменшення їх ресурсомісткості.
Оскільки більшість потенційних пасажирів моніторить місця на конкретний поїзд, то надання їм такої можливості в інтерфейсі знизило б на порядок навантаження на сервер БД.
Logged
Tags:
Pages: 1 ... 189 190 191 192 193 194 195 196 197 198 199 200 [201] 202 203 204 205 206 207 208 209 210 211 212 213
Reply | Print
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.8 | SMF © 2006-2008, Simple Machines LLC Valid XHTML 1.0! Valid CSS!