Как устроен сервис коротких ссылок ?! Часть 1.
UniLecs
Давайте разработаем архитектуру и дизайн сервиса коротких ссылок на примере сервиса google - Google URL Shortener.
Зачем нужно сокращать URL ссылки ?
Сокращение URL используется для создания более коротких псевдонимов для длинных URL. Также эти сокращенные псевдонимы называются «короткими ссылками». Пользователи перенаправляются на исходный URL-адрес при попадании на эти короткие ссылки. Короткие ссылки экономят много места при отображении, печати, обмене сообщениями или твиттинге. Кроме того, пользователи с меньшей вероятностью будут неправильно набирать короткие URL-адреса. Так что плюсы очевидны.
Например, если мы укоротим ссылку на статью через Google Shortener:
https://telegra.ph/Task-2-Najti-minimalnyj-ehlement-v-otsortirovannom-po-vozrastaniyu-i-ciklicheski-sdvinutom-massive-09-20
Мы получим: https://goo.gl/6gZT7P
Сокращенный URL-адрес составляет одну шестую размера фактического URL-адреса. Сокращение URL-адресов используется для оптимизации ссылок на разных устройствах, отслеживания отдельных ссылок для анализа эффективности аудитории и кампании, а также для сокрытия связанных исходных URL-адресов.
Системные требования и цели сервиса
Наша система сокращения URL должна соответствовать следующим требованиям:
Функциональные требования:
- Учитывая URL, наш сервис должен генерировать более короткий и уникальный псевдоним. Это называется короткой ссылкой.
- Когда пользователи получают доступ к короткой ссылке, наш сервис должен перенаправить их на исходную ссылку.
- При желании пользователи должны иметь возможность выбрать собственную короткую ссылку для своего URL.
- Срок действия ссылок истечет после стандартного промежутка времени по умолчанию. Пользователи должны иметь возможность указать срок действия.
Нефункциональные требования:
- Система должна быть высокодоступной. Это необходимо, потому что, если наш сервис не работает, все перенаправления URL-адресов начнут давать сбой.
- Перенаправление URL должно происходить в режиме реального времени с минимальной задержкой.
Расширенные требования:
- Аналитика; например, сколько раз происходило перенаправление.
- Наш сервис также должен быть доступен через REST API другими сервисами.
Оценка ресурсов и ограничения
Наша система будет ресурсоемкой для чтения. Будет много запросов на перенаправление по сравнению с новыми сокращениями URL. Давайте предположим, что соотношение между чтением и записью составляет 100:1.
Оценка трафика
Предполагается, что у нас будет 500 миллионов новых сокращений URL-адресов в месяц с соотношением чтения / записи 100:1, и мы можем ожидать 50 млрд перенаправлений в течение того же периода:
100 * 500М = 50 млрд
Какими будут запросы в секунду (QPS) для нашей системы? Новые сокращения URL-адресов в секунду:
500 million / (30 days * 24 hours * 3600 seconds) = ~200 URLs/s
С учетом соотношения чтения / записи 100: 1 число перенаправлений URL-адресов в секунду будет:
100 * 200 URLs/s = 20K/s
Оценки хранилища
Предположим, мы храним каждый запрос на сокращение URL (и связанную сокращенную ссылку) в течение 5 лет. Поскольку мы ожидаем, что 500 миллионов новых URL-адресов будут ежемесячно, общее количество объектов, которые мы ожидаем сохранить, составит 30 миллиардов.
500 миллионов * 5 лет * 12 месяцев = 30 миллиардов
Предположим, что каждый сохраненный объект будет иметь размер около 500 байт (приблизительная оценка - мы углубимся в него позже). Нам понадобится 15 ТБ общего хранилища:
30 billion * 500 bytes = 15 TB
Оценки пропускной способности
Для запросов на запись, поскольку мы ожидаем 200 новых URL-адресов каждую секунду, общее количество входящих данных для нашего сервиса будет составлять 100 КБ в секунду:
200 * 500 байт = 100 КБ / с
Для запросов на чтение, поскольку каждую секунду мы ожидаем перенаправления ~ 19 тыс. URL, общее количество исходящих данных для нашего сервиса будет составлять 9 МБ в секунду.
19K * 500 байт = ~ 9 МБ / с
Оценки памяти
Если мы хотим кэшировать некоторые горячие URL-адреса, к которым часто обращаются, сколько памяти нам потребуется для их хранения? Если мы следуем правилу 80-20, то есть 20% URL-адресов генерируют 80% трафика, мы хотели бы кэшировать эти 20% горячих URL-адресов.
Поскольку у нас 19 000 запросов в секунду, мы будем получать 1,7 миллиарда запросов в день:
19K * 3600 секунд * 24 часа = ~ 1,7 миллиарда
Для кэширования 20% этих запросов нам понадобится 170 ГБ памяти.
0,2 * 1,7 млрд * 500 байт = ~ 170 ГБ
Здесь следует отметить одну вещь: поскольку будет много повторяющихся запросов (с одним и тем же URL), следовательно, фактическое использование памяти будет меньше 170 ГБ.
Оценки высокого уровня
При условии 500 миллионов новых URL-адресов в месяц и соотношения чтения: записи 100:1, ниже приводится сводка оценок высокого уровня для нашего сервиса:
API системы
После того, как мы доработали требования, всегда полезно определить системные API. Здесь мы должны четко указать, что ожидается от системы.
У нас могут быть API-интерфейсы SOAP или REST для демонстрации функциональности нашего сервиса. Ниже приведены определения API для создания и удаления URL:
createURL(api_dev_key, original_url, custom_alias=None, user_name=None, expire_date=None)
Параметры:
- api_dev_key (string): Ключ разработчика API зарегистрированного аккаунта. Он будет использоваться, помимо прочего, для регулирования количества пользователей на основе их выделенной квоты.
- original_url (string): Исходный URL.
- custom_alias (string): Необязательный пользовательский ключ для URL.
- user_name (string): Необязательное имя пользователя, которое будет использоваться в кодировке.
- expire_date (string): Необязательный срок действия для сокращенного URL.
Response: (string): Успешная вставка возвращает сокращенный URL; в противном случае возвращается код ошибки.
deleteURL(api_dev_key, url_key)
Где «url_key» - это строка, представляющая сокращенный URL-адрес для извлечения. При успешном удалении возвращается «URL удален».
Как обнаружить и предотвратить злоупотребления при использовании нашего API?
Какой нибудь "кулцхакер" (нехороший человек) может сломать нашу систему, использовав все URL-ключи в текущем дизайне. Чтобы предотвратить злоупотребления, мы можем ограничить пользователей через их api_dev_key. Каждый ключ api_dev_key может быть ограничен определенным числом созданий и перенаправлений URL-адресов за некоторый период времени (для каждого ключа разработчика может быть задана разная продолжительность).