Railwayclub.info main
Welcome, Guest. Please login or register.
Did you miss your activation email?
16.01.19 , 21:01

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

Posts: 4205


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

А чому ви вважаєте, що проблема саме у каналі? купівля квитка супроводжується обміном дуже невеликої кількості даних, і канали зараз рідко коли проблема. Тут скоріше сервер може бути перевантажений.
По перше, це видно візуально, як вантажиться сайт, і як система реагувала на введення перших трьох літер станції... Тобто це, якщо вже так буде краще розумітися, повинні бути окремі сервери - відповідно до етапів обслуговування замовлення. Front-сервер, Back_1-сервер, Back_2-сервер, End-сервер. Якось так. От перший сервер візьме на себе усю фільтрацію "щасливих претендентів на пасажирство". Кожен наступний сервер (навіть найнедолугіший) цілком впорається із тим, щоб обслужити тих щасливчиків, і передати їх на наступну стадію. Зрештою за цією схемою цілком вистачить і двох серверів, головне, щоб був перший сервер, який допускає щасливчиків до наступного, який працюватиме у звичайному режимі (як у всі нормальні дні до красноштанячого інциденту). Це якимось чином перегується з одним із якихось попередніх дописів про "чергу претендентів". Черга, очевидно є крутішим вирішенням, але цілком достатньо буде якогось тоталізатор-сервера, який відбирає ту кількість щасливчиків, яку спроможний пропустити/обслужити реальний сервер замовлень.
Logged
Iwan
Active user

Posts: 4205


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

З цього опису виходить як раз проблема маштабування. Якщо б система була здатна справитись з піковим навантаженням - наприклад, задіявши додатковий сервер - повторних дублювань запитів не виникло б.
Так, проблема масштабування... як купа невивезеного сміття, яке місяць ніхто не вивозив... і це  не означає, що потрібно докупити сотню сміттярок, аби в одну мить вивезти це сміття... його можна вивозити поступово, і вивезти за 1 тиждень... і це краще розв'язання питання, ніж купувати 100 сміттярок. Навіщо нарощувати ресурс сервера тільки заради компенсування профнепридатності одного єдиного Красноштана? Це занадто високі видатки на вдале маскування його незгабностей.

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

Posts: 4205


View Profile
« Reply #2022 on: 10.12.18 , 00:12 »
Share Reply with quote

Можу трохи додати туалетну аналогію, аби ще трішки краще розумілося: якийсь умовний вагон, зупинка 60хв (якісь там перепричепки), а потім їм відкривають туалет, і замість того, щоб усі (в порядку якоїсь умовної черги) швиденько туди потрапили, пасажири влаштували бійку за те, в якому порядку доступитись до "благ цивілізації". Тобто, потрібен арбітр, який би допускав до сервера  ... чи то в порядку якоїсь справжньої черги (як тут раніше пропонували), або просто - в довільному порядку, головне аби до справжнього сервера допускати не більше, ніж він може коректно опрацювати.
Logged
Sergio
Active user

Posts: 4243


View Profile
« Reply #2023 on: 10.12.18 , 00:12 »
Share Reply with quote


Так, проблема масштабування... як купа невивезеного сміття, яке місяць ніхто не вивозив... і це  не означає, що потрібно докупити сотню сміттярок, аби в одну мить вивезти це сміття... його можна вивозити поступово, і вивезти за 1 тиждень... і це краще розв'язання питання, ніж купувати 100 сміттярок. Навіщо нарощувати ресурс сервера тільки заради компенсування профнепридатності одного єдиного Красноштана? Це занадто високі видатки на вдале маскування його незгабностей.

