Теперь самая популярная социальная сеть и блог-сервис – на WAP.LJ.MTS.COM.UA! Присоединяйтесь!
«Живой Журнал» (LiveJournal) – это глобальная социальная сеть, объединившая русскоязычных блоггеров во всем мире. Это более миллиона дневников, которые ведут журналисты, писатели, фотографы, политики, домохозяйки и все остальные. Это тысячи сообществ, посвященных обсуждению любых вопросов. И теперь все это доступно с мобильного телефона!

Пишите!
С помощью мобильной версии «Живого Журнала» вы можете писать о том, что вас волнует, общаться с родственниками, друзьями, коллегами и единомышленниками, заводить новые знакомства, где бы вы ни находились. Спорьте, убеждайте, доказывайте. Будьте он-лайн тогда, когда вам этого хочется!

Читайте!
Мобильная версия «Живого Журнала» также позволяет формировать собственную ленту друзей, а это самый простой и удобный способ читать другие дневники, даже, если вы не собираетесь вести собственный блог. Создайте свою персональную информационную ленту, в которой окажется только то, что вам действительно интересно.

Объединяйтесь!
Используйте возможности мобильного Живого Журнала для объединения в сообщества по интересам. Здесь есть тысячи сообществ обо всем!. Вы всегда найдете людей со схожими интересами. А если какого-то сообщества еще нет, вы всегда можете создать новое. И не забудьте, что мобильный «Живой Журнал» снабжен собственным каталогом украинских сообществ с рейтингами по количеству читателей, посетителей, участников.

Воспользоваться сервисом можно, перейдя в раздел «ЖЖ» на WAP-портале WAP.MTS.COM.UA, либо по прямой ссылке WAP.LJ.MTS.COM.UA.

C официального сайта МТС

Давайте я расскажу одну недлинную историю из доисторического прошлого ЖЖ – т.е. 2003 года.

В то время серверы ЖЖ стонали под напором пользовательного траффика. Старожилы подтвердят: сайт глючило часто и очень. Брэд Фицпатрик напряженно работал над тем, чтобы снизить нагрузку на базу данных, а заодно покупал и подключал новые машины. Однажды ему пришло в голову, что без ограничений на количество записей и комментов не обойтись – сайт не успевает приспосабливаться к росту числа пользователей. Кроме нормальных пользователей, стали появляеться первые спаммеры или просто всякие экспериментаторы, которые запускали халатно написанных роботов, и постили тысячи записей/комментров ежедневно или ежечасно. Все это вместе ужасно раздражало и мешало работать.

В феврале 2003-го, почти ни с кем не посоветовавшись, Брэд написал официальную запись в news – о том, что ЖЖ вводит ограничения на количество записей в сутки. Первоначальный вариант ограничений он выбрал особенно неудачно – 3 записи в сутки для бесплатных пользователей, 20 для платных.

Результатом был поток лучей ненависти флеймов, проклятий, протестов и апокалептических предсказаний. На запись пришло две с половиной тысячи комментариев – неслыханное на те времена количество. Даже те пользователи, кто в принципе выразил понимание и согласие с самой мерой, указывали, что 3 записи в сутки – смехотворно мало и совершенно необходимо поднять этот предел. Замечу, что пользователи тогда (как и сейчас) не особенно выбирали выражения. В русском ЖЖ тоже были протесты и демарши; об этом Брэд знал, например, от меня (я тогда работал в ЖЖ).

Подчеркну еще раз, что почти все протесты были от владельцев базовых аккаунтов (некоторым платникам тоже не понравился лимит в 20 записей в день, но их было намного меньше) – т.е. людей, которые ни за что не платили в ЖЖ и никакой прямой прибыли сервису не приносили (рекламы тогда никакой не было). Как поступил единоличный владелец ЖЖ Брэд в ответ на этот шторм яростного протеста? Как он отреагировал на сотни и тысячи издевательских или ругательных комментариев от базовых пользователей?

