LINUX.ORG.RU

возможна ли надёжная передача сообщений?

 ,


0

2

Начал осмысливать микросервисы и быстро стало ясно, что есть шаблон, который повторяется.

Есть два субъекта. Допустим, я и мой банк. Мне надо перевести деньги. Как сделать это надёжно, при условии, что у банка может упасть база, что моя программа клиент-банк может упасть, и что связь тоже может упасть.

Я нагуглил теорему CAP (латиницей), которая говорит, что вообще говоря, это можно сделать только ценой отсутствия гарантии обслуживания. Но это и не теорема, а так, наблюдение, да и мало ли что пишут в Википедии? Я уже не раз сталкивался с тем, что там пишут всякий бред.

Может кто-нибудь описать шаблон взаимодействия меня и банка и устройства базы, которая ценой отсутствия гарантии обслуживания гарантирует точность передачи? И как это может выглядеть?

В конечном итоге я хочу, чтобы было три знания.

  • Известно, сколько денег у меня есть.
  • Я знаю, что эти сведения у меня и у банка совпадают
  • Банк знает, что эти сведения у меня и у банка совпадают

Для простоты представим для начала, что есть только один канал связи между мной и банком, который либо работает, либо не работает, и что только я могу переводить деньги.

Даже в этом случае в конце любого алгоритма возникает порочный круг из «я знаю, что ты знаешь, что я знаю», который при отсутствии надёжного канала никогда не завершается.

Ясно, что я где-то туплю, но не понимаю, где.

★★★★★

Последнее исправление: den73 (всего исправлений: 3)

Моя не понимать. Ты распределенную транзакцию захотел? Один знакомый уверял, что всего лишь несколько человек во всем мире знают, как их реализовывать.

dave ★★★★★
()

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

anonymous
()
Ответ на: комментарий от anonymous

Ого! Тогда здравствуй, парадокс времени! Консервативные методы, оптимистичные методы, метод деформации времени и т.п. Честно говоря, я сомневаюсь, что их используют для таких задач. Был бы приятно удивлен, если используют.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)

Сейчас вроде пытаются реализовывать передачу с использованием эффектов квантовой запутанности, чтобы избежать вмешательства в передачу. Тот же сбер. Или что-то вроде того. Это достаточно надёжно?

anonymous
()
Ответ на: комментарий от dave

Тогда здравствуй, парадокс времени!

Что такое время? Если нет определения, то нет и парадокса. Пока эталон времени - это «период» одинаковых событий. События измеряются событиями. Парадокс не во времени.

anonymous
()
Ответ на: комментарий от anonymous

Вряд ли. Здесь есть два потока времени - вид событий для меня и вид событий для банка. В моём мире нет банка, а есть лишь сообщения из банка. А может быть, и сообщения из СМИ о том, что банк закрылся. И не исключено, что без сообщений СМИ вообще ничего не выйдет.

den73 ★★★★★
() автор топика
Ответ на: комментарий от dave

Что такое парадокс времени? Речь о путешествиях в прошлое или о чём-то другом? Что за метод деформации времени? Как-то не гуглится и не яндексится.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Да это принятый перевод забугорных терминов (не мной придумано). «Парадокс времени» они по другому называют. Не помню точно как. А «метод деформации времени» - это «Time Warp». Но я понятия не имею, относится ли это к твоему вопросу. Просто аноним выше предложил свести к задаче дискретно-событийного моделирования.

dave ★★★★★
()
Последнее исправление: dave (всего исправлений: 1)
Ответ на: комментарий от den73

потока времени - вид событий

Поток - это последовательность. Твой «поток времени» - это последовательность событий. Тебе надо добиться неразличимости этих последовательностой. Для последовательностей (где есть отношение порядка) еще можно напридумывать всяких «теорий изоморфизма». И тут вдруг окажется, что события не имеют отношения порядка...

anonymous
()
Ответ на: комментарий от dave

Но я понятия не имею, относится ли это к твоему вопросу. Просто аноним выше предложил свести

Аноним выше предложил свести обсуждение к флейму, поднявшись рассуждать о том, что не имеет отношения к теме.

Тема, замусоренная флеймом, мне скучна. Но пока его не навалили тут большую кучу, кратко отвечаю.

