существовать«Просветление!» Для проектирования удаленной мультиактивной архитектуры достаточно прочитать эту статью》в одной статье,На основе потребностей аварийного восстановления,Обсуждается модель Архитектуры, написанная data. аспект чтения данных,Основное внимание уделяется решению проблем распределения нагрузки и маршрутизации запросов на чтение.,Это мало влияет на выбор Архитектуры аварийного восстановления. но,Это сценарий «читай сразу после написания».,Проблема категории дасогласованности,То есть проблема в том, согласуется ли записанная датада с прочитанной данными после записи.,В этой статье не обсуждаются различные модели согласованности.,Только конкретная проблема с требованием «читать сразу после записи» дана, что запрос на чтение, поступающий через короткое время после записи, может прочитать последнее записанное значение.,Это относительно уникальный и типичный сценарий чтения данных в интернет-приложениях.,Стоит изучить глубже,В этой статье предпринята попытка проанализировать детали этой проблемы и изучить соответствующие решения.

Следите за разработчиками Tencent Cloud и заранее получайте техническую информацию из первых рук👇

01. Анализ деталей проблемы

1.1 Направление решения

Проблема чтения сразу после записи означает, что после записи части данных данные считываются в течение короткого времени, и последнее записанное значение не может быть прочитано. Чтобы решить эту проблему, операция чтения должна иметь возможность получать данные из узла, куда данные были недавно записаны. Существует несколько направлений:

1. Одиночная запись и одиночное чтение: все запросы, которые необходимо прочитать сразу после записи, направляются в единственную точку записи для чтения, что гарантирует возможность чтения последнего записанного значения;
2. Пишите больше и читайте больше, следя за тем, чтобы сумма количества точек письма (W) и количества точек чтения (R) превышала общее количество узлов (N), то есть N < R + W, также известный как да NRW план;
3. скопировать при прочтении,Когда узел чтения получает запрос на чтение,Проверьте, является ли статус чтения этого узла последним.,Если не,Просто подождите, пока последние данные не будут скопированы на место, а затем вернитесь.

В инфраструктуре уровня доступа, логического уровня и уровня данных уровень базы данных имеет наиболее полную информацию о репликации данных и может отображать наиболее точное состояние данных. Если мы сможем начать с уровня базы данных, это фундаментально решит проблему. чтение сразу после записи. Если проблема не имеет никакого отношения к бизнесу, с деловой стороны будет проще. Например, копирование во время чтения выше проще сделать на уровне базы данных. Однако многие предприятия не используют такую ​​идеальную систему баз данных, и решения следует рассматривать с точки зрения бизнеса.

NRW — это одноранговая парламентская система для каждого узла. Большинство используется для решения проблемы чтения новых значений. Значения R и W корректируются в соответствии с давлением уровня чтения и записи, чтобы обеспечить достижение системой. лучшее состояние. В этой модели есть проблема усиления запросов. Независимо от того, как вы регулируете значения R и W, она только сбалансирует нагрузку R и W. Неизбежно, что общая стоимость чтения и записи увеличится. В сценарии аварийного восстановления в пределах города решение NRW является дорогостоящим и менее приемлемым, поскольку:

1. Если вам приходится каждый раз читать несколько узлов, вам, по сути, придется сталкиваться с запросами на чтение по городам;
2. Если ближайший узел читается каждый раз, при записи требуется запись во все узлы.

Поэтому многие предприятия не используют одноранговый механизм для хранения данных, а применяют модель «главный-подчиненный». После записи основной точки записи в целях аварийного восстановления она будет ждать, пока не будут получены данные основной точки записи. копируется на некоторые подчиненные узлы до достижения успеха записи. Почему бы не выполнить репликацию на все подчиненные узлы? Потому что основное внимание уделяется аварийному восстановлению, обеспечению наличия избыточных данных за пределами основной точки записи, а не обеспечению полной согласованности данных на каждом узле. Таким образом, это эквивалентно NRW в W да 1 < W < N, но эта партия точек записи неравна, и запись осуществляется посредством репликации «главный-подчиненный». W эффект узла. Что касается операций чтения, то однократного чтения недостаточно. N < R + W Понятно。существовать Этот тип хозяина-раба Архитектура Вниз,Чтобы прочитать новое значение сразу после записи,В общем, я просто пошел читать и писать.,Он выродился в ситуацию «только запись-чтение».,Именно об этой модели и пойдет речь в этой статье.

