Блог-портал Masterpro.ws
Вопрос Как устроены Facebook и Vkontakte
7 года 10 мес. назад - 7 года 10 мес. назад #1
от Aleksej
Aleksej создал тему: Как устроены Facebook и Vkontakte
Вот какую информацию удалось найти в рунете.
«Facebook» — социальная сеть, основанная в 2004 году Марком Цукербергом и его соседями по комнате во время обучения в Гарвардском университете Эдуардо Саверином, Дастином Московицем и Крисом Хьюзом. Благодаря своему сайту Марк Цукерберг стал самым молодым миллиардером в свои 23 года.
Первоначально веб-сайт был назван thefacebook.com (позже изменён на современный вариант facebook) и открыт только для студентов Гарвардского Университета, затем доступ был расширен для других университетов Бостона, а затем и для студентов любых учебных учреждений США, имеющих электронный адрес с доменом .edu. Начиная с сентября 2006 года сайт был открыт для всех пользователей в возрасте от 13 лет, имеющих электронную почту. По состоянию на 21 июля 2010 года Facebook насчитывает более 500 миллионов пользователей по всему миру. При этом количество уникальных посетителей сайта в апреле 2010 года составило 540 млн, а количество просмотров страниц — 570 млрд. Прибыль Facebook за 2009 год по собственной оценке компании составила 700 млн долларов США.
Платформа
* Linux — операционная система
* PHP с HipHop — код на PHP компилируется в C++
* memcached — агрессивное кэширование объектов
* MySQL — используется как хранилище пар ключ-значение, никаких join'ов
* Thrift — интерфейс взаимодействия между сервисами, написанными на разных языках программирования
* Scribe — универсальная система сбора и агрегации данных с рабочих серверов
Статистика
* Более 500 миллионов активных пользователей (месячная аудитория)
* Более миллиарда социальных связей
* Более 200 миллиардов просмотров страниц в месяц
* Более 4 триллионов действий попадает в новостные ленты каждый день
* Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше
* Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно
* Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду
* 20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых
* О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно
* Более миллиарда сообщений в чате каждый день
* Более ста миллионов поисковых запросов в день
* Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect
* Более 400 тысяч разработчиков сторонних приложений
* Менее 500 разработчиков и системных администраторов в штате
* Более миллиона активных пользователей на одного инженера
* Десятки тысяч серверов, десятки гигабит трафика
Архитектура
Общие принципы
* Балансировщик нагрузки выбирает веб-сервер для обработки запроса
* PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:
o MySQL
o memcached
o Специализированные сервисы
* Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
o Вер-приложение
o Распределенный индекс
o Постоянное хранилище
* Использование открытых технологий там, где это возможно
* Поиск возможностей оптимизации используемых продуктов
* Философия Unix:
o Старайтесь делать каждый компонент системы простым и производительным
o Комбинируйте компоненты для решения задач
o Концентрируйте внимание на хорошо обозначенных точках взаимодействия
* Все усилия направлены на масштабируемость
* Попытки минимизации количества точек отказа
* Простота.
PHP
Почему PHP?
* Во многом «так исторически сложилось»
* Хорошо подходит для веб-разработки
* Легок в изучении: небольшой набор выражений и языковых конструкций
* Легок в написании: нестрогая типизация и универсальный «массив»
* Легок в чтении: синтаксис похож на C++ и Java
* Прост в дебаггинге: нет необходимости в перекомпиляции
* Большой ассортимент библиотек, актуальных для веб-проектов
* Подходит для процесса разработки с короткими итерациями
* Активное сообщество разработчиков по всему миру
* Динамическая типизация, интерпретируемый язык для скриптов
Как оказалось на самом деле?
* Высокий расход оперативной памяти и вычислительных ресурсов
* Сложно работать, когда объем исходного кода очень велик: слабая типизация и ограниченные возможности для статичного анализа и оптимизации кода
* Не особо оптимизирован для использования в крупных проектах
* Линейный рост издержек при подключении файлов с исходным кодом
* Механизм разработки расширений не очень удобен
Доработки:
* Оптимизация байт-кода
* Улучшения в APC (ленивая загрузка, оптимизация блокировок, «подогрев» кэша)
* Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)
* HipHop — трансформатор исходных кодов:
o Разработчики пишут на PHP, который конвертируется в оптимизированный C++
o Статический анализ, определение типов данных, генерация кода, и.т.д.
o Облегчает разработку расширений
o Существенно сокращает расходы оперативной памяти и вычислительных ресурсов
o У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка
o Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля
MySQL
Как используется MySQL?
* Используется как хранилище пар ключ-значение
* Большое количество логических узлов распределено между физическими машинами
* Балансировка нагрузке на уровне физических серверов
* Репликация для распределения операций чтения не используется
* Большинство запросов касаются самой свежей информации: оптимизация таблиц для доступа к новым данным, архивация старых записей
* В целом быстро и надежно
Как оказалось на самом деле?
* Логическая миграция данных очень сложна
* Создавать большое количество логических баз данных и перераспределять их между физическими узлами, балансируя таким образом нагрузку, намного удобнее
* Никаких join'ов на рабочих серверах баз данных
* Намного проще наращивать вычислительные мощности на веб-серверах, чем на серверах баз данных
* Схемы, основанные на структуре данных, делают программистов счастливыми и создают большую головную боль администраторам
* Никогда не храните не-статичные данные в централизованное базе данных
Доработки:
* Практически никаких модификаций исходного кода MySQL
* Своя схема партиционирования с глобально-уникальными идентификаторами
* Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя
* Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша
* Библиотеки для доступа к данным на основе графа:
o Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)
o Реплицированные связи (ребра графа)
o Аналоги распределенных внешних ключей (foreign keys)
o Большинство данных распределено случайно
Memcache
Как используется memcached?
* Высокопроизводительная распределенная хэш-таблица
* Содержит «горячие» данные из MySQL
* Снижает нагрузку на уровень баз данных
* Основная форма кэширования
* Используется более 25TB памяти на нескольких тысячах серверов
* Среднее время отклика менее 250 микро-секунд
* Кэшируются сериализованные структуры данных PHP
* Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL — приходится делать это на уровне программного кода
* Множество multi-get запросов для получения данных на другом конце ребер графа
* Ограниченная модель данных, неэффективен для маленьких объектов
Доработки:
* Порт на 64-битную архитектуру
* Более эффективная сериализация
* Многопоточность
* Улучшенный протокол
* Компрессия
* Проксирование запросов
* Доступ к memcache через UDP:
o уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений
o управление ходом исполнения приложение (оптимизация для multi-get)
* Статистика о работе потоков по запросу — уменьшает блокировки
* Ряд изменений в ядре Linux для оптимизации работы memcache:
o распределение управления сетевыми прерывания по всем ядрам
o оппортунистический опрос сетевых интерфейсов
* После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений
Thrift
Что это?
* Легкий механизм построения приложений с использованием нескольких языков программирования
* Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.
* Предоставляет язык описания интерфейсов, статический генератор кода
* Поддерживаемые языки: C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell и многие другие
* Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)
* Протоколы: стандарты сериализации (бинарный, JSON)
* Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные
Почему именно Thrift?
* Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers — но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию
* Он быстрый, очень быстрый
* Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы
* Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями
* Общий инструментарий, знакомый всем разработчикам
Scribe
Что это?
* Масштабированный распределенный механизм ведения логов
* Перемещает данные с серверов в центральный репозиторий
* Широкая сфера применения:
o Логи поисковых запросов
o Публикации в новостных лентах
o Данные по A/B тестированиям
* Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных
* Простая модель данных
* Построен на основе Thrift
Хранение фотографий
Сначала сделали это просто:
* Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
* Загрузка с сервера: изображения отдаются из NFS через HTTP
* NFS построена на коммерческих продуктах
* Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
* На самом деле оказалось, что:
o Файловые системы непригодны для работы с большим количеством небольших файлов
o Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
o Ограничивающим фактором является ввод-вывод, а не плотность хранения
Потом начали оптимизировать:
* Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
* Распределение их по CDN для уменьшения сетевых задержек
* Возможно сделать еще лучше:
o Хранение изображений в больших бинарных файлах (blob)
o Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
o Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»
Другие сервисы
* SMC: консоль управления сервисами — централизованная конфигурация, определение на какой физической машине работает логический сервис
* ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
* Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
* И еще около 50 других сервисов.
В Контакте — крупнейшая в Рунете социальная сеть, российский аналог сервиса Facebook. По данным Alexa Internet - второй по посещаемости сайт России, второй на Украине и в Белоруссии, четвёртый в Казахстане, 34-й в мире. Сайт изначально позиционировал себя в качестве социальной сети студентов и выпускников элитных российских высших учебных заведений, позднее — как универсальный способ связи для всех социальных групп и возрастов. В январе 2009 года «В Контакте» впервые обогнал по посещаемости в России своего главного конкурента — «Одноклассники». А уже в апреле на сайт «В Контакте» зашло 14,3 миллиона уникальных российских пользователей, тогда как на «Одноклассники» — 7,8 миллиона, что почти в 2 раза меньше.
Платформа
* Debian Linux — основная операционная система
* nginx — балансировка нагрузки
* PHP + XCache
* Apache + mod_php
* memcached
* MySQL
* Собственная СУБД на C
* node.js — прослойка для реализации XMPP, живет за HAProxy
* Изображения отдаются просто с файловой системы xfs
* ffmpeg — конвертирование видео
Статистика
* 95 миллионов учетных записей
* 40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
* 11 миллиардов запросов в день
* 200 миллионов личных сообщений в день
* Видеопоток достигает 160Гбит/с
* Более 10 тысяч серверов, из которых только 32 — фронтенды на nginx (количество серверов с Apache неизвестно)
* 30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
* Каждый день выходит из строя около 10 жестких дисков
Архитектура
Общие принципы
* Cервера многофункциональны и используются одновременно в нескольких ролях:
o Перебрасывание полуавтоматическое
o Требуется перезапускать daemon'ы
* Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие — использование собственной СУБД вместо MySQL
* При балансировке нагрузки используются:
o Взвешенный round robin внутри системы
o Разные сервера для разных типов запросов
o Балансировка на уровне ДНС на 32 IP-адреса
* Большая часть внутреннего софта написано самостоятельно, в том числе:
o Собственная СУБД (см. ниже)
o Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс
)
o Автоматическая система тестирования кода
o Анализаторы статистики и логов
* Мощные сервера:
o 8-ядерные процессоры Intel (по два на сервер, видимо)
o 64Гб оперативной памяти
o 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
o RAID не используется
o Не брендированные, собирает компания ТехноОкта
* Вычислительные мощности серверов используются менее, чем на 20%
* Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
o Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
o В Московских датацентрах только аудио и видео
o В планах сделать репликацию базы данных в другой датацентр в ленинградской области
* CDN на данный момент не используется, но в планах есть
* Резервное копирование данных происходит ежедневно и инкрементально
База данных на C
Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он, собственно говоря, собой представляет, так и не было обнародовано. Известно, что:
* Разработана «лучшими умами» России:
o Андрей Лопатин
o Николай Дуров
o Арсений Смирнов
o Алексей Левин
* Используется в огромном количестве сервисов:
o Личные сообщения
o Сообщения на стенах
o Статусы
o Поиск
o Приватность
o Списки друзей
* Нереляционная модель данных
* Большинство операций осуществляется в оперативной памяти
* Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
* Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
* Кластеризация осуществляется легко
* Есть репликация
* Если честно, я так и не понял зачем им MySQL с такой штукой — возможно просто как legacy живет со старых времен
Аудио и видео
Эти подпроекты являются побочными для социальной сети, на них особо не фокусируются. В основном это связанно с тем, что они редко коррелируют с основной целью использования социальной сети — общением, а также создают большое количество проблем: видеотраффик — основная статья расходов проекта, плюс всем известные проблемы с нелегальным контентом и претензиями правообладателей. Медиа-файлы банятся по хэшу при удалении по просьбе правообладателей, но это неэффективно и планируется усовершенствовать этот механизм.
1000—1500 серверов используется для перекодирования видео, на них же и хранится.
XMPP
Некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.
По ряду причин, среди которых проблемы с интеграцией с остальными сервисами, было решено за месяц создать собственный сервер, представляющий собой прослойку между внутренними сервисами Вконтакте и реализацией XMPP протокола. Основные особенности этого сервиса:
* Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
* Работа с большими контакт-листами — у многих пользователей количество друзей на вконтакте измеряется сотнями и тысячами
* Высокая активность смены статусов — люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
* Аватарки передаются в base64
* Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
* 60-80 тысяч человек онлайн, в пике — 150 тысяч
* HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
* Данные хранятся в MySQL (думали о MongoDB, но передумали)
* Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на node.js (по 4 процесса на сервер), а на трех самых мощных — еще и MySQL
* В node.js большие проблемы с использованием OpenSSL, а также течет память
* Группы друзей в XMPP не связаны с группами друзей на сайте — сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся
Интеграция со внешними ресурсами
Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:
* Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
* Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
* Кнопка «поделиться с друзьями», поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
* Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими
«Facebook» — социальная сеть, основанная в 2004 году Марком Цукербергом и его соседями по комнате во время обучения в Гарвардском университете Эдуардо Саверином, Дастином Московицем и Крисом Хьюзом. Благодаря своему сайту Марк Цукерберг стал самым молодым миллиардером в свои 23 года.
Первоначально веб-сайт был назван thefacebook.com (позже изменён на современный вариант facebook) и открыт только для студентов Гарвардского Университета, затем доступ был расширен для других университетов Бостона, а затем и для студентов любых учебных учреждений США, имеющих электронный адрес с доменом .edu. Начиная с сентября 2006 года сайт был открыт для всех пользователей в возрасте от 13 лет, имеющих электронную почту. По состоянию на 21 июля 2010 года Facebook насчитывает более 500 миллионов пользователей по всему миру. При этом количество уникальных посетителей сайта в апреле 2010 года составило 540 млн, а количество просмотров страниц — 570 млрд. Прибыль Facebook за 2009 год по собственной оценке компании составила 700 млн долларов США.
Платформа
* Linux — операционная система
* PHP с HipHop — код на PHP компилируется в C++
* memcached — агрессивное кэширование объектов
* MySQL — используется как хранилище пар ключ-значение, никаких join'ов
* Thrift — интерфейс взаимодействия между сервисами, написанными на разных языках программирования
* Scribe — универсальная система сбора и агрегации данных с рабочих серверов
Статистика
* Более 500 миллионов активных пользователей (месячная аудитория)
* Более миллиарда социальных связей
* Более 200 миллиардов просмотров страниц в месяц
* Более 4 триллионов действий попадает в новостные ленты каждый день
* Более 150 миллионов обращений к кэшу в секунду; 2 триллиона объектов в кэше
* Более 8 миллиардов минут провели пользователи на Facebook'е ежедневно
* Более 3 миллиардов фотографий загружается каждый месяц, до 1.2 миллиона фотографий в секунду
* 20 миллиардов фотографий в 4 разрешениях = 80 миллиардов фотографий, их бы хватило чтобы покрыть поверхность земли в 10 слоев; это больше, чем на всех других фото-ресурсах в месте взятых
* О более чем 5 миллиардах единиц контента рассказывается друзьям еженедельно
* Более миллиарда сообщений в чате каждый день
* Более ста миллионов поисковых запросов в день
* Более 250 приложений и 80 тысяч сторонних ресурсов на платформе Facebook Connect
* Более 400 тысяч разработчиков сторонних приложений
* Менее 500 разработчиков и системных администраторов в штате
* Более миллиона активных пользователей на одного инженера
* Десятки тысяч серверов, десятки гигабит трафика
Архитектура
Общие принципы
* Балансировщик нагрузки выбирает веб-сервер для обработки запроса
* PHP-код в веб-сервере подготавливает HTML, пользуясь данными из различных источников:
o MySQL
o memcached
o Специализированные сервисы
* Если взглянуть с другой стороны, то получим трехуровневую архитектуру:
o Вер-приложение
o Распределенный индекс
o Постоянное хранилище
* Использование открытых технологий там, где это возможно
* Поиск возможностей оптимизации используемых продуктов
* Философия Unix:
o Старайтесь делать каждый компонент системы простым и производительным
o Комбинируйте компоненты для решения задач
o Концентрируйте внимание на хорошо обозначенных точках взаимодействия
* Все усилия направлены на масштабируемость
* Попытки минимизации количества точек отказа
* Простота.
PHP
Почему PHP?
* Во многом «так исторически сложилось»
* Хорошо подходит для веб-разработки
* Легок в изучении: небольшой набор выражений и языковых конструкций
* Легок в написании: нестрогая типизация и универсальный «массив»
* Легок в чтении: синтаксис похож на C++ и Java
* Прост в дебаггинге: нет необходимости в перекомпиляции
* Большой ассортимент библиотек, актуальных для веб-проектов
* Подходит для процесса разработки с короткими итерациями
* Активное сообщество разработчиков по всему миру
* Динамическая типизация, интерпретируемый язык для скриптов
Как оказалось на самом деле?
* Высокий расход оперативной памяти и вычислительных ресурсов
* Сложно работать, когда объем исходного кода очень велик: слабая типизация и ограниченные возможности для статичного анализа и оптимизации кода
* Не особо оптимизирован для использования в крупных проектах
* Линейный рост издержек при подключении файлов с исходным кодом
* Механизм разработки расширений не очень удобен
Доработки:
* Оптимизация байт-кода
* Улучшения в APC (ленивая загрузка, оптимизация блокировок, «подогрев» кэша)
* Свои расширения (клиент memcache, формат сериализации, логи, статистика, мониторинг, механизм асинхронной обработки событий)
* HipHop — трансформатор исходных кодов:
o Разработчики пишут на PHP, который конвертируется в оптимизированный C++
o Статический анализ, определение типов данных, генерация кода, и.т.д.
o Облегчает разработку расширений
o Существенно сокращает расходы оперативной памяти и вычислительных ресурсов
o У команды из трех программистов ушло полтора года на разработку, переписаны большая часть интерпретатора и многие расширения языка
o Опубликован под opensource лицензией в начале года, нет необходимости проходить этот же путь с нуля
MySQL
Как используется MySQL?
* Используется как хранилище пар ключ-значение
* Большое количество логических узлов распределено между физическими машинами
* Балансировка нагрузке на уровне физических серверов
* Репликация для распределения операций чтения не используется
* Большинство запросов касаются самой свежей информации: оптимизация таблиц для доступа к новым данным, архивация старых записей
* В целом быстро и надежно
Как оказалось на самом деле?
* Логическая миграция данных очень сложна
* Создавать большое количество логических баз данных и перераспределять их между физическими узлами, балансируя таким образом нагрузку, намного удобнее
* Никаких join'ов на рабочих серверах баз данных
* Намного проще наращивать вычислительные мощности на веб-серверах, чем на серверах баз данных
* Схемы, основанные на структуре данных, делают программистов счастливыми и создают большую головную боль администраторам
* Никогда не храните не-статичные данные в централизованное базе данных
Доработки:
* Практически никаких модификаций исходного кода MySQL
* Своя схема партиционирования с глобально-уникальными идентификаторами
* Своя схема архивирования, основанная на частоте доступа к данным относительно каждого пользователя
* Расширенный движок запросов для репликации между датацентрами и поддержания консистенции кеша
* Библиотеки для доступа к данным на основе графа:
o Объекты (вершины графа) с ограниченными типами данных (целое число, строка ограниченно длины, текст)
o Реплицированные связи (ребра графа)
o Аналоги распределенных внешних ключей (foreign keys)
o Большинство данных распределено случайно
Memcache
Как используется memcached?
* Высокопроизводительная распределенная хэш-таблица
* Содержит «горячие» данные из MySQL
* Снижает нагрузку на уровень баз данных
* Основная форма кэширования
* Используется более 25TB памяти на нескольких тысячах серверов
* Среднее время отклика менее 250 микро-секунд
* Кэшируются сериализованные структуры данных PHP
* Отсутствие автоматического механизма проверки консистенции данных между memcached и MySQL — приходится делать это на уровне программного кода
* Множество multi-get запросов для получения данных на другом конце ребер графа
* Ограниченная модель данных, неэффективен для маленьких объектов
Доработки:
* Порт на 64-битную архитектуру
* Более эффективная сериализация
* Многопоточность
* Улучшенный протокол
* Компрессия
* Проксирование запросов
* Доступ к memcache через UDP:
o уменьшает расход памяти благодаря отсутствию тысяч буферов TCP соединений
o управление ходом исполнения приложение (оптимизация для multi-get)
* Статистика о работе потоков по запросу — уменьшает блокировки
* Ряд изменений в ядре Linux для оптимизации работы memcache:
o распределение управления сетевыми прерывания по всем ядрам
o оппортунистический опрос сетевых интерфейсов
* После вышеперечисленных модификаций memcached способен выполнять до 250 тысяч операций в секунду, по сравнению со стандартными 30-40 тысячами без данных изменений
Thrift
Что это?
* Легкий механизм построения приложений с использованием нескольких языков программирования
* Высокая цель: предоставить механизм прозрачного взаимодействия между языками программирования.
* Предоставляет язык описания интерфейсов, статический генератор кода
* Поддерживаемые языки: C++, PHP, Python, Java, Ruby, Erlang, Perl, Haskell и многие другие
* Транспорты: простой интерфейс для ввода-вывода (сокеты, файлы, буферы в памяти)
* Протоколы: стандарты сериализации (бинарный, JSON)
* Серверы: неблокирующие, асинхронные, как однопоточные, так и многопоточные
Почему именно Thrift?
* Альтернативные технологии: SOAP, CORBA, COM, Pillar, Protocol Buffers — но у всех есть свои существенные недостатки, что вынудило Facebook создать свою технологию
* Он быстрый, очень быстрый
* Меньше рабочего времени тратится каждым разработчиком на сетевые интерфейсы и протоколы
* Разделение труда: работа над высокопроизводительными серверами ведется отдельно от работы над приложениями
* Общий инструментарий, знакомый всем разработчикам
Scribe
Что это?
* Масштабированный распределенный механизм ведения логов
* Перемещает данные с серверов в центральный репозиторий
* Широкая сфера применения:
o Логи поисковых запросов
o Публикации в новостных лентах
o Данные по A/B тестированиям
* Более надежен, чем традиционные системы логгирования, но недостаточно надежен для транзакций баз данных
* Простая модель данных
* Построен на основе Thrift
Хранение фотографий
Сначала сделали это просто:
* Загрузка на сервер: приложение принимает изображение, создает миниатюры в нужных разрешениях, сохраняет в NFS
* Загрузка с сервера: изображения отдаются из NFS через HTTP
* NFS построена на коммерческих продуктах
* Это было необходимо, чтобы сначала проверить, что продукт востребован пользователями и они правда будут активно загружать фотографии
* На самом деле оказалось, что:
o Файловые системы непригодны для работы с большим количеством небольших файлов
o Метаданные не помещаются в оперативную память, что приводит к дополнительным обращениям к дисковой подсистеме
o Ограничивающим фактором является ввод-вывод, а не плотность хранения
Потом начали оптимизировать:
* Кэширование более часто используемых миниатюр изображений в памяти на оригинальных серверах для масштабируемости, надежности и производительности
* Распределение их по CDN для уменьшения сетевых задержек
* Возможно сделать еще лучше:
o Хранение изображений в больших бинарных файлах (blob)
o Сервис, отвечающий за фотографии имеет информацию о том, в каком файле и с каким отступом от начала расположена каждая фотография (по ее идентификатору)
o Этот сервис в Facebook называется Haystack и он оказался в 10 раз эффективнее «простого» подхода и в 3 раза эффективнее «оптимизированного»
Другие сервисы
* SMC: консоль управления сервисами — централизованная конфигурация, определение на какой физической машине работает логический сервис
* ODS: инструмент для визуализации изменений любых статистических данных, имеющихся в системе; удобен для мониторинга и оповещений
* Gatekeeper: разделение развертывания и запуска, A/B тестирования, таргетированный запуск, постепенный запуск
* И еще около 50 других сервисов.
В Контакте — крупнейшая в Рунете социальная сеть, российский аналог сервиса Facebook. По данным Alexa Internet - второй по посещаемости сайт России, второй на Украине и в Белоруссии, четвёртый в Казахстане, 34-й в мире. Сайт изначально позиционировал себя в качестве социальной сети студентов и выпускников элитных российских высших учебных заведений, позднее — как универсальный способ связи для всех социальных групп и возрастов. В январе 2009 года «В Контакте» впервые обогнал по посещаемости в России своего главного конкурента — «Одноклассники». А уже в апреле на сайт «В Контакте» зашло 14,3 миллиона уникальных российских пользователей, тогда как на «Одноклассники» — 7,8 миллиона, что почти в 2 раза меньше.
Платформа
* Debian Linux — основная операционная система
* nginx — балансировка нагрузки
* PHP + XCache
* Apache + mod_php
* memcached
* MySQL
* Собственная СУБД на C
* node.js — прослойка для реализации XMPP, живет за HAProxy
* Изображения отдаются просто с файловой системы xfs
* ffmpeg — конвертирование видео
Статистика
* 95 миллионов учетных записей
* 40 миллионов активных пользователей во всем мире (сопоставимо с аудиторией интернета в России)
* 11 миллиардов запросов в день
* 200 миллионов личных сообщений в день
* Видеопоток достигает 160Гбит/с
* Более 10 тысяч серверов, из которых только 32 — фронтенды на nginx (количество серверов с Apache неизвестно)
* 30-40 разработчиков, 2 дизайнера, 5 системных администраторов, много людей в датацентрах
* Каждый день выходит из строя около 10 жестких дисков
Архитектура
Общие принципы
* Cервера многофункциональны и используются одновременно в нескольких ролях:
o Перебрасывание полуавтоматическое
o Требуется перезапускать daemon'ы
* Генерация страниц с новостями (микроблоги) происходит очень похожим образом с Facebook (см. Архитектура Facebook), основное отличие — использование собственной СУБД вместо MySQL
* При балансировке нагрузки используются:
o Взвешенный round robin внутри системы
o Разные сервера для разных типов запросов
o Балансировка на уровне ДНС на 32 IP-адреса
* Большая часть внутреннего софта написано самостоятельно, в том числе:
o Собственная СУБД (см. ниже)
o Мониторинг с уведомлением по СМС (Павел сам помогал верстать интерфейс
)o Автоматическая система тестирования кода
o Анализаторы статистики и логов
* Мощные сервера:
o 8-ядерные процессоры Intel (по два на сервер, видимо)
o 64Гб оперативной памяти
o 8 жестких дисков (соответственно скорее всего корпуса 2-3U)
o RAID не используется
o Не брендированные, собирает компания ТехноОкта
* Вычислительные мощности серверов используются менее, чем на 20%
* Сейчас проект расположен в 4 датацентрах в Санкт-Петербурге и Москве, причем:
o Вся основная база данных располагается в одном датацентре в Санкт-Петербурге
o В Московских датацентрах только аудио и видео
o В планах сделать репликацию базы данных в другой датацентр в ленинградской области
* CDN на данный момент не используется, но в планах есть
* Резервное копирование данных происходит ежедневно и инкрементально
База данных на C
Этому продукту, пожалуй, уделялось максимум внимания аудитории, но при этом почти никаких подробностей о том, что он, собственно говоря, собой представляет, так и не было обнародовано. Известно, что:
* Разработана «лучшими умами» России:
o Андрей Лопатин
o Николай Дуров
o Арсений Смирнов
o Алексей Левин
* Используется в огромном количестве сервисов:
o Личные сообщения
o Сообщения на стенах
o Статусы
o Поиск
o Приватность
o Списки друзей
* Нереляционная модель данных
* Большинство операций осуществляется в оперативной памяти
* Интерфейс доступа представляет собой расширенный протокол memcached, специальным образом составленные ключи возвращают результаты сложных запросов (чаще всего специфичных для конкретного сервиса)
* Хотели бы сделать из данной системы универсальную СУБД и опубликовать под GPL, но пока не получается из-за высокой степени интеграции с остальными сервисами
* Кластеризация осуществляется легко
* Есть репликация
* Если честно, я так и не понял зачем им MySQL с такой штукой — возможно просто как legacy живет со старых времен
Аудио и видео
Эти подпроекты являются побочными для социальной сети, на них особо не фокусируются. В основном это связанно с тем, что они редко коррелируют с основной целью использования социальной сети — общением, а также создают большое количество проблем: видеотраффик — основная статья расходов проекта, плюс всем известные проблемы с нелегальным контентом и претензиями правообладателей. Медиа-файлы банятся по хэшу при удалении по просьбе правообладателей, но это неэффективно и планируется усовершенствовать этот механизм.
1000—1500 серверов используется для перекодирования видео, на них же и хранится.
XMPP
Некоторое время назад появилась возможность общаться на Вконтакте через протокол Jabber (он же XMPP). Протокол совершенно открытый и существует масса opensource реализаций.
По ряду причин, среди которых проблемы с интеграцией с остальными сервисами, было решено за месяц создать собственный сервер, представляющий собой прослойку между внутренними сервисами Вконтакте и реализацией XMPP протокола. Основные особенности этого сервиса:
* Реализован на node.js (выбор обусловлен тем, что JavaScript знают практически все разработчики проекта, а также хороший набор инструментов для реализации задачи)
* Работа с большими контакт-листами — у многих пользователей количество друзей на вконтакте измеряется сотнями и тысячами
* Высокая активность смены статусов — люди появляются и исчезают из онлайна чаще, чем в других аналогичных ситуациях
* Аватарки передаются в base64
* Тесная интеграция с внутренней системой обмена личными сообщениями Вконтакте
* 60-80 тысяч человек онлайн, в пике — 150 тысяч
* HAProxy обрабатывает входящие соединения и используется для балансировки нагрузки и развертывания новых версий
* Данные хранятся в MySQL (думали о MongoDB, но передумали)
* Сервис работает на 5 серверах разной конфигурации, на каждом из них работает код на node.js (по 4 процесса на сервер), а на трех самых мощных — еще и MySQL
* В node.js большие проблемы с использованием OpenSSL, а также течет память
* Группы друзей в XMPP не связаны с группами друзей на сайте — сделано по просьбе пользователей, которые не хотели чтобы их друзья из-за плеча видели в какой группе они находятся
Интеграция со внешними ресурсами
Во Вконтакте считают данное направление очень перспективным и осуществляют массу связанной с этим работы. Основные предпринятые шаги:
* Максимальная кроссбраузерность для виджетов на основе библиотек easyXDM и fastXDM
* Кросс-постинг статусов в Twitter, реализованный с помощью очередей запросов
* Кнопка «поделиться с друзьями», поддерживающая openGraph теги и автоматически подбирающая подходящую иллюстрацию (путем сравнивание содержимых тега <title> и атрибутов alt у изображений, чуть ли не побуквенно)
* Возможность загрузки видео через сторонние видео-хостинги (YouTube, RuTube, Vimeo, и.т.д.), открыты к интеграции с другими
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.
4 года 4 мес. назад - 4 года 4 мес. назад #5
от Aleksej
Aleksej ответил в теме Как устроены Facebook и Vkontakte
В блоге опубликован
краткий анонс
нового приложения Вконтакте... вполне возможно, что по окончании разработки смогу добавить кое-что новое к содержащейся в данном топике инфе. А может быть и нет, посмотрим. 
Пожалуйста Войти или Регистрация, чтобы присоединиться к беседе.