PACELC основан на развитии теории CAP.
Теория CAP является общей теорией в распределенных системах:
- C (согласованность): согласованность, данные всех узлов одновременно полностью согласованы.
- A (Доступность): Доступность, услуга всегда доступна.
- P (допуск к разделам): допуск к разделам, при сбое узла или сетевого раздела он по-прежнему может предоставлять внешние услуги, соответствующие согласованности и доступности.
При проектировании системы можно выбрать только две из этих трех точек.Общие требования к распределенной системе должны бытьДопуск перегородки. Остальное можно выбрать только из C или A.
Но эту теорию нельзя очень хорошо применить на практике.Во-первых, в А есть определенная противоречивость, и на возврат уходит много времени.Хотя она и доступна, но может быть неприемлема в бизнесе. Кроме того, большую часть времени раздел работает гладко без ошибок.В этом случае дизайн системы должен сбалансировать задержку и согласованность данных.Чтобы обеспечить согласованность данных, запись и задержка чтения будут увеличиваться. Это приводит к теории PACELC.
В случае ошибки раздела берется первая половина PAC, и теория согласуется с содержимым CAP. В случае отсутствия ошибки раздела (E в PACELC означает Else), выберите LC, то есть Latency and Consistency.
в настоящее время,Фактически, во многих хранилищах реализованы разные стратегии PACELC, и они настраиваются пользователями для гибкого использования различных стратегий в соответствии с различными бизнес-сценариями..
DynamoDB, Riak, модель NWR Кассандры
Например, DynamoDB, Riak и Cassandra — это хранилища, основанные на согласованной записи хэшей для достижения возможной согласованности в теоретических статьях Dynamo.По умолчанию используется система P+A и E+L., но может быть изменен в соответствии с конфигурацией, в основном на основеМодель NWR с синхронным и асинхронным резервированием. N означает N резервных копий, W означает, что должно быть записано не менее W копий, чтобы считаться успешным, а R означает, что прочитано не менее R копий. Во время настройки требуется W+R > N. Поскольку W+R > N, R > N-W. Что это значит, то есть количество прочитанных копий должно быть больше, чем разница между общим количеством резервных копий за вычетом кратного, чтобы обеспечить успешную запись. То есть каждый раз, когда вы читаете, читается как минимум одна последняя версия. Таким образом, старые данные не будут прочитаны. Когда нам нужна среда с широкими возможностями записи (например, запрос на добавление корзины покупок Amazon никогда не должен быть отклонен), мы можем настроить W = 1, если N = 3, то R = 3. В это время, пока любой узел успешно записан, он считается успешным, но при чтении данные должны быть прочитаны со всех узлов. Если нам нужна высокая эффективность чтения, мы можем настроить W=N R=1. В настоящее время любой узел, который успешно читается, считается успешным, но при записи все три узла должны быть успешно записаны, чтобы считаться успешными. Обратите внимание, что время выполнения операции равно времени выполнения самой медленной из нескольких параллельных операций. Например, когда R=3, запрос на чтение фактически отправляется трем узлам одновременно, и все три узла должны возвращать результаты, чтобы считаться успешными. Если предположить, что узел медленно отвечает, это может серьезно замедлить скорость отклика операции чтения.
MongoDB
MongoDB похожа на Dynamo, описанную выше.Выбор MongoDB между согласованностью и доступностью зависит от трех вещей:
-
write-concern: указывает, что запрос на запись не возвращается клиенту до тех пор, пока не будет обработано значение экземпляров MongoDB. -
read-concern: Укажите, должны ли последние данные считываться с основного устройства или окончательные согласованные данные могут быть считаны с дополнительного устройства. -
read-preference: Для набора реплик, следует ли возвращать последние данные текущего узла, или возвращать большинство данных, записанных на узел, или данные, рассчитанные в соответствии с некоторыми функциями.
синхронизация MySQL
Репликация master-slave MySQL включает асинхронный режим, полусинхронный режим, полную синхронную репликацию.
По умолчанию этоАсинхронный режим, MySQL достигает окончательной согласованности в случае разделения чтения-записи одного главного и нескольких подчиненных развертываний.Если определенная задержка считается приемлемой, ее обычно можно достичь с помощьюshow slave statusчтобы увидеть задержку ведущий-ведомый, чтобы определить, могут ли данные быть прочитаны от подчиненного устройства. Промежуточное ПО, такое как MyCat, использует этот механизм. Компромисс между L и C и компромисс между A и C можно контролировать с помощью допуска для этой задержки.
Полная синхронная репликация: Относится к тому, что когда основная библиотека выполняет транзакцию, все подчиненные библиотеки выполняют транзакцию перед возвратом к клиенту. Это обеспечивает высокую согласованность, но время отклика увеличивается.
полусинхронная репликация: основная библиотека не возвращается к клиенту сразу после выполнения транзакции, представленной клиентом, а ждет, пока хотя бы один ведомый ее получит и запишет в журнал ретрансляции, прежде чем вернуться к клиенту. Хотя задержка все же есть, она намного меньше, и вероятность потери данных меньше, чем при асинхронной репликации.
Протокол соответствия
Протоколы соответствия обычно включают:
- 2PC, двухэтапная фиксация
- 3PC, трехэтапная фиксация
- Paxos, Paxos — это очень подробный протокол консенсуса, но общая реализация слишком сложна, и это всего лишь теория.
- Raft, Raft — это алгоритм, который может обеспечить строгую согласованность в распределенных системах.Протокол согласованности TiDB основан на Raft.
- ZAB, согласованный протокол Zookeeper, упрощенный на основе Paxos
- NWR, протокол, основанный на упомянутой выше теории динамо, предоставляет пользователю баланс PACELC.