Возможность надёжной передачи сообщений есть. Для этого нужны протоколы передачи сообщений и инфраструктура. Протоколы (и API) с поддержкой надёжной передачи сообщений: JMS и AMQP. А также нестандартные от разных разработчиков, Например, Oracle AQ Streams.

Инфраструктура - службы передачи сообщений (message broker или message service или message bus) - программное обеспечение. Накапливает сообщения в очереди (те из них, которые ддолжны передаваться надёжно, хранятся в файлах или в базе) и посылает их клиентам, пока те не примут.

Клиент посылает уведомление, что принял. Оно может быть или автоматическое, или нет. Не автоматическое нужно, если нужна дополнительная обработка сообщения на стороне клиента и заранее неизвестно, удастся ли она. Например, надо поместить информацию в свою базу и только после этого запрограммировать передачу уведомления, что сообщение получено вдруг своя база временно недоступна).

Из бесплатных message broker для JSP можно первоначально ознакомиться с Apache ActiveMQ, для AMQP - с RabbitMQ.

Ещё есть ESB , которые обычно включают в себя messaging service (или соединяются с ними). Из бесплатных ознакомиться с MuleESB (есть коммерческий вариант), а программистам на Java - ещё с WSO2.

Транзакции базы данных - другой способ надёжной передачи. Надо использовать оба.

Partisan ★★★★★
()
Ответ на: комментарий от Partisan

А может аноним и не набросил. Сам автор метода деформации времени указывал на такую возможность. Честно говоря, я тоже задумывался на эту тему, но никаких толковых мыслей не зародилось, кроме общих идей.

dave ★★★★★
()
Ответ на: комментарий от Partisan

Я почитаю. Но пока что складывается ощущение, что вместо цикла «я знаешь что ты знаешь что я знаю» ты предлагаешь цикл контроля за контролирующим. Тут тоже получается безконечная рекурсия, когда в систему добавляются всё новые контролирующие звенья, но всё равно попа остаётся неприкрытой.

den73 ★★★★★
() автор топика
Ответ на: комментарий от Partisan

Вот возьмём, для примера, JMS. Цитирую википедию:

Модель «точка - точка» характеризуется следующим:

* Каждое сообщение имеет только одного адресата

* Сообщение попадает в «почтовый ящик», или «очередь» адресата и может быть прочитано когда угодно. Если адресат не работал в момент отсылки сообщения, сообщение не пропадёт.

* После получения сообщения адресат посылает извещение.

«После получения сообщения адресат посылает извещение» - это называется «я знаю, что ты знаешь, что я знаю». Потому что что будет, если сеть отвалилась в момент посылки извещения?

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от anonymous

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

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

В общем, у меня пока складывается мнение, что цикл «я знаю, что ты знаешь, что я знаю» не может быть разорван. Вот может быть такой сценарий.

Я                         Банк
Исходящее: Эй, Банк, Отправь деньги
                         Входящее: Эй, Банк, Отправь деньги
                         Реально отправляет деньги
                         Исходящее: Эй, Ден73, я отправил деньги
Входящее: Эй, Ден73, я отправил деньги
ЗаписьБД: банк отправил деньги
Исходящее: Эй банк, я понял, что ты отправил деньги
                         Входящее: Эй банк, я понял, что ты отправил деньги
                         ЗаписьБД: Ден73 понял, что я отправил деньги
                         Исходящее: Эй, Ден73, я понял, что ты понял
Входящее: Эй, Ден73, я понял, что ты понял
ЗаписьБД: банк понял, что я понял
Исходящее: Эй, банк, я понял, что ты понял, что я понял

И так далее. 

Мы можем сделать здесь только одно: прервать этот диалог в какой-то момент. Когда мне ещё что-то понадобится от банка, я возобновляю эту переписку с того, что получаю баланс и сверяю его со своей информацией. Если что-то не так - начинается процедура сверки. КОторая опять же заканчивается этим «я понял, что ты понял».

И в итоге синхронность знаний вообще никогда не достигается. Но синхронность знаний о прошлом с неким зазором от сегодняшего момента может быть достигнута.

Как-то так.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от den73

одинаковое знание

Что такое знание? В базе данных можно хранить последовательности. Допустим, знание - это последовательность, тогда одинаковые знания - это одинаковые (неразличимые) последовательности.

anonymous
()
Ответ на: комментарий от anonymous

