1. Предпосылки
В качестве базовой службы социальных приложений IM выполняет такие функции, как мгновенный чат, групповой чат, прямая трансляция и голосовая связь с несколькими людьми. Живой чат является наиболее важным из многих функциональных модулей. Он должен поддерживать сеансовые отношения (многие ко многим) между двумя пользователями. С продвижением приложения количество пользователей продолжает расти. Сеансовые отношения увеличиваются в геометрической прогрессии, а частота вызовов интерфейса для получения информации о сеансе Экспоненциальный рост Из-за спешки с утверждением проекта приложения прогноз скорости разработки приложения является относительно пессимистичным, а первоначальные человеческие ресурсы ограничены, а подбаза данных и подтаблица не вводятся. Данные одной таблицы растут в геометрической прогрессии, поэтому скорость отклика медленная, и неизбежна оптимизация таблицы сеансов.
Связанные концепции
- беседа
- тянуть сеанс
2. Статус проблемы
Если предположить, что количество сеансов на одного активного пользователя равно 10, то при ежедневной активности 100 общее количество сеансов составляет около 1000, а когда ежедневная активность достигает миллиона, количество ежедневных сеансов составляет большой порядок. бизнес-сценарии Пока пользователь разговаривает и в списке сеансов нет текущего сеанса чата, интерфейс (qps составляет 1000, rt составляет около 400 мс) будет вызываться для получения информации о сеансе.Высокая частота вызовов и низкая скорость ответа приводят к ухудшению пользовательского опыта.Пик пользовательской активности часто связан с этим.Интерфейс приводит к тому, что ЦП сервера находится под чрезвычайно высокой нагрузкой в течение длительного времени, а в тяжелых случаях вся система прямо парализована.
3. Решения
вопрос
- UID является идентификатором инициатора сеанса, TO_UID является идентификатором приемника сеанса, UID является ролью плательщика в действительном бизнесе, TO_UID является ролью бенефициара, и требуется определенная плата за UID, чтобы найти TO_UID чат. В этом бизнес-контексте структура таблицы uid и to_uid предназначена. Хотя эта структура соответствует бизнес-требованиям, есть еще дефекты бизнеса, такие как: Запрос информации о сеансе пользователя 1 (ID = 1), пользователя 2 (ID = 2), так и пользователя 3 (ID = 3), соответствующие следующему SQL, нет способа определить, кто UID и кто TO_UID, только через или узнать
// SQL
SELECT * FROM chat_table
WHERE
(uid = 1 AND to_uid IN (2,3))
OR
(uid IN (2,3) AND to_uid = 2);
- Поскольку это одна таблица, а объем данных достигает 3000w+, только SQL-запрос занимает около 300 мс, плюс время бизнес-обработки, один вызов интерфейса занимает 400+ мс.
- Процесс оптимизации не может быть остановлен на техническое обслуживание и не может повлиять на нормальное использование пользователями.
Идеи оптимизации
-
Поскольку исходная структура таблицы не может определить, кто является uid, когда известны два идентификатора пользователя, их сеанс может быть запрошен только по ИЛИ. Вы можете добавить поле splic_user_id uid и to_uid в таблицу в соответствии с .Поскольку и uid, и to_uid определяются однозначно, сплайсированный splic_user_id также определяется однозначно, то есть splic_user_id определяется однозначно по uid, to_uid быстро определяет цель сеанса
-
После прояснения идеи оптимизации необходимо учитывать, что обслуживание не может быть остановлено, добавление полей непосредственно в таблицу через операторы DDL неизбежно приведет к блокировке таблицы и прямому параличу службы обмена мгновенными сообщениями.
- Вариант 1: Создайте новую таблицу (chat_table_new) с добавленным полем splic_user_id, chat_table записывает данные в chat_table_new в режиме реального времени, и после того, как данные будут в основном синхронизированы, выпустите код для запроса таблицы chat_table_new Это решение, очевидно, требует много времени
- Вариант 2. Найдите инструмент, который может изменять структуру таблицы в режиме онлайн без блокировки таблицы, чтобы не было необходимости изменять код и стоимость была очень небольшой.
Я обнаружил, что есть инструмент (percona-toolkit) может изменять структуру таблицы MySQL в режиме онлайн, не блокируя таблицу
Сравнение схем
percona-toolkit
percona-toolkitСоздан на основе инструментов Maatkit и Aspersa, двух самых известных инструментов для управления MySQL, но Maatkit больше не поддерживается, и все они объединены в percona-toolkit. Percona Toolkit — это набор расширенных инструментов командной строки для управления MySQL и системными задачами, в основном включающий:
- Проверка согласованности первичных и реплицированных данных
- Эффективно архивируйте строки записей
- Найти дубликат индекса
- Резюме Сервер MySQL
- Анализ запросов из логов и tcpdump
- Сбор важной системной информации при возникновении проблемы
- Изменить структуру таблицы онлайн
В случае непрерывной бизнес-итерации неизбежно выполнять операции DDL над таблицами данных, изменять, добавлять, удалять поля и индексы.Для MySQL DDL — это функция, которую нужно использовать с большой осторожностью, потому что в MySQL DDL — это выполняется на таблицах.Когда таблица заблокирована, чем больше объем табличных данных, тем сильнее влияние. До 5.1 DDL был очень трудозатратным и трудозатратным, после 5.1, с появлением плагина innodb, скорость онлайн-индексации сильно увеличилась, но все равно влияет (время сократилось), в 5.6, описанной выше ситуации можно избежать.В настоящее время InnoDB The Engine выполняет DDL с помощью следующих шагов:
- Создайте невидимую временную таблицу (tmp_table) в соответствии со структурой таблицы и оператором DDL исходной таблицы (original_table)
- Добавьте блокировку записи в исходную таблицу, заблокируйте все обновления (вставка, удаление, обновление и т. д.)
- воплощать в жизнь
insert into tmp_table select * from original_table
- переименуйте original_table и tmp_table, наконец, удалите original_table
- Снимите блокировку записи.
Мы видим, что когда InnoDB выполняет DDL, исходная таблицаМожет только читать и не писать. С этой целью perconal запустил инструмент pt-online-schema-change, который отличается отсутствием блокировки чтения и записи в процессе модификации.
pt-online-schema-changeПринцип работы
- Если есть внешний ключ, согласно
alter-foreign-keys-methodОпределяется значение параметра, таблица, относящаяся к внешнему ключу, и обрабатываются соответствующие настройки. Инструмент не запускается без указания конкретного значения с помощью метода alter-foreign-keys.
- Создайте новую пустую таблицу, правило именования: подчеркивание + исходное имя таблицы +
_new——-_原表名_new
- В соответствии с оператором alter обновите структуру новой таблицы;
- Создайте триггер для записи операций, которые продолжают изменять данные в исходной таблице данных после копирования данных, и выполняйте эти операции после завершения копирования данных, чтобы гарантировать, что данные не будут потеряны. Этот инструмент не будет работать, если в таблице уже определены триггеры.
- Скопируйте данные, скопируйте данные из исходной таблицы данных в новую таблицу.
- Измените подтаблицу, связанную с внешним ключом, и измените подтаблицу, связанную с внешним ключом, в соответствии с измененными данными.
- Переименуйте таблицу исходных данных в старую таблицу, переименуйте новую таблицу в имя исходной таблицы и одновременно обработайте две таблицы с помощью RENAME TABLE для выполнения атомарных операций. (ПЕРЕИМЕНОВАТЬ ТАБЛИЦУ dbteamdb.chat_table В dbteamdb._chat_table_old, dbteamdb._chat_table_new В dbteamdb.chat_table)
- Удалите старую таблицу и удалите триггер.
- Новое решение напрямую попадает в индекс, обеспечивая точный запрос и высокую скорость запроса.
-- 新
SELECT * FROM chat_table WHERE splic_user_id IN ('1_2','1_3');
4. Сравнение эффектов
Оптимизация назад:
После оптимизации: запросы более чем в 10 раз быстрее
5. Резюме
- Старайтесь не работать за закрытыми дверями при столкновении с проблемами, а хорошенько подумать.Вы можете сначала узнать, сталкивались ли другие люди с подобными проблемами в Интернете, чтобы вы могли не попасть в яму и погружаться все глубже и глубже, и решить ее на на основе опыта предшественников. Проблемы могут сделать больше с меньшими затратами
- Практика доказываетpercona-toolkitИзменение структуры таблицы в режиме реального времени — это действительно мощный инструмент.Добавление полей в таблицы с десятками миллионов данных не оказывает никакого влияния на бизнес.