Дивна аналогія. Сміття буде розкладатись і отруювати життя, тому треба мати стільки сміттярок, щоб вивезти його більш-менш швидко. І якби ж кількість сміття, яку продукують люди була весь час сталою. Вона міняється, і треба мати запас, якщо раптом буде більше. Те ж саме і для системи продажу квитків - дво- або- трикратний пік може виникнути і без усіляких зусиль з боку УЗ, і система має його витримати. Те ж саме з туалетною аналонгією. Крім арбітра ще потрібно, щоб всі встигли за час зупинки, інакше немає сенсу ні у черзі ні у туалеті взагалі.

Буває наприклад що недодумана архітектура БД призводить до того, що транзакції блокують одна одну не поділивши доступ до спільного ресурса, після чого кількість таких транзакції починає різко наростати і ресурси сервера починають швидко марнуватись на їх зберігання і невдовзі закінчуються. У таких випадках - нарощування ресурсів сервера в той чи інший спосіб (якісь хмарні технології чи просто той чи інший апгрейд кластера) майже не допомагає.
Можливо, але... Сам Експрес з таким навантаженням справлявся, а інше - так купівля квитка не потребує збереження даних в бд, хіба тільки додати квитки до профілю. Хоча ще залишається сервер оплати - і я не знаю, чия це розробка, чи УЗ чи якась 3rd party. не виключено, що це власна розробка і там є проблеми.
Logged
Maxy
Главный
Active user

Posts: 22180


View Profile
« Reply #2024 on: 10.12.18 , 00:12 »
Share Reply with quote

Експрес справлявся не в останню через ліміт на кількість запитів від користувачів сайту.
Quote
так купівля квитка не потребує збереження даних в бд, хіба тільки додати квитки до профілю.
а от і ні.
Адже Еспрес сам не обробляє оплату карткою і не він розрізняє оплачені замовлення від неоплачених, цей функціонал на сайтику. Значить сайтик мусить знати про усі транзакції і зіставляти їх з повідомленнями про успішну оплату. Судячи з поведінки - коли оплата прийматись приймалась, але потрім не оброблялась успішна оплата і транзакція "губилась" - саме на цій стадії щось було негаразд.
Сервер оплати - чим би він не був - при цьому працював коректно - тобто дані платежа приймав, давав оплатити, тобто слабкою ланкою був не він.
Logged
Sergio
Active user

Posts: 4243


View Profile
« Reply #2025 on: 10.12.18 , 00:12 »
Share Reply with quote

Експрес справлявся не в останню через ліміт на кількість запитів від користувачів сайту.
Quote
так купівля квитка не потребує збереження даних в бд, хіба тільки додати квитки до профілю.
а от і ні.
Адже Еспрес сам не обробляє оплату карткою і не він розрізняє оплачені замовлення від неоплачених, цей функціонал на сайтику. Значить сайтик мусить знати про усі транзакції і зіставляти їх з повідомленнями про успішну оплату. Судячи з поведінки - коли оплата прийматись приймалась, але потрім не оброблялась успішна оплата і транзакція "губилась" - саме на цій стадії щось було негаразд.
Сервер оплати - чим би він не був - при цьому працював коректно - тобто дані платежа приймав, давав оплатити, тобто слабкою ланкою був не він.
Достеменно невідомо, як воно все там працює, і де зберігаються проміжні дані - у будь-якому випадку, зберігати дані, які актуальні тільки 20-30 хв в базі не обов'язково. Сайт може знати тільки про квитки в процессі купівлі, надсилати на сайт оплати ID та суму, і отримувати те ж саме ID з результатом так або ні. Щодо роботи сервера оплати - я, наприклад, стикався саме з проблемою потрапити на сервер оплати (з різних клієньських пристроїв пробував через різні мережі, і все неуспішно).
Logged
niсk
Active user

Posts: 742


View Profile
« Reply #2026 on: 10.12.18 , 03:12 »
Share Reply with quote