1.2 Пример бизнес-архитектуры

Чтобы не быть слишком широким, следующее обсуждение будет основано на типичной городской архитектуре аварийного восстановления из трех мест и пяти центров, с которой столкнулся автор в своей работе. Я надеюсь, что обсуждение этой типичной модели поможет прояснить суть. При разработке плана на основе реальной ситуации Будьте вдохновлены. Несколько замечаний по архитектуре ниже:

• Режим репликации Master-Slave или полусинхронный режим,Только главный автор должен получить 2 подтверждения копирования от данных.,Отправка будет успешной после подтверждения наличия избыточных данных за пределами города.,Но да2 копии данных подтверждают, откуда берутся 2 подчиненных узла,неопределенный;
• Уровень данных прозрачен для вызовов верхнего уровня, чтобы защитить изменения узлов чтения и записи, вызванные аварийным восстановлением и эксплуатационными действиями.,Предоставить доступ на чтение и запись по имени Служить,Обеспечивает написание и чтение имен,Напишите имя, указывая на основную точку письма.,Чтение имен указывает на все узлы, чтобы обеспечить возможность доступа поблизости;
• Если вы хотите заняться чтением сразу после написания,Затем при выполнении маршрутизации операции чтения,Вам нужно выбрать имя, чтобы получить основную точку записи для чтения данных.

1.3 Модель решения

Судя по диаграмме архитектуры бизнес-архитектуры, это похоже на ситуацию с несколькими R в NRW. Каждое чтение выполняется в разных городах. На самом деле это не так. Разбить «читать сразу после записи» можно на следующие пункты:

1. Источник записи:То есть происхождение операции записи,Его можно условно разделить на две категории,Один тип источника для запуска пользователем,Другая категорияда За кулисами триггер. Разница в том, что пользователь обычно запускает одно детальное обновление записи. кулисами часто вызывают большие партии обновлений записи,В сочетании с потребностями в чтении,У этих двоих разное давление при написании статей;
2. Архитектура:существоватьодин мастерNхранение от Архитектура Вниз,Данные После записи основного узла записи,Когда он не был синхронизирован с подчиненным узлом,Запрос на чтение попадает на подчиненный узел,Это создает проблему невозможности прочитать новое значение;
3. старение:одиндаданные Разница во времени после записи и до поступления запроса на чтение,Запишите интервал чтения после записи,То есть, «читать сразу после записи» — это более непосредственное записывание и копирование другой даданной разницы во времени;,Обратите внимание на задержку записи-репликации. Если задержка записи-копирования превышает интервал чтения после записи,Это вызовет проблему невозможности прочитать новое значение. По сути, трудно гарантировать, что задержка записи-репликации будет меньше интервала чтения после записи;
4. читатель:то есть написатьданныепрочитать пользователя,Источник записи аналогичен,Тип дареальных пользователей,Своеобразная программа «Да За кулисами». За кулисами Программы в принципе могут решаться асинхронно.,В большинстве случаев нет необходимости рассматривать «неотложные» вопросы.,Целью чтения сразу после написания является удовлетворение потребностей пользователя в «немедленном чтении»;
5. Сценарий:одна порцияданные Сценарии использования в основном вседаразнообразный,Не все сцены требуют прочтения сразу после написания.,Обычно он может удовлетворить потребности лишь небольшого количества основных сцен;
6. объем:существоватьданные Полная концентрация,Сколько данных должно столкнуться с проблемой чтения после записи за определенный период времени? Из анализа источника,Запись, инициируемая пользователем, очевидно, имеет небольшой масштаб.,За кулисами вызвало письмо в широком диапазоне,Но такие большие партии часто можно разделить на периоды времени.,Можно уменьшить объем,Затем рассмотрим показания реальных пользователей.,Это только в небольших масштабах. «Маленький масштаб» в сочетании с «меньшим количеством сцен»,Это типичная проблема «локальности».

