Railwayclub.info main
Welcome, Guest. Please login or register.
Did you miss your activation email?
24.06.19 , 19:06

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

Posts: 270


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

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

https://m.zn.ua/internal/borispolskiy-ekspress-piar-i-korrupciya-302597_.html
Logged
Emblaze
Active user

Posts: 3874


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

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

Дык каждый делится опытом собственной работы. Кто-то откаты с продаж билетов оттачивает, кто-то распределенные облачные технологии. xD

В целом я, конечно, согласен, что при остром желании и потребности сэкономить вполне возможно пропатчить букинг на основе существующих, как ни громоздких, решений. К примеру, вполне вероятно, что Internet Explorer в той или иной форме останется существовать в недрах Windows вечно, как раз для совместимости с подобными замшелыми программными веб-комплексами, густо заваренными на Java, JS+PHP и пр. (Но его преемника Edge это уже не касается; EdgeHTML вчера официально прикрыли.) Но и тут созревают свои "золотые малины"; сайт мосметро в его Silverlight-воплощении мог седьмую корку одного из первых поколений подвесить.
« Last Edit: 08.12.18 , 13:12 by Emblaze » Logged
niсk
Active user

Posts: 767


View Profile
« Reply #2012 on: 09.12.18 , 19:12 »
Share Reply with quote

Что вы про облака, сотрудники УЗ уверены, что ни одно серьезное предприятие не доверится хранению данных не на серверах в своих помещениях)
По рассказам у УЗ существует своя оптика вдоль основных линий, которая используется только для нужд УЗ - мне кажется не использование одной известной сети общего пользование, очередное "грамотное решение". Так же говорят на дарнице есть 2 сервера, основной и резервный, при этом резервный в обычное время не выполняет практически никаких работ, почему не предусмотрена возможность использования как ноты вопрос открытый...
Logged
Sargis
User

Posts: 70


View Profile
« Reply #2013 on: 09.12.18 , 21:12 »
Share Reply with quote

Что вы про облака, сотрудники УЗ уверены, что ни одно серьезное предприятие не доверится хранению данных не на серверах в своих помещениях)
По рассказам у УЗ существует своя оптика вдоль основных линий, которая используется только для нужд УЗ - мне кажется не использование одной известной сети общего пользование, очередное "грамотное решение". Так же говорят на дарнице есть 2 сервера, основной и резервный, при этом резервный в обычное время не выполняет практически никаких работ, почему не предусмотрена возможность использования как ноты вопрос открытый...
Мне кажеться ты тупой
Logged
Iwan
Active user

Posts: 4314


View Profile
« Reply #2014 on: 09.12.18 , 22:12 »
Share Reply with quote

