IB
Size: a a a
2020 January 13
AB
На реддите было вроде
IB
Спасибо
IB
Прочитал текст. Интересный подход. "Подпишите здесь, а мы чуть позже сделаем список правил которые вы обязаны будуте соблюдать."
AK
Я тут наткнулся на эту статью ещё раз независимо от тебя. Ну и прочитал её. Вспомнил, что ты писал про неё.
Про lua написали вроде как верно, redis впринципе однопоточный (кстати, есть его fork многопоточный, там такой хак не сработает), но я хочу написать о другом.
Вообщем моё мнение такое, что этот алгоритм распределённой блокировки как-то уж очень сомнительный в плане безопасности (safety). Если даже написать его правильно один раз, то программисту, который использует этот алгоритм, нужно о многом задумываться, что чревато ошибками, если он об этом не будет задумываться.
1. Произвольные задержки могут быть где угодно (garbage collector, сеть)
2. CPU bound таск просто так не напишешь, нужно думать о расширении лока (https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock) и код программиста будет усложнятся.
Кто-нибудь знает корректный алгоритм реализации, так как этот не выглядит безопасным?
Возможно тут ответ https://dl.acm.org/doi/10.1145/74851.74870
Пока ещё это не читал
Про lua написали вроде как верно, redis впринципе однопоточный (кстати, есть его fork многопоточный, там такой хак не сработает), но я хочу написать о другом.
Вообщем моё мнение такое, что этот алгоритм распределённой блокировки как-то уж очень сомнительный в плане безопасности (safety). Если даже написать его правильно один раз, то программисту, который использует этот алгоритм, нужно о многом задумываться, что чревато ошибками, если он об этом не будет задумываться.
1. Произвольные задержки могут быть где угодно (garbage collector, сеть)
2. CPU bound таск просто так не напишешь, нужно думать о расширении лока (https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock) и код программиста будет усложнятся.
Кто-нибудь знает корректный алгоритм реализации, так как этот не выглядит безопасным?
Возможно тут ответ https://dl.acm.org/doi/10.1145/74851.74870
Пока ещё это не читал
У меня в итоге сильно другой скрипт на LUA, а вся цель блокировки - в том, чтобы воркер ни в коем случае не лез за данными в базу, если они есть в кеше или если другой воркер в данный момент уже запросил те же данные. Т.е. задача куда более банальная: избежать лишних запросов, чтобы время ответа от БД не подскочило для остальных страждущих.
А так да, я пока думал над этим - пришёл к выводу, что степень надёжности алгоритма не слишком высока.
А так да, я пока думал над этим - пришёл к выводу, что степень надёжности алгоритма не слишком высока.
a
Я тут наткнулся на эту статью ещё раз независимо от тебя. Ну и прочитал её. Вспомнил, что ты писал про неё.
Про lua написали вроде как верно, redis впринципе однопоточный (кстати, есть его fork многопоточный, там такой хак не сработает), но я хочу написать о другом.
Вообщем моё мнение такое, что этот алгоритм распределённой блокировки как-то уж очень сомнительный в плане безопасности (safety). Если даже написать его правильно один раз, то программисту, который использует этот алгоритм, нужно о многом задумываться, что чревато ошибками, если он об этом не будет задумываться.
1. Произвольные задержки могут быть где угодно (garbage collector, сеть)
2. CPU bound таск просто так не напишешь, нужно думать о расширении лока (https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock) и код программиста будет усложнятся.
Кто-нибудь знает корректный алгоритм реализации, так как этот не выглядит безопасным?
Возможно тут ответ https://dl.acm.org/doi/10.1145/74851.74870
Пока ещё это не читал
Про lua написали вроде как верно, redis впринципе однопоточный (кстати, есть его fork многопоточный, там такой хак не сработает), но я хочу написать о другом.
Вообщем моё мнение такое, что этот алгоритм распределённой блокировки как-то уж очень сомнительный в плане безопасности (safety). Если даже написать его правильно один раз, то программисту, который использует этот алгоритм, нужно о многом задумываться, что чревато ошибками, если он об этом не будет задумываться.
1. Произвольные задержки могут быть где угодно (garbage collector, сеть)
2. CPU bound таск просто так не напишешь, нужно думать о расширении лока (https://redis.io/topics/distlock#making-the-algorithm-more-reliable-extending-the-lock) и код программиста будет усложнятся.
Кто-нибудь знает корректный алгоритм реализации, так как этот не выглядит безопасным?
Возможно тут ответ https://dl.acm.org/doi/10.1145/74851.74870
Пока ещё это не читал
Это же всё зависит от твоей задачи. Распределённое программирование вообще непростая штука. Блокировки сразу подразумевают возможность дедлоков, лайвлоков и инверсии приоритетов. В дополнение к стандартным штукам вроде гарантий.
AS
У меня в итоге сильно другой скрипт на LUA, а вся цель блокировки - в том, чтобы воркер ни в коем случае не лез за данными в базу, если они есть в кеше или если другой воркер в данный момент уже запросил те же данные. Т.е. задача куда более банальная: избежать лишних запросов, чтобы время ответа от БД не подскочило для остальных страждущих.
А так да, я пока думал над этим - пришёл к выводу, что степень надёжности алгоритма не слишком высока.
А так да, я пока думал над этим - пришёл к выводу, что степень надёжности алгоритма не слишком высока.
Ну наверняка в 99.9% будет работать как надо. Просто когда есть какая-то вероятность взять один и тот же lock дважды - это уже не является надёжным решением.
AS
allter
Это же всё зависит от твоей задачи. Распределённое программирование вообще непростая штука. Блокировки сразу подразумевают возможность дедлоков, лайвлоков и инверсии приоритетов. В дополнение к стандартным штукам вроде гарантий.
Когда описываешь алгоритм в распределённой системе, который не обеспечивает 100% гарантии надёжности, не нужно говорит/писать, что ты сделал алгоритм, который обеспечивает 100% гарантию надежности.
a
Когда описываешь алгоритм в распределённой системе, который не обеспечивает 100% гарантии надёжности, не нужно говорит/писать, что ты сделал алгоритм, который обеспечивает 100% гарантию надежности.
Практически у любого алгоритма есть область, в которой он не корректен/бесполезен/ошибочен в каком-то смысле (собственно, и сам этот "смысл" формально не всегда можно описать).
AK
Особенно мне нравятся сравнения O(log n), но каждый шаг занимает год, всего log(n) лет, с O(n^2), где, правда, каждый шаг занимает микросекунду.
Но если представить, что у нас сеть Господа, а клиентами является каждый атом по вселенной, и все они у нас есть в базе, то O(log n) конечно выгоднее.
Но если представить, что у нас сеть Господа, а клиентами является каждый атом по вселенной, и все они у нас есть в базе, то O(log n) конечно выгоднее.
AK
Ну т.е. вообще безумно правильно оценивать эффективность алгоритма при n=Infinity. Ведь у нас же в объективной реальности по жизни всё стремится к Infinity, это ясно как Божий пень
SZ
Ну т.е. вообще безумно правильно оценивать эффективность алгоритма при n=Infinity. Ведь у нас же в объективной реальности по жизни всё стремится к Infinity, это ясно как Божий пень
Объективная сегодня реальность завтра будет не такой объективной.
AK
Ну вот вопрос о том, что лучше - сочинять феерические абсолютно эффективные алгоритмы в вакууме или адаптировать алгоритмы, решая проблему по мере её поступления (ну ок, чуть загодя, до поступления).
VO
А по чесноку оценивать очень не просто
VO
и сложно математически
AK
А по чесноку оценивать очень не просто
Поэтому ИМХО куда проще делать внешнее нагрузочное тестирование чёрного ящика :)
VO
И сделано только для одной модели вычислительного устройства одним челом, примерно 40 лет назад
AK
При этом конечно нагружать в тех пределах, которые разумны с некоторым запасом, а не считать, что если у интернет-магазина "рога и копыта" вчера было 5 клиентов в день, то завтра их может вдруг стать 5 миллиардов.
VO
Ну сделай нагрузочное тестирование стримингового сервера (одного сервера не всего сервиса) на 100гигабит