Estás viendo la documentación de Apigee Edge.
Ve a la
Documentación de Apigee X. información
El almacenamiento en caché es un proceso de almacenamiento de datos temporal en un área de almacenamiento llamado caché para referencia futura. El almacenamiento de datos en caché ofrece importantes beneficios de rendimiento por lo siguiente:
- Permite una recuperación de datos más rápida.
- Reduce el tiempo de procesamiento, ya que evita la regeneración de datos una y otra vez.
- Evita que las solicitudes a la API lleguen a los servidores de backend y, por lo tanto, reduce la sobrecarga en estos.
- Permite un mejor uso de los recursos del sistema o aplicación.
- Mejora los tiempos de respuesta de las API
Cuando tenemos que acceder frecuentemente a algunos datos que no cambian con demasiada frecuencia, que recomendamos usar una caché para almacenar esos datos.
Apigee Edge proporciona la capacidad de almacenar datos en caché durante el entorno de ejecución para lograr persistencia y rapidez y la recuperación de datos. La función de almacenamiento en caché está disponible a través de la política de PopulateCache, la política de LookupCache, la política InvalidateCache y la política ResponseCache.
En esta sección, veremos la política de Caché de respuesta. La política de Caché de respuesta de Apigee Edge te permite almacenar en caché las respuestas de los servidores backend. Si las aplicaciones cliente realizan solicitudes al mismo recurso de backend varias veces y el recurso se actualiza periódicamente, podemos almacenar estas respuestas en caché con esta política. La política ResponseCache ayuda a mostrar las respuestas almacenadas en caché y, en consecuencia, evita reenviar las solicitudes a los servidores de backend innecesariamente.
La política de caché de respuesta tiene los siguientes beneficios:
- Reduce la cantidad de solicitudes que llegan al backend.
- Reduce el ancho de banda de red.
- Mejora el rendimiento de las API y los tiempos de respuesta.
Antipatrón
La política ResponseCache te permite almacenar en caché las respuestas HTTP con cualquier código de estado posible, de forma predeterminada. Esto significa que tanto las respuestas correctas como las de error se pueden almacenar en caché.
A continuación, se muestra un ejemplo de política de Caché de respuesta con configuración predeterminada:
<!-- /antipatterns/examples/1-1.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServer ResponseCache</DisplayName> <CacheKey> <Key Fragment ref="request.uri" /></CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutInSec ref="flow.variable.here">600</TimeoutInSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> </ResponseCache>
La política ResponseCache almacena en caché las respuestas de error en su configuración predeterminada. Sin embargo, no se recomienda almacenar en caché las respuestas de error sin tener en cuenta las implicaciones adversas debido a lo siguiente:
- Situación 1: Se producen fallas temporales durante un período desconocido y seguimos enviando respuestas de error debido al almacenamiento en caché incluso después de que se solucione el problema.
O
- Situación 2: Las fallas se observarán durante un período fijo y, luego, tendremos que modificar el código para evitar las respuestas en caché una vez que se solucione el problema.
Analicemos estas dos situaciones con más detalle para explicarlo.
Situación 1: Falla temporal del backend o recurso
Si la falla es en el servidor de backend, se debe a uno de los siguientes motivos:
- Una falla temporal de la red
- El servidor de backend está muy ocupado y no puede responder a las solicitudes durante un período temporal
- El recurso de backend solicitado se puede haber quitado o no está disponible durante un período
- El servidor de backend responde con lentitud debido al tiempo de procesamiento alto durante un período temporal, etc.
En todos estos casos, las fallas pueden ocurrir durante un período desconocido y, luego, podemos comenzar a obtener respuestas exitosas. Si almacenamos en caché las respuestas de error, es posible que sigamos enviando respuestas de error a los usuarios, incluso si el problema con el servidor de backend se solucionó.
Situación 2: Falla prolongada o fija de backend o recursos
Si sabemos que la falla en el backend durará un período de tiempo fijo. Por ejemplo, sabes que:
- Un recurso de backend específico no estará disponible durante 1 hora
O
- El servidor de backend se quita o no está disponible durante 24 horas debido a una falla repentina del sitio, problemas de escalamiento, mantenimiento, actualización, etcétera.
Con esta información, podemos configurar el tiempo de caducidad de la caché de manera adecuada en la Caché de respuesta. para no almacenar en caché las respuestas de error por más tiempo. Sin embargo, una vez que el servidor o el recurso de backend esté disponible de nuevo, tendremos que modificar la política para evitar el almacenamiento en caché de las respuestas de error. Esto se debe a que, si hay una falla temporal o de uno fuera del servidor de backend, almacenaremos en caché la respuesta y tendremos el problema que se describió en la situación 1.
Impacto
- Almacenar en caché las respuestas de error puede provocar que se envíen respuestas de error incluso después de que se haya resuelto el problema en el servidor de backend
- Los usuarios pueden dedicar mucho esfuerzo a solucionar la causa de un problema sin saber que se genera por almacenar en caché las respuestas de error del servidor de backend.
Práctica recomendada
- No almacenes las respuestas de error en la caché de respuestas. Asegúrate de que el elemento
<ExcludeErrorResponse>
esté configurado comotrue
en la política ResponseCache para evitar que las respuestas de error se almacenen en caché, como se muestra en el siguiente fragmento de código. Con esta configuración, solo se almacenarán en caché las respuestas de los códigos de éxito predeterminados del 200 al 205 (a menos que se modifiquen los códigos de éxito).<!-- /antipatterns/examples/1-2.xml --> <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <ResponseCache async="false" continueOnError="false" enabled="true" name="TargetServerResponseCache"> <DisplayName>TargetServerResponseCache</DisplayName> <CacheKey> <KeyFragment ref="request.uri" /> </CacheKey> <Scope>Exclusive</Scope> <ExpirySettings> <TimeoutinSec ref="flow.variable.here">600</TimeoutinSec> </ExpirySettings> <CacheResource>targetCache</CacheResource> <ExcludeErrorResponse>true</ExcludeErrorResponse> </ResponseCache>
- Si tienes el requisito de almacenar en caché las respuestas de error por algún motivo específico, puedes determinar la duración máxima/exacta para la cual se observará el error (si es posible):
- Configura la hora de vencimiento de forma adecuada para asegurarte de no almacenar en caché las respuestas de error mayor que el tiempo durante el que se puede ver la falla.
- Usa la política ResponseCache para almacenar en caché las respuestas de error sin el elemento
<ExcludeErrorResponse>
.
Haz esto solo si estás completamente seguro de que la falla del servidor de backend no es por un período breve o temporal.
- Apigee no recomienda almacenar en caché respuestas 5xx de servidores de backend.