Спасибо, ты ничего не объяснил.

den73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

генераторы абсолютного точного времени и помечать каждую операцию временными меткам

Просто нумеровать.

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

генераторы абсолютного точного времени и помечать каждую операцию временными меткам

Просто нумеровать.

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

anonymous
()
Ответ на: комментарий от torvn77

Вопрос не в том. Вопрос в том, что распространение информации не гарантировано, т.к. может в любой момент оборваться связь. Соответственно, как минимум, я не знаю простого факта о том, было ли какое-то событие в банке (например, его ограбили и моих денег там больше нет) за последнюю секунду, или не было.

Если бы это были звёзды, можно увидеть, что звезда взорвалась, через фиксированное число лет. Это только потому, что божественный вакуум гарантирует доставку света (если не считать тёмных газопылевых туманностей). Сеть же не гарантирует ни доставки, ни сроков доставки.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от den73

Повесь скрипт на питоне с паролем от банка, пусть раз в 5 минут проверяет свой счёт.

Но вообще с такими запросами проще криптовалюты использовать.

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Повесь скрипт на питоне с паролем от банка, пусть раз в 5 минут проверяет свой счёт.

Ну это тоже возможный шаблон поведения, называется «раз звезда светит, то она взорвалась не ранее, чем 35 лет назад». Вот. Начинаем подходить ближе к теме.

Так я внезапно подумал, что неблокирующие алгоритмы - именно для распределённых систем. И что не «блокируй, сделай, разблокируй», а «повторяй, пока инвариант не будет достигнут» - это основная философия создания распределёнщины.

И плюс к тому «прими гипотезу о том, что в последние эн секунд ничего не происходило».

Но с этой гипотезой теряется надёжность.

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 2)
Ответ на: комментарий от torvn77

один запрос

«Один» получен от абсолютного счетчика. Как отличить «один» запрос от «другого» запроса.

anonymous
()
Ответ на: комментарий от anonymous

Не может быть абсолютного счётчика. Потому что если он в банке, то у меня нет к нему доступа. А если у меня, то у банка нет к нему доступа (вообще говоря, в любой случайный момент времени, когда упала связь)

den73 ★★★★★
() автор топика
Последнее исправление: den73 (всего исправлений: 1)
Ответ на: комментарий от torvn77

Так мне кажется, что криптовалюты тоже ничего не гарантируют. Хотя... блокчейн - это именно последовательность. Надо подумать.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Я почему-то решил не ставить знаки вопросов. Допустим, вместо точек стоят знаки вопросов.

anonymous
()
Ответ на: комментарий от torvn77

Клиент и банк - жулики (почему жулики, прост кушать хочется), у них очень изобретательные счётчики.

anonymous
()

Тему скатили в какие-то рассуждения о сжатии инопланетян, вместо рассуждении о транзакциях и RSA/DSA.

menangen ★★★★★
()
Ответ на: комментарий от menangen

RSA/DSA - это про цифровые подписи? Допустим, о подлинности речь не идёт. Речь идёт только о том, что любое звено в системе может сломаться, и после восстановления система должна продолжать работать.

Началось вообще-то вот с этого тестового задания. https://github.com/budden/rlj

Мне сказали «напиши что-нибудь про redis, т.е. подключение, запись, чтение». Я «что-нибудь написал», и понял, что я не знаю, как сделать эту штуку отказоустойчивой. Если она неудачно упадёт, она после этого перестанет работать.

Дальше я стал думать про восстановление и ушёл в безконечный цикл.

den73 ★★★★★
() автор топика
Ответ на: комментарий от anonymous

В сообщении и клиент и банк должны ссылаться на номера друг друга, сослался на номер, значит получил и прочитал всё что до него было, иначе создавай ошибку «ваш счётчик перескочил».

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Ну ладно, пусть будет время по локальным часам плюс уникальный возрастающий номер на случай, если Димона с Айфоном прокатят и вернут перевод часов. Но вопрос не в этом: вопрос, как я уже сказал, в том, что информация о состоянии банка недоступна мне (ввиду ненадёжности канала и немгновенности передачи) и обратно.

den73 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

иначе создавай ошибку «ваш счётчик перескочил».

Последовательность не должна канать по идее. Разве только ты получил инфу явно из будущего и тогда нужно понять, что где-то должна дойти инфа из прошлого.

