Привет всем, я Бинхэ~~

Среди крупных интернет-компаний существует распространенное явление: в некоторой степени, пока это относительно важная система, необходимо учитывать аварийное восстановление системы.

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

1. Введение в аварийное восстановление

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

Для локального «активный-активный» и удаленного «активный-активный» — это разные решения для аварийного восстановления. У них разные требования к технологии, затратам на развертывание, затратам на эксплуатацию и обслуживание, пропускной способности сети, стабильности сети и т. д.

Это в некоторой степени увеличит сложность и стоимость развертывания. Однако в случае сбоя определенной системы аварийное восстановление может быстро переключиться на другую систему, чтобы обеспечить ее высокую доступность.

2. Проблема простоев

Базовые системы предприятия и более важные системы также должны учитывать вопросы аварийного восстановления. Здесь аварийное восстановление в основном достигается за счет развертывания двух или более систем. Эти две или более системы обычно развертываются в разных компьютерных залах, чтобы избежать развертывания одной системы. или в одном компьютерном зале развернуто несколько систем, происходит простой.

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

Этот тип системной аварии не вызван людьми, но если проблема аварийного восстановления не рассматривается или проблема аварийного восстановления не учитывается полностью, эта проблема может возникнуть, когда две или более системы развернуты в одном компьютерном зале.

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

3. Развертывание нескольких машинных залов

Развертывание нескольких компьютерных залов, как следует из названия, заключается в развертывании двух или более систем в нескольких компьютерных залах. Развертывание двух или более систем в нескольких компьютерных залах не так просто и красиво, как можно себе представить. несколько компьютерных залов определенного уровня сложности и сложности.

Возьмем в качестве примера базу данных. Предположим, что в настоящее время имеется два компьютерных зала, а именно компьютерный зал A и компьютерный зал B. Основная база данных A и подчиненная база данных B находятся в компьютерном зале A. Так как же работает приложение в компьютерном зале B? прочитать данные? В настоящее время обычно существует два решения: чтение данных в разных компьютерных залах и чтение данных в одном компьютерном зале.

3.1 Чтение данных в компьютерных залах

Если данные считываются в компьютерных залах, приложение в компьютерном зале B будет считывать данные в компьютерном зале A в разных компьютерных залах, как показано на рисунке ниже.

Видно, что в это время приложение в компьютерном зале B будет считывать данные из компьютерного зала A по всем компьютерным залам.

3.2 Чтение данных в локальном компьютерном зале

Если данные считываются в локальном компьютерном зале, ведомая библиотека может быть развернута в компьютерном зале B. Подчиненная библиотека в компьютерном зале B синхронизирует данные компьютерного зала A в компьютерных залах. Затем приложение в компьютерном зале B считывает данные. данные подчиненной библиотеки в локальном компьютерном зале, как показано ниже.

Можно видеть, что если ведомая база данных развернута в компьютерном зале B и данные компьютерного зала A синхронизированы между компьютерными залами, приложение в компьютерном зале B может читать данные ведомой базы данных в компьютерном зале.

4.3 Проблемы, связанные с машинным залом

Независимо от того, считывает ли приложение в компьютерном зале B данные в компьютерном зале или считывает данные в этом компьютерном зале, возникнут проблемы с передачей данных между компьютерными залами, когда приложение в компьютерном зале B напрямую считывает данные в компьютере. Зал А. Проблема передачи данных между компьютерными залами.

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

Согласно прошлому опыту, задержка передачи данных между компьютерными залами напрямую связана с физическим расстоянием между компьютерными залами. Здесь я приведу вам некоторые эмпирические данные.

(1) Задержка выделенной линии в двух компьютерных залах в одном городе.

В обычных условиях задержка выделенной линии с двумя компьютерными залами в одном городе составляет от 1 до 3 мс.

Предположим, что время отклика интерфейса должно контролироваться в пределах 200 мс, и вызов интерфейса может активировать некоторые службы RPC или другие службы, если выделенная сеть двух компьютерных залов в одном городе исправна и службы вызываются через нее. В компьютерных залах время отклика интерфейса может увеличиться на несколько миллисекунд, а если данные считываются и записываются в разных компьютерных залах, время отклика интерфейса увеличивается на несколько миллисекунд, что является приемлемым.

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

(2) Задержка в выделенной линии внутреннего удаленного двухкомпьютерного зала.

В нормальных условиях задержка внутренних выделенных линий с двумя машинными залами находится в пределах 50 мс.

Детали еще необходимо определить на основе физического расстояния между компьютерными залами. Например, задержка выделенной линии из Пекина в Шанхай обычно составляет около 30 мс, а задержка выделенной линии из Пекина в Гуанчжоу — около 50 мс. Физическое расстояние между компьютерными залами разное, и задержка тоже разная.

