índice
Publicação e assinatura do Redis
Consulte as notas escritas pelo blogueiro na estação b quando conheceu o deus louco. Conexão do Blogger: link .
Publicação e assinatura do Redis (pub / sub) é um modo de comunicação de mensagens: o remetente (pub) envia uma mensagem e o assinante (sub) recebe a mensagem. WeChat,
Weibo, siga o sistema!
Os clientes Redis podem se inscrever em qualquer número de canais.
Diagrama de assinatura / publicação da mensagem: o
primeiro: o remetente da mensagem, o segundo: o canal e o terceiro: o assinante da mensagem!
comando
teste
Segmento de assinatura:
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"
Fim de envio:
[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
princípio
O Redis é implementado em C. Ao analisar o arquivo pubsub.c no código-fonte do Redis, podemos entender a implementação subjacente do mecanismo de publicação e assinatura, de modo a aprofundar nosso conhecimento do Redis.
O Redis implementa funções de publicação e assinatura por meio de comandos como PUBLISH, SUBSCRIBE e PSUBSCRIBE.
cenas a serem usadas:
- Sistema de mensagens em tempo real!
- Bate-papo de fato! (O canal é usado como uma sala de bate-papo e as informações são exibidas para todos!)
- Você pode se inscrever ou seguir o sistema!
Para cenários um pouco mais complexos, usaremos a mensagem de middleware MQ (...)
Replicação mestre-escravo Redis
conceito
A replicação mestre-escravo refere-se à cópia dos dados de um servidor Redis para outros servidores Redis. O primeiro é chamado de nó mestre
(mestre / líder) e o último é chamado de nó escravo (escravo / seguidor); a replicação de dados é unilateral e só pode ser do nó mestre para o nó escravo.
O Mestre está principalmente escrevendo, o Escravo está principalmente lendo.
Por padrão, cada servidor Redis é o nó mestre
e um nó mestre pode ter vários nós escravos (ou nenhum nó escravo), mas um nó escravo só pode ter um nó mestre. ()
O papel da replicação mestre-escravo inclui principalmente:
1. Redundância de dados: a replicação mestre-escravo realiza backups a quente de dados, que é um método de redundância de dados além da persistência.
2. Recuperação de falhas: quando o nó mestre tem um problema, o nó escravo pode fornecer serviços para obter uma recuperação rápida de falhas; na verdade, é uma espécie de
redundância de serviço .
3. Balanceamento de carga: Com base na replicação mestre-escravo, com a separação de leitura e gravação, o nó mestre pode fornecer o serviço de gravação e o nó escravo fornece o serviço de leitura
(ou seja, o aplicativo se conecta ao nó mestre ao gravar dados do Redis, e o aplicativo se conecta ao nó escravo ao ler os dados do Redis. Nós) para compartilhar a carga do servidor; especialmente no
cenário de escrever menos e ler mais, compartilhar a carga de leitura por vários nós escravos pode aumentar muito a simultaneidade do servidor Redis.
4. Pedra fundamental de alta disponibilidade (cluster): além das funções acima, a replicação mestre-escravo também é a base para a implementação de sentinelas e clusters, portanto, a replicação mestre-escravo
é a base para a alta disponibilidade do Redis.
De modo geral, para usar o Redis em projetos de engenharia, é absolutamente impossível usar apenas um Redis (tempo de inatividade) pelos seguintes motivos:
1. Estruturalmente, um único servidor Redis terá um único ponto de falha, e um servidor precisa lidar com todos a carga solicitada, a pressão é
alta;
2. Em termos de capacidade, a capacidade de memória de um único servidor Redis é limitada. Mesmo que a capacidade de memória de um servidor Redis seja 256G, toda a
memória não pode ser usada como memória de armazenamento Redis. De modo geral, um único servidor Redis tem uma capacidade de memória limitada . A memória máxima usada pelo Redis não deve exceder 20G.
Configuração do ambiente
Só precisa configurar a biblioteca escrava, não há necessidade de configurar a 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>
teste
Copie três arquivos de configuração, modifique as informações correspondentes
1, número da porta
2, nome do pid
3, nome do arquivo de log
4, nome do 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
Após a conclusão da modificação, inicie nossos 3 servidores redis, que podem ser visualizados através das informações do processo!
Um mestre e dois escravos
Por padrão, todo servidor redis é o nó mestre:
reconheça o chefe! Um mestre (79) dois escravos (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>
Se ambos estiverem configurados, existem dois escravos.A
configuração mestre-escravo real deve ser configurada no arquivo de configuração.Neste caso, é permanente.O comando que usamos aqui é temporariamente!
detalhe
O mestre pode escrever, mas o escravo não pode escrever, apenas ler! Todas as informações e dados do mestre serão salvos automaticamente pelo escravo!
Escrita no host: O
escravo só pode ler o conteúdo!
Teste: O mestre está desconectado e o escravo ainda está conectado ao mestre, mas não há operação de escrita. Neste momento, se o mestre voltar, o escravo ainda pode obter diretamente as informações escritas pelo mestre!
Se você usar a linha de comando para configurar o mestre e o escravo, se você reiniciar neste momento, ele mudará de volta para o host! Enquanto se tornar um escravo, ele obterá imediatamente o valor do mestre!
Princípio de cópia
Depois que o escravo for conectado com sucesso ao mestre, ele enviará um comando de sincronização de sincronização. O
mestre recebe o comando, inicia o processo de salvamento em segundo plano e coleta todos os comandos recebidos para modificar o conjunto de dados. Após a execução do processo em segundo plano
, o mestre irá transmitir todo o arquivo de dados Vá para o escravo e conclua uma sincronização completa.
Cópia completa: Depois que o serviço escravo recebe os dados do arquivo do banco de dados, ele os salva e carrega na memória.
Replicação incremental: O mestre continua a passar todos os novos comandos de modificação coletados para o escravo, por sua vez, para completar a sincronização.
No entanto, enquanto o mestre for reconectado, uma sincronização completa (replicação completa) será executada automaticamente! Nossos dados podem definitivamente ser vistos na máquina escrava!
Link camada por camada
Escreva um S na última conexão M!
Neste momento, nossa replicação mestre-escravo também pode ser concluída!
Se não houver chefe, você pode escolher um chefe agora? Manualmente!
Conspirar para usurpar o trono
Se o host estiver desconectado, não podemos usar escravo de ninguém para nos tornar o host! Outros nós podem se conectar manualmente ao nó mestre mais recente (manualmente)! Se o chefe for reparado, reconecte!
Modo sentinela
(Seleção automática do modo de chefe)
Visão geral
O método da tecnologia de comutação mestre-escravo é: quando o servidor mestre fica inativo, um servidor escravo precisa ser trocado manualmente para o servidor mestre, o que requer intervenção manual, trabalhosa e trabalhosa, e fará com que o serviço fique indisponível por um período de tempo. Esta não é uma forma recomendada. Mais frequentemente, damos prioridade ao modo sentinela. O Redis forneceu oficialmente a arquitetura Sentinel desde a versão 2.8 para resolver esse problema.
A versão automática que visa usurpar o trono pode monitorar se o host está com defeito em segundo plano.Se falhar, ele mudará automaticamente da biblioteca para a biblioteca principal de acordo com o número de votos.
O modo sentinela é um modo especial. Em primeiro lugar, o Redis fornece o comando da sentinela. A sentinela é um processo independente. Como processo, será executado de forma independente. O princípio é que a sentinela pode monitorar várias instâncias do Redis em execução, enviando comandos e aguardando a resposta do servidor Redis.
teste!
1. Configure o arquivo de configuração sentinel sentinel.conf
#sentinel monitor 被监控的名称 host port 1
sentinel monitor myredis 127.0.0.1 6379 1
O número 1 na parte de trás significa que o host está fora do ar! Escravo de votos para ver quem consegue ser o anfitrião. Aquele com mais votos se tornará o anfitrião!
2. Inicie o sentinela
[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
Se o nó Mestre for desconectado, um servidor será selecionado aleatoriamente do escravo neste momento! (Há um algoritmo de votação nele!)
Log do Sentinel
Se o host voltar neste momento, ele só pode ser mesclado no novo host e usado como escravo.Esta é a regra do modo de sentinela!
Modo sentinela
Vantagens:
1. O cluster Sentinel, baseado no modelo de replicação mestre-escravo, tem todas as vantagens da configuração mestre-escravo
2. O mestre-escravo pode ser comutado e a falha pode ser transferida.A disponibilidade do sistema será melhor.
3. O modo sentinela é o modo mestre-escravo. Upgrade, manual para automático, mais robusto!
Desvantagens:
1. Redis não é bom. Expansão online, uma vez que a capacidade do cluster atinge o limite superior, a expansão online será muito problemática!
2. Realizar a configuração do modo sentinela é realmente muito problemático, existem muitas opções!
Configuração completa do modo sentinela!
# 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 # 一般都是由运维来配置！
Penetração e avalanche do cache Redis
Penetração de cache
Conceito de penetração de cache
O conceito de penetração do cache é muito simples, o usuário deseja consultar um dado e descobre que falta o banco de dados da memória do redis, ou seja, o cache não foi atingido, então o usuário consulta
o banco de dados da camada de persistência. Nada foi encontrado, então esta consulta falhou. Quando há muitos usuários, o cache perde (segunda
eliminação!), Então todos solicitam o banco de dados da camada de persistência. Isso colocará muita pressão no banco de dados da camada de persistência, o que é equivalente à
penetração do cache.
solução
Filtro Bloom O filtro
Bloom é uma estrutura de dados que armazena todos os parâmetros de consulta possíveis em forma de hash. É verificado primeiro na camada de controle e, se não forem atendidos, são descartados, evitando assim a pressão da consulta no sistema de armazenamento subjacente; Depois a camada é perdida, até mesmo o objeto vazio retornado será armazenado em cache e um tempo de expiração será definido ao mesmo tempo. O acesso posterior a esses dados será obtido do cache, protegendo a fonte de dados de back-end;
mas este método irá tem duas perguntas:
1. Se o valor nulo pode ser armazenado em cache, significa que o cache precisa de mais espaço para armazenar mais chaves, porque pode haver muitas
chaves com valores nulos;
2. Mesmo se o valor nulo estiver definido para expirar Com o tempo, ainda haverá inconsistências entre os dados na camada de cache e na camada de armazenamento por um período de tempo, o que
terá um impacto nas empresas que precisam manter a consistência.
Quebra do cache (a quantidade é muito grande, o cache expira!)
Visão geral
Aqui, você precisa prestar atenção à diferença entre a quebra do cache. A quebra do cache se refere a uma chave que está muito quente. Ela está constantemente carregando grande simultaneidade, e a grande simultaneidade concentra o acesso a este ponto. Quando a chave é invalidada, ela continua Grande a simultaneidade rompe o cache e solicita diretamente o banco de dados, exatamente como cavar um buraco em uma barreira.
Quando uma chave expira, há um grande número de solicitações de acesso simultâneas. Esse tipo de dados geralmente são dados dinâmicos. Como o cache expira, o banco de dados será acessado ao mesmo tempo para consultar os dados mais recentes e o cache será gravado de volta, o que fará com que o banco de dados fique sobrecarregado em um instante.
solução
Definindo os dados do ponto de acesso para nunca expirarem
Da perspectiva do cache, não há tempo de expiração definido, portanto, não haverá problemas depois que a chave do ponto de acesso expirar.
Adicionar bloqueios mutex Bloqueios
distribuídos: use bloqueios distribuídos para garantir que haja apenas um encadeamento para consultar o serviço de back-end para cada chave ao mesmo tempo, e outros encadeamentos não têm autoridade para obter o bloqueio distribuído, então você só precisa esperar. Este método transfere a pressão de alta simultaneidade para bloqueios distribuídos, portanto, é um ótimo teste para bloqueios distribuídos.
Avalanche de cache
conceito
A avalanche de cache se refere a um período de tempo em que a coleção de cache expira e se torna inválida. Redis caiu!
Um dos motivos da avalanche, por exemplo, no momento da redação deste artigo, será à meia-noite do Double Twelve, e em breve haverá uma onda de pânico de compras. Essa onda de mercadorias é colocada no cache de um maneira concentrada, supondo que o cache seja de uma hora. Então, à uma hora da manhã, o cache desse lote de mercadorias expirou. O acesso e a consulta desse lote de commodities caem no banco de dados, pois o banco de dados produzirá picos de pressão periódicos. Portanto, todas as solicitações alcançarão a camada de armazenamento e o volume de chamadas da camada de armazenamento aumentará drasticamente, fazendo com que a camada de armazenamento também desligue.
Na verdade, a expiração centralizada não é muito fatal. Uma avalanche de cache mais fatal é que um nó do servidor de cache está inativo ou a rede está desconectada. Por causa da avalanche natural do cache, o cache deve ser criado em um determinado período de tempo.Neste momento, o banco de dados também pode suportar a pressão. Nada mais é do que pressão periódica sobre o banco de dados. O tempo de inatividade do nó do serviço de cache causará uma pressão imprevisível no servidor de banco de dados e é muito provável que sobrecarregue o banco de dados em um instante.
Solução
Alta disponibilidade do Redis
A implicação dessa ideia é que, como o redis provavelmente travará, adicionarei mais alguns redis para que, depois que um travar, os outros possam continuar a funcionar; na verdade, é um cluster construído. (Mais ao vivo em lugares diferentes!)
Downgrade do limite atual (explicado em SpringCloud!)
A ideia desta solução é controlar o número de threads que lêem o banco de dados e gravam no cache bloqueando ou enfileirando após a falha do cache. Por exemplo, apenas um thread tem permissão para consultar dados e gravar no cache de uma determinada chave, e outros threads aguardam.
Pré-aquecimento de dados
O significado do aquecimento de dados é que antes da implantação formal, eu primeiro visito os dados possíveis, de forma que parte dos dados que podem ser acessados em grande quantidade sejam carregados no cache. Antes que um grande acesso simultâneo esteja prestes a ocorrer, acione manualmente o carregamento de diferentes chaves no cache, defina diferentes tempos de expiração e torne os pontos de tempo de invalidação do cache tão uniformes quanto possível.