об авторе
Чен Бо, технический эксперт Sina Weibo, автор книги «Глубокий распределенный кэш».
Примечание:Эта статья перенесена с номера подписки мезозойской технологии (идентификатор: freshmanTechnology), воспроизведена с разрешения платформы.
У Weibo 160 миллионов активных пользователей в день и десятки миллиардов ежедневных посещений.В условиях массовых посещений огромной пользовательской базы хорошо структурированная и постоянно совершенствуемая система кэширования играет очень важную вспомогательную роль. В этой статье г-н Чен Бо, технический эксперт Sina Weibo, подробно объяснит, как представляются эти огромные данные.
План этой статьи
1. Проблемы с данными во время работы Weibo
2. Архитектура системы кормовой платформы
3. Архитектура и эволюция кэша
4. Резюме и перспективы
вызов данных
Системная архитектура платформы Feed разделена на пять уровней.Верхний уровень — терминальный уровень, такой как веб-терминал, клиент, некоторые клиенты IOS или Android, которые все используют, а также некоторые открытые платформы и некоторые интерфейсы для сторонний доступ, следующий уровень-это уровень доступа к платформе.Различные пулы в основном используются для выделения хороших ресурсов для важных основных интерфейсов, так что, когда возникает внезапный трафик, существует большая гибкость для обслуживания и повышения стабильности обслуживания. Далее идет уровень службы платформы, в основном алгоритм подачи, отношения и так далее. Далее идет средний уровень, который предоставляет некоторые услуги через различные промежуточные среды. Нижний слой — это слой хранения.
1 Feed Timeline
Например, когда вы пролистываете Weibo каждый день, нажимаете, чтобы обновить на главном веб-сайте или в клиенте, и недавно вы получаете от десяти до пятнадцати Weibo, как это устроено?
После обновления в первую очередь будет получено отношение внимания пользователя. Например, если у него есть тысяча подписчиков, он получит тысячу идентификаторов, а затем, согласно тысяче идентификаторов, он получит несколько микроблогов, опубликованных каждым пользователем. В то же время он получит папку «Входящие» пользователя, то есть специальные сообщения, которые он получает, такие как некоторые сгруппированные микроблоги, групповые микроблоги, следующие отношения и список микроблогов подписчика.
Получив эту серию списков микроблогов, соберите и отсортируйте их, получите требуемые идентификаторы, а затем извлеките из этих идентификаторов содержимое микроблогов, соответствующее каждому идентификатору микроблога. Если эти Weibo будут перенаправлены, у него все еще будет исходный Weibo, и он будет дополнительно извлекать исходный контент Weibo. Информация о пользователе получается через исходный микроблог, и эти микроблоги дополнительно фильтруются в соответствии с фильтрующими словами пользователя, чтобы отфильтровать микроблоги, которые пользователь не хочет видеть.
В соответствии с микроблогами, оставленными вышеописанными шагами, мы дополнительно проверим, добавили ли пользователи в избранное или понравились эти микроблоги, установим некоторые флаги, а также соберем различные подсчеты, пересылки, комментарии и лайки этих микроблогов. , и, наконец, вернули эту дюжину микроблогов на различные терминалы пользователя.
Таким образом, внутреннему серверу, вероятно, потребуется собрать сотни или даже тысячи данных в режиме реального времени для дюжины или около того записей, полученных пользователем за один раз, а затем вернуть их пользователю Весь процесс зависит от сила системы Cache, поэтому дизайн архитектуры Cache имеет свои плюсы и минусы, что напрямую повлияет на производительность системы Weibo.
2 Архитектура кэша каналов
Далее давайте взглянем на архитектуру Cache, которая в основном разделена на шесть уровней. Во-первых, первый уровень — это «Входящие», в котором в основном группируются некоторые Weibo, а затем — непосредственно некоторые Weibo владельца группы. Входящие сообщения относительно небольшие, в основном в виде push-уведомлений.
Затем для Исходящих второго слоя каждый пользователь будет отправлять обычные сообщения Weibo, и они попадут в его Исходящие. По количеству хранимых ID он фактически делится на несколько Кэшей, среднее количество около 200, а длинное около 2000.
Третий слой — это какие-то отношения, его подписчики, поклонники, пользователи.
Четвертый уровень — это контент, и здесь присутствует некоторый контент каждого Weibo.
Пятый слой — это некоторые экзистенциальные суждения, например, понравился ли мне определенный Weibo. Раньше некоторые знаменитости говорили, что мне не нравится этот Weibo, как это показало, что мне нравится этот Weibo, что вызвало некоторые новости. А это пластинка, она ей когда-то нравилась, но, наверное, забыла.
Внизу также есть относительно большой слой — количество комментариев, репостов и т. д. каждого Weibo, а также количество внимания пользователей и количество поклонников.
Архитектура и эволюция кэша
1 Простой тип данных KV
Далее мы сосредоточимся на эволюции архитектуры кэша Weibo. Когда Weibo был впервые запущен, мы сохранили его как простой тип данных KV. В основном мы используем хэш-шарды для хранения в пуле MC.После нескольких месяцев запуска мы обнаружили некоторые проблемы: некоторые узлы узлов не работают или по другим причинам большое количество запросов будет проникать через уровень кэша, чтобы достичь БД, что приводит к весь запрос на замедление, и даже БД мертва.
Поэтому мы быстро провели трансформацию и добавили слой HA, чтобы даже если какие-то узлы в слое Main упадут или зависнут, эти запросы в дальнейшем будут проникать на уровень HA и не будут проникать на уровень DB. Это может гарантировать, что ни при каких обстоятельствах частота попаданий всей системы не будет снижена, а стабильность системных служб значительно улучшена.
Для этого метода индустрия сейчас использует его больше, и многие люди говорят, что я использую хэш напрямую, но в нем есть некоторые подводные камни. Например, у меня есть нода, нода 3 не работает, Main ее удаляет, а некоторый QA ноды 3 распределяется на несколько других нод Этот бизнес-объем не очень большой, и он может выдержать проникновение в БД. Но если этот узел 3 будет восстановлен и добавлен снова, то доступ к узлу 3 вернется, позже узел 3 снова будет отключен по сетевым причинам или по самой машине, а некоторые запросы узла 3 будут распределены на другие узлы. В это время будет проблема.Данные, которые ранее были распределены по другим узлам, не обновились.Если их не удалить, будут смешанные данные.
На самом деле Weibo — это бизнес квадратного типа: например, в экстренной ситуации, когда знаменитость найдет себе девушку, трафик мгновенно увеличится до 30%. После аварийной ситуации на некоторых узлах появится большое количество запросов, из-за чего эти узлы будут очень горячими, и даже MC не сможет удовлетворить такое большое количество запросов. В это время MC станет узким местом, что приведет к замедлению работы всей системы.
По этой причине мы ввели слой L1, который также является основным пулом отношений.Каждый L1 составляет примерно одну N-ю часть основного уровня, одну шестую, одну восьмую и одну десятую объема памяти. request Я увеличу объем от 4 до 8 L1, чтобы все запросы сначала посещали L1. Если попадет L1, он будет доступен напрямую, если нет, то он посетит уровень Main-HA, чтобы L1 мог противостоять большинству горячих запросов во время некоторого всплеска трафика. Для самого Weibo новые данные будут горячее, а пока добавляется небольшой объем памяти, он выдержит больший объем.
Подводя краткий итог, за счет хранения данных простого типа KV мы фактически фокусируемся на MC, узлы HASH в слое не дрейфуют, а Miss проникает на следующий уровень для чтения. Улучшая производительность чтения нескольких групп L1, он может выдерживать пиковый и всплеск трафика, а стоимость будет значительно снижена. Для стратегии «чтение-запись» используется многократная запись, для чтения используется послойное проникновение, а в случае промаха выполняется обратная запись. Для данных, которые в нем есть, мы изначально использовали Json/xml, а после 2012 года мы напрямую использовали формат Protocol Buffer, а для сжатия некоторых больших файлов использовали QuickL.
2 сбор данных
Я только что говорил о простых данных QA, как быть со сложными данными сбора?
Например, если я слежу за 2000 человек и добавлю одного человека, это потребует некоторых изменений. Один из способов — удалить все 2000 идентификаторов для модификации, но это создаст большую нагрузку на пропускную способность и машины. Есть также несколько пейджинговых сборов. Я сэкономил 2000, и мне нужно получить только первые несколько страниц, например вторую страницу, которая находится с десятой по двадцатую. Могу ли я вернуть все данные? Есть также связанные расчеты некоторых ресурсов, которые подсчитают, что ABC также следует за пользователем D в некоторых людях, которых я читаю. Такого рода модификации и получение некоторых данных, в том числе расчетных, на самом деле не очень хорошо для МК.
Все виды связанных отношений хранятся в Redis, а разделение чтения и записи выполняется с помощью распределения хэшей, хранения и набора методов с несколькими хранилищами. На данный момент память Redis составляет около 30 Т, а запросов 2-3 триллиона каждый день.
В процессе использования Redis на самом деле возникают некоторые другие проблемы. Например, из следующего отношения я проследил 2000 UID. Один из способов — хранить их полностью. Однако у Weibo большое количество пользователей. Некоторые пользователи меньше входят в систему, а некоторые пользователи очень активны, поэтому стоимость хранение их всех в памяти относительно велико. Поэтому мы изменили использование Redis на Cache, например, сохраняются только активные пользователи.Если вы какое-то время не были активны, вас выкинет из Redis, и вы добавитесь, когда у вас снова появится доступ.
В настоящее время существует проблема, поскольку рабочий механизм Redis представляет собой однопоточный режим, если он добавляет определенный UV и обращает внимание на 2000 пользователей, он может расшириться до 20 000 UID. в основном застрял способ предоставления других услуг. Поэтому мы расширяем новую структуру данных, 20 000 UID напрямую открываются, а при записи напрямую записываются в Redis по очереди, и общая эффективность чтения и записи будет очень высокой. Его реализация представляет собой открытый массив типа long, к которому обращается Double Hash.
Мы сделали некоторые другие расширения для Redis. Возможно, вы видели некоторые из наших предыдущих публикаций в Интернете. Помещение данных в общедоступные переменные, весь процесс обновления, если мы протестируем 1G, загрузка займет 10 минут, а 10G займет около десяти минут Более минуты, теперь обновление на миллисекунду.
Для AOF мы используем скользящий AOF, каждый AOF имеет идентификатор, а затем прокручиваем до следующего AOF, когда достигается определенное количество. Когда RDB будет реализована, мы запишем файл AOF и его местоположение при построении RDB, и обеспечим полную инкрементную репликацию с помощью новых режимов расширения RDB и AOF.
3 Другие типы данных — количество
Далее идут еще какие-то типы данных, например счетчик.На самом деле счетчики можно встретить в каждой интернет-компании.Для некоторых малых и средних бизнесов на самом деле достаточно MC и Redis,но в Weibo есть некоторые особенности в количество: у одного ключа есть несколько счетчиков, таких как Weibo, с количеством репостов, комментариев и лайков; у пользователя есть разные числа, такие как количество поклонников и подписчиков. Поскольку это счетчик, размер его значения относительно невелик.В соответствии с различными бизнес-сценариями он составляет около 2-8 байтов, обычно более 4 байтов, а затем каждый день добавляется около миллиарда новых сообщений Weibo. общая запись еще больше впечатляет, а то запрос, сотни отсчетов может быть возвращен.
4 Счетчик-счетчик службы
Изначально можно было взять Memcached, но у него есть проблема: если счетчик превысит вместимость его содержимого, это приведет к отбраковке некоторых счетчиков, и счетчик исчезнет после простоя или перезапуска. Кроме того, может быть много нулевых отсчетов, так как их сохранить в это время, сохранять их или нет, если они будут сохранены, то это займет много памяти. Каждый день Weibo считает миллиард, а большой объем памяти будет занимать только 0. Если его не будет, это приведет к проникновению в БД, что повлияет на растворимость сервиса.
После 2010 года мы снова использовали доступ к Redis.По мере того, как объем данных становился все больше и больше, мы обнаружили, что полезная нагрузка памяти Redis по-прежнему относительно мала.Для KV требуется не менее 65 байт, но на самом деле нам нужно 8 слов для a count.Section, а затем Value составляет около 4 байтов, поэтому действует только 12 байтов, а более 40 байтов тратятся впустую. Это всего лишь один KV, если ключ имеет несколько значений, это будет более расточительно. Например, для четырех счетчиков один ключ имеет 8 байтов, каждый из четырех счетчиков — 4 байта, а для 16 байтов требуется около 26 байтов, но для хранения в Redis требуется около 200 байтов.
Позже с помощью Counter Service, разработанного нами, память была уменьшена до одной пятой до менее чем одной пятнадцатой Redis, а горячие и холодные данные были разделены.Горячие данные хранились в памяти.Если холодные данные стали снова горячий, он был помещен в Go to LRU. Внедрите RDB и AOF для достижения полной инкрементной репликации.Таким образом, горячие данные могут храниться на одном компьютере на уровне 10 миллиардов, а холодные данные могут храниться на уровне 100 миллиардов.
Вся архитектура хранилища примерно как на картинке выше.Сверху память, а снизу SSD.В памяти она заранее разбита на N Таблиц.Каждая Таблица разбита на определенный диапазон согласно последовательности Идентификационные указатели. При переходе любого ID сначала найдите Таблицу, где она находится.Если в ней прямое увеличение или уменьшение, и придет новый счет, когда обнаружится, что памяти не хватает, он свалит маленькую Таблицу в SSD и сохраните новый. Позиция помещается вверху для использования нового идентификатора.
Некоторые люди спрашивают, если в пределах определенного диапазона счетчик моего идентификатора изначально был установлен на 4 байта, но Weibo очень популярен и превышает 4 байта, что мне делать, если он становится очень большим? Для тех, которые превышают лимит, мы храним их в Aux dict. Для таблиц, которые попадают в SSD, у нас есть специальный IndAux для доступа к ним и их репликации через RDB.
5 Другие типы данных - оценка существования
Помимо подсчета, у Weibo также есть бизнес и некоторые экзистенциальные суждения. Например, если Weibo показывает, есть ли лайки, чтения или рекомендации, если пользователь уже читал этот Weibo, не показывайте ему это снова. У этого есть отличная функция.Он проверяет, существует ли он.Каждая запись очень маленькая, например Value1 бит, но общий объем данных огромен. Например, Weibo публикует около 100 миллионов новых сообщений Weibo каждый день, и могут быть десятки миллиардов или сотни миллиардов общих данных, которые необходимо оценить. Как его хранить — большая проблема, а многие существования равны 0. Или, как я уже говорил, вы хотите сохранить 0? Если он есть, то каждый день хранятся сотни миллиардов записей, если его нет, то большое количество запросов со временем проникнет из уровня кэша на уровень БД, и ни одна БД не выдержит такого большого объема трафика.
Мы также сделали некоторые выборки, в первую очередь, мы напрямую рассмотрели, можем ли мы использовать Redis. Один KV составляет 65 байт, если KV может быть 8 байт, значение равно только 1 биту, поэтому эффективность добавления новой памяти каждый день очень низкая. Второй вид услуги счетчика, который мы недавно разработали, одно значение KV 1 бит, я сэкономлю 1 байт, всего достаточно 9 байт. Таким образом, каждый день добавляется 900 ГБ новой памяти. Если вы сохраните ее, вы сможете сохранить только последние несколько дней. Это почти 3 Т после трех дней хранения. Давление также довольно высокое, но это намного лучше. чем Редис.
Наш окончательный план состоит в том, чтобы разработать Phantom самостоятельно.Во-первых, мы распределяем общую память по сегментам, и в конечном итоге используемая память составляет всего 120G. Алгоритм очень простой, каждый ключ можно хэшировать N раз, если определенный бит хеша равен 1, то выполняется 3 хеширования, а трем числам присваивается значение 1. X2 также хешируется три раза.При оценке существования X1 позже, с точки зрения трех хэшей, если все они равны 1, считается, что он существует.Если определенный хэш X3, его биты вычисляются как 0. , тогда 100 % точно не существует.
Архитектура его реализации относительно проста: разделяемая память предварительно разбивается на разные таблицы, в ней выполняется расчет в открытом режиме, а затем чтение и запись, в случае высадки используется метод AOF+RDB для обработки. Поскольку весь процесс помещается в разделяемую память, данные не будут потеряны, если процесс будет обновлен и перезапущен. При внешнем доступе создайте протокол Redis, и он может напрямую расширить новый протокол для доступа к нашему сервису.
6 резюме
Подводя итог, до сих пор мы обращали внимание на высокую доступность, масштабируемость и высокую производительность компонентов в кластере Cache.Другим важным моментом является стоимость хранилища, и есть некоторые вещи, на которые мы не обращали внимания, например эксплуатация и обслуживание, Weibo.Сейчас там тысячи серверов и так далее.
7 расширенная оптимизация
8 Обслуживание
Принятое решение состоит в том, чтобы сначала управлять всем кэшем как службой, а затем управлять конфигурацией как службой, чтобы избежать частых перезапусков.Кроме того, если конфигурация изменяется, используйте сценарий для ее непосредственного изменения.
Serviceization также представляет Cluster Manager для реализации внешнего управления, управления через интерфейс и выполнения проверки обслуживания. С точки зрения управления сервисами можно добиться расширения и сокращения мощностей, а также можно надежно гарантировать SLA. Кроме того, для разработки теперь можно блокировать ресурсы Cache.
Резюме и перспективы
Наконец, если кратко подвести итог, мы оптимизировали и усовершенствовали архитектуру Weibo Cache с различных аспектов, таких как архитектура данных, производительность, стоимость хранения и обслуживание. Приглашаем коллег, у которых есть исследования или вопросы по этому поводу, оставить сообщение и обсудить с нами.
Последние горячие статьи
Распределенная база данных и решение схемы согласованности двойной записи кэша
Одна статья для разъяснения контекста управления памятью Apache Spark.
Создайте простую в реализации цепочку инструментов DevOps
На практике с SQL Server на MySQL переносится около 10 миллиардов томов данных.
Последние действия
Саммит DAMS China по управлению активами данных, 2018 г.