можно увидеть,Решить задачу чтения сразу после написания,Не обязательно, чтобы все запросы направлялись на основной узел записи.,Просто выберите «шипы»,Другими словами, да ищет решение: решение должно определить, какие данные имеют операции записи.,Когда запрос на чтение для определенного сценария поступает в течение определенного периода времени,Когда данные не уверены, синхронизировано ли да с подчиненной репликой,Направьте эту часть запроса на прочтение основной мысли. На сцене нескольких действий в разных местах,Точка доступа, откуда поступает запрос на чтение, может находиться на другом конце города.,Если требования к задержке запросов на чтение являются чувствительными,Также необходимо, чтобы новые данные могли обеспечить непосредственный доступ в течение короткого времени после записи.,Избегайте поездок по городу. Подведем итоги ключевых моментов:

1. Дифференцировать бизнес-сценарии;
2. Данные, написанные на логотипе；
3. Определить требования к задержке;
4. Обеспечьте доступ поблизости.

Эти 4 пункта,да, исходя из местных особенностей,Процесс детализации слой за слоем,Давайте посмотрим на каждый из них ниже.

02. Дифференцируйте бизнес-сценарии

Различение бизнес-сценариев означает, как идентифицировать «сложные» сценарии, которые требуют немедленного прочтения после написания. По сути, это можно рассматривать с точки зрения обеих сторон вызывающего абонента Служить и провайдера Служить:

1. Служить Точка зрения звонящего,Разные звонилки Служить по необходимости,При звонке Служить уточняйте, есть ли в запросе да запрос на чтение сразу после написания.,Вы можете использовать поставщика Служить для определения полей протокола в протоколе, чтобы позволить вызывающей стороне заявить свои требования;
2. Служить обеспечивает вид сбоку,Служить провайдер присваивает идентификаторы разным абонентам,Управление свойствами вызывающего абонента внутри провайдера Служить,Определите вызывающего абонента, у которого есть запрос на чтение сразу после записи;
3. Вообще говоря,Служить обеспечивает квадратную перспективу с лучшей управляемостью и управляемостью.,Менее подвержены злоупотреблениям со стороны звонящих,Рекомендуется.

Уточнены сценарии чтения и письма.,Когда приходит каждый запрос пользователя на чтение,Определите атрибуты сцены,Если да не нужно читать сразу после написания, сценарий,Просто посетите локальную копию данных.,Нет необходимости заботиться о том, актуальна ли копия. Для сценариев, где требуется чтение сразу после записи,Требуется дальнейшее суждение и обработка.

03. Данные для написания логотипа

Как определить, что определенный фрагмент данных был записан, имеет два направления:

1. Сценарии, в которых пользователи запускают запись,При возврате посылки пользователю,,Возьмите с собой письменную информацию,Воспроизведение при чтении сразу,За кулисами можно использовать непосредственно для вынесения суждений;
2. Независимо от того, какая операция записи инициируется из,За кулисами единый учет недавно написанной информации,когда придет запрос,Сначала получите доступ к записанной информации для записи,Затем определите, писалось ли да недавно. Вы можете пойти дальше здесь,Не только фиксирует, есть ли в данныхдаде письменная отметка,Вы также можете рассмотреть возможность записи полных данных;
3. За кулисами Единый метод обработки записи более универсален В двух типичных сценариях, упомянутых выше, независимо от того, читает ли пользователь ее сразу после записи или да За. кулисами Пользователь может прочитать его сразу после написания, и с ним легко обращаться.

Независимо от того, передает ли клиент идентификатор записи записи.,Также да За кулисами хранится идентификатор записи записи.,Оба вводят дополнительный механизм зависимостей вне библиотеки данных.,увеличит сложность,Представленный механизм более надежен, чем библиотека данных.,Также будет некоторый ущерб. но,Чтение сразу после написания в основном решает проблему уровня пользовательского опыта.,Следует сказать, что да в целом приемлемо. конечно,Конкретные детали должны быть тщательно оценены на основе фактического бизнеса.

При идентификации записанных данных, когда поступает запрос на чтение, сначала прочитайте недавно записанную идентификацию и определите, если недавней записи нет, это означает, что локальная копия уже имеет последние данные. Доступ к локальной копии данных. это. Если запись была сделана недавно, требуется дальнейшее рассмотрение и обработка.

04. Определите требования к задержке