На следующий день он подтвердил, что намерения обидеть бесплатных пользователей не было, и предложил новую схему пределов (5/50 для бесплатных/платников); и заодно провел опрос на эту тему для всех желающих. Еще через несколько дней, под влиянием этого опроса и продолжающихся обсуждений в ЖЖ, Брэд извинился перед пользователями за всю эту плохо продуманную идею. Особенно важным он посчитал извиниться за то, что собирался ввести эти ограничения, не предупредив заранее пользователей и не объяснив заранее, зачем это надо. Брэд рассказал подробно о том, как так получилось и почему, отменил все планы на введение пределов, пообещал в будущем перед любым введением таких мер обсудить их с пользователями, итд. итп.

1. Если перед Вами появилась нетривиальная задача – не бойтесь написать программное обеспечение для ее решения самостоятельно! Пускай, возможно, это потребует некторых дополнительных усилий, но масса преимуществ, связанных с полным соответствием требованиям конкретного проекта, превосходит все издержки дополнительной разработки.

2. Невозможно масштабировать проект просто постоянно добавляя новые сервера, рано или поздно все же прийдется задуматься об его архитектуре;

3. Распределение нагрузок и параллельное операций порой заслуживают того, чтобы разработчики обратили на них внимание;

4. “Мы ненавидим изобретать колесо! Но тем не менее, если колесо не существует или оно квадратное, то мы не боимся изобретать круглое колесо.” (с)

Как всегда следуя принципу “чем проще – тем лучше”, разработки LJ написали этот крошечный daemon, лежащий в основе их Jabber/LJTalk. Он способен спокойно работать с более чем 300 тысячами соединений, используя очень скромное количество оперативной памяти для поддержания каждого соединения.

Основной причиной для написания собственного Jabber-сервера, стало недостаточная расширяемость и масштабируемость существующих решений. Была необходимость в реализации многих нестандартных функций, вроде индивидуальных обработчиков пользовательских изображений и личных данных, обычно в других решениях было доступно только изменение методов аутентификации.

В качестве альтернативы gearman’у для работ, для выполнения которых необходимы некоторые гарантии успешности, а также некоторая стабильность, была разработана эта библиотека. Общая схема работы осталась та же: клиент-серверная, но за стабильность приходится платить – производительность существенно ниже, возможно возникновение задержек.

Хоть эти два продукта и выполняют схожие функции, используются они обычно в совокупности друг с другом, просто-напросто обрабатывая разные типы работ.

Основными сферами применения TheShwartz в LJ являются:
- отправка электронной почты (SMTP клиент);
- LJ Notifications: каждое событие может вызывать за собой цепочку из тысяч уведомлений по электронной почте, SMS, XMPP и так далее;
- отправка RPC сообщений внешним сервисам;
- внедрение Atom потоков;

Gearman по сути прост до безобразия, но это не мешает ему быть чрезвычайно эффективным. Возможно Вы уже догадались в чем суть этого еще одного продукта, написанного специально для LJ, если уже навели курсор на акроним в начале этого абзаца, если же нет – поясню: он управляет общей работой системы средствами клиент-серверной архитектуры и высокопроизводительного бинарного протокола. С их помощью он способен удаленно вызывать практически любые процедуры на удаленных серверах с минимальными задержками во времени. Казалось бы ничего особенного он сам по себе не делает, но на самом деле он выполняет очень важную функцию: увеличивает степень параллельности выполнения операций, необходимых для полноценного функционирования проекта. Единственное но в работе этого механизма заключается в том, что он не предоставляет никаких гарантий успешности выполнения работ.

В рамках LiveJournal Gearman применяется в основном для:
- обработка изображений средствами Image::Magick вне perl-приложений;
- создание pool’а DBI соединений (DBD::Gofer + Gearman);
- уменьшением нагрузки, создаваемой отдельными компонентами системы;
- улучшения субъективного впечатления пользователей о быстродействии сервиса, благодаря выполнению части работ параллельно в фоновом режиме;
- выполнение блокирующего ресурсы кода отдельно от обработчиков различных событий.