А чому ви вважаєте, що проблема саме у каналі? купівля квитка супроводжується обміном дуже невеликої кількості даних, і канали зараз рідко коли проблема. Тут скоріше сервер може бути перевантажений.
По перше, це видно візуально, як вантажиться сайт, і як система реагувала на введення перших трьох літер станції... Тобто це, якщо вже так буде краще розумітися, повинні бути окремі сервери - відповідно до етапів обслуговування замовлення. Front-сервер, Back_1-сервер, Back_2-сервер, End-сервер. Якось так. От перший сервер візьме на себе усю фільтрацію "щасливих претендентів на пасажирство". Кожен наступний сервер (навіть найнедолугіший) цілком впорається із тим, щоб обслужити тих щасливчиків, і передати їх на наступну стадію. Зрештою за цією схемою цілком вистачить і двох серверів, головне, щоб був перший сервер, який допускає щасливчиків до наступного, який працюватиме у звичайному режимі (як у всі нормальні дні до красноштанячого інциденту). Це якимось чином перегується з одним із якихось попередніх дописів про "чергу претендентів". Черга, очевидно є крутішим вирішенням, але цілком достатньо буде якогось тоталізатор-сервера, який відбирає ту кількість щасливчиків, яку спроможний пропустити/обслужити реальний сервер замовлень.
Не будет ли сервер очереди самым слабым узким системы? Например он подвиснет от нагрузки , а все остальные сервера будут проставивать. Так же возникает ощущение что букинг каждый раз подгружает ui, хотя эти данные можно сохранить на стороне клиента.
В мобильном клиенте часть данных храниться у пользователя и идёт в месте с приложением. Но данные идущие с приложением не обновляется при выходе новой версии. (Поставив приложение с нуля и запустив при выключенном интернете можно найти станцию Днепропетровск-Главный)

Так же можно использовать ассинхронную оплату - но это подойдёт для поездов которые отправляются в ближайшее время. На практике сталкивался со списанием после покупок на Али и букинге
« Last Edit: 10.12.18 , 03:12 by nikooolay » Logged
Iwan
Active user

Posts: 4205


View Profile
« Reply #2027 on: 10.12.18 , 11:12 »
Share Reply with quote

А чому ви вважаєте, що проблема саме у каналі? купівля квитка супроводжується обміном дуже невеликої кількості даних, і канали зараз рідко коли проблема. Тут скоріше сервер може бути перевантажений.
По перше, це видно візуально, як вантажиться сайт, і як система реагувала на введення перших трьох літер станції... Тобто це, якщо вже так буде краще розумітися, повинні бути окремі сервери - відповідно до етапів обслуговування замовлення. Front-сервер, Back_1-сервер, Back_2-сервер, End-сервер. Якось так. От перший сервер візьме на себе усю фільтрацію "щасливих претендентів на пасажирство". Кожен наступний сервер (навіть найнедолугіший) цілком впорається із тим, щоб обслужити тих щасливчиків, і передати їх на наступну стадію. Зрештою за цією схемою цілком вистачить і двох серверів, головне, щоб був перший сервер, який допускає щасливчиків до наступного, який працюватиме у звичайному режимі (як у всі нормальні дні до красноштанячого інциденту). Це якимось чином перегується з одним із якихось попередніх дописів про "чергу претендентів". Черга, очевидно є крутішим вирішенням, але цілком достатньо буде якогось тоталізатор-сервера, який відбирає ту кількість щасливчиків, яку спроможний пропустити/обслужити реальний сервер замовлень.
Не будет ли сервер очереди самым слабым узким системы? Например он подвиснет от нагрузки , а все остальные сервера будут проставивать. Так же возникает ощущение что букинг каждый раз подгружает ui, хотя эти данные можно сохранить на стороне клиента.
В мобильном клиенте часть данных храниться у пользователя и идёт в месте с приложением. Но данные идущие с приложением не обновляется при выходе новой версии. (Поставив приложение с нуля и запустив при выключенном интернете можно найти станцию Днепропетровск-Главный)

Так же можно использовать ассинхронную оплату - но это подойдёт для поездов которые отправляются в ближайшее время. На практике сталкивался со списанием после покупок на Али и букинге

