Рафт не способен работать в условиях нечестных участников, т.е. он не решает задачу византийского консенсуса. Поэтому он не годится для условий наличия недоверенных узлов.
Честность определяется тем, что данный участник действует согласно описанному протоколу в полном его соответствии. Нечестность — это любое отклонение от него, включая злонамеренное.
в децентрализованной сети применяется принцип избыточности, который основан на том, что узлы могут делать одну и ту же работу. Для централизованной сети это, естественно, неэффективно
Для централизованной тоже применяется принцип избыточности: есть реплики и репликация. Алгоритм консенсуса приходит к согласованному решению между участниками системы, при этом каждый участник содержит один и тот же набор данных, т.е. хранение информации является избыточным, вне зависимости от централизации/децентрализации.
Safety – способность учетной системы сохранять основные принципы функционирования и интересы честных участников при любых злоумышленных воздействиях.
Не при любых, а лишь при определенных. Например, BFT сохраняет safety при количестве честных участников > 2/3. В противном случае safety нарушается.
1) Отмечу, что даже если бы популярные системы поточной обработки (например Flink, Spark) поддерживали параллельное дублированное исполнение, которое называется в статье concurrent,
Оно не зря называется concurrent, потому что если обработчик взаимодействует с одним и тем же набором данных, то возникает конкуренция за обновление, а не параллелизация действия.
его бы мало кто включал на практике, потому что цена ресурсов как правило оказывается важнее, чем гарантия отсутствия затупов.
Я предоставляю пользователям выбор: можно запускать в одном экземпляре, а можно в двух или даже более. Другие системы такого выбора не предоставляют от слова совсем.
Кроме того, даже с дублированием такой гарантии нет, потому что большинство причин падений и затупов коррелируют.
Кажется очевидным, что если проблемы коррелируют, то надо их решать. В данном случае в статье рассмотрен лишь один аспект, но чрезвычайно важный, который до сих пор никто не решал и даже не задумывался. Я лишь немного опережаю время.
Разносить же дубли в разные облачные провайдеры в разных гео-регионах, и так же распределять все хранилища, означает целый новый класс проблем и просадку производительности.
Цена этого может быть велика. Однако на сегодняшний день существуют подходы, которые позволяют решить все эти проблемы, причем относительно несложно.
Но это, понятно, серьезно бы увеличило размер и без того немаленькой статьи.
Никогда не создавай язык с исключениями, в котором нет детерминированного освобождения ресурсов.
Громкое заявление. Читаем обоснование:
Причина по которой существует данное правило — детерминированное освобождение ресурсов необходимо для создания поддерживаемых программ.
Отсюда сразу следует, что недетерминированное освобождение не дает возможности создавать поддерживаемые программы. Т.е. если мы недетерминированно освобождаем память — то такие программы неподдерживаемые. А, значит, любые программы на языке с GC — неподдерживаемые.
Выглядит очень странно. Или я неправильно понял посыл?
И далее:
Детерминированное освобождение ресурсов обеспечивает определенную точку, в которой программист уверен, что ресурс освобожден.
Определенную точку это, может быть, и обеспечивает, только не определенное время, т.к. обычно используются не real-time OS. А раз значит разницы между так называемым "традиционным" и "современным" подходом в такой постановке сильно размывается.
The United States joined the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas\
— результат
Соединенные Штаты присоединились к территории Техаса
Соединенные Штаты присоединили территорию Техаса
Соединенные Штаты аннексировали территорию Техаса \
США присоединила территорию техаса
США присоединила территорию Техаса
США присоединили территорию техаса
США присоединили территорию Техаса
— результат
The United States joined the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas
К слову, буква-в-букву эти требования не выполняются почти нигде и никогда, а в распределённых системах просто никогда (CAP-теорема мешает).
CAP теорема и ACID — это ортогональные вещи, и одно другому не мешает. См. Spanner, Cockroach DB, YT. Поэтому про "никогда" я бы не говорил в таком разрезе.
Это фиксирует разработчик на этапе реализации. Т.е. это возможные реализации, и надо выбрать одну из двух стратегий и ее придерживаться.
Откуда он знает, когда транзакция закончена и "надо бы начать ждать команду от клиента"
Когда получены ответы от всех участников, тогда и можно переходить ко второй фазе. От клиента ничего не надо ждать, т.к. либо необходимая информация пришла от другого участника, либо мы говорим неОК сразу, откатывая транзакцию. Можно, конечно, еще ввести и 3-й вариант с ожиданием, но он может приводить к затупам, я бы не рекомендовал.
Если в каждой консенсус-группе по три участника, а сообщения шлются вообще от всех вообще всем, не возникает ли тут серьезного network communication amplification?
Зависит от тяжести транзакции. Но в целом это сильнее нагружает сеть, нежели другие способы. Это ожидаемо и такова плата за уменьшение времени.
Похоже что предложенный алгоритм существенно сложнее сделать корректно в случае различных "плохих" сценариев, чем более модульные алгоритмы, где консенсус, коммит, participation, conflict resolution, random backoffs for liveness, etc. не запихнуты в один единственный RTT.
Хитрожопые алгоритмы, как правило, сложнее. Тем не менее, модульность тут вполне возможна. Во-первых, консенсус алгоритм никак не завязан на двухфазность. Просто надо добавить режим для клиента посылки запросов всем участникам. Единственное добавление: это спекулятивное исполнение, т.е. алгоритм должен поддерживать такое.
Ну а в целом нет ничего нового: оптимизации, как правило, пронизывают многие слои абстракции. В данном случае, тем не менее, можно реализовать все компоненты независимо с дополнительными фишками типа спекулятивного исполнения.
Тут также стоит отметить следующую вещь. Когда проектируется система, то у тебя всегда есть выбор между различными компромиссами. Важно их иметь. Статья как раз задает рамки, в которых его можно искать. До этого рамок не было, был просто классический двухфазный коммит, который был, скажем так, недостаточно быстр.
Это звучит несколько странно, конечно. С тем же успехом можно сказать, что можно написать программу на колбеках, а затем переписать ее на корутины. Только зачем?
И это говорит лишь о том, что подход на stackful сопрограммах более полновесный, т.к. на него можно легко переписать, и код получится проще. А с простого на сложное переписывать — то еще занятие. Именно поэтому подход на stackful сопрограммах рулит и бибикает.
Я считаю, что надо и stackless, и stackful. Дело в том, что для простых однопоточных генераторов нет ничего лучше stackless сопрограмм, т.к. их компилятор при желании может превратить в обычные циклы без аллокаций памяти. И это действительно круто и стоит того.
Другое дело, использовать сопрограммы как файберы в многопоточной и конкурентной среде. Там все эти оптимизации с аллокациями невозможно применить, появляется куча мелких аллокаций для вложенных асинхронных вызовов, что может приводить наоборот к еще большему оверхеду.
Зачем нужен стандарт для stackful? Для того, чтобы различные инструменты научились их поддерживать без танцев с бубнами. Чтобы дебагеры их обнаруживали, чтобы санитайзеры из видели и т.д. Т.е. чтобы все работало из коробки так, как будто это нативные инструменты. Когда есть единый инструмент, тогда он будет вылизан и отточен. Поэтому его тоже надо в стандарт.
Это крайне слабый аргумент. По этой причине тогда не нужно было включать boost::filesystem, т.к. не нужно изменять компилятор. Тем не менее, это было сделано.
Стандарт — он не только для компилятора, но и для расширения существующей библиотеки и интеграции разных кусков воедино.
Рафт не способен работать в условиях нечестных участников, т.е. он не решает задачу византийского консенсуса. Поэтому он не годится для условий наличия недоверенных узлов.
Честность определяется тем, что данный участник действует согласно описанному протоколу в полном его соответствии. Нечестность — это любое отклонение от него, включая злонамеренное.
Начать стоит с этой книги: "Introduction to Reliable and Secure Distributed Programming", 2nd ed. 2011
Для централизованной тоже применяется принцип избыточности: есть реплики и репликация. Алгоритм консенсуса приходит к согласованному решению между участниками системы, при этом каждый участник содержит один и тот же набор данных, т.е. хранение информации является избыточным, вне зависимости от централизации/децентрализации.
Не при любых, а лишь при определенных. Например, BFT сохраняет safety при количестве честных участников > 2/3. В противном случае safety нарушается.
Оно не зря называется concurrent, потому что если обработчик взаимодействует с одним и тем же набором данных, то возникает конкуренция за обновление, а не параллелизация действия.
Я предоставляю пользователям выбор: можно запускать в одном экземпляре, а можно в двух или даже более. Другие системы такого выбора не предоставляют от слова совсем.
Кажется очевидным, что если проблемы коррелируют, то надо их решать. В данном случае в статье рассмотрен лишь один аспект, но чрезвычайно важный, который до сих пор никто не решал и даже не задумывался. Я лишь немного опережаю время.
Цена этого может быть велика. Однако на сегодняшний день существуют подходы, которые позволяют решить все эти проблемы, причем относительно несложно.
Но это, понятно, серьезно бы увеличило размер и без того немаленькой статьи.
Не очень понятна проблематика.
Громкое заявление. Читаем обоснование:
Отсюда сразу следует, что недетерминированное освобождение не дает возможности создавать поддерживаемые программы. Т.е. если мы недетерминированно освобождаем память — то такие программы неподдерживаемые. А, значит, любые программы на языке с GC — неподдерживаемые.
Выглядит очень странно. Или я неправильно понял посыл?
И далее:
Определенную точку это, может быть, и обеспечивает, только не определенное время, т.к. обычно используются не real-time OS. А раз значит разницы между так называемым "традиционным" и "современным" подходом в такой постановке сильно размывается.
Далее тоже немало перлов в таком же духе.
The United States joined the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas\
— результат
Соединенные Штаты присоединились к территории Техаса
Соединенные Штаты присоединили территорию Техаса
Соединенные Штаты аннексировали территорию Техаса \
США присоединила территорию техаса
США присоединила территорию Техаса
США присоединили территорию техаса
США присоединили территорию Техаса
— результат
The United States joined the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas
The United States annexed the territory of Texas
CAP теорема и ACID — это ортогональные вещи, и одно другому не мешает. См. Spanner, Cockroach DB, YT. Поэтому про "никогда" я бы не говорил в таком разрезе.
Спасибо! Мне тоже хотелось бы это увидеть!
Это фиксирует разработчик на этапе реализации. Т.е. это возможные реализации, и надо выбрать одну из двух стратегий и ее придерживаться.
Когда получены ответы от всех участников, тогда и можно переходить ко второй фазе. От клиента ничего не надо ждать, т.к. либо необходимая информация пришла от другого участника, либо мы говорим неОК сразу, откатывая транзакцию. Можно, конечно, еще ввести и 3-й вариант с ожиданием, но он может приводить к затупам, я бы не рекомендовал.
Зависит от тяжести транзакции. Но в целом это сильнее нагружает сеть, нежели другие способы. Это ожидаемо и такова плата за уменьшение времени.
Хитрожопые алгоритмы, как правило, сложнее. Тем не менее, модульность тут вполне возможна. Во-первых, консенсус алгоритм никак не завязан на двухфазность. Просто надо добавить режим для клиента посылки запросов всем участникам. Единственное добавление: это спекулятивное исполнение, т.е. алгоритм должен поддерживать такое.
Ну а в целом нет ничего нового: оптимизации, как правило, пронизывают многие слои абстракции. В данном случае, тем не менее, можно реализовать все компоненты независимо с дополнительными фишками типа спекулятивного исполнения.
Тут также стоит отметить следующую вещь. Когда проектируется система, то у тебя всегда есть выбор между различными компромиссами. Важно их иметь. Статья как раз задает рамки, в которых его можно искать. До этого рамок не было, был просто классический двухфазный коммит, который был, скажем так, недостаточно быстр.
В нормальных системах (Spanner, YT) координатор является отказоустойчивым. В противном случае все становится плохо.
Немного улучшил этот фрагмент. Надеюсь, так будет понятнее.
А я вообще не вижу смысла использовать разные подходы, когда можно использовать один подход, и уже сегодня.
В чем профит?
Это звучит несколько странно, конечно. С тем же успехом можно сказать, что можно написать программу на колбеках, а затем переписать ее на корутины. Только зачем?
И это говорит лишь о том, что подход на stackful сопрограммах более полновесный, т.к. на него можно легко переписать, и код получится проще. А с простого на сложное переписывать — то еще занятие. Именно поэтому подход на stackful сопрограммах рулит и бибикает.
Чтобы получить и те и другие из коробки, надо добавить оба в стандарт.
Я считаю, что надо и stackless, и stackful. Дело в том, что для простых однопоточных генераторов нет ничего лучше stackless сопрограмм, т.к. их компилятор при желании может превратить в обычные циклы без аллокаций памяти. И это действительно круто и стоит того.
Другое дело, использовать сопрограммы как файберы в многопоточной и конкурентной среде. Там все эти оптимизации с аллокациями невозможно применить, появляется куча мелких аллокаций для вложенных асинхронных вызовов, что может приводить наоборот к еще большему оверхеду.
Зачем нужен стандарт для stackful? Для того, чтобы различные инструменты научились их поддерживать без танцев с бубнами. Чтобы дебагеры их обнаруживали, чтобы санитайзеры из видели и т.д. Т.е. чтобы все работало из коробки так, как будто это нативные инструменты. Когда есть единый инструмент, тогда он будет вылизан и отточен. Поэтому его тоже надо в стандарт.
Это крайне слабый аргумент. По этой причине тогда не нужно было включать boost::filesystem, т.к. не нужно изменять компилятор. Тем не менее, это было сделано.
Стандарт — он не только для компилятора, но и для расширения существующей библиотеки и интеграции разных кусков воедино.
Спасибо! Этот комментарий должен был быть первым.