Я лишь указал, что сравнивать размер данных сырого protobuf и сжатого json - не очень актуально. А жать данные - да, это всегда вопрос утилизации проца. Но иногда бывает так, что потери в проце становятся ничтожными, в сравнении с потерями от передачи сырых данных.
Столкнулся с такой же проблемой, аккаунт уже удалили.
Если глубже почитать их документы, то если вы из РФ, то вам не дадут возможности пройти проверки из-за всяких документов и прочего. В основном касается денежных всяких вопросов, которые пройти невозможно. Это как с godaddy - "мы документы РФ не принимаем". Обновить приложение и подтвердить почту мало. Активность проявлять тоже мало.
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут. Организация решает не везде, но то что она дает мультипликативный эффект - да.
Все под управлением кубернетис, внутри него крутится (кроме БД, редиса и кафки). Если вы про миграцию между кубернетис кластерами, то на этот вопрос пока не могу ответить, но могу сказать, что без отключения шарда на время - перенос невозможен, за исключением случаев, когда БД/редис не мигрируют никуда. Возможно вы имели ввиду перенос сущностей между шардами?
Поддержка кафки добавлена две недели назад. Пока никак ничего не масштабируется. Конфигурация "как есть" и "что бы работало". Даже НТ не делал.
Но за вопрос про кафку спасибо, будет что изучить.
Именно они и не нужны для проведения платежей. Вы видимо ни эту статью не читали, ни предыдущие. И в код не заглядывали, хотя ссылки есть. Не вижу смысла с вами спорить, потому что вы ожидаете определенный ход вещей, а все иное для вас по определению ошибка.
Речь идет о транзакции, которая запускается при работе с БД с целью выполнения запросов в рамках одного окна. Если происходит ошибка или иная проблема - все изменения откатываются.
Именно эти транзакции и не требуются для работы с финансовыми данными.
С и С++ не подходят для прикладных приложений. Я бы вообще уже постарался бы выводить их из использования, потому что они устарели по всем показателям.
Главная проблема С и С++ в том, что нужно быть мега-крутым, что бы что-то дельное писать, но что бы стать мега-крутым, надо кучу программ написать. И когда ты приложение напишешь - тебе никто не сможет сказать, что все работает правильно.
Но в целом с видосом согласен =) Поэтому и писал на Java изначально. Только нужно учитывать, что сервис проектировался таким образом, что у него есть ядро, которое можно написать один раз и больше не трогать - потому что не нужно.
Большая часть микросервисов такой фокус не провернет. Постоянно что-то менять надо. И менять много!
Делаете всем банкоматам, у которых есть лимит один кошелек. Делаете правило, что на баланс в этот кошелек нельзя переводить больше, чем Х рублей за период. Количество рпс значения не имеет. Все операции можно проводить параллельно.
Вариант 2, делаете специальный ресурс "лимит", который банкоматы "покупают". В этом случае у всех банкоматов может быть свой кошелек. Т.е. у вас будет контракт, состоящий из: 1. Перевод Х от клиента банкомату; 2. Банкомат покупает на Х лимитов с спец. кошелька; 3. Покупка у банкомата клиентом банкнот с серийниками, ну или если их нет - просто пишем, что "выдача наличных средств из банкомата YYY". Т.к. каждый ресурс (а деньги на балансе - это ресурс) нужно в начале подготовить к списанию, то ваш лимит выглядит вообще просто - обычный ресурс, каждый день ставите лимит в Х миллиардов рублей по cron-правилу и все. Наступило 00:00 и не важно, сколько сейчас лимит - делаете его Х млрд рублей. И подключаете ваши банкоматы, хоть все сразу на покупку лимитов у кошелька. Количество рпс значения не имеет от слова полностью. Если решите домашнее задание, то поймете, что упретесь в сетевые адаптеры и IOPS. В этой статье не просто так в домашнем задании сказано про резервирование товаров. Это универсальный алгоритм. Так же как и протокол общения с ресурсными подсистемами, такими как баланс - он универсальный.
И если в первом случае сделать лимит очень сложно (на самом деле сложно, лично я браться не буду за такое), то в случае с покупкой банкоматом лимита с какого-то спец. кошелька - это вообще легко и просто. И даже если по каким-то причинам банкомат деньги не выдаст, то просто отменим контракт, потому что банкомат не подтвердил выдачу (у контракта есть возможность сделать так, что бы стороны подтвердили, что можно завершать, когда все готово к процессу завершения). Но у вас вроде как есть "установка" на да или нет, так что вам явно не подходит более безопасный вариант.
И еще, про этот лимит вы мне сейчас говорите.
UPD: на самом деле можно даже ресурс "лимит" не создавать. Просто на кошельке держать деньги, которые могут быть переданы только банкоматам и больше никому. Система это прямо сейчас умеет. В этом случае даже усложнять ничего не придется. Оно просто будет работать.
UPD2: Для сервиса Баланс будет лучше, если лимит будет не устанавливаться в Х каждый день, а будут создаваться балансы заранее, в которых будет прописано, что АктивноС и АктивноДо - это с начала дня и до начала следующего дня. С точки зрения архитектуры сервиса Баланс, в т.ч. на данный момент это будет более правильным решением. Огромный +, что записи можно создавать заранее и не беспокоится, что что-то пройдет не так, а если и пойдет - сразу звать тех поддержку.
У налоговой в системе mireapay контроль еще выше, чем в текущей системе. Налоговая буквально является частью платежной системы и все проводимые платежи по идее должны проводиться с уплатой налогов сразу в налоговую, минуя всякие юрлица, т.е. покупая что-то - НДС сразу улетает в налоговую, переводя зп сотруднику - НДФЛ сразу вычисляется системой;
Контроль у государства в mireapay еще выше, чем есть сейчас, потому что можно не только контроллировать куда уходят деньги, но и кому и почему. Этому будет посвящена отдельная статья про СОРМ и в целом гос безопасность с секретностью;
Мошенникам будет еще сложнее, потому что если физ лицо получает деньги от множества других лиц (или сумма слишком большая, скажем больше 100 тыс), то полученные деньги могут быть "временно" заморожены и доложено куда надо, что бы разобрались. Деньги будут на счету у "мошенника", но забрать их можно будет в любой момент и вернуть потерпевшему, пока заморозка конкретных средств не пройдет. Причем работает это таким образом, что замораживается конкретная сумма, а не вообще весь счет. Даже если будет ложное срабатывание - людям жизнь это не испортит, свои деньги, которые у него до этого были - он сможет тратить как и раньше.
Уважаемый, правда, я вижу что вам в боль со мной общаться и вам сложно понять мои слова. Вы не читали мои статьи, особенно от 1 сентября, где все описано. Перечитайте, пожалуйста, мои статьи по mireapay. Вам яснее станет, что никаких мечтательством у меня и не пахнет в работе.
Банкомат - это просто "еще один кошелек", что бы выдать деньги мы можем передавать деньги на кошелек банкомата. Если успешно проходит - выдаем деньги. Тот кто стоит перед банкоматом деньги не получит, если у него на балансе нет нужной суммы и/или у банкомата нет нужных средств для выдачи - например не хватает банкнот или еще какой-либо мелочи. Причем при формировании таких запросов можно контроллировать такую штуку как "банкнотный ресурс" - потому что банкноты не являются "деньгами", это штуки, у которых есть серийник и от продажи чайников они никак не отличаются. Человек, который в банкомате снимает деньги для системы mireapay будет выглядеть как покупать банкнот с номерами 1,2,3,4. И это будет отражаться в контракте. Правда скорее всего для этого уже нужно будет банкоматы переделывать. Вряд ли серийники где-то хранятся в банкоматах сейчас и/или есть возможность у инкасаторов вводить такую информацию.
И это лишь один из вариантов решения. Если вас для принципиально, что банкомат - это тупая кнопка, то можно списывать деньги со счета клиента на какой-нибудь специальный счет. И потом система уже выдаст разрешение, что выдать деньги можно.
Но первый вариант мне кажется намного лучше, потому что у каждого банкомата будет свой цикл обработки и все что ему нужно будет - это дождаться завершения обработки контракта - считай разрешения, что можно выдать деньги или нет. Я уже не говорю про безопасность и аудит. На счете банкомата должен отражатся объем выданных средств. При начислении денег (клиент вносит сумму в банкомат) - банкомат переводит со своего счета на счет клиента - т.е. в явной форме еще и фиксируется откуда пришли деньги, потому что у каждого банкомата свой счет. Можно проводить аудит конкретного банкомата. Если удается - он завершает операцию, если нет - возвращает деньги. Если деньги вносит инкасатор - то деньги списываются в специальный счет - печатную машинку откуда деньги могут генерироваться в систему и который их и поглощает, цифры на этом счете можно рисовать любые, потому что это делает государство и ему без разницы какая сумма там будет, потому что эти деньги не существуют для экономики. Так как вся система контроллируется гос органами и только государство владеет узлами обработки, либо напрямую контроллируется специально обученным полковником - то это вполне нормально работает.
Вообще не очень понятно почему тема ушла в банкоматы, если это утилитарная вещь и ее реализовать можно многочисленными способами.
Причем эти два - это то что пришло в голову сразу. Существующие банкоматы, если я правильно понял ваши слова - вообще менять не надо, что бы они работали с mireapay. Сделать для них адаптер, который будет выполнять нужные команды - это вопрос 4-12 человеко-часов. Во всяком случае, если как вы говорите, ему надо сказать "да" или "нет".
Так же вы видимо забываете, что у меня нет заказчика и нет требований от него, что я обязан следовать требованиям "какого-то там регулятора с горы".
Что бы что-то требовать от меня, нужно для начала иметь влияние. А писать про "у нас оно работать так должно" - идите к тем, кто сидит на зарплате.
Если вы не способны мыслить за рамками вашего "загона", то пожалуйста, не тратьте хотя бы собственное время. Я уверен, что вы очень занятой человек, занимающий важную должность "где-то".
Этот разговор не стоит затрачиваемого вами времени.
Я лишь указал, что сравнивать размер данных сырого protobuf и сжатого json - не очень актуально.
А жать данные - да, это всегда вопрос утилизации проца. Но иногда бывает так, что потери в проце становятся ничтожными, в сравнении с потерями от передачи сырых данных.
В общем случае бинарный формат хранения с сжатием gzip даст больше сохраненного места, чем json с сжатием.
Что мешает сжимать protobuf?
Столкнулся с такой же проблемой, аккаунт уже удалили.
Если глубже почитать их документы, то если вы из РФ, то вам не дадут возможности пройти проверки из-за всяких документов и прочего. В основном касается денежных всяких вопросов, которые пройти невозможно. Это как с godaddy - "мы документы РФ не принимаем".
Обновить приложение и подтвердить почту мало. Активность проявлять тоже мало.
Если в армии даже огранизованная группа желторотиков - это сила, то в программировании как вы говнокодеров не сажайте - лучше они работать не будут.
Организация решает не везде, но то что она дает мультипликативный эффект - да.
<deleted>
Все под управлением кубернетис, внутри него крутится (кроме БД, редиса и кафки). Если вы про миграцию между кубернетис кластерами, то на этот вопрос пока не могу ответить, но могу сказать, что без отключения шарда на время - перенос невозможен, за исключением случаев, когда БД/редис не мигрируют никуда. Возможно вы имели ввиду перенос сущностей между шардами?
Поддержка кафки добавлена две недели назад. Пока никак ничего не масштабируется. Конфигурация "как есть" и "что бы работало". Даже НТ не делал.
Но за вопрос про кафку спасибо, будет что изучить.
Про демонов вы еще CI/CD расскажите. Там сессия закончилась - будь добр выключиться. Никаких демонов.
Для успешного запуска вируса нужно всего лишь запускаться от рута. Дальше уже дело техники.
Нельзя просто так взять и скопировать чужую 3D модель.
Да, поправил. Спасибо. Видимо при копировании потерялось
Вот именно в предметной области вы и не разбираетесь, потому что не понимаете азов информатики. Изучите для началу теорию, потом возвращайтесь.
Именно они и не нужны для проведения платежей. Вы видимо ни эту статью не читали, ни предыдущие. И в код не заглядывали, хотя ссылки есть.
Не вижу смысла с вами спорить, потому что вы ожидаете определенный ход вещей, а все иное для вас по определению ошибка.
Речь идет о транзакции, которая запускается при работе с БД с целью выполнения запросов в рамках одного окна. Если происходит ошибка или иная проблема - все изменения откатываются.
Именно эти транзакции и не требуются для работы с финансовыми данными.
Есть и другие ЯП, компилируемые в исполняемые файлы. Некоторые даже используют тот же тулчейн, что и gcc.
С и С++ не подходят для прикладных приложений.
Я бы вообще уже постарался бы выводить их из использования, потому что они устарели по всем показателям.
Главная проблема С и С++ в том, что нужно быть мега-крутым, что бы что-то дельное писать, но что бы стать мега-крутым, надо кучу программ написать.
И когда ты приложение напишешь - тебе никто не сможет сказать, что все работает правильно.
Но в целом с видосом согласен =) Поэтому и писал на Java изначально.
Только нужно учитывать, что сервис проектировался таким образом, что у него есть ядро, которое можно написать один раз и больше не трогать - потому что не нужно.
Большая часть микросервисов такой фокус не провернет. Постоянно что-то менять надо. И менять много!
Это как раз предполагается. Вариант, что штекер вытащили и все рухнуло. Даже в этом случае все должно восстанавливаться.
Делаете всем банкоматам, у которых есть лимит один кошелек. Делаете правило, что на баланс в этот кошелек нельзя переводить больше, чем Х рублей за период.
Количество рпс значения не имеет. Все операции можно проводить параллельно.
Вариант 2, делаете специальный ресурс "лимит", который банкоматы "покупают". В этом случае у всех банкоматов может быть свой кошелек.
Т.е. у вас будет контракт, состоящий из:
1. Перевод Х от клиента банкомату;
2. Банкомат покупает на Х лимитов с спец. кошелька;
3. Покупка у банкомата клиентом банкнот с серийниками, ну или если их нет - просто пишем, что "выдача наличных средств из банкомата YYY".
Т.к. каждый ресурс (а деньги на балансе - это ресурс) нужно в начале подготовить к списанию, то ваш лимит выглядит вообще просто - обычный ресурс, каждый день ставите лимит в Х миллиардов рублей по cron-правилу и все. Наступило 00:00 и не важно, сколько сейчас лимит - делаете его Х млрд рублей. И подключаете ваши банкоматы, хоть все сразу на покупку лимитов у кошелька. Количество рпс значения не имеет от слова полностью. Если решите домашнее задание, то поймете, что упретесь в сетевые адаптеры и IOPS. В этой статье не просто так в домашнем задании сказано про резервирование товаров. Это универсальный алгоритм. Так же как и протокол общения с ресурсными подсистемами, такими как баланс - он универсальный.
И если в первом случае сделать лимит очень сложно (на самом деле сложно, лично я браться не буду за такое), то в случае с покупкой банкоматом лимита с какого-то спец. кошелька - это вообще легко и просто. И даже если по каким-то причинам банкомат деньги не выдаст, то просто отменим контракт, потому что банкомат не подтвердил выдачу (у контракта есть возможность сделать так, что бы стороны подтвердили, что можно завершать, когда все готово к процессу завершения). Но у вас вроде как есть "установка" на да или нет, так что вам явно не подходит более безопасный вариант.
И еще, про этот лимит вы мне сейчас говорите.
UPD: на самом деле можно даже ресурс "лимит" не создавать. Просто на кошельке держать деньги, которые могут быть переданы только банкоматам и больше никому. Система это прямо сейчас умеет. В этом случае даже усложнять ничего не придется. Оно просто будет работать.
UPD2: Для сервиса Баланс будет лучше, если лимит будет не устанавливаться в Х каждый день, а будут создаваться балансы заранее, в которых будет прописано, что АктивноС и АктивноДо - это с начала дня и до начала следующего дня. С точки зрения архитектуры сервиса Баланс, в т.ч. на данный момент это будет более правильным решением. Огромный +, что записи можно создавать заранее и не беспокоится, что что-то пройдет не так, а если и пойдет - сразу звать тех поддержку.
У налоговой в системе mireapay контроль еще выше, чем в текущей системе. Налоговая буквально является частью платежной системы и все проводимые платежи по идее должны проводиться с уплатой налогов сразу в налоговую, минуя всякие юрлица, т.е. покупая что-то - НДС сразу улетает в налоговую, переводя зп сотруднику - НДФЛ сразу вычисляется системой;
Контроль у государства в mireapay еще выше, чем есть сейчас, потому что можно не только контроллировать куда уходят деньги, но и кому и почему. Этому будет посвящена отдельная статья про СОРМ и в целом гос безопасность с секретностью;
Мошенникам будет еще сложнее, потому что если физ лицо получает деньги от множества других лиц (или сумма слишком большая, скажем больше 100 тыс), то полученные деньги могут быть "временно" заморожены и доложено куда надо, что бы разобрались. Деньги будут на счету у "мошенника", но забрать их можно будет в любой момент и вернуть потерпевшему, пока заморозка конкретных средств не пройдет. Причем работает это таким образом, что замораживается конкретная сумма, а не вообще весь счет. Даже если будет ложное срабатывание - людям жизнь это не испортит, свои деньги, которые у него до этого были - он сможет тратить как и раньше.
Уважаемый, правда, я вижу что вам в боль со мной общаться и вам сложно понять мои слова. Вы не читали мои статьи, особенно от 1 сентября, где все описано.
Перечитайте, пожалуйста, мои статьи по mireapay. Вам яснее станет, что никаких мечтательством у меня и не пахнет в работе.
Банкомат - это просто "еще один кошелек", что бы выдать деньги мы можем передавать деньги на кошелек банкомата. Если успешно проходит - выдаем деньги. Тот кто стоит перед банкоматом деньги не получит, если у него на балансе нет нужной суммы и/или у банкомата нет нужных средств для выдачи - например не хватает банкнот или еще какой-либо мелочи. Причем при формировании таких запросов можно контроллировать такую штуку как "банкнотный ресурс" - потому что банкноты не являются "деньгами", это штуки, у которых есть серийник и от продажи чайников они никак не отличаются. Человек, который в банкомате снимает деньги для системы mireapay будет выглядеть как покупать банкнот с номерами 1,2,3,4. И это будет отражаться в контракте. Правда скорее всего для этого уже нужно будет банкоматы переделывать. Вряд ли серийники где-то хранятся в банкоматах сейчас и/или есть возможность у инкасаторов вводить такую информацию.
И это лишь один из вариантов решения. Если вас для принципиально, что банкомат - это тупая кнопка, то можно списывать деньги со счета клиента на какой-нибудь специальный счет. И потом система уже выдаст разрешение, что выдать деньги можно.
Но первый вариант мне кажется намного лучше, потому что у каждого банкомата будет свой цикл обработки и все что ему нужно будет - это дождаться завершения обработки контракта - считай разрешения, что можно выдать деньги или нет. Я уже не говорю про безопасность и аудит. На счете банкомата должен отражатся объем выданных средств. При начислении денег (клиент вносит сумму в банкомат) - банкомат переводит со своего счета на счет клиента - т.е. в явной форме еще и фиксируется откуда пришли деньги, потому что у каждого банкомата свой счет. Можно проводить аудит конкретного банкомата. Если удается - он завершает операцию, если нет - возвращает деньги. Если деньги вносит инкасатор - то деньги списываются в специальный счет - печатную машинку откуда деньги могут генерироваться в систему и который их и поглощает, цифры на этом счете можно рисовать любые, потому что это делает государство и ему без разницы какая сумма там будет, потому что эти деньги не существуют для экономики. Так как вся система контроллируется гос органами и только государство владеет узлами обработки, либо напрямую контроллируется специально обученным полковником - то это вполне нормально работает.
Вообще не очень понятно почему тема ушла в банкоматы, если это утилитарная вещь и ее реализовать можно многочисленными способами.
Причем эти два - это то что пришло в голову сразу. Существующие банкоматы, если я правильно понял ваши слова - вообще менять не надо, что бы они работали с mireapay. Сделать для них адаптер, который будет выполнять нужные команды - это вопрос 4-12 человеко-часов. Во всяком случае, если как вы говорите, ему надо сказать "да" или "нет".
Так же вы видимо забываете, что у меня нет заказчика и нет требований от него, что я обязан следовать требованиям "какого-то там регулятора с горы".
Что бы что-то требовать от меня, нужно для начала иметь влияние. А писать про "у нас оно работать так должно" - идите к тем, кто сидит на зарплате.
Если вы не способны мыслить за рамками вашего "загона", то пожалуйста, не тратьте хотя бы собственное время. Я уверен, что вы очень занятой человек, занимающий важную должность "где-то".
Этот разговор не стоит затрачиваемого вами времени.