Тобто отримання інформації про вдалий платіж через інший канал зв'язку (навіть іншим кабелем) хіба б не врятував ситуацію? Як я зрозумів, ці "квитанції" про успішну оплату намагались прорватися в ті ж самі "двері", що й мільйони користувачів зі своїми множинними запитами (тут наявність черги доступу до сервісу була б дуже доречною), а тому упродовж тієї регламентної 15-хвилинки залишались "за бортом".
Допомогло, але ж проблема не завжди у пропускнній здатності. Просто система повинна бути більш толерантна до збоїв. І недоставка квитанції про успішну оплату була не єдиною проблемою. Я всі свої сім разів просто не потрапив на сервер оплати, причому одразу (тобто скоріше не тайм-аут а сервер відбивав запити бо перевантажений).
Я зрозумів, а точніше - дізнався від Вас про ще одну проблему/ваду - ініціаціія обміну даними (коректне відкриття сесії) з платіжною системою - теж виявилось проблемою... але розв'язок міг би бути таким самим, тільки більш багатоканальнішим (у фізичному плані):
1-й фізичний канал для первинної стадії запитів (перегляд меню/форми вибору сполучень);
2-й фіз. канал активується для тих, кому вдалося зробити запит - таким користувачам відкривається список поїздів (так, як зараз є), користувачі обирають те, що їм потрібно;
3-й фіз канал активується для роботи з платіжними системами (безпосередньо не пов'язаний із потенційним пасажиром);
4-й фіз канал активується для введення/трансляції інформації картки та відбораження результату придбання квитка.
Таким чином, існування чотирьох незалежних фізичних каналів гарантує ізольованість кожного каналу від перевантаження інших каналів. Найперше можна очікувати перевантаженість першого каналу, а до усіх інших не повинно дійти. Перший канал повинен бути "найширшим" (за пропускною здатністю та операційною спроможністю процесорів), усі інші необхідно ізолювати винятково для уникнення впливу. Нічого особливого це не вимагає. Всі оці перевантаження наступають (якщо абстрагуватись від негативного красноштанячого фактора) через те, що накопичуються відмови, які породжують наступні запити. Це можна порівняти з тим, як у середньовіччі брали фортеці: прийшла перша шеренга воїнів до стіни, почали вилазити на драбини, за ними наступна шеренга на ті ж самі драбини, наступні шеренги - туди ж... воїни першої шеренги починають падати зверху, підводяться, і долучаються до наступних шеренг, які ще не були на драбині (навантаження зростає удвічі).... одним словом - одиниці долазили до верхівки фортових мурів, а навантаження на драбини стрімко росло, бо це була найслабша ланка в усьому процесі/тракті, яка крім того накопичувала збої.
Якщо коротко, то необхідно забезпечити гарантоване (безвідмовне) обслуговування для тих, хто пройшов попередній (а найголовніше - перший) етап процесу.

Тепер проаналізуємо наслідки такої ізоляції:
1) усі, хто побачив інтерфейс вибору маршруту, ті неодмінно отримають відповідь про наявність місць;
2) усі, хто отримав відповідь про наявність місць, ті неодмінно отримають можливість обрати конкретне місце;
3) усі, хто обрав конкретне місце, ті неодмінно отримають можливість сплатити вартість замовлення;
4) усі, хто отримав можливість сплатити вартість замовлення, ті неодмінно отримають підтвердження оплати (99,99%, бо тут ще платіжні впливи можуть бути, не пов'язані з УЗ).

Це тупе апаратне розмежування. Тут не потрібно особливо видатних фахівців від програмування. А можливо і взагалі жодної модернізації не потрібно, якби не було впливу негативного красноштанячого фактору з відтермінуванням продажу через нездатність формувати пасажироорієнтовану політику пас перевезень? (запитання риторичне) Зробив би усе одразу по нормальному, то не було б 100500 переробок з великомучениками-графістами.
« Last Edit: 09.12.18 , 22:12 by Iwan » Logged
Sergio
Active user

Posts: 4285


View Profile
« Reply #2015 on: 09.12.18 , 22:12 »
Share Reply with quote

А чому ви вважаєте, що проблема саме у каналі? купівля квитка супроводжується обміном дуже невеликої кількості даних, і канали зараз рідко коли проблема. Тут скоріше сервер може бути перевантажений.
Logged
Iwan
Active user

Posts: 4314


View Profile
« Reply #2016 on: 09.12.18 , 23:12 »
Share Reply with quote

Я думаю що УЗ до 5 млн. DAU ще трохи далеко (з розрахунку що 227 тис. купило квитки протягом доби і прикидки, що це зробив кожен десятий користувач системи). Але поки вони не усвідомлять, що в них проблема з масштабуванням, і що під це треба виділяти гроші та шукати людей з відповідним досвідом (яким ще потім потрібно надати можливість працювати та втілювати свої ідеї без перешкод та мізкограйства з боку нетехнічного керівництва УЗ), доти ситуація буде лише погіршуватись.
Це не проблема з масштабуванням, а проблема з навмисно створеним КШ відкладеним попитом на товар (квитки). Якщо проаналізувати попит у періоди з 12.11 по 03.12 двох попередніх років та цього року, то побачимо, що цього року попит на квитки у зазначений період був приблизно на третину меншим. Тепер про Вашу, volotar, масштабність: кожного дня 1/3 квитків від очікуваного обсягу не була реалізована. За 21 день (з 12.11 по 03.13) такої "нереалізації" обсяг "нереалізації" був еквівалентний 7-денному усередненому обсягу за цей період. Крім того, касноштанячий фактор перетворився у фактор додаткового ажіотажу. Настав "перший день" і на дотаток до "денного попиту" додався ще 7-денний відкладений попит, що в результаті спричинило до 8-кратного попиту, який через досягнення критичного рівня гарантованого обслуговування та з урахуванням 5-кратних (у середньому) повторних дублювань цих запитів фактично перетворився на 40-кратний ріст запитів, бо машина (на даному етапі еволюції) не розмежовує первинний невдалий запит від наступних дубляжів запиту... для неї це все єдина множина запитів. В результаті - те що всі знають (не буду писати).
Logged
Sergio
Active user

Posts: 4285


View Profile
« Reply #2017 on: 09.12.18 , 23:12 »
Share Reply with quote

З цього опису виходить як раз проблема маштабування. Якщо б система була здатна справитись з піковим навантаженням - наприклад, задіявши додатковий сервер - повторних дублювань запитів не виникло б.
Logged
Maxy
Главный
Active user

Posts: 22486


View Profile
« Reply #2018 on: 09.12.18 , 23:12 »
Share Reply with quote

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

Posts: 3874


View Profile
« Reply #2019 on: 09.12.18 , 23:12 »
Share Reply with quote

Кстати, да. Там еще вполне состояние гонки может быть, когда семафоры и балансировщики нагрузки друг другу мешают (железнодорожная специфика почти обязывает, бгг). Результатом будет ошибка типа backend_connection_closed_before_data_sent_to_client.

Первый подвернувшийся пример с Github для иллюстрации этой мысли:

https://github.com/cloudflare/lua-resty-logger-socket/issues/13

Возможно, следует поднять данные tcpdump и поиграть с параметрами keepalive_timeout и keepalive_requests, или идейно аналогичными им, при обработке запросов? Здесь это помогло.
« Last Edit: 09.12.18 , 23:12 by Emblaze » Logged
Tags:
Pages: 1 ... 190 191 192 193 194 195 196 197 198 199 200 201 [202] 203 204 205 206 207 208 209 210 211 212 213 214 ... 229
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!