Национальная библиотека им. Н. Э. Баумана
Bauman National Library
Персональные инструменты
Stack Overflow
Stack Overflow – это сайт вопросов и ответов для профессиональных разработчиков программного обеспечения, энтузиастов программирования и системных администраторов. Сайт создан и управляется сообществом. Сервис создает свободную библиотеку подробных ответов на любой прикладной вопрос по программированию и системному администрированию. [Источник 1]
Содержание
Информация с официального сайта
Вопрос – ответ. Ничего лишнего.
Это сайт вопросов и ответов для профессиональных программистов и энтузиастов. Он построен таким образом чтобы каждый мог найти для себя ответ.
С помощью пользователей создается библиотека подробных ответов на каждый вопрос о программировании.
Лучшие ответы поднимаются наверх, чтобы их было легче найти.
Автор вопроса может пометить один из ответов «принятым».
Принятие ответа не означает, что он лучший; это значит, что изложенное в нём решение помогло автору вопроса.
Получайте ответы на детализированные и конкретные вопросы
Вопросы задаются о реальной проблеме, с которой столкнулись пользователи. Описание проводится детально, описываются все цели и пути к ним.
Не все вопросы хорошо вписываются в наш формат. Избегайте вопросов, которые сильно зависят от мнения отвечающего или тех, которые способны спровоцировать обсуждение вместо ответов.
Вопросы, которые необходимо улучшить могут оставаться закрытыми, пока их не исправят.
Не задавайте вопросы…
Метки упрощают поиск интересных вопросов
Все вопросы отмечены метками в соответствии с их тематикой. Каждый вопрос может иметь до пяти меток, если он относится сразу к нескольким тематикам.
Нажмите на метку, чтобы увидеть все вопросы с ней, или просмотрите список меток, чтобы найти интересующую вас тему.
Ваша репутация растет, когда люди голосуют за ваши сообщения.
Репутация растет, когда другие участники голосуют за вопросы, ответы и правки.
По мере получения репутации участнику будут открываться новые привилегии, например возможность голосовать, комментировать и даже редактировать сообщения других участников.
Заработав большую репутацию, каждый участник получит доступ к специальным инструментам модератора. Пользователь сможет работать вместе с модераторами сообщества, чтобы следить за порядком на сайте.
Улучшайте сообщения с помощью правок или комментариев
Цель сервиса – собрать лучшие ответы на все вопросы, поэтому, если вам попадутся сообщения, требующие улучшения, вы можете отредактировать их.
Используйте редактирование для исправления ошибок, улучшения форматирования и разъяснения смысла сообщения.
Используйте комментарии, чтобы получить дополнительную информацию или уточнить вопрос или ответ.
Вы всегда можете оставлять комментарии под своими вопросами и ответами. Когда репутация достигнет 50, каждый участник сможет комментировать сообщения других участников.
Получайте знаки за достижения
Знаки – это достижения, полученные за участие в жизни сайта. Они бывают трёх видов: бронзовые, серебряные и золотые.
Собственно, каждый может получить знак, просто прочитав данную страницу. [Источник 1]
Компания
Основанное в 2008 году, Stack Overflow является крупнейшим и наиболее надежным онлайн-сообществом, в котором разработчики могут учиться, делиться своими знаниями и строить свою карьеру. Более 50 миллионов профессиональных и начинающих программистов посещают Stack Overflow каждый месяц, чтобы помочь решить проблемы кодирования, развить новые навыки и найти рабочие места.
Stack Overflow сотрудничает с предприятиями, чтобы помочь им понять, нанять, привлечь и помочь разработчикам со всего мира. Продукты и услуги ориентированы на маркетинг для разработчиков, технический рекрутинг, исследования рынка и обмен корпоративными знаниями.
Stack Overflow входит в сеть так называемых Stack Exchange сайтов, список которых можно видеть далее. [Источник 2]
Офисы
В Stack Overflow в настоящее время работают более 250 человек в головных офисах в Нью-Йорке, Лондоне и Мюнхене, а также удаленные работники из Израиля, Бразилии, Японии, Германии, Словении, Испании, Польши, Франции, России, Канады, Великобритании и других стран. Компания стремится к разнообразию на рабочем месте и в настоящее время нанимает на работу. [Источник 2]
История
История начинается в 2008 году, когда Джоэл Спольски, тогдашний генеральный директор Fog Creek Software и автор широко читаемого блога Joel on Software под названием Джефф Этвуд, также известный своим популярным блогом Coding Horror, решил создать сайт вопросов и ответов. Джоэл Спольски и Джефф Этвуд вместе запускают Stack Overflow.
В 2010 году серия инвестиция в размере 6 млн. долларов США во главе с Union Square Ventures. Запускается Stack Exchange Network, распределяя вопросы и ответы в стиле Stack Overflow по новым темам (в настоящее время 133).
В 2012 году Stack Overflow Careers запускает свой первый локализованный сайт для говорящих на немецком языке (год спустя к нему добавится французский).
В 2014 году появляются мобильные приложения для Android и iOS. В этом же году Stack Overflow запускает локализованные сайты на португальском и японском языках.
Архитектура сервиса
Чтобы понять, как работает сервис, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2016 года:
Из-за модернизации оборудования в начале 2015 года и из-за некоторого изменения параметров в самих приложениях существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день.
Вот укрупненный список хардверной части, которая обеспечивает работу ресурса:
Чтобы запустить Stack Overflow необходим только один web-сервер.
Теперь, когда у нас есть некоторые числа для понятия масштаба, давайте рассмотрим, как это присходит. Так как немногие системы работают в полной изоляции, часто конкретные архитектурные решения почти не имеют смысла без общей картины того, как эти части взаимодействуют между собой.
На рисунке 1 представлена логическая схема взаимодействия главных систем:
Рисунок 1 – логическая схема взаимодействия главных систем
Вот некоторые всеобще применяемые правила, поэтому буду повторять их для каждой системы:
В сети Интернет
Сначала Вы должны найти сайт – это DNS. Процесс нахождения нас должен быть быстрым, поэтому этим занимается CloudFlare, так как их серверы DNS ближе почти всех остальных DNS мира. Записи DNS обновляются через API, а они делают «хостинг» DNS. Однако, при этом, сервис имеет собственные DNS-сервера. Если произойдет апокалипсис (вероятно, вызванный GPL, Punyon или кэшированием), а люди все еще будут хотеть программировать, чтобы не думать о нем, сервис переключится на них.
После того, как Вы найдете Stack Overflow, пойдет HTTP-трафик через одного из четырех Интернет провайдеров (Level 3, Zayo, Cogent, и Lightower в Нью-Йорке), и через один из наших четырех локальных маршрутизаторов. Для достижения максимальной эффективности, вместе с провайдерами используется BGP для управления трафиком и обеспечения нескольких путей его передачи. Маршрутизаторы ASR-1001 и ASR-1001-X объединены в 2 пары, каждая из которых обслуживает 2 провайдера в режиме активный/активный. Таким образом, обеспечивается резервирование. Хотя они подключены все к той же физической сети 10 Гбит/с, внешний трафик проходит по отдельным изолированным внешним VLAN, которые также подключены к балансировщикам нагрузки. После прохождения через маршрутизаторы, трафик направляется к балансировщикам нагрузки.
Между двумя дата-центрами используется линия MPLS на 10 Гбит/с, но это напрямую не связано с обслуживанием сайта. Она служит для дублирования данных и их быстрого восстановления в случаях, когда нужна пакетная передача. Через провайдеров имеется еще две более отказоустойчивые линии OSPF (по стоимости MPLS – № 1, а это № 2 и 3). Каждое из упомянутых устройств быстрее подключается к соответствующему устройству в Колорадо, и при отказе они распределяют между собой сбалансированный трафик. Разработчики смогли заставить оба устройства соединяться с обоими устройствами 4-мя способами, но все они и так одинаково хороши. [Источник 3]
Балансировщики нагрузки (HAProxy)
Балансировщики нагрузки работают на HAProxy 1.5.15 под CentOS 7, предпочтительной разновидности Linux. HAProxy также ограничивает и трафик TLS (SSL).
В отличие от всех других серверов с двойным сетевым подключением по LACP 10 Гбит/с, каждый балансировщик нагрузки имеет по 2 пары каналов 10 Гбит/с: одну для внешней сети и одну для DMZ. Для более эффективного управляемого согласования SSL эти «коробки» имеют память 64 ГБ или больше. Когда можно кэшировать в памяти больше сессий TLS для повторного использования, тратится меньше времени на образование нового соединения с тем же самым клиентом. Это означает, что можно возобновлять сессии и быстрее, и с меньшими затратами. Учитывая, что RAM в переводе на доллары довольно дешевая, это – легкий выбор.
Сами балансировщики нагрузки – довольно простые устройства. Создается иллюзия, что разные сайты «сидят» на различных IP (в основном по вопросам сертификации и управления DNS), и маршрутизируются на различные выходные буфера основываясь, главным образом, на заголовках хоста. Единственными «знаменитыми» вещами, которые осуществляются, является ограничение скорости и некоторые захваты заголовков (отсылаемых с уровня веб-узлов) в сообщение системного журнала HAProxy. Поэтому можно делать запись метрик производительности для каждого запроса. [Источник 3]
На чем написан stackoverflow
Stack Overflow является любимым многими программистами сайтом, где можно задать профессиональный вопрос и получить ответы от коллег. Этот проект был написан двумя никому не известными парнями, о которых никто никогда раньше не слышал. Хорошо, не совсем так. Stack Overflow был создан топовыми программистами и звездами блогосферы: Jeff Atwood и Joel Spolsky. В этом отношении Stack Overflow похож на ресторан, владельцами которого являются знаменитости. По оценкам Joel’а около 1/3 программистов всего мира использовали этот интернет-ресурс, так что должно быть он представляет собой что-то достаточно полезное и интересное.
Одним из ключевых моментов в истории Stack Overflow является использование вертикального масштабирования, как достаточно работоспособного решения достаточного большого класса проблем. Не смотря на то, что публика на сегодняшний день больше склоняется к подходу с использованием горизонтальным масштабирования и не-SQL баз данных.
Joel любит похвастаться тем, что они достигли производительности, сравнимой с другими сайтами аналогичных размеров, используя в 10 раз меньше оборудования. Он удивляется, работали над этими сайтами по-настоящему хорошие программисты. Давайте взглянем на то, как им это удалось, и дадим Вам возможность побыть судьей.
Статистика
Стратегия монетизации: ненавязчивая реклама, вакансии, конференции DevDays, достижения других смежных ниш (Server Fault, Super User), разработка StackExchange и возможно каких-то других систем рейтингов для программистов.
Платформа
Уровень базы данных:
Четвертый сервер был добавлен для запуска superuser.com. Все сервера вместе обеспечивают работу Stack Overflow, Server Fault, и Super User.
Подводим итоги
Данный список является сборником уроков от Jeff и Joel, а также из комментариев к их записям:
Архитектура Stack Overflow версия 2016
Авторизуйтесь
Архитектура Stack Overflow версия 2016
Данная публикация является первой в серии, посвященной архитектуре Stack Overflow. Рады приветствовать.
Чтобы получить представление о том, как все работает, начну со среднестатистических данных Stack Overflow за день. Для того чтобы вы могли сравнить текущие данные с предыдущими, — по состоянию на ноябрь 2013 года, — привожу показатели за 9.02.2016 и их отличие от статистики на 12.11.2013.
Вас может удивить резкое падение времени обработки для ASP.NET по сравнению с 2013 годом (на тот момент оно составляло 757 часов) на фоне увеличения количества запросов на 61 млн. в день. Этому есть две причины: обновление аппаратного обеспечения в начале 2015 года, и серьезная работа по настройке производительности самих приложений. Не стоит забывать: производительность важна. Если вы хотите узнать об аппаратном обеспечении больше — не беспокойтесь, в следующей публикации мы предоставим детальную спецификацию аппаратного обеспечения для всех серверов, используемых сайтами (ссылку на материалы я предоставлю, как только они будут опубликованы).
Итак, что изменилось за последние два года? Кроме замены некоторых серверов и сетевого оборудования, не так уж и много. Вот список аппаратного обеспечения, на котором работают сайты в настоящий момент (с указанием отличий от 2013 г.):
Что же нам нужно для работы Stack Overflow? По сравнению с 2013-м годом изменилось немногое, но в связи с оптимизацией и упомянутым обновлением аппаратного обеспечения, все, что нам нужно — один-единственный веб-сервер. Благодаря случаю, мы уже несколько раз успешно это проверили. Уточню: я лишь говорю, что это работает, я не утверждаю, что работа на одном сервере — удачное решение, но каждый раз этот факт меня поражает.
Теперь, когда у нас есть исходные данные, которые позволяют понять общие масштабы, посмотрим, как мы генерируем наши замечательные веб-страницы. Поскольку не многие системы могут существовать обособленно (и наша — не исключение), архитектурные решения часто теряют смысл без ясного понимания того, каким образом компоненты системы должны взаимодействовать в контексте единого целого. Цель публикации — дать полную картину, полное представление о системе. Частные вопросы её работы будут подробнейшим образом рассмотрены во многих последующих публикациях. Данная публикация представляет собой общий обзор аппаратного обеспечения, а уже в следующей, я остановлюсь на спецификациях устройств более детально.
Для тех из вас, кто хотел бы узнать, как выглядит современное «железо», я сделал несколько снимков стойки А (у которой есть сестра-близнец, стойка В) во время нашего февральского обновления 2015-го года:
… а для фанатов — полный альбом тех дней, состоящий из 256 фотографий (да, вы правы, такое количество фотоснимков отнюдь не случайно). Теперь углубимся в конфигурацию. Ниже логический обзор основных используемых систем:
Основополагающие правила
Несколько правил, которые действуют всегда, и мы не будем повторять их перед каждым разделом: — У всего есть копия. — Все сервера и сетевое оборудование соединены как минимум 2 x 10Gbps. — Все сервера имеют по 2 независимых входа питания от 2 источников бесперебойного питания с 2 резервными генераторами и 2 вспомогательными входами питания. — Все сервера имеют резервную связь между стойками A и B. — Все сервера и сервисы продублированы в дата-центре в Колорадо (все остальное оборудование находится преимущественно в Нью-Йорке). — У всего есть копия.
Сеть Интернет
Сначала нас надо найти — а это DNS. И найти нас надо быстро, поэтому мы делегируем эту задачу (в данный момент) CloudFlare, поскольку их DNS-сервера расположены максимально близко к любому компьютеру в любой точке земного шара. Мы обновляем наши DNS-записи через API, которые выполняют задачу хостинга DNS. Поскольку мы настоящие параноики в том, что касается надежности соединения, мы, в дополнение, позаботились и о собственных DNS-серверах. И если в случае Апокалипсиса (причиной которого, вероятно, станет GPL, Punyon или кэширование) люди, чтобы отвлечься, все еще захотят программировать, мы будем в состоянии предоставить им качественную связь.
После того, как вы обнаруживаете наше тайное убежище, HTTP-трафик поступает от одного из четырех наших ISP (Level 3, Zayo, Cogent, и Lightower в Нью-Йорке) и направляется одним из наших четырех граничных маршрутизаторов. Мы взаимодействуем с ISP при помощи протокола BGP (довольно стандартного), контролируя поток трафика и обеспечивая несколько путей наиболее эффективного его приема. Маршрутизаторы ASR-1001 и ASR-1001-X работают попарно, при этом каждая пара обслуживает по 2 ISP в режиме «активный-активный» — резервное копирование обеспечено. Несмотря на то, что все они находятся в одной и той же физической сети пропускной способностью 10Gbps, внешний трафик идет через выделенные изолированные VLAN, к которым также подключены балансировщики нагрузки. Итак, после маршрутизаторов, трафик попадает на балансировщик нагрузки.
Думаю, сейчас самое время упомянуть, что между двумя нашими дата-центрами запущен сервис 10Gbps MPLS, однако, не задействованный непосредственно в обслуживании сайтов. Этот сервис мы используем для репликации данных и быстрого восстановления при возрастании нагрузки. «Но, Ник, где же здесь резервирование?» Что ж, теоретически вы правы (в лучшем смысле этого слова), тут мы ошиблись — на первый взгляд. Но подождите! У нас есть еще два отказоустойчивых маршрутизатора OSPF (MPLS идет под номером 1, два сервера OCPF — под номерами 2 и 3, в порядке убывания себестоимости), работающие у наших ISP. Каждая из упомянутых групп подсоединяется к соответствующей группе в Колорадо, и они делят между собой нагрузку в случае отказа. Мы могли бы связать обе группы с одной стороны и обеими группами с другой стороны, получив, таким образом, 4 пути, но… Неважно. Идем дальше.
Балансировщики нагрузки (HAProxy)
Балансировщики нагрузки используют HAProxy 1.5.15 на CentOS 7, нашей любимой версии Linux. Трафик TLS (SSL) также распределяется на HAProxy. Тем временем мы присматриваемся к HAProxy 1.7, который поддерживает HTTP/2.
В отличие от остальных серверов с дублированием сетевого подключения 10Gbps LACP, каждый балансировщик нагрузки имеет по 2 пары, пропускной способностью 10Gbps: одна для внешней сети и одна для DMZ. Для повышения эффективности SSL-взаимодействия в этих боксах использовано 64GB и более памяти. Поскольку мы можем кэшировать для повторного использования больше сессий TLS, сокращаются работа по вычислениям при повторных подключениях к клиенту. Это означает, что мы сможем восстанавливать сессии и быстрее, и дешевле. Учитывая довольно низкую стоимость RAM в рублевом эквиваленте, выбор был прост.
Сами по себе балансировщики нагрузки устанавливаются достаточно легко. Мы прослушиваем различные сайты на разных IP (в основном, в целях ознакомления с сертификатами и управления DNS) и направляем трафик на различные терминалы в зависимости от названия сетевых узлов (в основном). Единственный примечательный факт в этом — ограничение скорости и сохранение данных о названиях узлов (отправляемых с нашего web-уровня) в syslog-сообщении HAProxy, что позволяет нам записывать метрики производительности для каждого запроса. Позже мы на этом также остановимся.
Балансировщики нагрузки передают трафик на 9 серверов, которые мы называем основными (01-09) и на два «dev/meta»-сервера (10-11, наша вспомогательная среда). Основные сервера обеспечивают работу Stack Overflow, Careers и всех сайтов Stack Exchange, кроме meta.stackoverflow.com и meta.stackexchange.com, которые работают на последних двух серверах. Основное приложение, сервис вопросов и ответов – распределенное. Это означает, что одно приложение отвечает на запросы всех сайтов вопросов и ответов. Иными словами, вся сеть сайтов вопросов и ответов может функционировать на одном пуле приложения, находящемся на одном сервере. Остальные приложения, такие как Careers, API v2, Mobile API и т.п. обособлены. Вот как выглядит первичный уровень и dev-уровень в IIS:
Так выглядит распределение Stack Overflow по веб-уровню в Opserver (наша внутренняя панель мониторинга):
… а так выглядят сервера с точки зрения загрузки:
В следующих публикациях я подробнее остановлюсь на причинах подобной избыточности, а пока назову основное: загрузка программных версий, резерв мощности, резервное копирование.
За веб-серверами стоит очень похожий сервисный уровень. Он также использует IIS 8.5 на Windows 2012R2. Этот уровень задействует внутренние сервисы для обеспечения работы продуктового веб-уровня и других внутренних систем. Два основных игрока здесь — Stack Server, использующий сервер меток и http.sys (без привязки к IIS) и Providence API (на IIS). Забавный факт: я должен был установить соответствие, определяющее, что каждый из этих двух процессов должен обрабатываться отдельным процессором, потому что при обновлении списков вопросов Stack Server занимает всю кэш-память L2 и L3 примерно на 2 минуты.
Буферная память и Pub/Sub (Redis)
Мы используем Redis для выполнения нескольких функций: он надежен, как скала. Несмотря на внушительные 160 миллиардов операций в месяц, каждый экземпляр использует менее 2% CPU. Но обычно гораздо меньше:
В случае с Redis, мы имеем кэш-систему L1/L2. «L1» — это HTTP Cache на веб-серверах или на любом задействованном приложении. «L2» обращается к Redis и выбирает элемент данных. Наши данные хранятся в формате Protobuf — благодарим @Marc Gravell за его protobuf-dot-net. Для клиента мы используем StackExchange.Redis — написаного нами, общедоступного и бесплатного. Когда один веб–сервер получает непопадание сразу в кэш на L1 и на L2, он выбирает один элемент из источника данных (запрос базы данных, API-вызов и т.п.) и сохраняет результат — как в локальный кэш, так и в Redis. Следующий сервер, обращающийся к этому элементу, может получить непопадание на L1, но не на L2/Redis, что позволяет сохранить запрос к базе данных или API-вызов.
Мы обеспечиваем работу множества сайтов вопросов и ответов, и каждый сайт имеет собственное L1/L2-кэширование: по префиксу ключа на L1 и по идентификатору базы данных на L2/Redis. Более подробно об этом читайте в нашей будущей публикации.
Наряду с двумя основными серверами Redis (первичным/вторичным), на которых работают все копии сайтов, у нас также есть самообучающаяся платформа, расположенная еще на двух подчиненных серверах (в связи с требованиями к объемам памяти), которая используется для реализации механизма рекомендации вопросов, отображаемых на домашней странице, улучшения алгоритма поиска вакансий и т. п.. Платформа называется «Providence», описание которой вы можете найти у @Kevin Montrose.
Основные сервера Redis имеют 256GB оперативной памяти (используется около 90GB), а сервера Providence — 384GB оперативной памяти (используется около 125GB).
Выбор Redis объясняется не только кэшированием, но также механизмом публикации и подписки – когда один сервер публикует сообщение, а все остальные подписчики его получают — включая нисходящих клиентов на вторичных серверах Redis. Мы используем этот механизм для очистки буферной памяти L1 на других серверах в случаях, когда для согласованности данных очистка производится только одним веб–сервером, но есть еще одна великолепная причина, по которой мы выбрали Redis – протокол Websockets.
Websockets (NetGain)
Мы используем Websockets для осуществления принудительных обновлений в режиме реального времени, таких как показ уведомлений в верхнем горизонтальном меню, подсчет голосов, формирование статистики новой навигации, показ новых ответов и комментариев, и еще для нескольких задач.
Сами сервера сокетов используют сырые сокеты, работающие на веб–уровне. Это очень тонкое приложение, использующее нашу открытую библиотеку: StackExchange.NetGain. При пиковой нагрузке мы поддерживаем около 500,000 открытых соединений Websocketодновременно, а это, на самом деле, довольно большое число браузеров. Забавный факт: некоторые из этих браузеров остаются открытыми в течение полутора лет и более, почему — неизвестно. Надо, чтобы кто-то проверил, живы ли люди по ту сторону экрана… Так выглядит график работы Websocket за эту неделю:
Почему мы выбрали Websockets? Они в сотни раз эффективнее ждущего режима — если говорить о наших масштабах. Таким образом, мы можем предоставлять пользователю больше данных с большей скоростью, используя при этом меньше ресурсов. Однако не обошлось и без нюансов: динамический порт и недостаточность дескриптора файлов на балансировщике — курьезы, на которых мы остановимся более подробно чуть позже.
Поиск (Elasticsearch)
Каждый кластер Elasticsearch (по одному в каждом из дата-центров) имеет 3 узла, и каждый сайт имеет свой собственный индекс (кроме Careers, который имеет несколько дополнительных индексов). Что делает нашу установку немного нетривиальной в терминах «эластичности»: наши 3 серверных кластера чуть мощнее среднего за счет SSD-хранилища, 192GB оперативной памяти и дублированной сети пропускной способностью 10Gbps для каждого из кластеров.
Главная причина, по которой мы выбрали Elasticsearch, а не что-то типа полнотекстового поиска SQL — его расширяемость и то, что он является более удачным выбором с точки зрения цена–производительность. Центральные процессоры SQL относительно дороги, а Elastic дешев, и, в данный момент, обладает большим набором функций. Почему не Solr? Нам нужен поиск по всей сети (одновременно по нескольким индексам), а на момент принятия решения эта возможность была недоступна. Почему мы еще не на 2.x — значительное изменение в «типах», которое для обновления требует полной переиндексации. И у меня пока просто нет времени внести необходимые изменения и составить план миграции.
Базы данных (SQL Server)
SQL-сервер является нашим единственным источником информации, все данные в Elastic и Redis поступают именно оттуда. У нас работают 2 кластера SQL-сервера с AlwaysOn Availability Groups. Каждый кластер имеет один первичный сервер (принимающий на себя почти всю нагрузку) и одну копию в Нью-Йорке. Дополнительно имеется еще одна копия в Колорадо (в нашем дата-центре аварийного восстановления). Все копии работают асинхронно.
Первый кластер представляет собой несколько серверов Dell R720xd, каждый на 384GB RAM, 4TB PCIe SSD и 2x 12 ядер. На нем работают Stack Overflow, Sites (плохое название; позже объясню), PRIZM и мобильные базы данных.
Второй кластер представляет собой несколько серверов Dell R730xd, каждый на 768GB RAM, 6TB PCIe SSD и 2x 8 ядер. На этом кластере работает все остальное. Список включает:Careers, Open ID, систему чатов, наш Журнал исключений и все остальные сайты вопросов и ответов (напр., Super User, Server Fault и т.п.).
Мы хотим сократить до минимума использования CPU на уровне баз данных, но пока это невозможно в связи с некоторыми нюансами планирования кэша, которые в данный момент мы пытаемся исправить.
На текущий момент, NY-SQL02 и 04 являются первичными, 01 и 03 — копиями, которые мы перезапустили как раз сегодня во время обновлений SSD. Так выглядит статистика за последние 24 часа:
Наш способ использования SQL довольно прост, а проще — значит быстрее. И хотя некоторые запросы могут быть довольно заумными, наше взаимодействие с самим SQL особой сложностью не отличается. У нас есть унаследованный Linq2Sql, но все новые разработки используют Dapper, нашу библиотеку Micro-ORM с открытым исходным кодом, использующую объекты POCO. Выражусь иначе: в базе данных Stack Overflow есть только одна сохраненная процедура и я твердо намерен перенести этот пережиток прошлого в код.
