Выбрать главу

Приложение доступно на сайте Mulve.com. Оно занимает всего 2 Мб и состоит из двух файлов, один из который установочный, а второй — текстовый. В нём написано, каким образом можно материально поддержать проект. Похоже, никакого вредоносного кода здесь нет — по крайней мере, из 43 антивирусов выявили в программе чего-то подозрительное только 3.

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

После запуска исполняемого файла пользователю нужно просто ввести поисковый запрос. Как это ни странно, найти здесь можно практически любые композиции, причём с хорошим качеством — до 320 кб/с. Загружаются файлы очень быстро — жаловаться не на что.

http://www.youtube.com/watch?v=PUIo8pTP--U?fs=1

Каким же образом работает Mulve? Это определённо не пиринговая программа и поисковики для обнаружения звуковых файлов она также не использует. Похоже, весь контент скачивается с централизованных серверов.

Разработчики Mulve не признаются, что это за сервера, но практически все треки загружаются из сети «ВКонтакте». Неудивительно, поиск этой социальной сети позволяет найти практически любую, даже самую редкую музыку — видимо, администрация особо не следит за тем, что пользователи закачивают на сервера.

Закрыть Mulve достаточно просто — достаточно провайдеру заблокировать сервера, с которых идёт пиратский трафик. Но если это действительно «ВКонтакте», то ничего хорошего администрации социальной сети тоже ждать не стоит. Западные правообладатели до сих пор не замечали ресурс только потому, что сеть эта российская. Теперь создатели Mulve раструбят о происходящем беспределе по всему миру. Сервису не помешает навести у себя порядок — может быть, если парочка крупных компаний подаст на его владельцев в суд, оно и к лучшему.

К оглавлению

Facebook подвело основное хранилище данных

Михаил Карпов

ОпубликованоМихаил Карпов

Многие пользователи социальной сети Facebook не могли получить доступ к сайту 23 сентября 2010 года в течение примерно 2,5 часов. Ничего подобного не случалось уже почти четыре года. Не работал как сам сайт, так и кнопки Like («Мне нравится»), соединённые с этой сетью. У сторонних ресурсов также не было доступа к инструментам разработчика Facebook.

Во всём виноват кэш — сервера, данные которых дублируют значения, находящиеся в основном хранилище. Эта информация периодически актуализируется. Иногда случается, что информация в кэше устаревает, но обычно это не представляет собой проблемы, так как сервер кэша просто делает запрос к основному хранилищу и получает актуальные данные. Это срабатывает, когда проблема возникает в самом кэше. Но на этот раз всё получилось иначе.

Вскоре после того, как сайт поднялся, Роберт Джонсон, директор подразделения разработки ПО Facebook, написал в блоге, что же произошло. По его словам, основной причиной, из-за которой сайт был недоступен в течение продолжительного периода заключается именно в том, что система, которая призвана устранять ошибки в кэше и актуализировать данные, «перестаралась» и причинила больше вреда, чем пользы.

23 сентября в основное хранилище данных были внесены изменения, которые были признаны кэшем ошибочными. Таким образом, каждый клиент кэша стал обращаться к базе для того, чтобы получить верные значения, однако опять получал то, что интерпретировалось как ошибка. Таким образом, ситуация повторялась постоянно на всех машинах. Вскоре основные хранилища данных были буквально завалены запросами кэша.

Каждый раз, когда клиент получал ошибку, полученные данные стирались и он вновь делал запрос к базе, получая оттуда очередную информацию, которую вновь интерпретировал как ошибочную и стирал. Но это ещё не всё — даже исправив данные в хранилище, остановить поток запросов оказалось невозможно. Некоторые сервера уже были перегружены и не пропускали запросы кэша, что также истолковывалось клиентами как ошибка, и они продолжали обращаться к машинам основной базы данных.