Сценарии чтения часто предъявляют более высокие требования к производительности.,Задержка обработки — очень важный показатель,В межгородской Архитектуре, полной жизни в другом месте,Будет предоставлена ​​локальная доступная копия.,для достижения цели низкой задержки. но,Обычные реплики чтения не имеют возможности предоставлять доступ к последним данным записи. Чтение сразу после написания,К основным факторам, которые необходимо учитывать при определении задержки, относятся:

1. Задержка в пути туда и обратно по городу составляет ок. 30ms,Такая задержкада Это приемлемо?？
2. Запрос на чтение должен прочитать данные. Имеется ли несколько копий да? Требуется ли чтение нескольких копий данных сразу после записи?
3. При чтении нескольких копий данных есть ли какие-либо зависимости, которые необходимо читать последовательно? Можно ли читать одновременно?
4. Несколько вопросов выше,Необходимо комплексно рассматривать множество сценариев развития всего бизнеса.,и уделять должное внимание будущему,Потребности, удовлетворяемые в настоящее время,Будет ли будущее таким же?

После выяснения требований бизнеса к задержке,,Для запросов на чтение последнего значения,Если требования к задержке не так высоки,Просто помогите читателю написать суть,в противном случае,Необходимо обеспечить возможности близлежащего доступа。Внизлапшадак более общему За кулисами Запишите шаблон метки записи, чтобы проиллюстрировать принципиальную схему задержки.

05. Обеспечьте доступ поблизости

Читать сразу после написания рядом доступ,Попросите копию, которая доступна вам, чтобы убедиться, что она актуальна.,И уровень данных Архитектура, о котором мы говорим, не может быть гарантирован.,Для этого требуется, чтобы бизнес-уровень успешно записывал данные на уровень данных.,Пожалуйста, напишите дополнительную копию в каждое место, запрашивающее доступ.,Для достижения цели близлежащего доступа. В этом случае,Записи записи, упомянутые выше в разделе «Данные записи идентификации», могут быть расширены.,Не только записывать и писать идентификацию,В то же время запишите конкретные записанные данные. Упрощенная схема обработки ниже,Расположение ближайшей копии,да используется для решения задачи чтения сразу после письма.,Объединение запросов на чтение не загрязняет данные.,А добиться сильной последовательности в бизнесе сложно.,Может быть легким по конструкции,Например:

1. Шаг 2. После записи данных,Вы можете возвращать посылки параллельно,И напишите несколько соседних копий параллельно;
2. При записи в ближайшую копию можно использовать облегченную гарантию записи CAS. В случае сбоя количество повторов можно соответствующим образом увеличить;
3. Добавьте краткосрочную асинхронную сверку для обнаружения разницы между ближайшей копией и основной точкой записи, чтобы можно было контролировать влияние сбоя в небольшом временном диапазоне;
4. Для асинхронной записи в ближайшую инкапсулированную копию API,Предоставляется нуждающимся,Сократите затраты на использование.

06. Краткое изложение идей решения

Чтение сразу после записи — типичная локальная проблема,Если вы можете копировать детали на основе данных «главный-подчиненный» на уровне библиотеки данных,Опишите местные особенности,Решив ее, вы получите вдвое больший результат, прилагая вдвое меньше усилий. Данная статья основана на локальных особенностях проблемы.,С точки зрения бизнеса,Обобщена идея четырехэтапного решения: дифференциация бизнес-сценариев, запись идентификации, оценка требований к задержке и обеспечение близлежащего доступа.,Детализация слой за слоем,Уточнить местные особенности.

-End-

Автор оригинала｜Сюн Чжанцзюнь

Есть ли у вашего бизнеса подобные проблемы?,Какова конкретная практика да? Добро пожаловать, чтобы оставлять комментарии и сообщения. Мы выберем 1 качественный отзыв,Раздайте 1 индивидуальный комплект сумок для документов Tencent Cloud (см. рисунок ниже). Розыгрыш лотереи состоится в 12:00 4 декабря.

📢📢Добро пожаловать в сообщество разработчиков Tencent Cloud, чтобы получать новейшую информацию, полезную информацию от громких имен, находить друзей по интересам и заводить друзей в том же городе. Goose Factory также предлагает возможности набора персонала и периферийные подарки ограниченным тиражом. жду тебя~