Архитектура MySQL с высокой степенью расширения для создания миллионов системных онлайн-практик

Большой объем данных является очень очевидной проблемой на данном этапе.Многие из случаев, с которыми мы недавно столкнулись, могут легко достигать более 8 терабайт данных, и резервное копирование данных стало очень проблематичным. Сейчас наступила эра массивных данных.

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

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

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

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

- Нет кеша плана выполнения, высокая загрузка ЦП

- Одноядерная операция запроса, не подходящая для запуска более крупного и сложного SQL.

- Чувствителен к данным подключения до MySQL 5.7 (рекомендуется контролировать ниже 300)

- Решения на основе механизма хранения (Innodb, TokuDB, MyRocks, Spider)

- Не поддерживает вложенность транзакций, не поддерживает хеш-соединение

Несмотря на такое количество проблем, в Китае есть много успешных случаев. Такие как WeChat Tenpay, логистика, кредит P2P, игровая индустрия, интернет-индустрия.

При планировании мощностей особое внимание необходимо уделить выравниванию распределения ресурсов.У многих компаний размеры баз данных неравномерны: большие — более десятка T, а маленькие — всего несколько десятков мегабайт.

Таким образом, управление всем ресурсом будет очень хаотичным.Для осуществления крупномасштабного управления необходимо использовать БД в качестве ресурса хранения и сформулировать нормы распределения. Например, когда один экземпляр работает на PCIE, размер экземпляра составляет около 1T, а размер одной базы данных — около 200G.Если он превышает 200G, он будет разделен.

Кроме того, мы выступаем за использование одной машины с несколькими экземплярами. Преимущество этого заключается в том, что его можно контролировать и легко мигрировать, а внутреннюю платформу управления ресурсами БД легко использовать. С другой стороны, для одной машины и одного экземпляра объем хранилища превышает 4T, а управление резервным копированием очень неудобно.

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

Принцип разделения, который мы отстаиваем, состоит в том, чтобы сначала разделить по функциям, таким как тип аутентификации, тип пользовательского ядра, базовая информация о пользователе и т. д. После разделения по функциям рассмотрите возможность горизонтального разделения после того, как размер отдельной библиотеки превысит 200 ГБ. Здесь обычно используются два алгоритма: Range и Hash. Когда размер одного экземпляра достигает примерно 1T, рассмотрите возможность его разделения на наборы. Например, 1–20 миллионов — это Set1, а 20–40 миллионов — Set2. С помощью управления наборами можно легко решить проблему распределения данных по нескольким IDC.

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

Самая безмолвная проблема, с которой сталкиваются вызовы БД для сложных проектов, заключается в том, что БД вызывается более чем N сервисами.В конце концов, невозможно различить, какой IP соответствует какому сервису.Когда БД нужно мигрировать, неизвестно кого нужно уведомить.

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

Кроме того, если вы не знаете свой предел параллелизма, вам следует использовать потоковые вызовы для управления параллелизмом в определенном диапазоне и ввести защиту от перегрузки.

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

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

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

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

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

На самом деле есть много вариантов для Cache.Как правило, в начале проекта вы можете игнорировать Cache и кэшировать только те, которые вызываются чаще всего. Мы перечисляем некоторые категории кеша ниже.

Нестабильный кэш

- Memcache

- Redis

энергонезависимый кеш

- Redis

- MongoDB

- MySQL NDB Cluster

Более рекомендуемыми являются Redis-Cluster и MongoDB Cluster. С точки зрения нестабильности вы можете выбрать Redis, но вы должны учитывать, что после зависания Redis база данных может выжить.Общее решение состоит в том, чтобы автоматически снижать уровень соединения, когда обнаруживается, что реакция базы данных медленная.