Оригинал: Miss Sister Taste (идентификатор публичной учетной записи WeChat: xjjdog), добро пожаловать, пожалуйста, сохраните источник для перепечатки.
Распределенные системы обеспечивают безопасность данных за счет избыточности данных. При написании распределенной системы нельзя обойти одно препятствие — синхронизацию данных.
Синхронизация, эти два слова, замучили многих людей до смерти.
Это синхронно или асинхронно? Это толкать или тянуть? Кто хозяин, а кто раб? Что происходит, когда вы выходите из сети, и что происходит, когда вы подключаетесь к сети? Централизованный или одноранговый?
Все эти проблемы мучают разработчиков распределенных систем.
Далее мы рассмотрим, как несколько основных сервисов хранения решают проблему синхронизации данных.
Как MySQL выполняет синхронизацию master-slave?
Главный сервер MySQL называется главным, а подчиненный сервер называется подчиненным.
Мастер-сервер фиксирует изменения в бинлоге, а слейв будет копировать эти записи через отдельный поток, а затем переигрывать.
Формат binlog делится на три типа: операторный, строковый и смешанный.
- оператор Записать измененный оператор sql в binlog, что окажет определенное влияние на точность
- row записывает изменения каждой записи в binlog
- смешанный Комбинация двух вышеперечисленных. MySQL определит, когда использовать оператор и когда использовать строку
Поскольку это асинхронный поток для копирования, ведомое устройство склонно к задержкам. Когда мастер, к сожалению, выйдет из строя, это вызовет отложенную потерю данных.
Чтобы решить проблему асинхронной репликации, после версии 5.5 в MySQL была введена концепция полусинхронной репликации (semi sync). Полусинхронизация находится между асинхронной и полной синхронизацией.После того, как мастер выполняет транзакцию, он не возвращается напрямую, а ждет, пока хотя бы один ведомый будет успешно записан, прежде чем вернуться. Из-за необходимости взаимодействия хотя бы с одним ведомым устройством должна быть большая потеря производительности по сравнению с асинхронной репликацией.
Режим полной репликации, конечно же, предполагает ожидание завершения репликации всеми подчиненными узлами, что является наиболее безопасным, но и наименее эффективным. Концептуально половинная копия только с одним подчиненным устройством является полной копией.
После версии 5.7 в mysql реализован протокол групповой репликации. Он поддерживает режим с одним основным и несколькими основными режимами, но в одной группе не может существовать одновременно. Звучит потрясающе, но на самом деле это все же реализовано через протокол paxos.
Как Kafka выполняет синхронизацию реплик?
Поскольку кафка — это очередь сообщений, ей не нужно рассматривать проблему случайного удаления и случайного обновления, она обращает внимание только на проблему записи. Структурно модуль синхронизации Kafka очень децентрализован: у Kafka несколько тем, каждая тема разделена на несколько разделов, а копия основана на разделах.
Первичный раздел называется лидером, а 1-n реплик называются последователями. Когда производитель отправляет сообщение, ему нужно сначала найти лидера раздела, а затем отправить ему данные. Последователь существует только в качестве резервного, чтобы его можно было активировать в случае проблемы с основным разделом.
Синхронизация главного и подчиненного устройств Kafka называется механизмом ISR (In Sync Replica).
Когда сообщение успешно отправлено? Это также зависит от уровня отправки подтверждения.
-
0Указывает на асинхронную отправку, и сообщение успешно отправлено. -
1Мастер-копия лидера записывается, даже если она успешно отправлена -
-1Отправка лидера завершена, и реплики в ISR должны ответить на подтверждение
В случае 0 и 1 у Kafka есть вероятность потери сообщений. В случае -1 также необходимо убедиться, что по крайней мере один фолловер успешно выполнил фиксацию для обеспечения безопасности сообщения. Если последователи не могут догнать лидера, они будут удалены из списка ISR. Да, прямо удаляется. Когда ISR пуст, раздел kafka ничем не отличается от раздела отдельной машины, поэтому kafka предоставляетmin.insync.replicasПараметр указывает минимальное значение ISR.
- Что делать, если ISR не устраивает? Конечно, кафка не потеряет сообщения, потому что в это время происходит сбой отправки производителя, и сообщение вообще не может попасть в систему.
- Что делать, если все реплики недоступны? В этот момент раздел никогда не будет доступен
Репликация данных между репликами осуществляется через последователейpullПуть, то есть способ тянуть, чтобы получить это.
Репликация Redis master-slave
Redis — это база данных kv в памяти, которая намного быстрее, чем другие базы данных.Теоретически синхронизация master-slave проще. Но при большом потоке и высоком количестве запросов в секунду репликация master-slave все равно будет иметь проблемы.
После подключения Redis Slave сначала будет выполнена полная синхронизация. Он отправит команду psync мастеру, а затем мастер выполнит bgsave для создания файла rdb. Полная синхронизация заключается в копировании файла моментального снимка rdb на ведомое устройство.
Как насчет данных, которые появляются в середине полной репликации? Он должен быть кэширован. Мастер откроет буфер, а затем запишет новые данные, сгенерированные в процессе полной репликации, а затем заполнит добавочные данные после завершения полной синхронизации.
После отключения слейва нет необходимости каждый раз выполнять полную синхронизацию, для совпадения инкремента также вводится смещение репликации.（offset）, скопируйте буфер невыполненной работы（replication backlog buffer）и запустить идентификатор（run_id）три концепции. Видно, что он используется для идентификации слейва, а также его позиции копирования и буфера.
После синхронизации вы всегда можете использовать psync для репликации. Еще асинхронная репликация.
Видно, что согласованность репликации master-slave в Redis сильно зависит от памяти, а уровень очень слабый. Но это быстро. Fast может решить многие проблемы, поэтому сценарии применения разные.
Репликация ведущий-ведомый ElasticSearch
es — это поисковая система, основанная на lucene, и узел данных будет содержать несколько индексов. Каждый индекс содержит несколько сегментов, а каждый сегмент содержит несколько реплик.
Из приведенного выше описания эти концепции очень похожи на kafka, а единицей репликации es является сегментация.
Данные es по-прежнему записываются в мастер в первую очередь.Он также ведет список слейвов в синхронизации (InSyncAllocationIds).Конечно, реплик в желтом и красном состояниях нет в этом списке.
Ведущему устройству необходимо дождаться завершения всех этих обычных копий, прежде чем вернуться к клиенту, поэтому уровень согласованности относительно высок, поскольку его подчиненные узлы участвуют в операциях чтения, и это система, работающая почти в реальном времени.
Поскольку это база данных, все равно будут операции удаления и обновления. Translog эквивалентен журналу wal, который обеспечивает безопасность данных при сбое питания, что согласуется с рутиной других rdbms.
Кластерный режим Кассандры
Cassandra — очень известная база данных теории и практики CAP, больше похожая на базу данных AP, и до сих пор имеет высокий рейтинг на db-engines.com.
Хранение данных — это концепция таблиц, а таблица может храниться на нескольких машинах. Его раздел спроектирован с помощью ключа раздела, и распределение данных очень зависит от хеш-функции. Что делать, если есть проблема с узлом? Это требует поддержки последовательного хеширования.
Cassandra очень интересна, ее репликация (реплики) не похожа на другие первичные и вторичные данные, это больше похоже на множественные мастер-данные, которые одновременно предоставляются во внешний мир. Когда контрольная точка выходит из строя, переключение ведущий-резервный не требуется.
Почему это возможно? Потому что кассандра стремится к окончательной согласованности. Из-за наличия реплик в распределенных системах асинхронная или синхронная репликация неизбежна. Так до какой степени уместно копировать?QuorumизR+WЭто стратегия компромисса.
quorum = (sum_of_replication_factors / 2) + 1
Что это значит? Учитывая, что у вас есть 5 ящиков и случайным образом положили W шаров, найдите, сколько R раз потребуется, чтобы вытащить шар. Если вы положите в него 1 шар, вам нужно открыть его 5 раз, чтобы каждый раз иметь правильное суждение, в это время R = 5, W = 1; когда вы кладете 2 шара, вам нужно открыть его только 4 раза. ; если вы поставите 5 шаров, вам нужно прочитать его только один раз.
Когда R+W>N, это относится к строгой непротиворечивости, когда R+W
Интересно, что кластерная информация в cassandra, то есть метаинформация, передается с помощью сплетен (push-pull-gossip).
Репликация ведущий-ведомый MongoDB
MongoDB имеет три метода избыточности данных. Один — master-slave (устаревший), один — набор реплик, а другой — режим сегментирования.
Набор реплик master-slave в mongodb — это стандартная реализация автоматического перехода на другой ресурс без ручного вмешательства. После сбоя главного узла он найдет новый главный узел из реплик, установленных посредством выборов, а затем направит другие узлы для подключения к этому главному узлу.
Алгоритм выборов mongodb использует хулигана.
Изменения главного узла сохраняются в специальной системной таблице. Подчиненный сервер будет периодически извлекать эти изменения и применять их. Из этого описания также видно, что mongodb может терять данные при задержке синхронизации или отказе одного узла.
Суммировать
Распределенная предназначена для решения проблемы емкости одной машины, но вводит новую проблему, а именно синхронизацию данных.
Синхронизация данных должна быть сосредоточена на согласованности, восстановлении после сбоев и своевременности.
Существует два основных типа данных, которые необходимо синхронизировать.
- информация метаданных
- реальные данные
Для получения информации метаданных в настоящее время существует основной подход, вы можете обратиться к распределению данных с использованием протокола RAFT. Что касается синхронизации реальной даты, эффективность протокола плода все еще низкая, поэтому обычно используется асинхронная репликация.
В этом случае список асинхронной репликации становится ключевой информацией метаданных, и кластеру необходимо поддерживать состояние этих узлов. В худшем случае все узлы асинхронной репликации будут недоступны, и мастер будет работать в очень ненадежной среде.
Чтобы повысить гибкость распределения данных, большинство этих единиц репликации будут работать на осколках, что приведет к взрывному росту метаинформации.
Существует так много распределенных систем, но нет единой модели, которую можно было бы унифицировать. Интересно, что даже у самых неэффективных распределенных систем много последователей. Не верю? Просто посмотрите на тренд BTC.
Об авторе:Мисс сестра вкус(xjjdog), публичная учетная запись, которая не позволяет программистам идти в обход. Сосредоточьтесь на инфраструктуре и Linux. Десять лет архитектуры, десятки миллиардов ежедневного трафика, обсуждение с вами мира высокой параллелизма, дающие вам другой вкус. Мой личный WeChat xjjdog0, добро пожаловать в друзья для дальнейшего общения.