Получается, что даже не имея лицензии, но продав цифровую копию на площадке, площадка может оформить все так, что доступ вполне даже сохраниться. Было бы желание. И так понимаю, все вполне законно, большие площадки не хотят ссориться, рано или поздно все закончится и нужно будет продолжать работу со всеми.
Вопрос знатокам, в КиноПоиск тоже продавались фильмы. Правообладатели ушли и не продлили лицензии. Как обыватель, вижу оба сценария если не идентичными, то близкими. Понятно, что нужно читать договора. Остался ли доступ к купленным но ушедшим фильмам на КиноПоиск?
Почему сразу запреты. Фонд кино инвестирует свои (читай бюджетные) деньги и вполне может закладывать условия получения этих денег. Если не хочется их исполнять, можно не брать у них, а искать в другом месте и показывать в кадре что душа пожелает.
Когда приеду на Пхукет, обязательно воспользуюсь. Но с 2022 Google, перестал актуализировать карты, причины понятны, но от это не легче. В то же время в Я без проблем внёс правки и после модерации они стали доступны всем.
На Гугл картах не то что моего дома нет, района нет, даже земли на которой он стоит весь район нет. И это СПб. Особенно удобно в ТГ было смотреть гео трекинг, по сути по компасу искать приходилось.
Так понял, что сейчас это single node server? И как раз для масштабирования планируется добавление raft и тп., а почему не смотрите в сторону распределенных БД чтобы там хранить мету (распространенная практика) или смотрели, но сознательно решили не идти туда?
Есть два сценария: RW и чистый R. Вот в первом случае понижать гарантии есть риск собрать бинго. Если смотрим на чистый R, то тут уже можно обменивать гарантии на что-то другое. В частности, можно читать чуть неконсистентные данные в моменте чтения, но в следующий момент все будет ок.
слетает не бронь, а ВРЕМЕННАЯ блокировка пока клиент билет выбрал, но не оплатил (Ну так она и должна слетать если сессия клиента отвалилась). А вот в програмной эмуляции - придется огород городить, если во время блокировки клиент отвалился.
Т.е. вы предлагаете:
получаем запрос на один из N инстов и открываем транзакцию
держим эту транзакцию до завершения
при обработке все действия с этим платежом роутим на этот же инст где транзакция, иначе как мы ее закроем
получили оплату, закрываем транзакцию
PROFIT
Если верно понял схему то сходу возникают задачи, которые нужно решать:
sticky session
таймаут на транзакцию все равно нужен, т.к. (если коговорим про web) пользователь может закрыть/обновить страницу, потерять соединение и это нормально, но в итоге у нас разорвется соединение, как следствие клиент типо ушел, транзакция висит, но он же не ушел никуда. Да и вообще процессы оплаты бывают очень разные
как перезапустить сервис, чтобы не сбросить пользователей, которые в процессе оплаты (прервать happy path)
Видится мне, что это не сильно проще чем просто временная блокировка, а поддержка возможно и сложнее.
auto err=tr->commit(updateTotal, &fileSize); // call_back и аргумент
это вот этот пример?
судя по всему callback синхронный, для репликации во внешнее хранилище минус, так же не вижу как прервать транзакцию внутри этого метода или такой возможности нет или нужно исключение кидать?
И код приложен zip архивом, а не в публичной репке о_О?
А это прям так плохо и ужасно? Могу конечно ошибаться, но транзакция живет, пока живо соединение с БД, получается, если мы решим перезапустить инстанс приложения, то все наши транзакции (брони) слетают? Иначе наши сервисы из stateless превращаются в statefull.
Что значит блокировать, не дать другому купить его? Зачем для этого длинная транзакция? Добавляем поле status (и другие если надо), помечаем что забронировано, все, теперь хоть через 1с, хоть через 10, хоть через сутки другие не смогут его забронировать и это будет работать на любой БД с транзакциями достаточными для выполнения простого обновления.
Если очень хочется, можете поднять лимит, но зачем?
В остальном он предлагает аналогичную концепцию создания структур второго порядка на базе мамы и транзакций.
То что описано у вас хорошо, но как это использовать в реальной жизни? Если говорим про сервис, то нужно минимум 2 экземпляра, следовательно надо решать проблемы синхронизации и тд.
Какие пессимистичные блокировки в распределенных системах о_О? Если они вам нужны, транзакции вам в помощь, реализуем распределенную блокировку + подписка на ключ и вот вам "оптимистичная блокировка" хоть на сутки.
Есть примитивы, достаточно надёжные, далее из них строим все что нужно на уровне приложения.
Получается, что даже не имея лицензии, но продав цифровую копию на площадке, площадка может оформить все так, что доступ вполне даже сохраниться. Было бы желание. И так понимаю, все вполне законно, большие площадки не хотят ссориться, рано или поздно все закончится и нужно будет продолжать работу со всеми.
Вопрос знатокам, в КиноПоиск тоже продавались фильмы. Правообладатели ушли и не продлили лицензии. Как обыватель, вижу оба сценария если не идентичными, то близкими. Понятно, что нужно читать договора. Остался ли доступ к купленным но ушедшим фильмам на КиноПоиск?
А можно описать профиль генерируемой нагрузки и размер данных передаваемых?
Почему сразу запреты. Фонд кино инвестирует свои (читай бюджетные) деньги и вполне может закладывать условия получения этих денег. Если не хочется их исполнять, можно не брать у них, а искать в другом месте и показывать в кадре что душа пожелает.
Когда приеду на Пхукет, обязательно воспользуюсь. Но с 2022 Google, перестал актуализировать карты, причины понятны, но от это не легче. В то же время в Я без проблем внёс правки и после модерации они стали доступны всем.
На Гугл картах не то что моего дома нет, района нет, даже земли на которой он стоит весь район нет. И это СПб. Особенно удобно в ТГ было смотреть гео трекинг, по сути по компасу искать приходилось.
Тогда можно и на https://github.com/deepseek-ai/3FS посмотреть, не S3 совместимое, но распределенное хранилище.
А будет запись докладов?
Так понял, что сейчас это single node server? И как раз для масштабирования планируется добавление raft и тп., а почему не смотрите в сторону распределенных БД чтобы там хранить мету (распространенная практика) или смотрели, но сознательно решили не идти туда?
Есть два сценария: RW и чистый R. Вот в первом случае понижать гарантии есть риск собрать бинго. Если смотрим на чистый R, то тут уже можно обменивать гарантии на что-то другое. В частности, можно читать чуть неконсистентные данные в моменте чтения, но в следующий момент все будет ок.
Код все же лучше в git держать и дать ссылку. Так проще будет его копировать и видеть актуальную версию.
В таком случае хоть правым пользоваться можно. У меня стал так садится правый, а без него левый не хочет работать :/.
Прочитайте про STUN сервер, один из вариантов обхода NAT.
Т.е. вы предлагаете:
получаем запрос на один из N инстов и открываем транзакцию
держим эту транзакцию до завершения
при обработке все действия с этим платежом роутим на этот же инст где транзакция, иначе как мы ее закроем
получили оплату, закрываем транзакцию
PROFIT
Если верно понял схему то сходу возникают задачи, которые нужно решать:
sticky session
таймаут на транзакцию все равно нужен, т.к. (если коговорим про web) пользователь может закрыть/обновить страницу, потерять соединение и это нормально, но в итоге у нас разорвется соединение, как следствие клиент типо ушел, транзакция висит, но он же не ушел никуда. Да и вообще процессы оплаты бывают очень разные
как перезапустить сервис, чтобы не сбросить пользователей, которые в процессе оплаты (прервать happy path)
Видится мне, что это не сильно проще чем просто временная блокировка, а поддержка возможно и сложнее.
это вот этот пример?
судя по всему callback синхронный, для репликации во внешнее хранилище минус, так же не вижу как прервать транзакцию внутри этого метода или такой возможности нет или нужно исключение кидать?
И код приложен zip архивом, а не в публичной репке о_О?
А это прям так плохо и ужасно? Могу конечно ошибаться, но транзакция живет, пока живо соединение с БД, получается, если мы решим перезапустить инстанс приложения, то все наши транзакции (брони) слетают? Иначе наши сервисы из stateless превращаются в statefull.
Что значит блокировать, не дать другому купить его? Зачем для этого длинная транзакция? Добавляем поле status (и другие если надо), помечаем что забронировано, все, теперь хоть через 1с, хоть через 10, хоть через сутки другие не смогут его забронировать и это будет работать на любой БД с транзакциями достаточными для выполнения простого обновления.
Если очень хочется, можете поднять лимит, но зачем?
В остальном он предлагает аналогичную концепцию создания структур второго порядка на базе мамы и транзакций.
То что описано у вас хорошо, но как это использовать в реальной жизни? Если говорим про сервис, то нужно минимум 2 экземпляра, следовательно надо решать проблемы синхронизации и тд.
Какие пессимистичные блокировки в распределенных системах о_О? Если они вам нужны, транзакции вам в помощь, реализуем распределенную блокировку + подписка на ключ и вот вам "оптимистичная блокировка" хоть на сутки.
Есть примитивы, достаточно надёжные, далее из них строим все что нужно на уровне приложения.
Посмотрите на FoundationDB. Все что описано у вас, там и используется, только в большом масштабе.
Судя по тексту, вы использовали не чистый NATS, а его компонент JetStream.
Почему Kafka? Почему не отказались от JetStream и остались на Nats + DB?