Soy nuevo en redis, por lo tanto, no sé más sobre sus complejos tecnicismos. Pero permítanme poner mi escenario aquí: estoy ejecutando dos sitios web desde el mismo servidor y quería que redis funcionara en ambos. Al buscar, descubrí que puedo hacer esto asignando un índice diferente a una base de datos diferente en la misma instancia del servidor, como se muestra a continuación:
//In my first website (development) Idatabase dbOfDev=_conn.GetDatabase(0); //In my second website (production) Idatabase dbOfProd=_conn.GetDatabase(1);Esto fue ideal para mí, ya que podía almacenar en caché mi base de datos en la misma instancia. Pero luego me topé con ¿Cuál es el punto de múltiples bases de datos de Redis? y ¿Cómo cambio entre la base de datos redis? enlaces que dicen "El uso de múltiples bases de datos en la misma instancia de servidor se desaconseja y está obsoleto ". Aunque estos enlaces intentan explicar la razón detrás de esto, siendo un principiante, todavía no puedo entender sus aspectos técnicos profundos.
¿Alguien puede explicar el motivo en términos más simples de por qué se desaconseja el uso de múltiples redis db de la misma instancia de servidor? Además, en términos más simples, ¿cómo puedo administrar el almacenamiento en caché de mis dos sitios web en el mismo servidor sin el enfoque mencionado anteriormente?
¿Cómo puedo administrar el almacenamiento en caché de mis dos sitios web en el mismo servidor sin el enfoque mencionado anteriormente?
Puede usar una etiqueta clave diferente para cada sitio web. Diga, nombre los dos sitios web como A y B Para todas las claves del sitio web A , asigne a cada clave un prefijo (etiqueta clave): A: . Por otro lado, asigne a cada clave para el sitio web B otro prefijo: B: . De esta manera, puede tener un espacio de nombres clave único para cada sitio web.
SET A:key1 val1 SET A:key2 val2 LPUSH B:key1 1 SADD B:key2 valTambién verifique esta respuesta para más soluciones.
¿Alguien puede explicar el motivo en términos más simples de por qué se desaconseja el uso de múltiples redis db de la misma instancia de servidor?
AFAIK, la característica de múltiples bases de datos NO es desanimado y obsoleto. Es un método para aislar espacios de nombres clave para diferentes aplicaciones. Sin embargo, el autor de Redis considera que los errores múltiples de la base de datos de Redis son mi peor decisión en el diseño de Redis , ya que hace que las partes internas de Redis sean más complejas.
Redis es de subproceso único , por lo que, en comparación con varias bases de datos, varias instancias de Redis pueden aprovechar varios núcleos. Si tiene varias bases de datos en una instancia de Redis, solo puede usar un núcleo. Además, la instancia de Redis en sí tiene poca huella de memoria, por lo que no necesita preocuparse por los costos de varias instancias de Redis.
Redis es muy rápido y normalmente el cuello de botella es el ancho de banda de la red, NO la CPU. Por lo tanto, normalmente NO PUEDE obtener demasiada ganancia al usar varias instancias de Redis. Sin embargo, si una de sus aplicaciones necesita ejecutar algunos comandos lentos en Redis y no quiere que bloquee otras aplicaciones, puede tener una instancia de Redis separada para la aplicación lenta y tener otra instancia de Redis para otras aplicaciones rápidas .
Tenga en cuenta también que Redis Cluster no admite varias bases de datos.
Personalmente, me gusta esta función de base de datos múltiple. Normalmente, si ejecuto una instancia de Redis, no Redis Cluster, colocaré mis datos en alguna base de datos que no sea la base de datos predeterminada, es decir, la base de datos 0, para evitar accidentalmente iniciar sesión en Redis y hacer cosas horribles en la base de datos predeterminada. También es muy fácil implementar un búfer doble con múltiples bases de datos, por ejemplo, escribir datos en una nueva base de datos, cuando haya terminado, use el comando SWAPDB para intercambiar la base de datos antigua y la nueva de forma automática y eficiente.
No lo es. Si está creando una aplicación multiinquilino, compatible con varios sitios web, tiene sentido. Y si uno de los sitios web necesita escalar más rápidamente, puede configurar una instancia (o clúster) diferente para ese solo y la migración es mucho más simple.