Tabla de contenido
Publicar y suscribirse a Redis
Consulte las notas escritas por el bloguero en la estación b cuando conoció al dios loco. Conexión de Blogger: enlace . La
publicación y suscripción de Redis (pub / sub) es un modo de comunicación de mensajes: el remitente (pub) envía un mensaje y el suscriptor (sub) recibe el mensaje. WeChat,
Weibo, ¡sistema de seguimiento!
Los clientes de Redis pueden suscribirse a cualquier número de canales.
Diagrama de suscripción / publicación de mensajes: el
primero: el remitente del mensaje, el segundo: el canal y el tercero: ¡el suscriptor del mensaje!
mando
prueba
Segmento de suscripción:
127.0.0.1:6379> subscribe chaoyang //订阅一个频道chaoyang
Reading messages... (press Ctrl-C to quit)
1) "subscribe"
2) "chaoyang"
3) (integer) 1
#等待读取推送的信息
1) "message" //消息
2) "chaoyang" //哪个频道的消息
3) "hello,chaoyang" //消息的具体内容
1) "message"
2) "chaoyang"
3) "hello,redis"
Envío final:
[root@iZbp1ilygspotccpj3hnyaZ bin]# redis-cli -p 6379
127.0.0.1:6379> publish chaoyang "hello,chaoyang" //发布者发布消息到频道
(integer) 1
127.0.0.1:6379> publish chaoyang "hello,redis" //发布者发布消息到频道
(integer) 1
principio
Redis se implementa en C. Al analizar el archivo pubsub.c en el código fuente de Redis, podemos comprender la implementación subyacente del mecanismo de publicación y suscripción, a fin de profundizar nuestra comprensión de Redis.
Redis implementa funciones de publicación y suscripción a través de comandos como PUBLISH, SUBSCRIBE y PSUBSCRIBE.
escenas a utilizar:
- ¡Sistema de mensajería en tiempo real!
- ¡Charla de hechos! (¡El canal se usa como sala de chat y la información se muestra a todos!)
- ¡Puedes suscribirte o seguir el sistema!
Para escenarios un poco más complejos, usaremos el middleware de mensajes MQ (...)
Replicación maestro-esclavo de Redis
concepto
La replicación maestro-esclavo se refiere a copiar los datos de un servidor Redis a otros servidores Redis. El primero se llama nodo maestro
(maestro / líder) y el segundo se llama nodo esclavo (esclavo / seguidor); la replicación de datos es unidireccional y solo puede ser desde el nodo maestro al nodo esclavo.
El maestro está escribiendo principalmente, el esclavo está leyendo principalmente.
De forma predeterminada, cada servidor Redis es el nodo maestro;
y un nodo maestro puede tener varios nodos esclavos (o ningún nodo esclavo), pero un nodo esclavo solo puede tener un nodo maestro. ()
La función de la replicación maestro-esclavo incluye principalmente:
1. Redundancia de datos: la replicación maestro-esclavo realiza una copia de seguridad en caliente de los datos, que es un método de redundancia de datos además de la persistencia.
2. Recuperación de fallas: cuando el nodo maestro tiene un problema, el nodo esclavo puede proporcionar servicios para lograr una rápida recuperación de fallas, de hecho, es una especie de
redundancia de servicio .
3. Equilibrio de carga: sobre la base de la replicación maestro-esclavo, con la separación de lectura y escritura, el nodo maestro puede proporcionar el servicio de escritura y el nodo esclavo proporciona el servicio de lectura
(es decir, la aplicación se conecta al nodo maestro al escribir datos de Redis, y la aplicación se conecta al nodo esclavo al leer datos de Redis. Nodos) para compartir la carga del servidor; especialmente en
el escenario de escribir menos y leer más, compartir la carga de lectura entre varios nodos esclavos puede aumentar en gran medida la simultaneidad del servidor Redis.
4. Piedra angular de alta disponibilidad (clúster): además de las funciones anteriores, la replicación maestro-esclavo también es la base para la implementación de centinelas y clústeres. Por lo tanto, la replicación maestro-esclavo
es la base para la alta disponibilidad de Redis.
En términos generales, para usar Redis en proyectos de ingeniería, es absolutamente imposible usar solo un Redis (tiempo de inactividad) por las siguientes razones:
1. Estructuralmente, un solo servidor Redis tendrá un solo punto de falla y un servidor Necesita manejar todo la carga de solicitud, la presión es
alta
2. En términos de capacidad, la capacidad de memoria de un solo servidor Redis es limitada Incluso si la capacidad de memoria de un servidor Redis es 256G, toda la
memoria no se puede usar como memoria de almacenamiento Redis. En términos generales, un solo servidor Redis tiene una capacidad de memoria limitada . La memoria máxima utilizada por Redis no debe exceder los 20G.
Configuración del entorno
Solo es necesario configurar la biblioteca esclava, ¡no es necesario configurar la biblioteca principal!
127.0.0.1:6379> info replication //查看当前库的信息
# Replication
role:master //角色 master
connected_slaves:0 //没有从机
master_replid:67c4fa8812b819d22ebec58cce90cab3def77805
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:0
master_repl_meaningful_offset:0
second_repl_offset:-1
repl_backlog_active:0
repl_backlog_size:1048576
repl_backlog_first_byte_offset:0
repl_backlog_histlen:0
127.0.0.1:6379>
prueba
Copie tres archivos de configuración, modifique la información correspondiente
1, número de puerto
2, nombre de pid
3, nombre de archivo de registro
4, nombre de dump.rdb
[root@iZbp1ilygspotccpj3hnyaZ sconfig]# ls
redis.conf
[root@iZbp1ilygspotccpj3hnyaZ sconfig]# cp redis.conf redis79.conf
[root@iZbp1ilygspotccpj3hnyaZ sconfig]# cp redis.conf redis80.conf
[root@iZbp1ilygspotccpj3hnyaZ sconfig]# cp redis.conf redis81.conf
[root@iZbp1ilygspotccpj3hnyaZ sconfig]# ls
redis79.conf redis80.conf redis81.conf redis.conf
Una vez completada la modificación, inicie nuestros 3 servidores redis, que se pueden ver a través de la información del proceso.
Un amo y dos esclavos
Por defecto, cada servidor redis es el nodo maestro: ¡
reconozca al jefe! Un maestro (79) dos esclavos (80, 81)
127.0.0.1:6380> slaveof 127.0.0.1 6379 //slaveof host 6379
OK
127.0.0.1:6380> info replication
# Replication
role:slave //当前角色是从机
master_host:127.0.0.1 //可以的看到主机的信息
master_port:6379
master_link_status:up
master_last_io_seconds_ago:10
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:6baf8a28749017e3cb6582e1b019b7f069014c81
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
master_repl_meaningful_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:14
127.0.0.1:6380>
#在主机中查看！
127.0.0.1:6379> info replication
# Replication
role:master
connected_slaves:1 //多了从机的配置
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=0 //多了从机的配置
master_replid:6baf8a28749017e3cb6582e1b019b7f069014c81
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
master_repl_meaningful_offset:0
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42
127.0.0.1:6379>
Si ambos están configurados, hay dos esclavos, la configuración
real maestro-esclavo debe estar configurada en el archivo de configuración, en este caso es permanente, el comando que usamos aquí es temporal!
detalle
El maestro puede escribir, pero el esclavo no puede escribir, ¡solo leer! ¡El esclavo guardará automáticamente toda la información y los datos del maestro!
Escritura de host: ¡El
esclavo solo puede leer el contenido!
Prueba: El maestro está desconectado y el esclavo todavía está conectado al maestro, pero no hay operación de escritura. En este momento, si el maestro regresa, ¡el esclavo todavía puede obtener directamente la información escrita por el maestro!
Si usa la línea de comando para configurar el maestro y el esclavo, si reinicia en este momento, ¡volverá a cambiar al host! ¡Mientras se convierta en esclavo, obtendrá inmediatamente el valor del maestro!
Principio de copia
Una vez que el esclavo se haya conectado correctamente al maestro, enviará un comando de sincronización de sincronización. El
maestro recibe el comando, inicia el proceso de guardado en segundo plano y recopila todos los comandos recibidos para modificar el conjunto de datos. Una vez ejecutado el proceso en segundo plano
, el maestro transmitirá el archivo de datos completo Vaya al esclavo y complete una sincronización completa.
Copia completa: después de que el servicio esclavo recibe los datos del archivo de la base de datos, los guarda y los carga en la memoria.
Replicación incremental: el maestro continúa pasando todos los nuevos comandos de modificación recopilados al esclavo para completar la sincronización.Sin
embargo, mientras el maestro se vuelva a conectar, ¡se ejecutará automáticamente una sincronización completa (replicación completa)! ¡Nuestros datos definitivamente se pueden ver en la máquina esclava!
Enlace capa por capa
¡Escriba una S en la última conexión M!
¡En este momento, nuestra replicación maestro-esclavo también se puede completar!
Si no hay jefe, ¿puede elegir un jefe en este momento? ¡A mano!
Conspirar para usurpar el trono
Si el host está desconectado, ¡no podemos usar el esclavo de nadie para convertirnos en el host! ¡Otros nodos pueden conectarse manualmente al último nodo maestro (manualmente)! Si reparan al jefe, ¡vuelva a conectarse!
Modo centinela
(Elección automática del modo jefe)
Visión general
El método de la tecnología de conmutación maestro-esclavo es: cuando el servidor maestro deja de funcionar, un servidor esclavo debe cambiarse manualmente al servidor maestro, lo que requiere una intervención manual, laboriosa y laboriosa, y hará que el servicio no esté disponible durante un período. de tiempo. Esta no es una forma recomendada. Más a menudo, damos prioridad al modo centinela. Redis ha proporcionado oficialmente la arquitectura Sentinel desde 2.8 para resolver este problema.
La versión automática que busca usurpar el trono puede monitorear si el host está fallando en segundo plano, si falla, automáticamente cambiará de la biblioteca a la biblioteca principal según el número de votos.
El modo centinela es un modo especial. En primer lugar, Redis proporciona el comando del centinela. El centinela es un proceso independiente. Como proceso, se ejecutará de forma independiente. El principio es que el centinela puede monitorear múltiples instancias de Redis en ejecución enviando comandos y esperando la respuesta del servidor de Redis.
¡prueba!
1. Configure el archivo de configuración de centinela sentinel.conf
#sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
¡El número 1 en la parte de atrás significa que el anfitrión está caído! Los esclavos votan para ver quién tiene éxito como anfitrión. ¡El que tenga más votos se convertirá en anfitrión!
2. Enciende el centinela
[root@iZbp1ilygspotccpj3hnyaZ bin]# redis-sentinel sconfig/sentinel.conf
1681:X 21 Nov 2020 12:43:32.590 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
1681:X 21 Nov 2020 12:43:32.590 # Redis version=6.0.1, bits=64, commit=00000000, modified=0, pid=1681, just started
1681:X 21 Nov 2020 12:43:32.590 # Configuration loaded
_._
_.-``__ ''-._
_.-`` `. `_. ''-._ Redis 6.0.1 (00000000/0) 64 bit
.-`` .-```. ```\/ _.,_ ''-._
( ' , .-` | `, ) Running in sentinel mode
|`-._`-...-` __...-.``-._|'` _.-'| Port: 26379
| `-._ `._ / _.-' | PID: 1681
`-._ `-._ `-./ _.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' | http://redis.io
`-._ `-._`-.__.-'_.-' _.-'
|`-._`-._ `-.__.-' _.-'_.-'|
| `-._`-._ _.-'_.-' |
`-._ `-._`-.__.-'_.-' _.-'
`-._ `-.__.-' _.-'
`-._ _.-'
`-.__.-'
1681:X 21 Nov 2020 12:43:32.591 # WARNING: The TCP backlog setting of 511 cannot be enforced because /proc/sys/net/core/somaxconn is set to the lower value of 128.
1681:X 21 Nov 2020 12:43:32.594 # Sentinel ID is 70c1c96bbf2f1d15fd3eeb0d4db9736f2850b91b
1681:X 21 Nov 2020 12:43:32.594 # +monitor master myredis 127.0.0.1 6379 quorum 1
1681:X 21 Nov 2020 12:43:32.595 * +slave slave 127.0.0.1:6380 127.0.0.1 6380 @ myredis 127.0.0.1 6379
1681:X 21 Nov 2020 12:43:32.597 * +slave slave 127.0.0.1:6381 127.0.0.1 6381 @ myredis 127.0.0.1 6379
Si el nodo maestro está desconectado, ¡se seleccionará un servidor al azar del esclavo en este momento! (¡Hay un algoritmo de votación en él!)
Registro de centinela
Si el host regresa en este momento, solo puede fusionarse con el nuevo host y usarse como esclavo. ¡Esta es la regla del modo centinela!
Modo centinela
Ventajas:
1. El clúster Sentinel, basado en el modelo de replicación maestro-esclavo, tiene todas las ventajas de la configuración maestro-esclavo
2. El maestro-esclavo se puede cambiar y la falla se puede transferir. La disponibilidad del sistema será mejor.
3. El modo centinela es el modo maestro-esclavo.¡Actualización, manual a automático, más robusto!
Desventajas:
1. Redis no es bueno. Expansión en línea, una vez que la capacidad del clúster alcanza el límite superior, la expansión en línea será muy problemática.
2. Darse cuenta de que la configuración del modo centinela es realmente muy problemático, ¡hay muchas opciones!
¡Configuración completa del modo centinela!
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 配置多少个sentinel哨兵统一认为master主节点失联 那么这时客观上认为主节点失联了
# sentinel monitor <master-name> <ip> <redis-port> <quorum> sentinel monitor mymaster 127.0.0.1 6379 2
# 当在Redis实例中开启了requirepass foobared 授权密码 这样所有连接Redis实例的客户端都要提供 密码
# 设置哨兵sentinel 连接主从的密码 注意必须为主从设置一样的验证密码
# sentinel auth-pass <master-name> <password>
sentinel auth-pass mymaster MySUPER--secret-0123passw0rd
# 指定多少毫秒之后 主节点没有应答哨兵sentinel 此时 哨兵主观上认为主节点下线 默认30秒
# sentinel down-after-milliseconds <master-name> <milliseconds>
sentinel down-after-milliseconds mymaster 30000
# 这个配置项指定了在发生failover主备切换时最多可以有多少个slave同时对新的master进行 同步， 这个数字越小，完成failover所需的时间就越长，
但是如果这个数字越大，就意味着越 多的slave因为replication而不可用。
可以通过将这个值设为 1 来保证每次只有一个slave 处于不能处理命令请求的状态。
# sentinel parallel-syncs <master-name> <numslaves>
sentinel parallel-syncs mymaster 1
# 故障转移的超时时间 failover-timeout 可以用在以下这些方面：
#1. 同一个sentinel对同一个master两次failover之间的间隔时间。
#2. 当一个slave从一个错误的master那里同步数据开始计算时间。直到slave被纠正为向正确的master那 里同步数据时。
#3.当想要取消一个正在进行的failover所需要的时间。
#4.当进行failover时，配置所有slaves指向新的master所需的最大时间。不过，即使过了这个超时，slaves依然会被正确配置为指向master，但是就不按parallel-syncs所配置的规则来了
# 默认三分钟
# sentinel failover-timeout <master-name> <milliseconds>
sentinel failover-timeout mymaster 180000
# SCRIPTS EXECUTION
#配置当某一事件发生时所需要执行的脚本，可以通过脚本来通知管理员，例如当系统运行不正常时发邮件通知 相关人员。
#对于脚本的运行结果有以下规则：
#若脚本执行后返回1，那么该脚本稍后将会被再次执行，重复次数目前默认为10
#若脚本执行后返回2，或者比2更高的一个返回值，脚本将不会重复执行。
#如果脚本在执行过程中由于收到系统中断信号被终止了，则同返回值为1时的行为相同。
#一个脚本的最大执行时间为60s，如果超过这个时间，脚本将会被一个SIGKILL信号终止，之后重新执行。
#通知型脚本:当sentinel有任何警告级别的事件发生时（比如说redis实例的主观失效和客观失效等等）， 将会去调用这个脚本，这时这个脚本应该通过邮件，SMS等方式去通知系统管理员关于系统不正常运行的信 息。调用该脚本时，将传给脚本两个参数，一个是事件的类型，一个是事件的描述。如果sentinel.conf配 置文件中配置了这个脚本路径，那么必须保证这个脚本存在于这个路径，并且是可执行的，否则sentinel无 法正常启动成功。
#通知脚本
# shell编程
# sentinel notification-script <master-name> <script-path>
sentinel notification-script mymaster /var/redis/notify.sh
# 客户端重新配置主节点参数脚本
# 当一个master由于failover而发生改变时，这个脚本将会被调用，通知相关的客户端关于master地址已 经发生改变的信息。
# 以下参数将会在调用脚本时传给脚本:
# <master-name> <role> <state> <from-ip> <from-port> <to-ip> <to-port> # 目前<state>总是“failover”,
# <role>是“leader”或者“observer”中的一个。
# 参数 from-ip, from-port, to-ip, to-port是用来和旧的master和新的master(即旧的slave)通 信的
# 这个脚本应该是通用的，能被多次调用，不是针对性的。
# sentinel client-reconfig-script <master-name> <script-path>
sentinel client-reconfig-script mymaster /var/redis/reconfig.sh # 一般都是由运维来配置！
Avalancha y penetración de caché de Redis
Penetración de caché
Concepto de penetración de caché
El concepto de penetración de caché es muy simple: el usuario quiere consultar un dato y encuentra que falta la base de datos de la memoria de redis, es decir, el caché no está afectado, por lo que el usuario consulta
la base de datos de la capa de persistencia. No se encontró nada, por lo que esta consulta falló. Cuando hay muchos usuarios, la caché falla (¡segunda
muerte!), Por lo que todos solicitan la base de datos de la capa de persistencia. Esto ejercerá mucha presión sobre la base de datos de la capa de persistencia, lo que equivale a la
penetración de la caché.
solución
Filtro
Bloom El filtro Bloom es una estructura de datos que almacena todos los posibles parámetros de consulta en forma de hash. Primero se verifica en la capa de control, y si no se cumplen, se descartan, evitando así la presión de consulta sobre el sistema de almacenamiento subyacente; después la capa se pierde, incluso el objeto vacío devuelto se almacenará en caché y se establecerá un tiempo de caducidad al mismo tiempo. El acceso posterior a estos datos se obtendrá de la caché, protegiendo la fuente de datos de back-end;
pero este método tiene dos preguntas:
1. Si el valor nulo se puede almacenar en caché, significa que la caché necesita más espacio para almacenar más claves, porque puede haber muchas
claves con valores nulos;
2. Incluso si el valor nulo está configurado para caducar Con el tiempo, seguirá habiendo inconsistencias entre los datos en la capa de caché y la capa de almacenamiento durante un período de tiempo, lo que
tendrá un impacto en las empresas que necesitan mantener la coherencia.
Desglose de la caché (la cantidad es demasiado grande, ¡la caché caduca!)
Visión general
Aquí debe prestar atención a la diferencia entre el desglose de la memoria caché. El desglose de la memoria caché se refiere a una clave que está muy activa. Constantemente tiene una gran concurrencia, y la gran concurrencia concentra el acceso a este punto. Cuando la clave se invalida, continúa Grande la concurrencia atraviesa la caché y solicita directamente la base de datos, al igual que cavar un agujero en una barrera.
Cuando una clave caduca, hay una gran cantidad de solicitudes de acceso simultáneas. Este tipo de datos generalmente son datos calientes. Debido a que la caché caduca, se accederá a la base de datos al mismo tiempo para consultar los datos más recientes y la caché se escribirá back, lo que hará que la base de datos se sobrecargue en un instante.
solución
Configuración de los datos del hotspot para que nunca caduquen
Desde la perspectiva del almacenamiento en caché, no hay un tiempo de vencimiento establecido, por lo que no habrá problemas después de que caduque la clave del hotspot.
Agregue bloqueos de exclusión mutua Bloqueos
distribuidos: use bloqueos distribuidos para asegurarse de que solo haya un hilo para consultar el servicio de back-end para cada clave al mismo tiempo, y otros hilos no tienen la autoridad para obtener el bloqueo distribuido, por lo que solo necesita esperar. Este método transfiere la presión de alta concurrencia a los bloqueos distribuidos, por lo que es una gran prueba para los bloqueos distribuidos.
Avalancha de caché
concepto
La avalancha de caché se refiere a un período de tiempo en el que la colección de caché expira y deja de ser válida. ¡Redis está caído!
Una de las razones de la avalancha, por ejemplo, al momento de escribir este artículo, será a la medianoche del Doble Doce, y pronto habrá una ola de compras de pánico. Esta ola de bienes se coloca en el caché en un de manera concentrada, asumiendo que el caché es una hora. Luego, a la una de la madrugada, caducó el alijo de este lote de productos. El acceso y la consulta de este lote de productos caen todos en la base de datos, para la base de datos, producirá picos de presión periódicos. Por lo tanto, todas las solicitudes llegarán a la capa de almacenamiento y el volumen de llamadas de la capa de almacenamiento aumentará considerablemente, lo que provocará que la capa de almacenamiento también cuelgue.
De hecho, la expiración centralizada no es muy fatal, una avalancha de caché más fatal es que un nodo del servidor de caché está inactivo o la red está desconectada. Debido a la avalancha de caché natural, la caché debe crearse en un período de tiempo determinado. En este momento, la base de datos también puede soportar la presión. No es más que una presión periódica sobre la base de datos. El tiempo de inactividad del nodo de servicio de caché causará una presión impredecible en el servidor de la base de datos y es muy probable que abrume la base de datos en un instante.
Solución
Alta disponibilidad de Redis
La implicación de esta idea es que, dado que es probable que redis se cuelgue, agregaré algunos redis más para que después de que uno se cuelgue, los otros puedan seguir funcionando, de hecho, es un clúster construido. (¡Más en vivo en diferentes lugares!)
Reducción del límite actual (¡explicado en SpringCloud!)
La idea de esta solución es controlar el número de subprocesos que leen la base de datos y escriben el caché bloqueando o haciendo cola después de que el caché falla. Por ejemplo, solo un subproceso puede consultar datos y escribir caché para una determinada clave, y otros subprocesos esperan.
Precalentamiento de datos
El significado del calentamiento de datos es que antes de la implementación formal, primero visito los datos posibles primero, de modo que parte de los datos a los que se puede acceder en una gran cantidad se carguen en la caché. Antes de que se produzca un gran acceso simultáneo, active manualmente la carga de diferentes claves en la caché, establezca diferentes tiempos de vencimiento y haga que los puntos de tiempo de invalidación de la caché sean lo más uniformes posible.