Так, сервер черги буде (і повинен бути) тим вузьким місцем, що лімітує доступ до головного сервера. За таким принципом працюють IVR-системи колцентрів, розділять вхідні дзвінки за категоріями, важливістю тощо, а також організують "телефонну чергу".
Повірте, сервер черги, якщо він буде зайнятий тільки арбітруванням черги, то 50-кратне перевантаження (від середнього рівня) витримає без жодних проблем... йому ж не доведеться порпатись у БД і вишукувати місця, він просто арбітр черги. Як ото є така гра - сортування овець: чорних - ліворуч, білих - праворуч, мішані - посередині... вівці біжать, і їх сортують (на ходу). Якщо Букінг пише "у Вас поганий інтернет", то це означає, що він не може отримати відповіді... от почали йти пакети стандартного повідомлення, і не усі доходять, через раз... в київському метро - асинхронна оплата працює кілька років, але ще раз кажу тут проблема в зовсім іншому.

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

Posts: 4205


View Profile
« Reply #2028 on: 10.12.18 , 11:12 »
Share Reply with quote


Так, проблема масштабування... як купа невивезеного сміття, яке місяць ніхто не вивозив... і це  не означає, що потрібно докупити сотню сміттярок, аби в одну мить вивезти це сміття... його можна вивозити поступово, і вивезти за 1 тиждень... і це краще розв'язання питання, ніж купувати 100 сміттярок. Навіщо нарощувати ресурс сервера тільки заради компенсування профнепридатності одного єдиного Красноштана? Це занадто високі видатки на вдале маскування його незгабностей.

Дивна аналогія. Сміття буде розкладатись і отруювати життя, тому треба мати стільки сміттярок, щоб вивезти його більш-менш швидко. І якби ж кількість сміття, яку продукують люди була весь час сталою. Вона міняється, і треба мати запас, якщо раптом буде більше. Те ж саме і для системи продажу квитків - дво- або- трикратний пік може виникнути і без усіляких зусиль з боку УЗ, і система має його витримати. Те ж саме з туалетною аналонгією. Крім арбітра ще потрібно, щоб всі встигли за час зупинки, інакше немає сенсу ні у черзі ні у туалеті взагалі.
Ні, теорія масового обслуговування допускає/регламентує втрати, і це нормально. Колись датський математик Ерланг писав про це. На цьому, раніше базувалась уся стаціонарна телефонія доцифрової ери. Добре, зі сміттям сприймається важко, то нехай це буде якесь дійство на стадіоні. Всі приїздять громадським транспортом і поступово заповнюють стадіон, а після закінчення матчу усі майже одномоментно поспішають на транспорт додому... звісно буде відмова, бо не може весь стадіон поміститись в одну (першу, дві перші, чи три перші маршрутки). Ніхто не буде купувати нові маршрутки заради "одного вечора".

Чи не дати якомусь місту (10 років тому, бо зараз у багатьох є власний бойлер) гарячої води, а потім подати. Буде зафіксоване різке її споживання. Не знаю, який аналог ще навести. Можна на добу не подавати будь-якої води, а потім дивуватися небувалим попитом на водовідведення (з унітазів)... бо це пікове навантаження не добове, і навіть не сезонне, а спровоковане ВІДКЛАДЕНИМ ПОПИТОМ.


