На чем написан stackoverflow
История проекта Stack Overflow — экспертные ответы на ваши вопросы
Авторизуйтесь
История проекта Stack Overflow — экспертные ответы на ваши вопросы
Каждый современный разработчик хотя бы раз слышал словосочетание «Stack Overflow». Сегодня многие программисты не могут вообразить себе, как может выглядеть трудовая деятельность без качественной базы готовых решений, доступной каждому через Интернет: каждую секунду StackOverflow.com посещают более 20 000 уникальных пользователей!
Но так было не всегда… Самая первая версия сайта была запущена в начале августа 2008 года. Доменное имя stackoverflow.com и логотип сайта были выбраны в результате голосования неравнодушных коллег. Результаты опроса, как и другие варианты предложенных имен, все еще можно найти в блоге Coding Horror, который ведет один из основателей проекта — Джефф Атвуд. Интересны и рассмотренные варианты логотипов.
Подобный «шум» кардинально снижал производительность индустрии в целом. Многие задумались о том, как можно было бы переработать существующий формат представления информации. В это время стали набирать популярность сервисы вопросов и ответов, где ответы можно было получать лишь за деньги. На некоторых сайтах платить необходимо было еще до того, как становилось понятно, что на сайте действительно есть решение имеющейся проблемы.
Да-да! Именно так! Либо бесплатно копаться в свалке информации, либо платить, «не видя товар»!
Далеко не всем такая ситуация была по душе. Джоэл Спольски и Джефф Атвуд, рок-звезды сообщества разработчиков, выдвинули основные идеи видения нового сайта для разработчиков:
Более подробно они описаны в блоге компании.
Вскоре после открытия публичного доступа к сайту был приобретен еще один аналогичный сервер. Архитектура была проста: на одном работал сайт, на втором — база данных.
Истинная ценность Stack Overflow в сообществе
Именно сообщество ответственно за создание и поддержку общей базы прикладных решений. Как результат, в конце марта 2009 года были проведены первые демократические выборы модераторов от сообщества.
В мае—июле того же года произошло еще несколько знаменательных для проекта событий:
Сегодня на Stack Overflow задано более 12 000 000 вопросов, опубликовано более 20 000 000 ответов. Сайт посещают более 45 000 000 уникальных пользователей в месяц.
Stack Overflow — это международная компания, состоящая из более чем 200 сотрудников, с тремя офисами: в Лондоне, Денвере и штаб-квартирой в Нью-Йорке.
Как уже говорилось, Stack Overflow — это прежде всего сообщество, то есть реальные разработчики. Компания старается сделать как можно больше полезного и интересного для людей:
Вы можете следить за развитием проекта на Мете или в блоге компании. Уверен, мы еще не раз убедимся в состоятельности идеи коллективной ответственности за будущее сообщества!
Секреты Stack Overflow
Приветствую, коллеги. За последние несколько лет Stack Overflow стал полезнейшим инструментом для разработчиков. Множество вопросов, заданных Гуглу и Яндексу, в первых же ссылках ведут на понятные и исчерпывающие ответы на этом ресурсе. Большинство разработчиков используют сайт Stack Overflow именно как базу знаний программистов, возможность быстро получить нужный ответ. Под катом я расскажу про несколько интересных кейсов подводной части айсберга: спрятанные ответы, награды, прокачивание кармы и многое другое, скрытое от поверхностного взгляда.
Ответ не всегда помечен зеленой галочкой
Много раз на хакатонах и консультациях я стоял за спиной ребят, ищущих ответ на Stack Overflow. И не раз наблюдал такую картину: человек переходит на Stack Overflow из поиска, ищет ответ, помеченный зеленой галочкой, не находит и тут же закрывает вкладку, резюмируя, что “вот, на стеке тоже спросили — и никто не знает”.
Иногда ответа действительно нет. Но чаще всего он есть, просто находится немного не там, где мы ожидаем:
Bounty за ответ
Возможность предложить награду (bounty) за ответ очень многие игнорируют: репутации, чтобы предложить награду, нету, да и зачем она кому-то может понадобиться — непонятно. Зря игнорируют, между прочим: даже сложнейшие вопросы, на которые никто не отвечает, сразу же получают ответы, если снабдить их bounty соответствующего размера. Более того, bounty можно установить не только для своего, но и для чужого вопроса.
Почему bounty настолько сильно влияет на привлекательность вопроса? Несколько факторов. Во-первых, это самый простой способ для новичков быстро получить много репутации. Во-вторых, топ-разработчики могут таким образом помериться силами: репутация в несколько сотен тысяч баллов на Stack Overflow выглядит очень солидно в резюме специалиста и помогает найти хорошую работу, если появляется желание ее поменять.
Откуда брать репутацию, чтобы тратить ее на bounty? Об этом ниже.
Неочевидные источники репутации
Самый очевидный способ заработать репутацию — это отвечать на вопросы. Он же — самый трудный. На простые вопросы можно быстро получить сразу несколько ответов, а вот на сложные вопросы ответить действительно… сложно. Пользователи Stack Overflow, зарабатывающие репутацию с помощью ответов, ставят специальные фильтры для получения мгновенных уведомлений о новых вопросах в очень узкой области, которую они лучше всего знают. Такие специалисты могут ответить на вопрос в течение десяти минут, получая за свои усилия максимум баллов репутации в день.
Фильтры ставятся по тегам. Если вы хотите, чтобы ваш вопрос увидело максимальное количество экспертов, не поленитесь потратить лишние 30 секунд и укажите все возможные теги, имеющие хоть какое-то отношение к вопросу.
Но что делать, если у вас нет никакого желания караулить вопросы и тратить силы на бесчисленные ответы, лишь малая часть которых принесет репутацию? Решение довольно неожиданное — задавать вопросы.
Репутация выдается не только за ответы, но и за то, что ваш вопрос кому-то понравился. При этом вопрос не обязательно должен быть гениальный. Многие завсегдатаи отмечают голосами просто аккуратно оформленные вопросы, соответствующие писаным и неписаным правилам сервиса: без грамматических ошибок, с выделением кода и т. д. Более того, новые пользователи часто голосуют за вопросы, которые они нашли через поиск, поэтому каждый вопрос может стать постоянным генератором репутации. Несколько десятков вопросов за год способны на следующий год принести тысячу-другую баллов репутации, которые затем можно будет потратить на bounty для действительно важных вещей. Если у вас что-то не получается дольше получаса, хорошей идеей будет уделить десять минут составлению качественного вопроса на Stack Overflow, после чего можно спокойно вернуться к поиску решения. Если кто-то ответит — вы сэкономите кучу времени. Если вы сами найдете ответ — смело отвечайте на собственный вопрос, это займет всего пару минут, зато в будущем увеличит поток пассивно генерируемой репутации.
Stack Overflow больше, чем кажется
Далеко не все знают, что stackoverflow.com — это не единственный сайт экосистемы вопросов и ответов, созданной Джоэлом Спольски. Это постоянно растущая сеть сайтов, суммарно называемая Stack Exchange и объединяющая десятки узкоспециализированных площадок с одинаковым интерфейсом и единым пользовательским профилем (но раздельной репутацией). Полный список сайтов на stackexchange.com/sites также содержит площадки для обсуждения работы самой сети и Area 51, где предлагают и “выращивают” новые сайты вопросов и ответов.
Русская версия Stack Overflow для специфических вопросов
Сеть Stack Exchange включает в себя не только специализированные сайты вроде “Вопросы по Ubuntu”, но и версии Stack Overflow для разных регионов. В частности, недавно была запущена русская версия, которая доступна по адресу ru.stackoverflow.com.
За последний год на многих конференциях и митапах я часто сталкивался с непониманием разработчиками назначения локализованной версии. Многие высказываются в духе “Любой настоящий программист (с) знает английский. Зачем нам еще один стек с меньшим количеством участников и вопросов. ”
В действительности всё совсем не так, как на самом деле. Назначение русского Stack Overflow вовсе не в том, чтобы дублировать функциональность англоязычной версии. Джоэл создает локализованные версии не для языка как такового, а для стран и регионов. Попробуйте спросить на основном сайте что-нибудь, связанное с разработкой для 1С, — вы там даже тега такого не найдете. Зато на русской версии и теги, и вопросы, и ответы — все представлено в большом количестве. IT — огромная область, разделенная не только платформами и областями, но и регионально. Во многих странах и регионах есть свои крупные игроки софтостроения, которые специализируются на локальном рынке и мало известны за его пределами. Русскоязычная версия Stack Overflow — возможность для разработчиков обсуждать специфические для России решения, использовать теги на русском языке, общаться в домашнем часовом поясе и прокачивать релевантную репутацию.
Кстати, по поводу репутации. Как я уже писал выше, заработать высокую репутацию на глобальном Stack Overflow очень сложно из-за слишком сильной конкуренции и отличий в часовых поясах. При этом высокая репутация на стеке украшает резюме, что особенно важно для начинающих специалистов, желающих продемонстрировать квалификацию при отсутствии формального стажа. Недавно появившийся русский стек позволил многим разработчикам начать прокачивать репутацию “с чистого листа” в гораздо более комфортных условиях.
Чукча не писатель?
И последнее. На консультациях меня часто спрашивают, на каком языке писать комментарии в исходном коде. Хочется, конечно, писать по-английски. Но тут есть тонкий момент: большинство айтишников действительно хорошо владеют английским — но только для чтения. Когда нужно написать понятный и емкий комментарий, у многих случается пробуксовка: одно дело бегло читать статьи, новости и книги, а совсем другое — писать самому. Многие разработчики формулируют вопросы для стека так, что даже после вдумчивого прочтения непонятно, что же они имеют в виду.
Комментарии на английском желательно писать, если большинство разработчиков в команде действительно хорошо знают английский язык. То же и с вопросами: многие разработчики не хотят задавать вопросы просто потому, что им не так просто их формулировать на чужом языке. Русская же версия убирает этот барьер, и теперь у коллег больше не будет такой удобной отмазки: “На стеке сложно хорошо вопрос сформулировать, поэтому я не стал спрашивать и сам три часа копался” 🙂
Stack Overflow
Stack Overflow Internet Services, Inc.
работает и развивается
Stack Overflow — популярная система вопросов и ответов о программировании, разработанная Джоэлем Сполски и Джеффом Этвудом (англ.) в 2008 году. Является частью Stack Exchange Network. Как и в других системах подобного рода, Stack Overflow предоставляет возможность оценивать вопросы и ответы, что поднимает или понижает репутацию зарегистрированных пользователей. Таким образом создаётся возможность оценить компетентность ответов.
В настоящее время отмечается рост количества клонов Stack Overflow. Например, немецкий CodeKicker, российский ХэшКод и ряд зарубежных сайтов, посвященных, в основном, программированию, администрированию и web-дизайну.
См. также
Примечания
Ссылки
Полезное
Смотреть что такое «Stack Overflow» в других словарях:
Stack overflow — In software, a stack overflow occurs when too much memory is used on the call stack. In many programming languages the call stack contains a limited amount of memory, usually determined at the start of the program. The size of the call stack… … Wikipedia
Stack Overflow — Pufferüberläufe (engl. buffer overflow) gehören zu den häufigsten Sicherheitslücken in aktueller Software, die sich u. a. über das Internet ausnutzen lassen können. Im Wesentlichen werden bei einem Pufferüberlauf durch Fehler im Programm zu große … Deutsch Wikipedia
Stack overflow — Dépassement de pile En informatique, un dépassement de pile ou débordement de pile (en anglais, stack overflow) est un bogue causé par un processus qui, lors de l écriture dans une pile, écrit à l extérieur de l espace alloué à la pile, écrasant… … Wikipédia en Français
Stack Overflow — Pour les articles homonymes, voir Stack overflow (homonymie). Stack Overflow … Wikipédia en Français
Stack overflow (homonymie) — Cette page d’homonymie répertorie les différents sujets et articles partageant un même nom. Stack overflow peut signifier: dépassement de pile une erreur de programmation. Stack Overflow un site web de question réponse. Catégorie : Homonymie … Wikipédia en Français
Call stack overflow — Dépassement de pile En informatique, un dépassement de pile ou débordement de pile (en anglais, stack overflow) est un bogue causé par un processus qui, lors de l écriture dans une pile, écrit à l extérieur de l espace alloué à la pile, écrasant… … Wikipédia en Français
Stack Exchange Network — Stack Exchange Network сеть вебсайтов для работы с вопросами и ответами в различных областях. Сайты позволяют пользователям задавать вопросы и отвечать на них. Путем учёта активной деятельности, происходит голосование за вопросы и ответы,… … Википедия
Stack buffer overflow — In software, a stack buffer overflow occurs when a program writes to a memory address on the program s call stack outside of the intended data structure; usually a fixed length buffer.cite web last = Fithen first = William L coauthors = Seacord,… … Wikipedia
На чем написан 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
Чтобы понять, как все это работает, давайте начнем с показателей Stack Overflow. Итак, ниже приводится статистика за 12 ноября 2013 и 9 февраля 2016 года:
Вы можете спросить, почему существенно сократилась продолжительность обработки в ASP.Net по сравнению с 2013 годом (когда было 757 часов) несмотря на прибавление 61 миллиона запросов в день. Это произошло как и из-за модернизации оборудования в начале 2015 года, так и из-за некоторого изменения параметров в самих приложениях. Пожалуйста, не забывайте, что производительность – это наша отличительная особенность. Если Вы хотите, чтобы я более подробно рассказал о характеристиках оборудования – без проблем. В следующем посте будут подробные спецификации железа всех серверов, которые обеспечивают работу сайта.
Итак, что изменилось за прошедшие 2 года? Кроме замены некоторых серверов и сетевого оборудования, не очень многое. Вот укрупненный список хардварной части, которая обеспечивает работу ресурса (выделены различия по сравнению с 2013 годом):
Для того, чтобы Вы поняли, как сегодня выглядит наше оборудование, привожу несколько своих фото рэковой стойки А (в сравнении с ее «сестрой» стойкой B), сделанных во время нашего переоборудования в феврале 2015 года:
И, как не парадоксально, с той недели у меня в альбоме есть еще 255 фотографий (в сумме 256, и да — это не случайное число). Теперь, давайте рассмотрим оборудование. Вот логическая схема взаимодействия главных систем:
Основные правила
Вот некоторые всеобще применяемые правила, поэтому я не буду повторять их для каждой системы:
В сети Интернет
Сначала Вы должны найти нас – это DNS. Процесс нахождения нас должен быть быстрым, поэтому мы поручаем это CloudFlare (в настоящее время), так как их серверы DNS ближе почти всех остальных DNS мира. Мы обновляем наши записи DNS через API, а они делают «хостинг» DNS. Но поскольку мы «тормозы» с глубоко укоренившимися проблемами доверия (к другим), мы также все еще имеем наши собственные DNS-сервера. Если произойдет апокалипсис (вероятно, вызванный GPL, Punyon или кэшированием), а люди все еще будут хотеть программировать, чтобы не думать о нем, мы переключимся на них.
После того, как Вы найдете наше «секретное убежище», пойдет HTTP-трафик через одного из наших четырех Интернет провайдеров (Level 3, Zayo, Cogent, и Lightower в Нью-Йорке), и через один из наших четырех локальных маршрутизаторов. Для достижения максимальной эффективности, мы вместе с нашими провайдерами используем BGP (довольно стандартный) для управления трафиком и обеспечения нескольких путей его передачи. Маршрутизаторы ASR-1001 и ASR-1001-X объединены в 2 пары, каждая из которых обслуживает 2 провайдера в режиме активный/активный. Таким образом, мы обеспечиваем резервирование. Хотя они подключены все к той же физической сети 10 Гбит/с, внешний трафик проходит по отдельным изолированным внешним VLAN, которые также подключены к балансировщикам нагрузки. После прохождения через маршрутизаторы, трафик направляется к балансировщикам нагрузки.
Я думаю, что самое время упомянуть, что между нашими двумя дата-центрами мы используем линию MPLS на 10 Гбит/с, но это напрямую не связано с обслуживанием сайта. Она служит для дублирования данных и их быстрого восстановления в случаях, когда нам нужна пакетная передача. «Но Ник, это не резервирование!» Да, технически Вы правы (абсолютно правы): это – единственное «пятно» на нашей репутации. Но постойте! Через наших провайдеров мы имеем еще две более отказоустойчивые линии OSPF (по стоимости MPLS — № 1, а это № 2 и 3). Каждое из упомянутых устройств быстрее подключается к соответствующему устройству в Колорадо, и при отказе они распределяют между собой сбалансированный трафик. Мы смогли заставить оба устройства соединяться с обоими устройствами 4-мя способами, но все они и так одинаково хороши.
Балансировщики нагрузки (HAProxy)
Балансировщики нагрузки работают на HAProxy 1.5.15 под CentOS 7, предпочтительной у нас разновидности Linux. HAProxy также ограничивает и трафик TLS (SSL). Для поддержки HTTP/2 мы скоро начнем внимательно изучать HAProxy 1.7.
В отличие от всех других серверов с двойным сетевым подключением по LACP 10 Гбит/с, каждый балансировщик нагрузки имеет по 2 пары каналов 10 Гбит/с: одну для внешней сети и одну для DMZ. Для более эффективного управляемого согласования SSL эти «коробки» имеют память 64 ГБ или больше. Когда мы можем кэшировать в памяти больше сессий TLS для повторного использования, тратится меньше времени на образование нового соединения с тем же самым клиентом. Это означает, что мы можем возобновлять сессии и быстрее, и с меньшими затратами. Учитывая, что RAM в переводе на доллары довольно дешевая, это – легкий выбор.
Сами балансировщики нагрузки – довольно простые устройства. Мы создаем иллюзию, что разные сайты «сидят» на различных IP (в основном по вопросам сертификации и управления DNS), и маршрутизируем на различные выходные буфера основываясь, главным образом, на заголовках хоста. Единственными «знаменитыми» вещами, которые мы делаем, является ограничение скорости и некоторые захваты заголовков (отсылаемых с нашего уровня веб-узлов) в сообщение системного журнала HAProxy. Поэтому мы можем делать запись метрик производительности для каждого запроса. Мы также расскажем об этом позднее.
Балансировщики нагрузки регулируют трафик 9-ти серверов, которые мы называем «Primary» (01-09), и 2-х web-серверов «Dev/meta» (10-11, среда нашей площадки). Серверы Primary управляют такими вещами, как Stack Overflow, Careers и всеми сайтами Stack Exchange, кроме сайтов meta.stackoverflow.com и meta.stackexchange.com, которые размещены на 2-х последних серверах. Основное приложение Q&A само по себе многопользовательское. Это означает, что одно приложение обслуживает запросы для всех Q&A сайтов. Скажем по-другому – мы можем управлять всей сетью Q&A одним пулом приложений на одном сервере. Другие приложения, такие как Careers, API v2, Mobile API и т.д. размещены отдельно. Вот так выглядят основной и dev-уровни в IIS:
Вот так выглядит распределение Stack Overflow по уровню веб-узлов, напоминая Opserver (наша внутренняя dashboard):
… а вот так выглядят web-серверы с точки зрения нагрузки:
В следующих постах я коснусь того, почему мы так «сверхоснащены», но самыми важными моментами являются: кольцевое построение (rolling builds), операционный резерв и избыточность.
В основе этих web-серверов лежит очень похожее «сервисное звено». Оно также работает на IIS 8.5 под Windows 2012R2 и отвечает за внутренние службы, поддерживая вычислительный уровень веб-узлов и другие внутренние системы. Здесь два крупных «игрока»: «Stack Server», который управляет Tag Engine и основан на http.sys (не под IIS), и Providence API (работает на IIS). Забавный факт: я должен настроить маску соответствия для каждого из этих 2-х процессов, чтобы прописать их на разных процессорах, потому что Stack Server «забивает» кэши L2 и L3 при обновлении списка вопросов каждые 2 минуты.
Эти сервисные «коробки» выполняют ответственную работу по поднятию Tag Engine и внутренних API, где нам нужна избыточность, но не 9-ти кратная. Например, загрузка из базы данных (в настоящее время 2-х) всех постов и их тэгов, которые изменяются каждую n-ную минуту, не очень «дешевая». Мы не хотим загружать все это 9 раз на уровень веб-узлов; достаточно 3 раза и это обеспечивает нам достаточную «безопасность». Кроме того, на уровне оборудования мы конфигурируем эти «коробки» по-разному, чтобы они были более оптимизированы под различные характеристики вычислительной нагрузки Tag Engine и гибкого индексирования (которое также здесь работает). Сам по себе «Tag Engine» является относительно сложной темой и ему будет посвящен отдельный пост. Основной момент: когда Вы заходите на /questions/tagged/java, вы нагружаете Tag Engine, чтобы определить соответствующие запросы. Он делает все наше сопоставление тэгов вне процесса поиска, поэтому новая навигация и все прочее используют эти сервисы для обработки данных.
Кэш и Pub/Sub (Redis)
Здесь мы используем Redis для нескольких вещей и они вряд ли будут сильно изменяться. Несмотря на выполнение примерно 160 миллиардов операций в месяц, в каждый момент загрузка центрального процессора менее 2%. Обычно намного ниже:
С Redis мы имеем систему кэшей L1/L2. «L1» – это кэш HTTP на web-серверах или каком-либо работающем приложении. «L2» обращается к Redis за выборкой значений. Наши значения сохраняются в формате Protobuf через protobuf-dot-net от Марка Грэвелла (Marc Gravell). Для клиента мы используем StackExchange.Redis – open source проект. Когда один web-сервер получает «промах кэша» (cache miss) L1, либо L2, он берет выборку из источника (запрос к базе данных, вызов API и т.д.) и помещает результат и в местный кэш, и в Redis. Следующий сервер, нуждающийся в выборке, может получить «промах кэша» L1, но найдет ее в L2/Redis, экономя на запросе к базе данных или вызове API.
Также у нас работает много Q&A сайтов, поэтому у каждого сайта есть свое собственное кэширование L1/L2: по ключевому префиксу в L1 и по ID базы данных в L2/Redis. Более подробно этот вопрос мы рассмотрим в следующих постах.
Вместе с 2-мя основными серверами Redis (мастер/ведомый), которые управляют всеми запросами к сайтам, у нас также есть система машинного обучения, работающая на 2-х более специализированных серверах (из-за памяти). Она используется для отображения рекомендованных запросов на домашней странице, улучшения выдачи и т.д. Эта платформа, называемая Providence, у нас обслуживается Кевином Монтроузом (Kevin Montrose).
Основные серверы Redis имеют по 256 ГБ RAM (используется около 90 ГБ), а в серверах Providence установлено по 384 ГБ RAM (используется около 125 ГБ).
Redis используется не только для работы с кэшем – он также имеет алгоритм «publish & subscriber» (публикация и подписка), работающий так, что один сервер может разослать сообщение, а все другие «подписчики» получат его – включая нижерасположенных клиентов на ведомых серверах Redis. Мы используем этот алгоритм для очистки кэша L1 на других серверах, когда один web-сервер делает удаление для сохранения согласованности. Но есть и другое важное применение: websockets.
Websocket’ы (NetGain)
Мы используем websocket’ы для отправки пользователям в реальном времени обновлений, таких как уведомления, подсчет голосов, новое навигационное исчисление, новые ответы и комментарии и т.п.
Сами сокет-серверы используют необработанные сокеты, выполняемые на уровне веб-узлов. Это — очень маленькое приложение на вершине нашей открытой библиотеки: StackExchange.NetGain. Во время пиковой нагрузки у нас одновременно открыто около 500,000 параллельных каналов websocket. Это — множество браузеров. Забавный факт: некоторые из этих страниц были открыты более 18 месяцев назад. Мы не знаем почему. Кто-то должен проверить, живы ли еще эти разработчики.
Вот так изменялось на этой неделе число одновременно открытых websocket:
Почему websocket? При нашем масштабе они намного более эффективны, чем опрос. Просто таким способом мы можем передать пользователю больше данных при меньшем количестве используемых ресурсов, к тому же более быстро. Но у них тоже есть проблемы, хотя временный порт и полный перебор всех дескрипторов файлов на балансировщике нагрузки – несерьезные проблемы. Мы расскажем о них позже.
Поиск (Elasticsearch)
Спойлер: это не то, от чего можно прийти в восторг.
Уровень веб-узлов выполняет солидную поисковую работу по сравнению с Elasticsearch 1.4, который использует очень тонкий высокоэффективный клиент StackExchange.Elastic. В отличие от большинства других средств, мы не планируем выкладывать его в открытый доступ просто потому, что он отражает только очень небольшое подмножество API, которые мы используем. Я убежден, что его выпуск «в свет» принесет больше вреда, чем пользы из-за путаницы среди разработчиков. Мы используем Elastic для поиска, вычисления связанных запросов и советов, как формировать вопрос.
Каждый кластер Elastic (по одному такому есть в каждом дата-центре) имеет 3 узла, а каждый сайт имеет свой собственный индекс. Careers имеет несколько дополнительных индексов. Это делает нашу систему немного нестандартной: наши 3 серверных кластера немного больше «накачаны» всеми этими хранилищами SSD, памятью в 192 ГБ и двойной сетью по 10 Гбит/с на каждый канал.
Главной причиной того, что мы остановились на Elasticsearch вместо чего-то подобного полнотекстовому поиску SQL, является масштабируемость и лучшее распределение денег. SQL CPU достаточно дорогие, Elastic же дешевый и сегодня имеет намного лучшие характеристики. Почему не Solr? Мы хотим искать по всей сети (сразу много индексов), но это не поддерживалось Solr во время принятия решения. Причиной того, что мы еще не перешли на 2.x, является солидная доля «types», из-за которых нам надо будет все переиндексировать для обновления. У меня просто нет достаточно времени, чтобы когда-нибудь составить план и сделать необходимые для перехода изменения.
Базы данных (SQL-сервер)
Мы используем SQL Server как наш единственный источник достоверной информации. Все данные Elastic и Redis получают от SQL-сервера. У нас работают 2 кластера SQL-серверов под AlwaysOn Availability Groups. У каждого из этих кластеров есть один мастер (выполняющий почти всю нагрузку) и одна реплика в Нью-Йорке. Кроме этого, еще есть одна реплика в Колорадо (наш дата-центр с динамическим копированием). Все реплики асинхронные.
Первый кластер – набор серверов Dell R720xd, у каждого 384 ГБ RAM, 4 TB PCIe SSD и 2 x 12 ядер. На нем установлены Stack Overflow, Sites (имеет дурную славу, я объясню позже), PRIZM и базы данных Mobile.
Второй кластер – это набор серверов Dell R730xd, у каждого 768 ГБ RAM, 6 TB PCIe SSD и 2 x 8 ядер. На этом кластере стоит все остальное. Список «всего остального» включает Careers, Open ID, Chat, наш Exception log и некоторые Q&A сайты (например, Super User, Server Fault и т.д.).
Использование CPU на уровне баз данных – это то, чего мы предпочитаем избегать, но, фактически, в данный момент оно немного повысилось из-за некоторых проблем с кэшем, которые мы сейчас решаем. Сейчас NY-SQL02 и 04 назначены мастерами, 01 и 03 – репликами, которые мы сегодня перезагрузили после обновления SSD. Вот как выглядят прошедшие 24 часа:
Мы используем SQL довольно просто. Ведь просто – это быстро. Хотя некоторые запросы могут быть безумными, наше взаимодействие с SQL само по себе – просто классика. У нас есть одна «древняя» Linq2Sql, но все новые разработки используют Dapper – наш выложенный в открытый доступ Micro-ORM, использующий POCOs. Позвольте сказать по-другому: Stack Overflow имеет только 1 хранимую в базе данных процедуру, и я намереваюсь перевести тот последний кусок в код.