Идея распределенных файловых систем далеко не нова, достаточно вспомнить лишь GFS или любой ее opensource аналог. Сам факт создания такой системы был очень легок, изначальная версия была написана за одни выходные, но при доведении ее до требуемого уровня качества пришлось попотеть. Решение о ее создании было развитием идеи распределения операций записи. Общая принцип хранения файлов прост: каждый файл в ФС относится к определенному классу файлов, который определяет все правила работы с файлом, в основном механизм его реплицирования, об остальном заботится сама система.

Как и все файловые системы этого класса, MogileFS работает на уровне пользовательских приложений и использует достаточно тривиальные протокол передачи данных и общую архитектуру: клиенты, управляющие серверы, абстрактные базы данных, сервера для хранения самих данных – в этом плане ничего нового придумано не было. Доступ к файлам осуществляется с помощью HTTP-запросов PUT/GET либо через виртуальный NFS-раздел. Единственной особенностью можно назвать уклон в построение собой абстрактной прослойки между приложением и собственно кластером базы данных (в случае LiveJournal – сегмента), используемой в роли альтернативы более тривиальной master/slave схемы.

Perlbal
При решении вопроса, связанного с балансировкой нагрузки между веб-серверами, пришлось перепробовать далеко не один десяток готовых решений, но, к сожалению, ни один из них не смог удовлетворить все потребности проекта. Не растерявшись, разработчики написали свое решение этой задачи и назвали его Perlbal. Конкурентов у него множество, начиная от решений на уровне оборудования, например от Foundry, заканчивая proxy балансировщиками нагрузки встроенные в более популярные веб-сервера, но, тем не менее, продукт получился достаточно конкурентноспособным.

Он удовлетворял всем требованиям, выдвигаемым разработчиками проекта:
- быстрый;
- небольшой размер;
- “сообразительный”;
- обработка “мертвых” узлов;
- может выступать как в роли reverse proxy, так и балансировщика нагрузки;
- базовый функционал классического веб-сервера;
- реализация внутреннего перенаправления данных;
- поддержка некоторых менее существенных трюков, реализованных обычно в виде plug-in’ов.

Perlbal не так активно используется вне LiveJournal, по сравнению с memcached, но для решения конкретной задачи он подошел как нельзя лучше.

В ситуации, когда не удавалось найти готового программного решения для какой-то конкретной задачи, они не боялись взяться за написание его самостоятельно, это стало одним из основных компонентов успеха проекта. Существенная часть программной платформы LiveJournal написана специально для этого проекта и выпущено под свободной лицензией с открытым исходным кодом, доступным в официальном SVN репозитории.

memcached
Залогом быстрой загрузки любой страницы крупного интернет-проекта является кэширование. Но как всегда возникает вопрос: а на каком уровне обработки данных его стоит выполнять? Для динамических страниц недопустимо кэширование на уровне готовых страниц. Можно кэшировать на уровне mod_perl, но по сути это пустая трата оперативной памяти, так как создастся отдельный кэш для каждого потока Apache, и количество промахов мимо кэша будет огромно. Кэширование запросов MySQL или HEAP таблицы также не дали бы требуемого результата ввиду чрезвычайной распределенности базы данных.

Выходом из сложившейся ситуации стало написание собственной распределенной системы кэширования объектов, получившей название memcached. Она позволяет:
- использовать для кэширования свободную оперативную память практически любого компьютера, задействованного в системе;
- кэшировать объекты практически любого языка программирования в сериализованном виде: Perl, PHP, Java, C++ и так далее;
- использовать для передачи кэшируемых данных простой протокол, не требующий избыточности данных;
- избегать даже теоретической возможности полного сбоя работы кэшируещей системы в связи с полной равнозначностью серверов;
- достигать превосходной производительности при формировании HTML-кода страниц;
- в разы снизить нагрузку на базы данных в проекте любого масштаба.

