Сообщение Re[5]: Сервисы, передающие изменения другим сервисам и т.д. от 08.04.2022 9:56
Изменено 08.04.2022 13:34 gandjustas
Re[5]: Сервисы, передающие изменения другим сервисам и т.д.
Здравствуйте, Sharov, Вы писали:
S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
Так в этом и суть CAP — сети ненадежны.
Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
Это при условии что один клиент может запрашивать данные записываемые другим клиентом.
В условиях локальной сети таким условием можно пренебречь, потому что там сеть падает или полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.
Из этого проистекает простой архитектурный принцип локальности:
Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).
S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
Так в этом и суть CAP — сети ненадежны.
Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
Это при условии что один клиент может запрашивать данные записываемые другим клиентом.
В условиях локальной сети таким условием можно пренебречь, потому что там сеть падает или полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.
Из этого проистекает простой архитектурный принцип локальности:
Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).
Re[5]: Сервисы, передающие изменения другим сервисам и т.д.
Здравствуйте, Sharov, Вы писали:
S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
Так в этом и суть CAP — сети ненадежны.
Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
Это при условии что один клиент может запрашивать данные записываемые другим клиентом.
В условиях локальной сети таким условием можно пренебречь, потому что там сеть или падает полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.
Из этого проистекает простой архитектурный принцип локальности:
Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).
S>Почему мы не может достичь 100% CA для банков? Насколько понимаю, именно для этих целей делали
S>мейнфреймы -- один большой и мощный компьютер. Т.е. в случае мощного монолита мы можем получить 100% CA.
S>Тут возможны проблемы, но только из-за ненадежной сети (проблема 2х генералов).
Так в этом и суть CAP — сети ненадежны.
Причем ненадежны настолько, что допускают потерю пакетов между узлами системы, но при этом сохраняют подключение к клиентам.
Это при условии что один клиент может запрашивать данные записываемые другим клиентом.
В условиях локальной сети таким условием можно пренебречь, потому что там сеть или падает полностью, или полностью работает, и в целом надежность сети примерно равна надёжности серверов. Даже в пределах одного ДЦ можно игнорировать CAP, хотя говорят у амазона случается split brain.
Из этого проистекает простой архитектурный принцип локальности:
Чтение локализуется, то есть один клиент (IP, учетка) всегда или почти всегда ходит в одну локацию.
система создается с расчетом CA (кворумы, локальная избыточность) в одной локации и AP с delayed consistency (репликация) между локациями, а для отдельных операций CA между локациями с повторением запросов (привет REST).