Но как выглядит минимально работающий механизм синхронизации? Я не смог написать. Наверняка это что-то каноническое, но я смотрю, народ что-то тоже начал подтупливать :)

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Из пока что ясного похоже, что нужно мыслить в терминах ФП (монады, будь они не ладны). Т.е. представлять историю клиента как последовательность иммутабельных состояний.

И признать тот факт, что нам известно состояние банка только до какого-то момента в прошлом. Все алгоритмы обращения к банку должны это учитывать.

Но это ещё пока не решение задачи и даже не постановка.

den73 ★★★★★
() автор топика
Ответ на: комментарий от den73

Т.е. можно представить себе, что банк постоянно вещает логи своего состояния, и мы вещаем. Всё, что мы можем узнать - это то, что мы получили вести от банка во столько-то.

Также неплохо бы сверить часы. Допустим, мы верим в надёжность часов и сверяли часы вчера. Банк должен вещать и о переводе часов. Тогда если мы в 17:20 получили лог банка по 17:15, то мы знаем историю состояния банка до 17:15 и ничего не знаем о его судьбе с этого момента.

Также можно слать keepalive. Тогда, если мы шлём keepalive раз в минуту, и получили последний keepalive от 17:16, то мы знаем, что что-то не в порядке. Но мы не знаем, сломался ли банк или сеть.

И вот исходя из всего этого нужно как-то строить свою стратегию так, чтобы банк не списал у нас лишние деньги.

den73 ★★★★★
() автор топика
Ответ на: комментарий от torvn77

Ну и добились они, что друг друга обвинили в жульничестве, например: из-за плохой связи, митм, реально сжульничали. Как дальше продожить диалог?

anonymous
()
Ответ на: комментарий от anonymous

Так транзакция то будет незавершена.

Ну или на худой конец оба будут предьявлять полную версию заверенной переписки.(тут по идее кто-то не сможет предьявить)

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 1)
Ответ на: комментарий от torvn77

Так транзакция то будет незавершена.

Какое будет состояние счётчиков? Как они продолжат диалог, если счётчики неправильные/несогласованные?

Ну или на худой конец оба будут предьявлять полную версию заверенной переписки.(тут по идее кто-то не сможет предьявить)

То есть, нужен сторонний канал связи с каким-то «заверителем». «Заверитель» - это мифический абсолютный счётчик?

anonymous
()
Ответ на: комментарий от anonymous

Счётчики не согласуются, у каждого своя последовательность отсчитываемая от начала транзакции.

Клиент дата номер один начать транзакцию
Банк на указанную клиентом дату один транзакцию по сообщению один начал
Клиент два от дата сколько денег на счёте?

torvn77 ★★★★★
()
Ответ на: комментарий от torvn77

Банк пять от дата 242рубля.
Клиент а почему увас пять от дата кода я получил только один?

Или другой вартант
Клиент номера два три четыре пропущенны, жду сообщения.
Банк я эти сообщения не оправлял.

torvn77 ★★★★★
()
Последнее исправление: torvn77 (всего исправлений: 3)

Я нагуглил теорему CAP (латиницей), которая говорит, что вообще говоря, это можно сделать только ценой отсутствия гарантии обслуживания. Но это и не теорема, а так, наблюдение, да и мало ли что пишут в Википедии? Я уже не раз сталкивался с тем, что там пишут всякий бред.

По твоей логике все что есть в википедии — бред. Почитай про нее в учебнике, делов-то.

В конечном итоге я хочу, чтобы было три знания…

Для простоты представим для начала, что есть только один канал связи между мной и банком, который либо работает, либо не работает.

Ты свои требования вообще видел? Смотри решение.

Банк посылает тебе сообщение «В 28.03.2019 13:51:15 у тебя было 76.8 рубля». Ты посылаешь «понял-принял». Готово.

Традиционно пожелаю тебе заняться делом.

t184256 ★★★★★
()
Ответ на: комментарий от torvn77

Клиент дата номер один начать транзакцию

:) Имя «клиент» берётся из галактического реестра всех клиентов через двухфакторную (с альтернативным каналом связи) аутентификацию втентакле
Время «дата» берется из абсолютных вселенских часов
Число «один» - ладно, возьмем с локального счетчика.
И все равно можно намухлевать, потому что есть изобретательный локальный счетчик.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.