Банкомат тупо от управляющей системы (на свой запрос) ждет ответа - выдавать ему деньги или нет. А вот логика управляющей системы свой ответ предоставляет в зависимости от бизнес логики, которая (в свою очередь) проверяет кучу условий по тому запросу который пришел от банкомата. Одно из бизнес условий я вам озвучил - до проверки клиентского контракта необходимо проверить другой контракт (в условия/баланс которого входят миллионы клиентских). Так как решать то такую проблему? 30 лет назад когда большинство контрактов (и клиентские и консолидированные) были кредитные (не контролирующие в момент исполнения Online операции балансы), проблема не возникала, но... Времена и бизнес условия с тех пор изменились значительно...
Еще раз... Для непонятливых.... Внешняя от вашей логики система не ждет от вас ответа - "что списать могут и ждут команду на подтверждение или отмену"... А ждет от вас однозначный ответ "да" или "нет" за ограниченное количество времени (банкомат ждет выдать вам денег или нет...).
Видимо понятия "Консолидированный баланс" для вас не существует? :-) Тогда "для простоты", пусть "баланс всегда принадлежит конкретному пользователю" но есть условие проверки, что общая сумма "по 1000рпс" (десятка миллионов пользователей) за сутки (ну или за час) не должна превысить определенной конкретной величины.... :-)
:-) А как быть с блокировками и параллельностью при такой бизнес логике работы? Есть один "Общий баланс" с минимально допустимым значением на который влияют операции по всем "Частным балансам". Операция проверяет "Общий баланс" и если он "допустим", проверяет "Частный баланс", и если он больше суммы операции его уменьшает, после уменьшения "Частного баланса" необходимо уменьшить (на сумму операции) "Общий баланс". На все это у вас есть пара секунд до "ответа" - успешно операция выполнилась или нет. И как предлагаете обойтись без транзакций и блокировок если у вас миллионы "Частных счетов" и тысяча операций в секунду? :-)
А можно мне самому решать "может утечь моя учетка или нет"? А остальные 999 999 999 учеток пусть сами решают... Репутация - это когда пользователя 3 раза попросят подтвердить что он хочет использовать "не безопасный" пароль, но позволят ему это сделать. А то что творится сейчас - это "мы лучше вас знаем что вам нужно"... :-(
:-) А можно мне (как пользователю сервисов) самому решать пользоваться ли "не надежным" входом на конкретный сервис с применением собственного пароля? Или "глядя на Apple" все начинают решать за пользователей "что им лучше и удобнее"?
:-) Вы еще не пробовали искать "удаленные" секретные данные на "сырых" носителях... А не в файловой системе... :-) Вот где будет "много сюрпризов".... А на "уровне виртуализации" эти "приключения" еще "интереснее"....
:-) В bigint ID (так же как и в символьных ID) при желании вы можете "впихнуть" что угодно... Номера шардов, дату время (с наносекундами) и все что необходимо базовой логике работы вашего приложения (зачастую "экономя" на дополнительных полях объекта)... Но "по факту" выбор конечно за архитектором прикладного ПО в каждом конкретном случае... "Костыли" потом уже можно будет "подставить".... :-)
:-) Oracle в data file "хранит" только актуальные (не удаленные данные), блоки содержащие удаленные данные помечены как "свободные для записи новых" и если у вас идет рост объема актуальных данных (а в большинстве приложений это так) - то data file будет расти, а если объем актуальных данных не изменится, то и роста data file (в большинстве случает) не будет. А в PG это "не так", "новые" (а "новыми" считаются даже обновленные данные уже существующей записи) данные всегда занимают новое место (целиком размером с блоки записи), а удаленные "не освобождают" место на диске без vacuum, причем для полного "освобождения от старых данных" вам необходимо иметь свободным место под весь текущий объем актуальных данных...
Хорошая статья, но если "копать глубже"... Вопрос о блокировках и целостности данных при многопоточной работе с ними возник еще на "уровне данных хранящихся в памяти", и на уровне работы многоядерных процессоров и OS, и "развился" в последствии на "уровень БД" (которые "по факту" работают "поверх" механизмов CPU и OS).... :-)
Именно карточные технологии дали "пинок" развития e-com, до этого мало кому хотелось ножками идти в пункт Webmoney, или перевести им через поход в свой банк чтобы "вложить" (да еще и с комиссией) деньги в электронный кошелек. Только отдельные "энтузиасты". Но стоило "появиться банковским картам" и ситуация уже изменилась, пошли уже "удаленные продажи по телефону", которые сменились на "покупку по карте на сайте в любой стране мира"(если продавец согласен на доставку в вашу страну), e-bay и т.п. (чему опять способствовали международные карты)....
"По большому" - все как бы "по делу", но... Кому не понятно что если ты "способен выполнять работы больше", то "нагружать тебя работой" будут "до бесконечности". И всегда наступает момент или ты (понимая что "предел наступил") говоришь - "дальше качество/результат моей работы будет ухудшаться или заданное время исполнения работы выдержано не будет", или эта ситуация "произойдет по факту" и заказчик работы это "увидит". Для специалистов "понимающих свой предел" + "хорошо понимающих/прогнозирующих свою работу" + "привыкших делать ее качественно" вариант сказать "стоп хватит" - предпочтительный, а другие специалисты (с отсутствием одного из 3-х критериев) будут "расти до уровня их некомпетентности"... "Умение видеть широко" и понимание "общих технологий" зависит от конкретного человека, его личных способностей + мотивации и для "разных задач и направлений/специфики работы" очень различное....
Наверно для начала можно констатировать что кредит - это всегда доход кредитора (это коммерческие организации и "работают для получения прибыли") и расходы заемщика (за исключением довольно редких исключений). Т.е. за получение определенных услуг/товаров их потребитель платит. В случае кредита потребитель платит как поставщику/производителю услуг/товаров, которые ему необходимы, так и банку/МФО - т.е. расходы потребителя будут однозначно выше чем при отсутствии "прокладки" в виде банка между ним и поставщиком услуги. В случае кредитования заемщик платит "прокладке" (% , комиссии) за возможность получить товар/услугу от поставщика "здесь и сейчас", даже если на текущий момент финансовое состояние заемщика не позволяет оплатить цену необходимую для приобретения этого товара/услуги. Конечно каждый сам определяет (индивидуально) сколько он готов заплатить "за срочность" кредитору.... :-)
Наверно я это писал "Не было бы привязки международных карт к НСПК - тогда бы мы остались без визы и МК."? И это так же - "Ну вот это как раз достижение того самого "полноценно работать"."...
:-) Вы же четкий вопрос задавали? Вот вам и ответ. 1) "Это" было сделано "до запуска НСПК", однако все МПС карты банков полноценно работали (а санкции уже были)... 2) "Это" было реализовано и запущено - за пару недель... А сколько там по времени НСПК запускали? А по поводу - "все и у всех работало"... Сколько там "после запуска НСПК", 3DSecure карточные операции без VISA и MC "не работали"?
:-) Тут с говнокодом разработчиков современных борешься, а предлагается еще бороться с таким же от ИИ? Спрашиваешь разработчика - "Ты почему вот так написал? Есть же еще 5 различных способов решить ту же задачу?". Хорошо если ответит, что про еще 5 способов он хотя бы знает... Задаешь следующий вопрос - "А почему из 6 способов решения выбрал именно этот? Может сравнивал и он оказался самым быстрым/оптимальным/эффективным по затратам CPU/памяти/IO?". Ответ разработчика - "Ну мне проще было так...". Финиш... :-)
Банкомат тупо от управляющей системы (на свой запрос) ждет ответа - выдавать ему деньги или нет. А вот логика управляющей системы свой ответ предоставляет в зависимости от бизнес логики, которая (в свою очередь) проверяет кучу условий по тому запросу который пришел от банкомата. Одно из бизнес условий я вам озвучил - до проверки клиентского контракта необходимо проверить другой контракт (в условия/баланс которого входят миллионы клиентских). Так как решать то такую проблему?
30 лет назад когда большинство контрактов (и клиентские и консолидированные) были кредитные (не контролирующие в момент исполнения Online операции балансы), проблема не возникала, но... Времена и бизнес условия с тех пор изменились значительно...
Еще раз... Для непонятливых.... Внешняя от вашей логики система не ждет от вас ответа - "что списать могут и ждут команду на подтверждение или отмену"...
А ждет от вас однозначный ответ "да" или "нет" за ограниченное количество времени (банкомат ждет выдать вам денег или нет...).
Видимо понятия "Консолидированный баланс" для вас не существует? :-)
Тогда "для простоты", пусть "баланс всегда принадлежит конкретному пользователю" но есть условие проверки, что общая сумма "по 1000рпс" (десятка миллионов пользователей) за сутки (ну или за час) не должна превысить определенной конкретной величины.... :-)
:-) А как быть с блокировками и параллельностью при такой бизнес логике работы?
Есть один "Общий баланс" с минимально допустимым значением на который влияют операции по всем "Частным балансам".
Операция проверяет "Общий баланс" и если он "допустим", проверяет "Частный баланс", и если он больше суммы операции его уменьшает, после уменьшения "Частного баланса" необходимо уменьшить (на сумму операции) "Общий баланс". На все это у вас есть пара секунд до "ответа" - успешно операция выполнилась или нет.
И как предлагаете обойтись без транзакций и блокировок если у вас миллионы "Частных счетов" и тысяча операций в секунду? :-)
А можно мне самому решать "может утечь моя учетка или нет"? А остальные 999 999 999 учеток пусть сами решают...
Репутация - это когда пользователя 3 раза попросят подтвердить что он хочет использовать "не безопасный" пароль, но позволят ему это сделать. А то что творится сейчас - это "мы лучше вас знаем что вам нужно"... :-(
:-) А можно мне (как пользователю сервисов) самому решать пользоваться ли "не надежным" входом на конкретный сервис с применением собственного пароля? Или "глядя на Apple" все начинают решать за пользователей "что им лучше и удобнее"?
А файловая система у вас не на сырых блочных устройствах? :-)
:-) Вы еще не пробовали искать "удаленные" секретные данные на "сырых" носителях... А не в файловой системе... :-) Вот где будет "много сюрпризов".... А на "уровне виртуализации" эти "приключения" еще "интереснее"....
:-) В bigint ID (так же как и в символьных ID) при желании вы можете "впихнуть" что угодно... Номера шардов, дату время (с наносекундами) и все что необходимо базовой логике работы вашего приложения (зачастую "экономя" на дополнительных полях объекта)...
Но "по факту" выбор конечно за архитектором прикладного ПО в каждом конкретном случае... "Костыли" потом уже можно будет "подставить".... :-)
:-) Oracle в data file "хранит" только актуальные (не удаленные данные), блоки содержащие удаленные данные помечены как "свободные для записи новых" и если у вас идет рост объема актуальных данных (а в большинстве приложений это так) - то data file будет расти, а если объем актуальных данных не изменится, то и роста data file (в большинстве случает) не будет. А в PG это "не так", "новые" (а "новыми" считаются даже обновленные данные уже существующей записи) данные всегда занимают новое место (целиком размером с блоки записи), а удаленные "не освобождают" место на диске без vacuum, причем для полного "освобождения от старых данных" вам необходимо иметь свободным место под весь текущий объем актуальных данных...
Хорошая статья, но если "копать глубже"... Вопрос о блокировках и целостности данных при многопоточной работе с ними возник еще на "уровне данных хранящихся в памяти", и на уровне работы многоядерных процессоров и OS, и "развился" в последствии на "уровень БД" (которые "по факту" работают "поверх" механизмов CPU и OS).... :-)
Именно карточные технологии дали "пинок" развития e-com, до этого мало кому хотелось ножками идти в пункт Webmoney, или перевести им через поход в свой банк чтобы "вложить" (да еще и с комиссией) деньги в электронный кошелек. Только отдельные "энтузиасты".
Но стоило "появиться банковским картам" и ситуация уже изменилась, пошли уже "удаленные продажи по телефону", которые сменились на "покупку по карте на сайте в любой стране мира"(если продавец согласен на доставку в вашу страну), e-bay и т.п. (чему опять способствовали международные карты)....
Судя по тексту статьи, ответ на ваш вопрос всего один - не использовать "чужие виртуальные ресурсы", а просто "развернуть свое железо".... :-)
"По большому" - все как бы "по делу", но...
Кому не понятно что если ты "способен выполнять работы больше", то "нагружать тебя работой" будут "до бесконечности". И всегда наступает момент или ты (понимая что "предел наступил") говоришь - "дальше качество/результат моей работы будет ухудшаться или заданное время исполнения работы выдержано не будет", или эта ситуация "произойдет по факту" и заказчик работы это "увидит". Для специалистов "понимающих свой предел" + "хорошо понимающих/прогнозирующих свою работу" + "привыкших делать ее качественно" вариант сказать "стоп хватит" - предпочтительный, а другие специалисты (с отсутствием одного из 3-х критериев) будут "расти до уровня их некомпетентности"...
"Умение видеть широко" и понимание "общих технологий" зависит от конкретного человека, его личных способностей + мотивации и для "разных задач и направлений/специфики работы" очень различное....
Наверно для начала можно констатировать что кредит - это всегда доход кредитора (это коммерческие организации и "работают для получения прибыли") и расходы заемщика (за исключением довольно редких исключений).
Т.е. за получение определенных услуг/товаров их потребитель платит.
В случае кредита потребитель платит как поставщику/производителю услуг/товаров, которые ему необходимы, так и банку/МФО - т.е. расходы потребителя будут однозначно выше чем при отсутствии "прокладки" в виде банка между ним и поставщиком услуги.
В случае кредитования заемщик платит "прокладке" (% , комиссии) за возможность получить товар/услугу от поставщика "здесь и сейчас", даже если на текущий момент финансовое состояние заемщика не позволяет оплатить цену необходимую для приобретения этого товара/услуги.
Конечно каждый сам определяет (индивидуально) сколько он готов заплатить "за срочность" кредитору.... :-)
Наверно я это писал "Не было бы привязки международных карт к НСПК - тогда бы мы остались без визы и МК."?
И это так же - "Ну вот это как раз достижение того самого "полноценно работать"."...
:-) Будь вы хоть не много "в теме", то мнения про "исключительность и технологичность" НСПК у вас бы не возникало... :-)
https://www.banki.ru/wikibank/obyedinennaya_raschetnaya_sistema/
:-) Вы же четкий вопрос задавали? Вот вам и ответ.
1) "Это" было сделано "до запуска НСПК", однако все МПС карты банков полноценно работали (а санкции уже были)...
2) "Это" было реализовано и запущено - за пару недель... А сколько там по времени НСПК запускали?
А по поводу - "все и у всех работало"... Сколько там "после запуска НСПК", 3DSecure карточные операции без VISA и MC "не работали"?
:-) Именно карты VISA и MC работали в заблокированных ими российских банках и без НСПК....
Прочитайте про ОРС - https://www.kommersant.ru/doc/2437346
:-) Тут с говнокодом разработчиков современных борешься, а предлагается еще бороться с таким же от ИИ?
Спрашиваешь разработчика - "Ты почему вот так написал? Есть же еще 5 различных способов решить ту же задачу?". Хорошо если ответит, что про еще 5 способов он хотя бы знает... Задаешь следующий вопрос - "А почему из 6 способов решения выбрал именно этот? Может сравнивал и он оказался самым быстрым/оптимальным/эффективным по затратам CPU/памяти/IO?".
Ответ разработчика - "Ну мне проще было так...". Финиш... :-)