1 В избранное 0 Ответвления 0

OSCHINA-MIRROR/darkranger-tiny-url

Присоединиться к Gitlife
Откройте для себя и примите участие в публичных проектах с открытым исходным кодом с участием более 10 миллионов разработчиков. Приватные репозитории также полностью бесплатны :)
Присоединиться бесплатно
Клонировать/Скачать
Внести вклад в разработку кода
Синхронизировать код
Отмена
Подсказка: Поскольку Git не поддерживает пустые директории, создание директории приведёт к созданию пустого файла .keep.
Loading...
README.md

Что такое короткий URL?

Это преобразование обычного веб-адреса в более короткий. Например: https://bit.ly/2sad9ss22. Это удобно для отправки коротких сообщений, где есть ограничение на количество символов. Преимущества очевидны: короткий, мало символов, красивый, удобный для публикации и распространения.

Принцип работы

Предположим, что в браузере вводится следующий адрес: https://bit.ly/2sad9ss22:

  1. Сначала DNS-сервер преобразует имя bit.ly в IP-адрес.
  2. После получения IP-адреса (например, 192.168.0.1) DNS отправляет HTTP GET-запрос на этот адрес, чтобы получить информацию о коротком URL 2sad9ss22.
  3. Сервер bit.ly использует суффикс короткого URL 2sad9ss22 для получения соответствующего длинного URL.
  4. Запрос перенаправляется через HTTP 302 на соответствующий длинный URL https://cn.bing.com/.

Почему используется код 302?

Код 301 означает постоянное перенаправление, а код 302 — временное перенаправление. Короткие URL не меняются после создания, и хотя код 301 соответствует семантике HTTP, он также может снизить нагрузку на сервер. Однако невозможно подсчитать количество кликов по коротким URL. Невозможно провести дальнейший анализ больших данных. С другой стороны, код 302 позволяет подсчитывать клики, хотя и увеличивает нагрузку на сервер, но облегчает дальнейший анализ больших данных.

Реализация алгоритма в проекте В настоящее время существует два основных алгоритма реализации коротких URL:

  • Алгоритм с использованием последовательности автоинкремента.
  • Сжатый алгоритм. В этом проекте используется первый алгоритм с использованием последовательности автоинкремента.

Алгоритм с использованием последовательности автоинкремента Устанавливается идентификатор, который увеличивается автоматически. Одно десятичное число соответствует одному шестидесятидвухричному числу, то есть один к одному, поэтому дублирования не происходит. Используется особенность уменьшения количества символов при преобразовании из одной системы счисления в другую с большим основанием. Длина короткого URL обычно составляет шесть цифр, и каждая цифра состоит из 62 букв от a до z, A до Z и от 0 до 9, всего 62^6 ~= 568 миллиардов комбинаций.

Процесс работы проекта Помимо реализации алгоритма, проект также изучает функцию увеличения короткого URL на bitly и использует Redis для кэширования, чтобы уменьшить нагрузку на базу данных при создании коротких URL. На следующем графике показан процесс работы проекта, основанный на процессе работы сервиса коротких URL от Baidu. Хотя есть некоторые различия с кодом, они незначительны.

Настройка короткого URL Чтобы реализовать настройку короткого URL, необходимо добавить поле типа url_type в таблицу базы данных, которое будет использоваться для обозначения того, был ли короткий URL создан пользователем или системой автоматически. Если пользователь уже создал короткий URL, его тип будет установлен как «настраиваемый». При создании нового короткого URL, если обнаруживается, что соответствующий короткий URL уже занят, можно выбрать запись с настраиваемым типом и использовать её идентификатор для создания нового короткого URL. Таким образом, можно различать длинные URL, созданные пользователями, и автоматически созданные системой, а также избегать повторного использования идентификаторов, занятых настроенными короткими URL.

Таблица длины короткого URL