Из-за задержки передачи данных по выделенным линиям в двух удаленных компьютерных залах, если время отклика интерфейса должно контролироваться в пределах 200 мс, следует избегать частых вызовов службы обслуживания между компьютерами, а также чтения и записи данных между компьютерами. .

(3) Задержка выделенной линии в международном удаленном двухкомпьютерном зале

При нормальных обстоятельствах сетевая задержка международных выделенных линий для удаленных двухкомпьютерных залов будет выше, чем у внутренних выделенных линий для удаленных двухкомпьютерных залов, обычно от 100 до 200 мс.

В этом сценарии необходимо избегать синхронизации данных между компьютерными залами и рассматривать только асинхронную синхронизацию данных между компьютерными залами.

4. Двойная деятельность в одном городе

Решение «активный-активный» для одного города развертывает систему в разных компьютерных залах одного города. Это решение позволяет обеспечить аварийное восстановление на уровне компьютерного зала, но не на уровне города.

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

Таким образом, вызовы RPC могут происходить, насколько это возможно, в локальном компьютерном зале. Если вы записываете данные, вы можете записать данные в один компьютерный зал и синхронизировать их с другим компьютерным залом в реальном времени, как показано на рисунке ниже.

Видно, что при реализации решения «активный-активный» в одном городе основная база данных может быть развернута в компьютерном зале А. Данные компьютерного зала А и компьютерного зала Б записываются в основную базу данных компьютерного зала А. Основная база данных синхронизирует данные с компьютерными залами А и Б. Из библиотеки. Как только в компьютерном зале A произойдет сбой, подчиненная база данных в компьютерном зале B может быть повышена до главной базы данных, а компьютерный зал B продолжит предоставлять услуги внешнему миру.

Кэш развернут в компьютерном зале A и в компьютерном зале B одновременно. Данные в кэше могут быть синхронизированы подчиненной базой данных в локальном компьютерном зале, а также могут быть прочитаны и записаны службой локального компьютерного зала.

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

При обновлении данных данные каждого компьютерного зала могут обновляться одновременно.

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

5. Больше живите в разных местах

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

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

В удаленном мультиактивном сценарии синхронизация данных может выполняться посредством синхронизации «главный-подчиненный» + асинхронной репликации сообщений. То есть для таких данных, как MySQL и Redis, репликация «главный-подчиненный» может использоваться для синхронизации данных из одного компьютерного зала в другой. другой. Компьютерный зал. Подобно кэшированным данным и данным в некоторых базах данных NoSQL, данные можно синхронизировать с помощью асинхронной репликации сообщений, как показано на рисунке ниже.

Можно видеть, что в удаленном мультиактивном сценарии для таких данных, как MySQL и Redis, репликация «главный-подчиненный» может использоваться для синхронизации данных из одного компьютерного зала в другой. Такие данные, как кэшированные данные и некоторые базы данных NoSQL, можно синхронизировать с помощью асинхронной репликации сообщений.

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

Чтение данных и вызов служб должны осуществляться в одном и том же компьютерном зале, насколько это возможно.

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

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

Еще один момент, который необходимо объяснить: если локальное решение с архитектурой «активный-активный» может удовлетворить потребности, не стоит легко пробовать удаленную архитектуру «активный-активный». На самом деле удаленная архитектура «активный-активный» слишком сложна, и немногие компании могут это сделать. построить настоящую удаленную архитектуру «активный-активный».

6. Резюме

Большая часть этой статьи взята изледникиз《Система мгновенного уничтожения Seckill》Столбец,существовать《Система мгновенного уничтожения Seckill》Столбецсередина,Речь идет не только о том, чтобы заставить всех написать систему флеш-продаж с нуля.,Но от установления требований до проектирования архитектуры, от создания среды до реализации кода, от повторения проблем до оптимизации кода, от монолитной архитектуры приложения до микро-архитектуры, от окончательной оптимизации до реализации решений с высоким уровнем параллелизма, от управления трафиком до отслеживания ссылок и защиты от очистки От плана до проектирования управления рисками, от развертывания кластера до полноканального стресс-тестирования,Тогда вся система флэш-продаж будет максимально оптимизирована.

Общее содержание столбца системы мгновенного уничтожения Seckill выглядит следующим образом.

7. Напишите в конце

Помимо высокопроизводительного шлюза, который в настоящее время обновляется, Glacier's Knowledge Planet также имеет шесть других проектов, таких как распределенная система обмена мгновенными сообщениями, распределенная система флэш-продаж Sekill, рукописный RPC, простая система торгового центра и т. д. Потребности этих проекты, планы, архитектура, реализация и т. д. — все это основано на реальных бизнес-сценариях в Интернете, что позволяет вам по-настоящему изучить планы внедрения бизнеса и технологий крупных интернет-компаний и эффективно преобразовать их в свои собственные резервы знаний.