El creador de los servicios de cadena corta es TinyURL , que fue el primer sitio web en proporcionar servicios de cadena corta. En la actualidad, hay muchos servicios de cadena corta en China: Sina (t.cn), Baidu (dwz.cn), Tencent (url.cn) y así sucesivamente.
Tengo que preguntar, ¿por qué usar cadenas cortas? Otro significado de esta pregunta es, ¿es necesario que existan servicios de cadena corta?
Parafraseando la respuesta del premio mayor: la existencia es razonable.
La racionalidad de la existencia de servicios de cadena corta
Hablemos primero de la racionalidad de la existencia de servicios de cadena corta.
La única ventaja de las cadenas cortas es que son cortas .
Los primeros usuarios de Weibo saben que cada Weibo solo puede tener un límite de 140 caracteres. Si desea compartir un enlace, debe reducir el texto de la descripción.
Del mismo modo, si desea incluir un enlace en un mensaje de marketing, debe considerar el costo. Si se trata de un teléfono móvil antiguo, también debe tener en cuenta que el usuario puede recibir tres mensajes cortos desconectados, lo que afectará seriamente el alcance y el clic de los mensajes cortos.
En este caso, si el enlace es lo suficientemente corto, otro contenido puede ser más rico. Sin embargo, podemos definir enlaces de diferentes longitudes según los diferentes negocios y, para satisfacer otras necesidades (por ejemplo, datos estadísticos de marketing), agregaremos parámetros a los enlaces ordinarios. Por lo tanto, nació el enlace corto. Al redireccionar, puede usar un enlace corto para reemplazar otro enlace. Por ejemplo , puede redirigir a través de un enlace de 20 caracteres como http://t.cn/A6ULvJho . Al enlace original con una longitud de 146 caracteres https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html?spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989 .
Los dos ejemplos anteriores demuestran el valor de las cadenas cortas. Resumimos los usos adicionales de varias cadenas cortas:
-
Enviar mensajes de texto de marketing ahorra más dinero: el vínculo se acorta, la longitud del mensaje de texto se reduce y el costo del mensaje de texto que se debe pagar se reduce. Por ejemplo, el vínculo corto anterior tiene 20 caracteres y el vínculo original tiene 146 caracteres. La diferencia es todo dinero.
-
Convertido a código bidimensional, puede ser más reconocible. Por ejemplo, las dos imágenes de código bidimensional a continuación son del mismo tamaño, porque el número de contenidos es diferente, la densidad de la celda también es diferente.
-
Flexible y configurable, porque el enlace original del salto de enlace corto ha sufrido una redirección. Si encuentra que hay un problema en el enlace original en un momento determinado, o necesita saltar a otro lugar, puede modificar el redireccionamiento. dirección de destino. Esto es muy beneficioso para la entrega de material sin conexión. Por ejemplo, si ya ha colocado un material de código bidimensional. En este momento, descubre que desea saltar a otros sitios web o actividades. Solo necesita modificar la dirección de destino de la cadena corta en lugar de sustituir todos los materiales que se han colocado.
El principio de cadena corta
De hecho, como se mencionó anteriormente, el enlace corto se realiza redirigiendo el servidor al enlace original. Observemos la cadena corta de Sina Weibo, la consola ejecuta el comando curl -i http://t.cn/A6ULvJho, y los resultados son los siguientes:
HTTP/1.1 302 Found
Date: Thu, 30 Jul 2020 13:59:13 GMT
Content-Type: text/html;charset=UTF-8
Content-Length: 328
Connection: keep-alive
Set-Cookie: aliyungf_tc=AQAAAJuaDFpOdQYARlNadFi502DO2kaj; Path=/; HttpOnly
Server: nginx
Location: https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html??spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989
<HTML>
<HEAD>
<TITLE>Moved Temporarily</TITLE>
</HEAD>
<BODY BGCOLOR="#FFFFFF" TEXT="#000000">
<H1>Moved Temporarily</H1>
The document has moved <A HREF="https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html??spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989">here</A>.
</BODY>
</HTML>
Como se puede ver en la información anterior, Sina ha realizado un salto 302 y también ha devuelto el contenido HTML para el ajuste manual de compatibilidad. Todo el proceso interactivo es el siguiente:
Método de generación de cadena corta
Según el número de páginas de información estadística , actualmente los 58 millones de páginas web del mundo, el valor de Java int de como máximo 2 ^ 32 = 4294967296 <4,3 mil millones <5,8 mil millones, el valor largo es 2 ^ 64> 5,8 mil millones. Entonces, si usa números, int apenas puede admitir (después de todo, no todas las URL llamarán a los servicios de cadena corta para crear cadenas cortas). Usar long es más seguro, pero causará una pérdida de espacio. El tipo específico que se usará necesita ser juzgado de acuerdo con el negocio.
Sina Weibo usa una cadena de 8 bits para representar el enlace original. Esta cadena puede entenderse como la representación hexadecimal 62 de un número, 62 ^ 8 = 3521614606208> 352.1 mil millones> 5.8 mil millones, es decir, puede resolver las URL conocidas actualmente en el mundo. La base 62 es un número que consta de 10 números + (az) 26 letras minúsculas + (AZ) 26 letras mayúsculas.
Método de generación 1: Hash
Tomar el valor hash del enlace original es una forma de pensar relativamente sencilla. Hay muchos algoritmos prefabricados que se pueden implementar, pero hay un problema que no se puede evitar: las colisiones de hash, por lo que es más importante elegir un algoritmo con una tasa de colisión baja.
Se recomienda el algoritmo MurmurHash . Este algoritmo es una función hash no cifrada y es adecuado para operaciones generales de recuperación de hash. Actualmente, Redis, Memcached, Cassandra, HBase y Lucene utilizan este algoritmo.
Con la ayuda de MurmurHash en Guayaba:
final String url = "https://www.howardliu.cn/how-to-use-branch-efficiently-in-git/index.html?spm=5176.12825654.gzwmvexct.d118.e9392c4aP1UUdv&scm=20140722.2007.2.1989";
final HashFunction hf = Hashing.murmur3_128();
final HashCode hashCode = hf.newHasher().putString(url, Charsets.UTF_8).hash();
final int hashCodeAsInt = hashCode.asInt();// 这里选择返回 int 值，也可以选择返回 long 值
System.out.println(hashCodeAsInt);// 输出的结果是：1810437348，转换成 62 进制是：1Ywpso
Para el problema de la colisión, la forma más sencilla de pensar es que si ocurre una colisión, adjunte una cadena especial a la URL original hasta que se evite la colisión. La operación específica es la siguiente:
Método de generación 2: emisor de número unificado
No importa lo que sea, asigne un ID a través del emisor unificado centralizado. Este ID es el contenido de la cadena corta. Por ejemplo, el primero es https://tinyurl.com/1 y el segundo es https : //tinyurl.com/2, etc. Por supuesto, algunos algoritmos de ID distribuidos pueden tener un número de serie muy largo. Para obtener un circuito más corto, también puede convertirlo en una cadena de 62 bases.
- Redis de crecimiento automático: Redis tiene un buen rendimiento y una sola máquina puede admitir solicitudes de más de 10 W. Si se utiliza como emisor, se debe considerar la persistencia de Redis y la recuperación ante desastres.
- Clave primaria autoincrementable de MySQL: este esquema es similar al esquema de Redis. Utiliza el recordatorio de la clave primaria autoincrementable de la base de datos para garantizar que las ID no se repitan y se crean de forma automática y continua.
- Snowflake: Este es un algoritmo de generación de secuencia de ID que se usa ampliamente en la actualidad. Leaf de Meituan es un servicio de encapsulación y actualización para este algoritmo. Pero este algoritmo se basa en el reloj del servidor, si hay un reloj atrasado, puede haber conflictos de ID. (Algunas personas pensarán que el valor de la secuencia en milisegundos es el cuello de botella de este algoritmo. Dicho esto, este algoritmo solo proporciona una idea. Si cree que la longitud de la secuencia no es suficiente, agréguela usted mismo, pero el nivel de un millón el servicio por segundo es realmente malo. ¿Es mucho?)
- y así. . .
Habrá un artículo separado que presentará el emisor del número unificado en el seguimiento. Después de eso, lo modificaré aquí y adjuntaré un enlace, o puede seguirme (WeChat ID: Watching the Mountain Lodge) para obtener información de primera mano .
Para el emisor unificado, otra pregunta que debe resolverse es: si el mismo enlace original, ¿debería devolver la misma cadena corta o una cadena corta diferente?
La respuesta es que el mismo enlace original devolverá diferentes enlaces cortos según dimensiones como usuarios y ubicaciones. Si se considera que las dimensiones son todas iguales, se devuelve la misma cadena corta. La ventaja de esto es que podemos hacer estadísticas basadas en clics de cadena corta y solicitar información. Para las cadenas cortas, lo que sacrificamos es solo un poco de almacenamiento y cálculos, pero la información recopilada es invaluable.
Almacenamiento de cadena corta
Generalmente, existen dos tipos de almacenamiento de datos: base de datos relacional o base de datos NoSQL. Con la lógica de creación anterior, el almacenamiento es una cuestión de rutina. La declaración de construcción de la tabla almacenada en MySQL se da a continuación:
CREATE TABLE IF NOT EXISTS tiny_url
(
sid INT AUTO_INCREMENT PRIMARY KEY,
create_time DATETIME DEFAULT CURRENT_TIMESTAMP NULL,
update_time TIMESTAMP DEFAULT CURRENT_TIMESTAMP NULL ON UPDATE CURRENT_TIMESTAMP,
version INT DEFAULT 0 NULL COMMENT '版本号',
tiny_url VARCHAR(10) NULL COMMENT '短链',
original_url TEXT NOT NULL COMMENT '原始链接',
# 其他附加信息
creator_ip INT DEFAULT 0 NOT NULL,
creator_user_agent TEXT NOT NULL,
# 用户其他信息，用于后续统计，对于这些数据，只要存储影响创建短链的必要字段就行，其他的都可以直接发送到数据服务中
instance_id INT DEFAULT 0 NOT NULL,
# 创建短链服务实例ID
state TINYINT DEFAULT 1 NULL COMMENT '-1无效 1有效'
);
En una frase larga, el almacenamiento debe considerar el nivel de datos y planificar de antemano si es necesario dividirlos en tablas y bases de datos.
Solicitud de cadena corta
Una vez que se completa el almacenamiento, es hora de usarlo a continuación.
La práctica habitual es buscar los datos del almacenamiento en función de la cadena de cadena corta solicitada y luego devolver la redirección HTTP a la dirección original. Si usa una base de datos relacional para el almacenamiento, generalmente necesita crear índices para campos de cadena corta y, para evitar que la base de datos se convierta en un cuello de botella, la base de datos también allanará el camino a través del almacenamiento en caché en el frente. Además, para mejorar el uso racional de la caché, los datos de cadena corta no activos generalmente se eliminan a través del algoritmo LRU. El proceso es el siguiente:
El filtro de floración en la imagen es para evitar la ruptura de la caché y causar una presión excesiva en el servidor.
Hay otra pregunta aquí: cuando HTTP devuelve el código de redirección, use 301 o 302, ¿por qué Sina Weibo devuelve 302 en lugar de la redirección 301 más semántica? (Para los estudiantes que no saben mucho sobre los códigos de estado HTTP, pueden obtener más información en el "Resumen del código de estado HTTP" ).
- 301, representa una redirección permanente. En otras palabras, una vez que el navegador obtiene la dirección de redireccionamiento para la primera solicitud, todas las solicitudes posteriores obtendrán directamente la dirección de redireccionamiento del caché del navegador y no volverán a solicitar servicios de cadena corta. Esto puede reducir efectivamente la cantidad de solicitudes de servicio y reducir la carga del servidor, pero debido a que los navegadores posteriores ya no envían solicitudes al backend, no se puede obtener la cantidad real de clics.
- 302, que representa una redirección temporal. Es decir, cada vez que el navegador iniciará una solicitud al servidor para obtener una nueva dirección, aunque aumentará la presión sobre el servidor, pero hoy con exceso de hardware, esta presión no vale la pena mencionarla frente a los datos. Por lo tanto, la redirección 302 es la primera opción para los servicios de cadena corta.
para resumir
El servicio de cadena corta es relativamente simple y no tiene mucha lógica de negocios, examina principalmente la comprensión del diseño común de sistemas distribuidos y también es una pregunta que se usa a menudo en el proceso de entrevistas. Aquí es solo para brindarle algunas ideas de diseño. El emisor (ID distribuido), el filtro Bloom, MurmurHash, etc. involucrados en el artículo no son demasiado detallados, porque cada uno de ellos no está en pocas palabras para explicarlo, y necesitas resolverlo tú mismo.
Página de inicio personal: https://www.howardliu.cn
Publicación de blog personal: Cómo diseñar un servicio de cadena corta en la serie de diseño de
sistemas Página de inicio de CSDN: http://blog.csdn.net/liuxinghao
Publicación de blog de CSDN: Cómo diseñar un Servicio de cadena corta en la serie de diseño de sistemas Servicio de cadena