# Prefacio

Al crear [este sitio] (https://tstrs.me), utilicé ElasticSearch como la base de datos Redis como componente de caché, que se usó sin ningún problema al principio, y luego debido a la iteración de versiones, la adición de módulos y la mejora continua de las páginas. Los datos en muchos lugares deben llenarse con Redis, e incluso algunas páginas deben consultarse docenas o cientos de veces, lo que resulta en una velocidad de carga más lenta y una mayor carga del sistema. Este tema se centra en corregir errores del sitio web, optimizar la carga del sistema y ajustar las políticas de caché.

# Introducción a los módulos del sistema

Contenido corporal

Debido a que no planeé importar publicaciones de blog antiguas al nuevo sistema al principio, diseñé un nuevo formato de enlace de página, es decir: '\result\article ID', porque este ID es único y la longitud se fija en 20 bits, por lo que el par clave-valor (KV) que diseñé en el sistema de almacenamiento en caché es el ID del artículo: contenido del artículo, por ejemplo:

hXia44YBlyC2E8nCuWW5:[Contenido del artículo]

La ventaja de esto es que es muy simple y rápido, cuando necesita consultar si un artículo está en caché, puede verificar directamente el ID, hay, si no, se colocará en la base de datos y luego se lanzará a Redis.

Lecturas recomendadas

Más tarde, [Lectura recomendada] se agregó al costado de la página, inicialmente usando la consulta de popularidad de ElasticSearch, y luego sintió que la lista de popularidad básicamente no había cambiado y no tenía sentido, por lo que se cambió a retorno aleatorio, para que cada actualización cambiara. Pero cada consulta a ElasticSearch es lenta, así que uso la función randomkey de Redis, que puede devolver aleatoriamente una clave, y luego obtengo los detalles del artículo en función de la clave.

En primer lugar, el contenido recomendado aquí no se puede repetir, y en segundo lugar, debido a que mi sitio web es bilingüe en inglés y chino, no siempre puedo recomendar artículos en inglés en la página china, y viceversa.

Así que en este módulo utilicé un bucle while, un total de 10 entradas, cada vez que se obtiene y luego se devuelve inmediatamente después de la consulta, para determinar si el lenguaje es consistente con el contenido del cuerpo, si es consistente, suma y cuenta +1 hasta que el recuento llegue a 10. Algunas personas pueden no entender, lo siguiente es esta parte del código del módulo, ingrese L para el idioma: '''Java def getrandomkeyredis(l): #随机获取文章 idlist = []#id rawinfolist = []#详细内容 mientras que len(rawinfolist) < 11:#直到列表大于11停止 onepagesid = str(pagecache.randomkey(), 'utf-8')#从redis Obtiene aleatoriamente un retorno de datos y datos de byte a cadena Si no onepagesid en idlist :#不在列表内 pcs = getpc(onepagesid) #获取文章详情 if pcs['language'] == l :#语言一致 a = {['Detalles del artículo']}#构造返回 rawinfolist. Apéndice a) #将构造好的返回打包到组里面 idlist. Apéndice(onepagesid) #计数 Volver rawinfo_list

En primer lugar, la razón del lenguaje aquí, debe consultar cada vez para saber si se pueden usar estos datos, y se necesitan 30-40 veces para completar el retorno de construcción para cada consulta, pero aun así, es más rápido que usar ElasticSearch directamente.

### Mira otra cosa
Ahora he agregado "Mira otra cosa" en la parte inferior de la página del artículo, que es diferente de la barra lateral, es estilo tarjeta. Y en ese momento, para ser conveniente y rápido, la barra lateral devolvía solo cuatro campos: 'nombre, enlace, hora, popularidad', y tenía dos campos más, a saber, 'imagen de vista previa, introducción', para el cual hice un módulo separado, pero la parte del código era básicamente la misma con solo unos pocos cambios.
![](https://pic.saltyleo.com/i/17108282981.webp)

Aunque la interfaz es atractiva y el contenido es rico, debido a demasiadas consultas, cada página básicamente necesita 80-100ms para emitir, lo cual es inaceptable para mí, y las lecturas y escrituras frecuentes de IO harán que el sistema se retrase, lo que hace que la velocidad de acceso que no es rápida en sí misma sea aún más lenta.

Ese es el agujero que cavé antes, y recientemente los he optimizado todos. Las ideas de solución y el código real se comparten a continuación.

## SOLUCIÓN DE ERRORES
En primer lugar, este problema se reduce al hecho de que la arquitectura general no puede mantenerse al día con las necesidades de las iteraciones de versiones posteriores, y algunos módulos centrales deben refactorizarse para resolver este problema. En este sentido, levanté directamente la mesa y la volví a activar, en lugar de optimizar el código anterior, era mejor cortar rápidamente el desorden y refactorizar.

Me basé en los 10 artículos en el lado de mi página de detalles del artículo más 6 en la parte inferior, para un total de 16 conjuntos de información. Obtenga directamente 16 retornos aleatorios para el idioma correspondiente en la base de datos de ElasticSearch, y cada retorno solo obtiene 6 registros, a saber: 'nombre, enlace, hora, popularidad, mapa de vista previa, introducción', lo que ahorra memoria. El código de consulta es el siguiente:

es.search(index="why", body={"query":{"bool":{"must":{"multimatch":{"query":'tttt',"fields":['so']}},"filter":{"match":{"language":l}} ,"mustnot":{"match":{"edit":' Editando '}}}}},"from":0,"size":16,"sort": {"_script": {"script": "Math.random()","type": "number"}}})

Traducido a palabras humanas, es [dame el lenguaje de consulta de la base de datos con L y artículos que no están en edición, y devuelve aleatoriamente 16 datos]. El 'tttt' en la consulta es el parámetro de consulta genérico que establezco. Para resolver fundamentalmente el problema del idioma, separé directamente las bibliotecas Redis chino e inglés, para no perder tiempo de consulta.

Escriba el contenido de la consulta anterior en Redis, la clave clave que estoy usando en el momento actual, no la necesito de todos modos, solo la única.

def setrdm(l): #给redis添加一组缓存, correspondiente a la lengua correspondiente Si l == 'zh': zhrdmcache.set(round(time.time()),json.dumps(esact.random(l)),ex=3600) elif l == 'es': enrdmcache.set(round(time.time()),json.dumps(esact._random(l)),ex=3600)

También es muy simple de leer, y puede leer la lectura recomendada en el idioma correspondiente utilizando el siguiente código.

def getrdm(l): Obtener un conjunto de retornos aleatorios en #从 redis, correspondientes al idioma correspondiente
Si l == 'zh': return json.loads(zhrdmcache.get(zhrdmcache.randomkey())) elif l == 'es': return json.loads(enrdmcache.get(enrdm_cache.randomkey())) ```

Después de esta operación, cada página solo necesita consultar el cuerpo una vez, y una recomendación aleatoria, y el consumo total de tiempo puede estar básicamente dentro de los 10 ms.

# Posdata

Por lo tanto, cuanto más simples son las cosas, más rápido y es fácil desperdiciar rendimiento, y es posible que no sienta mucho cambio en un servidor con un rendimiento sólido, pero un poco de optimización en un servidor con una configuración más baja puede traer una gran mejora.