Этот продукт на практике оказался более чем эффективен, о чем свидетельствует его более чем успешное использование во многих крупнейших веб-проектах.

5. Есть предположения о том, к чему привело дальнейшее добавление новых серверов? Правильно – к полнейшему хаосу! Со временем стала возникать проблема масштабируемости баз данных. Операции чтения производились на каком-то одном сервере, но когда приходил запрос на запись данных, так или иначе данные приходилось производить обновление на каждом из slave серверов. В итоге выполнение синхронизации данных стало занимать подавляющее большинство процессорного времени slave серверов, что привело к отсутствию возможности продолжать масштабирование просто добавлением дополнительных серверов.

6. Пришло время задуматься над архитектурой системы и распределением операций записи. Основной целью стало избавиться от такой серьезной избыточности данных, так как это было практически пустой тратой времени копировать одни и те же данные на десяток машин, да еще и с RAID на каждой из них.

7. Наиболее эффективным подходом в такой ситуации является сегментирование базы данных. Все серверы баз данных разбиваются на небольшие кластеры. Каждый пользователь системы прозрачно привязывается к определенному кластеру, таким образом когда он обновляет свой блог или какие-либо еще данные, запись ведется в рамках только небольшой группы серверов, такой же принцип справедлив и для чтения. При работе такой системы не используется auto_increment в MySQL, а также используется составной primary key из номера пользователя и номера записи. Таким образом пространство имен объектов разбито на группы, соответствующие конкретному пользователю.

8. Дальнейшим развитием решения проблемы излишней избыточности данных может послужить отказ от кластеров, аналогичных по структуре исходному для хранения сегментов базы данных. Это может быть как вариант с общим на несколько серверов хранилищем данных, так и более низкоуровневая репликация данных средствами DRBD в совокупности с HeartBeat. Каждый из возможных вариантов кластеризации MySQL имеет массу положительных и отрицательных сторон, так что конкретного лидера среди них выделить достаточно сложно. Возможно именно это и подтолкнуло разработчиков построить собственное решение, комбинируя их с целью получения наилучшего эффекта.

1. Все началось с одного обычного сервера. Он выполнял роль как веб-сервера так и базы данных. Единственный плюс такого подхода к организации работы оборудования – достаточно дешево. Само собой достаточно скоро этот сервер перестал справляться с нагрузкой.

2. Следующим шагом было разнесение веб-сервера и базы данных на разные серверы, всего их получилось два. По прежнему имелось два узла, сбой в которых означал недоступность сервиса. По прежнему вычислительная мощность такой системы оставалась более чем скромной.

3. Первым из тех двух серверов, как ни странно, перестал справляться с нагрузкой веб-сервер – докупили еще два. Веб-сервера три, внешний IP – один, теперь приходится как-то распределять нагрузку! А как добавить еще одну базу данных?

4. Новый сервер баз данных был подключен в роли slave к исходному, данные в нем обновлялись с помощью репликации, а обрабатывал он только операции чтения, оставив все операции записи первому серверу.

Билл Уошборн, исполнительный директор компании OpenID, говорит, что подобная схема позволяет углубить сотрудничество между отдельными сайтами. Он полагает, что для привлечения внимания всей сети к обсуждаемому вопросу понадобится громкий судебный иск. “Будет определенный набор судебных дел, которые определят, что необходимо и что допустимо”, – указывает он.

Его волнует, что решение о судьбе наших интернет-жизней, возможно, будем принимать уже не мы сами.

“Ситуация вокруг того, что могут делать веб-сайты и что могут люди в сети, достаточно неопределенная. Со временем она будет привлекать все больше и больше внимания. Конечные пользователи не полностью владеют своими данными”.