Длина Количество Диапазон
1 62 0–61
2 3844 62–3843
3 Около 23 тысяч 3844–23 8327
4 Около 1,4 миллиона 23 8328–14 776 335
5 Около 91 миллиона 14 776 336–91 613 2831
6 Около 568 миллиарда 91 613 2832–5 680 023 5583
Рекомендуется начинать настройку коротких URL с шести цифр, так как вероятность использования таких URL ниже.

Спутывание последовательности автоинкремента Поскольку алгоритм использует последовательность автоинкремента, легко определить следующий идентификатор. Поэтому необходимо спутать идентификаторы. В проекте используется класс EncodeUtils в пакете com.wujunshen.tinyurl.common.utils для выполнения этой задачи.

Описание таблицы базы данных Создаётся новая таблица tiny_url в базе данных и таблица tb_url_mapping. DDL-файл выглядит следующим образом:

create table tb_url_mapping
(
    url_id         bigint auto_increment comment '主键'
        primary key,
    origin_url     varchar(300)                        not null comment '原始长链接',
    origin_url_md5 varchar(32)                         not null comment '长链接md5值',
    tiny_url       varchar(10)                         not null comment '短链接',
    url_type       int(1)    default 0                 not null comment '是系统自动生成还是自定义的短链接类型,系统: “system”,自定义: “custom”
0为system,1为custom 缺省为0',
    create_time    timestamp default CURRENT_TIMESTAMP not null on update CURRENT_TIMESTAMP comment '生成时间',
    update_time    timestamp default CURRENT_TIMESTAMP not null comment '最后更新时间',
    constraint tb_url_mapping_origin_url_md5_uindex
        unique (origin_url_md5),
    constraint tb_url_mapping_tiny_url_uindex
        unique (tiny_url)
);

Здесь объясняется, почему используются поля origin_url_md5 и создаются индексы: Поскольку необходимо предотвратить создание разных коротких URL для одного и того же длинного URL, нужно сначала проверить наличие соответствующей записи в базе данных для каждого длинного URL. Обычно это делается путём добавления индекса для длинного URL, но индекс занимает много места. Поэтому используется индекс для поля md5 длинного URL, которое занимает меньше места. Затем можно найти соответствующую запись, используя значение md5.

Использование кэша Redis Кэш Redis в этом проекте представляет собой простую структуру ключ-значение, где ключом является короткий URL, а значением — длинный URL. Цель использования кэша заключается в том, чтобы при переходе по короткому URL не обращаться к базе данных, а получать длинный URL непосредственно из кэша и выполнять перенаправление 302.

Дополнительные сведения Проект основан на Springboot версии 2.2.6.RELEASE. Hikari используется в качестве пула соединений с базой данных. Lombok используется для упрощения кода. Snowflake используется для генерации идентификаторов. Кластер Redis используется для кэширования. Интерфейс реализован с помощью Swagger. Также используются следующие зависимости:

	<groupId>com.wujunshen</groupId>
	<artifactId>swagger-spring-boot-starter</artifactId>
	<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
	<groupId>com.wujunshen</groupId>
	<artifactId>snowflake-spring-boot-starter</artifactId>
	<version>0.0.1-SNAPSHOT</version>
</dependency>
<dependency>
	<groupId>com.wujunshen</groupId>
	<artifactId>redis-spring-boot-starter</artifactId>
	<version>0.0.1-SNAPSHOT</version>
</dependency>`

Для тестирования используется JUnit5.

Комментарии ( 0 )

Вы можете оставить комментарий после Вход в систему

Введение

Я сам написал сервис коротких ссылок, он работает. Развернуть Свернуть
MulanPSL-2.0
Отмена

Обновления

Пока нет обновлений

Участники

все

Недавние действия

Загрузить больше
Больше нет результатов для загрузки
1
https://api.gitlife.ru/oschina-mirror/darkranger-tiny-url.git
git@api.gitlife.ru:oschina-mirror/darkranger-tiny-url.git
oschina-mirror
darkranger-tiny-url
darkranger-tiny-url
master