El uso de la caché Redis mejora enormemente el rendimiento y la eficiencia de las aplicaciones, especialmente para consultas de datos. Pero al mismo tiempo, también trae algunos problemas. Entre ellos, el problema más importante es la consistencia de los datos, que es estrictamente irresoluble. Si se requiere consistencia de datos, entonces no se puede usar caché.
Otros problemas típicos son la penetración de cachés, la avalancha de cachés y la ruptura de cachés. Actualmente, también existen soluciones más populares en la industria. Este artículo no pretende resolver estos tres problemas de forma más perfecta, ni tampoco subvertir las soluciones populares en la industria. En su lugar, demostraremos estos tres fenómenos problemáticos a partir de la operación real del código. La razón de hacer esto es que es difícil tener un concepto muy vívido en la cabeza solo mirando la explicación académica de estos problemas, y con demostraciones reales de código puedes profundizar en tu comprensión y comprensión de estos problemas.
Penetración de caché
La penetración de caché se refiere a consultar datos que no existen en una base de datos. Si la clave no existe o ha expirado, se consulta la base de datos y los objetos consultados se almacenan en la caché. Si el objeto de consulta de la base de datos está vacío, no se almacena en caché.
Flujo de código
- pasa el ID de clave primaria del objeto
- Obtén el objeto de la caché según la clave
- Si el objeto no está vacío, devuelve directamente
- Si el objeto está vacío, realiza una consulta a la base de datos
- Si el objeto consultado desde la base de datos no está vacío, ponlo en la caché (establece el tiempo de caducidad). Imagina esta situación, ¿qué pasaría si el parámetro pasado fuera -1? Este -1 es un objeto que no debe existir. La base de datos será consultada cada vez, y cada consulta estará vacía, y no se almacenará en caché cada vez. Si hay un ataque malicioso, esta vulnerabilidad puede aprovecharse para presionar la base de datos o incluso sobrepasarla. Incluso si se usa UUID, es fácil encontrar una CLAVE inexistente y atacar.
En mi trabajo, utilizo el método de almacenar en caché valores nulos, es decir, el paso 5 en el [proceso de código], si el objeto consultado desde la base de datos está vacío, también se introduce en la caché, pero el tiempo de caducidad de la caché establecido es corto, como fijarlo en 60 segundos.
Avalancha de caché
Avalancha de caché se refiere a la expiración del conjunto de caché durante un determinado periodo de tiempo.
Una de las razones de la avalancha, por ejemplo, al escribir este artículo es que pronto serán las cero del día doce, y pronto habrá una oleada de compras rápidas. Luego, a la una de la madrugada, el alijo de este lote de mercancías expirará. La consulta de acceso para este lote de bienes recae en la base de datos, y para la base de datos habrá picos de presión periódicos.
Cuando Xiaobian realiza proyectos de comercio electrónico, generalmente adopta diferentes categorías de bienes y almacena en caché distintos ciclos. Bienes en la misma categoría, más un factor aleatorio. De este modo, el tiempo de caducidad de la caché puede dispersarse tanto como sea posible, y el tiempo de caché de los productos en categorías populares es más largo, y el tiempo de caché de los productos en categorías impopulares es más corto, lo que también puede ahorrar recursos al servicio de caché.
De hecho, la expiración centralizada no es muy fatal, y la avalancha de caché más fatal es que un nodo del servidor de caché se cae o se desconecta. Como la avalancha de caché que ocurre de forma natural debe crearse en un cierto periodo de tiempo, la base de datos puede soportar la presión, y en ese momento, la base de datos también puede soportar la presión. No es más que presión periódica sobre la base de datos. El tiempo de inactividad del nodo de servicio de caché genera una presión impredecible sobre el servidor de base de datos, y es probable que sobrepase la base de datos en un instante.
Desglose de caché
La ruptura de caché se refiere a una clave que está muy caliente, que constantemente transporta una gran concurrencia; la gran concurrencia se concentra en acceder a este punto; cuando esta clave falla, la gran concurrencia continua atraviesa la caché y solicita directamente la base de datos, igual que perforar un agujero en una barrera.
Cuando Xiaobian realizaba proyectos de comercio electrónico, convirtió este producto en un "éxito".
De hecho, en la mayoría de los casos, este tipo de explosión es difícil de ejercer con una presión aplastante sobre el servidor de la base de datos. Hay pocas empresas que hayan alcanzado este nivel. Por lo tanto, el editor pragmático se ha preparado para los productos principales con antelación, de modo que la caché nunca expire. Aunque algunos productos fermenten hasta convertirse en caladas, pueden configurarse como que nunca caducan.
La carretera principal es sencilla, y el candado de rechazo mutuo de la llave mutex realmente no se usa.
|
Publicado en 19/11/2019 9:55:04
|
|
|
|