Буває наприклад що недодумана архітектура БД призводить до того, що транзакції блокують одна одну не поділивши доступ до спільного ресурса, після чого кількість таких транзакції починає різко наростати і ресурси сервера починають швидко марнуватись на їх зберігання і невдовзі закінчуються. У таких випадках - нарощування ресурсів сервера в той чи інший спосіб (якісь хмарні технології чи просто той чи інший апгрейд кластера) майже не допомагає.
Можливо, але... Сам Експрес з таким навантаженням справлявся, а інше - так купівля квитка не потребує збереження даних в бд, хіба тільки додати квитки до профілю. Хоча ще залишається сервер оплати - і я не знаю, чия це розробка, чи УЗ чи якась 3rd party. не виключено, що це власна розробка і там є проблеми.
Власне так і є, Maxy, - блокують одна одну не поділивши доступ до спільного ресурсу, бо з гуманних міркувань зробили мегапродуктивний сервер, щоб нікому не було відмов. Практика показала, що при сторонніх завадах (наявності відмов через надмірні часті запити) сервер зумів вдало витримати навантаження, що перевищили 6-кратний рівень середнього дня сезону. Цього цілком достатньо. Там можливо б і 8-кратне навантаження витримав (з чітким обмеженням на доступ), але аж ніяк не 40-кратне навантаження. Так, Maxy, те нарощування є недоцільним. Раніше такі рішення (з відмовою) закладались у так званій "неповнодоступності". Ось перше, що трапило під руку:



Бачимо, що на 32+32 абон.комплекти (абон.лінії) є усього 32 проміжні лінії до яких можуть доступитись 16 вхідних та 16 вихідних комплектів... це не дуже вдалий приклад, ось більш древні АТСК:



Кожна сотня абонентів мала доступ на 60 ліній абонентського шукання, які у свою чергу могли бути сполучені тільки з 20 вхідними та вихідними лініями шукання. Тобто зі 100 абонентів тільки 20 могли ініціювати вихідний зв'язок, і тільки 20 могли його термінувати. 1:5 (!) і це було цілком нормально.

Sergio, ще раз звертаю увагу на те, що сервер УЗ був настільки задрочений клацаннями спраглих кудись поїхати, що по наявних каналах зв'язку не могли надійти квитанції від стороннього сервера оплати, бо йшли тими ж фізичними каналами. Навіть коли б і розмежованими логічними каналами, це б не допомогло. Це хаос у черзі на до ступ до черги. жодних проблем з платежами - вони успішно списувались але задрочений охочими кудись поїхати цей сервер не міг отримати ці квитанції... вони до нього просто не доходили (пакети даних)... а сервер оплати - це не той сервер, який 5 хвилин намагатиметься донести цей пакет, він занадто крутий, щоб 5хв стукати до сервера УЗ. Немає зв'язку - "допобачення сервер УЗ", повторно через 5хв... немає, тоді ще через 5, так чи інакше приходить та квитанція вночі, але 15хв очікувань давно вже пройдуть, місця повторно продадуть, і та квитанція нікому вже не буде потрібна, хіба для того, щоб повернути клієнту кошти.

Сервер черги - це єдина запорука нормальної роботи - захист від дрочерства квиткового сервера УЗ. Я б про це не писав, яки не знав психологія "наших людей": "Букінг трохи підвисає, значить треба тричі оновити сторінку". В масштабах країни - мільйони дурнуватих (непродуктивних запитів), які шкодять один одному.

В даному разі сервер черги - це те "добре зло", яке повинно бути притаманне квитковому серверу.
Logged
Iwan
Active user

Posts: 4205


View Profile
« Reply #2029 on: 10.12.18 , 12:12 »
Share Reply with quote

Ще можу аналогію з якимось лікарем: є електронна черга, яка більш-менш упорядковує процес, а в іншому разі або геть нікого під дверми, або усі та й одразу... і усім "негайно давайте лікаря".
Зараз гречка лежить по 0,45 USD, і ніхто її не гребе мішками... а були часи, коли по 1,5 USD її гребли мішками, бо "може пропасти". Достатньо на тиждень прибрати гречку з усіх полиць, і за перший день можна у 8 раз підняти обсяги виторгу від гречки. Але це геть не означає, що потрібно наступного року засівати гречки у 8 разів більше. Чи не так?
Logged
Tags:
Pages: 1 ... 191 192 193 194 195 196 197 198 199 200 201 202 [203] 204 205 206 207 208 209 210 211
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!