tag:blogger.com,1999:blog-654279083390275842.post7154864194574919552..comments2024-03-19T12:22:43.654+03:00Comments on Размышлизмы eao197: [comp.prog.thoughts] Фокусы распределенности: ответ приходит раньше, чем уходит запрос ;)eao197http://www.blogger.com/profile/17283739752119445290noreply@blogger.comBlogger15125tag:blogger.com,1999:blog-654279083390275842.post-62510032078509320742009-11-13T23:08:50.840+02:002009-11-13T23:08:50.840+02:00Ну кто же перепосылку по локальному времени делает...<i>Ну кто же перепосылку по локальному времени делает?</i><br />И кто же хранил в дате только последние 2 цифры года :D<br /><br /><i>По UTC, по UTC нужно было</i> <br />Не я, только какая от этого польза,<br />если в чьем-то коде на входе 4 цифры, на выходе - тоже 4ре, а в глубине - 2Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-57358205910699678282009-11-13T22:56:20.231+02:002009-11-13T22:56:20.231+02:00По поводу меток Лампорта - это первая ссылка в моё...По поводу меток Лампорта - это первая ссылка в моём блоге:<br />http://research.microsoft.com/en-us/um/people/lamport/pubs/time-clocks.pdf<br />Фундаментальная работа 78 года по поводу упорядочивания в распределенных системах. Этакая теория относительности применительно к CS.Dmitry Vyukovhttps://www.blogger.com/profile/10137998824493472445noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-74187466078221070112009-11-13T22:53:14.541+02:002009-11-13T22:53:14.541+02:00Метки времени Лампорта? ;)
При использовании мето...Метки времени Лампорта? ;)<br /><br />При использовании меток Лампорта, да и полных векторых часов, тоже не понятно сколько ждать. Там надо выбирать минимальный элемент из множества, а если некоторые элменты ещё не пришли по сети, то мы не можем определить минимальный пока не придут все. А когда они придут - не известно.<br />В системе с разделяемой памятью это можно обойти путём предугадывания/подглядывания "будущих" сообщений. А вот в распределенной системе с этим ничего хорошего не сделать.<br />Иногда это обходится с помощью таймаутов, но вариант тоже не идеальный. Т.к. всё равно будет либо неконсистентность либо придётся выкидывать какие-то сообщения.Dmitry Vyukovhttps://www.blogger.com/profile/10137998824493472445noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-88149627534207943262009-11-13T22:49:27.460+02:002009-11-13T22:49:27.460+02:00>Недавно был влет у нас на эту тему - ребята не...<i>>Недавно был влет у нас на эту тему - ребята не знали, а опытные вовремя не подсказали :)<br />И посыпались повторно сообщения. За последний час :)</i><br /><br />Ну кто же перепосылку по локальному времени делает? ;) По UTC, по UTC нужно было ;))eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-30255518269974751612009-11-13T22:45:05.770+02:002009-11-13T22:45:05.770+02:00Я о них прочитал в книге о распределенных системах...<i>Я о них прочитал в книге о распределенных системах</i><br />Да, спасибо, погуглю материал, думаю что иногда вполне может пригодится.<br /><br />Ну и в завершение:<br />Опытный программиста начинающему "А ты знаешь что в сутках 25 часов? 24 говоришь?<br />Так как же тогда твоя система среагирует на перевод летне-зимнего времени!"<br /><br />Недавно был влет у нас на эту тему - ребята не знали, а опытные вовремя не подсказали :)<br />И посыпались повторно сообщения. За последний час :)Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-34767996155766817002009-11-13T22:39:03.429+02:002009-11-13T22:39:03.429+02:00Метки времени Лампорта? ;)
Прочел в лекции "С...<i>Метки времени Лампорта? ;)</i><br />Прочел в лекции "Синхронизация в распределенных системах":<br />... в большинстве случаев согласованное время может не иметь ничего общего с астрономическим временем<br /><br />Если два события x и y случились в различных процессах, которые не обмениваются сообщениями, то отношения x->y и y->x являются неверными, а эти события называют одновременными. <br /><br />Беда как раз в том что и к астрономическому времени имеет, и в разных системах - а НЕ одновременные :)<br />Но почитаю дальше, пусть осядет, и проварится в головеSkyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-11086462765430193632009-11-13T22:37:07.041+02:002009-11-13T22:37:07.041+02:00>Может быть, не слышал о таких :)
Я о них проч...<i>>Может быть, не слышал о таких :)</i><br /><br />Я о них прочитал в книге о распределенных системах: http://www.rsdn.ru/article/?794<br /><br />На английском здесь: http://en.wikipedia.org/wiki/Lamport_orderingeao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-71180866247483184232009-11-13T22:26:53.504+02:002009-11-13T22:26:53.504+02:00Метки времени Лампорта? ;)
Может быть, не слышал о...<i>Метки времени Лампорта? ;)</i><br />Может быть, не слышал о таких :)<br /><br />Но я только начал :) "а когда прохождение заказа порождает новые заказы?"<br /><br />Вобщем у меня таких вопросов - тьма :)<br /><br /><i>Мне как раз нравится подход, когда получатель имеет возможность ответить отрицательно на запрос</i><br />Если имеет такую возможность, то может быть да, лучше - "а пошел ты со своей заявкой, знать не знаю об чем ты"<br /><br />Просто у каждого ж своя специфика. Я прикладник, всю эту распределенность-асинхронность наблюдаю сверху. И нередко - да какой угодно дай ЯП, платформу - я просто понять не могу, как же увязать такую-то схему работы.<br />Ну а после того как придумал - начинается подбор - UUID не UUID, иерархическая, или анархическая :) и т.д.<br />А когда платформа не дает возможности, начинается заталкивание в иерархию анархии, и создание иерархии в анархии :)<br /><br />Вобщем нравится мне моя область. А вот то о чем ФПшники говорят - скукота. Им наверное наоборотSkyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-57586826013415481992009-11-13T22:18:44.205+02:002009-11-13T22:18:44.205+02:002Dmitry Vyukov
Не читал раньше, вот оказывается от...2Dmitry Vyukov<br />Не читал раньше, вот оказывается откуда головняк при разработке корпоративного софта:<br /><br />В идеале, causal FIFO - это то, что всегда бы хотелось видеть конечному пользователю, ДЛЯ физически распределенных систем.<br /><br />Я когда читаю постинги ФП программистов все думаю - ребят, ну каким право баловством вы занимаетесь и называете это "взрывом мозга". Тут какой год мозг взрывается от causal FIFO в корпоративе, и ничего кроме "заплаток" и писанины по месту, по конкретике от этих взрывов в голову не приходит...Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-1852254986121625102009-11-13T22:13:02.310+02:002009-11-13T22:13:02.310+02:00>А частенько нужен порядок следования ID - чтоб...<i>>А частенько нужен порядок следования ID - чтобы когда соберутся в одном месте было понятно что этот ID идет после того ID.</i><br /><br />Метки времени Лампорта? ;)<br />Я у себя в таких случаях делаю объединение ID-шников в цепочки. По мере продвижения заявки по компонентам их ID провязываются в цепочки.<br /><br /><i>>Не-е-е, ждать придется до бесконечности. Тот кто отослал надеется что дело свое сделал.</i><br /><br />Мне как раз нравится подход, когда получатель имеет возможность ответить отрицательно на запрос, который он не готов сейчас обработать. И чтобы отправитель этого запроса получив такой отрицательный ответ повторял запрос через какое-то время. Или же отменял всю операцию.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-29013099861068561332009-11-13T22:08:33.581+02:002009-11-13T22:08:33.581+02:00>Это как раз то, о чём я писал тут:
http://soft...<i>>Это как раз то, о чём я писал тут:<br />http://software.intel.com/ru-ru/blogs/2009/02/07/fifo/</i><br /><br />Спасибо, что напомнил. Нужно будет перечитать. А то я действительно не подумал, что передача сообщений в независимые процессы одной системы может рассматриваться как вариант FIFO.eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-70388977971390630542009-11-13T21:48:47.574+02:002009-11-13T21:48:47.574+02:00Как обеспечить уникальность?
UUID-ами?
Если от &qu...<i> Как обеспечить уникальность?<br />UUID-ами?</i><br />Если от "заказа" больше ничего не нужно, кроме как быть уникальным, то да :)<br /><br />UUID это метка для компьютера, никак не связанная со смыслом самого "заказа". А частенько нужен порядок следования ID - чтобы когда соберутся в одном месте было понятно что этот ID идет после того ID. Миллисекунды не годятся, потому что на момент сверки может быть неизвестным - все ли "заказы" собрались?<br /><br /><i> А зачем отсылать? Рецепт известен:<br />Рутинная организация асинхронности, отложил неизвестный в копилку и жди.</i><br />Не-е-е, ждать придется до бесконечности. Тот кто отослал надеется что дело свое сделал. Ждать можно если кто-то пришлет - эй, у всех все в порядке, сообщите о своих застрявших ID и причинах!<br /><br /><i>Это уже зависит от специфики задачи.</i><br />Именно так, все эти проблемы решаются по специфике.<br />Печаль наступает когда система работает, а вот специфика - изменилась :)Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-28531282481303775292009-11-13T21:42:48.222+02:002009-11-13T21:42:48.222+02:00Это как раз то, о чём я писал тут:
http://software...Это как раз то, о чём я писал тут:<br />http://software.intel.com/ru-ru/blogs/2009/02/07/fifo/<br />(и ты, насколько я знаю, это читал ;) вообще после написания у меня было ощущение, что никто просто не понял, о чём я говорю :) )<br />В твоём примере middleware обеспечивает только per-producer FIFO. С ним возможны такие проблемы. Это, кстати, то, что обеспечивается в Эрланг.<br />Causal-FIFO значительно проще и интуитивнее, он таких проблем не вызывает.<br /><br />По поводу того, что с этим делать. Я на эту тему несколько размышлял; не могу сказать, что у меня полностью сформировался однозначный взгляд, но первый вывод получился следующий.<br />Проблема не в per-producer FIFO, проблема в топологии системы, где есть несколько путей от одной точки до другой (сообщение по одному пути может обогнать сообщение по другому пути). Это такой red herring как циклические ссылки между объектами (некоторые говорят, а вот у нас поддерживаются циклически ссылки а вот у вас нет, а лучше бы их вообще не иметь в системе, тогда и поддержка не нужна).<br />Соотв. решение для ситуации в примере: M посылает S запрос deliver, S отвечает М запросом deliver_schedule, S отвечает Р запросом pay_ack.Dmitry Vyukovhttps://www.blogger.com/profile/10137998824493472445noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-22699640451991355232009-11-13T21:05:39.122+02:002009-11-13T21:05:39.122+02:00>Это еще не проблема :)
Для меня было неожидан...<i>>Это еще не проблема :)</i><br /><br />Для меня было неожиданно обнаружить, что действие, которое инициирует мой запрос, может завершиться еще до того, как я завершу отсылку запроса.<br /><br />Т.е. проблема была разглядеть эту асинхронность :)<br /><br /><i>>Как обеспечить уникальность?</i><br /><br />UUID-ами?<br /><br /><i>>И вторая - а кто и как контролирует, "заказ" с таким ID всех кого нужно прошел?</i><br /><br />Это уже зависит от специфики задачи.<br /><br /><i>>И третья - кто-то из промежуточных наткнулся на инфу в заказе и не знает как ее обработать - кому отсылать на уточнение?</i><br /><br />А зачем отсылать? Рецепт известен:<br /><i>Рутинная организация асинхронности, отложил неизвестный в копилку и жди.</i><br />;)eao197https://www.blogger.com/profile/17283739752119445290noreply@blogger.comtag:blogger.com,1999:blog-654279083390275842.post-6664935193437928372009-11-13T20:47:24.719+02:002009-11-13T20:47:24.719+02:00Это еще не проблема :)
Рутинная организация асинхр...Это еще не проблема :)<br />Рутинная организация асинхронности, отложил неизвестный в копилку и жди.<br /><br />Проблема когда источником ID может выступать каждый. Как обеспечить уникальность?<br />И вторая - а кто и как контролирует, "заказ" с таким ID всех кого нужно прошел?<br />И третья - кто-то из промежуточных наткнулся на инфу в заказе и не знает как ее обработать - кому отсылать на уточнение?Skyninhttps://www.blogger.com/profile/17691734889443418349noreply@blogger.com