Linux安装redis(阅读官方文档进行安装)
Installation
Download, extract and compile Redis with:
$ wget http://download.redis.io/releases/redis-5.0.8.tar.gz
$ tar xzf redis-5.0.8.tar.gz
$ cd redis-5.0.8
$ make
$ make install
The binaries that are now compiled are available in the src directory. Run Redis with:
$ src/redis-server
Redis主从复制
概念：
主从复制是指将一台redis服务器的数据，复制到其他的redis服务器上。前者称为主节点（master/leader）后者称为从节点（slave）；
数据复制是单向的，只能从主节点到从节点。默认的情况下每个redis服务器都是一个主节点。
一个主节点可以有多个从节点，但是一个从节点只能有一个主节点
主从复制的作用：
- 数据冗余：主从复制实现了数据的热备份，是持久化之外的一种数据冗余
- 故障恢复：当主节点出现问题，可以由从节点提供服务，实现快速的故障恢复；实际上是一种服务的冗余。
- 负载均衡：在主从复制的基础上，配合读写分离，可以由主节点提供写服务，由从节点提供读服务（redis的主节点写，从节点读），分担服务器的负载；通过多个从节点分担读负载，可以大大提高redis服务器的并发量。
- 高可用（集群）基石：除了上述的作用以外，主从复制还是哨兵和集群能够实施的基础，因此主从复制是redis高可用的基础。
集群环境搭建：
此处使用伪集群
只配置从库，不用配置主库！
主从复制，从机里面配置主机的地址 通过 ==replicaof 127.0.0.1 6380== 配置主机的位置
- 复制3个redis 的配置文件 redis79.conf redis80.conf redis81.conf
- 修改里面的 端口号 ，pid名字，dump.rdb 名字 对应主节点的地址 replicaof 127.0.0.1 6380
- 修改后我们启动对应的三redis 的客户端
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
bilibili：狂神说Java
如果两个都配置完了，就是有两个从机的
真实的从主配置应该在配置文件中配置，这样的话是永久的，我们这里使用的是命令，暂时的！
细节
主机可以写，从机不能写只能读！主机中的所有信息和数据，都会自动被从机保存！
主机写：
master_link_status:up
master_last_io_seconds_ago:3
master_sync_in_progress:0
slave_repl_offset:14
slave_priority:100
slave_read_only:1
connected_slaves:0
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:14
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:6379> info replication
# Replication
role:master
connected_slaves:1 # 多了从机的配置
slave0:ip=127.0.0.1,port=6380,state=online,offset=42,lag=1 # 多了从机的配置
master_replid:a81be8dd257636b2d3e7a9f595e69d73ff03774e
master_replid2:0000000000000000000000000000000000000000
master_repl_offset:42
second_repl_offset:-1
repl_backlog_active:1
repl_backlog_size:1048576
repl_backlog_first_byte_offset:1
repl_backlog_histlen:42
编写shell脚本启动集群
- 测试redis-server启动
redis-server summerconfig/redis79.conf
启动成功
- 编写shell脚本 vim start-all.sh
redis-server summerconfig/redis79.conf
redis-server summerconfig/redis80.conf
redis-server summerconfig/redis81.conf
- 设置shell脚本权限
chmod +x start-all.sh
- 运行shell脚本
[root@VM_0_15_centos src]# ./start-all.sh
5113:C 29 Jun 2020 09:38:23.055 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5113:C 29 Jun 2020 09:38:23.055 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=5113, just started
5113:C 29 Jun 2020 09:38:23.055 # Configuration loaded
5115:C 29 Jun 2020 09:38:23.057 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5115:C 29 Jun 2020 09:38:23.057 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=5115, just started
5115:C 29 Jun 2020 09:38:23.057 # Configuration loaded
5120:C 29 Jun 2020 09:38:23.060 # oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
5120:C 29 Jun 2020 09:38:23.060 # Redis version=5.0.8, bits=64, commit=00000000, modified=0, pid=5120, just started
5120:C 29 Jun 2020 09:38:23.060 # Configuration loaded
- 查看后台进程
[root@VM_0_15_centos src]# ps -ef|grep redis
root 5114 1 0 09:38 ? 00:00:00 redis-server 127.0.0.1:6379
root 5119 1 0 09:38 ? 00:00:00 redis-server 127.0.0.1:6380
root 5125 1 0 09:38 ? 00:00:00 redis-server 127.0.0.1:6381
root 7755 3447 0 09:53 pts/0 00:00:00 grep --color=auto redis
redis集群一键启动成功
细节
redis集群中的主机可以写也可以读，但是redis从机只能读
复制原理
Slave 启动成功连接到 master 后会发送一个sync同步命令 Master 接到命令，启动后台的存盘进程，同时收集所有接收到的用于修改数据集命令，在后台进程执行 完毕之后，master将传送整个数据文件到slave，并完成一次完全同步。
全量复制：而slave服务在接收到数据库文件数据后，将其存盘并加载到内存中。
增量复制：Master 继续将新的所有收集到的修改命令依次传给slave，完成同步 但是只要是重新连接master，一次完全同步（全量复制）将被自动执行！ 我们的数据一定可以在从机中 看到！
如果没有老大了，这个时候能不能选择一个老大出来呢？ 手动！
谋朝篡位
如果主机断开了连接，我们可以使用 ==SLAVEOF no one== 让自己变成主机！其他的节点就可以手动连 接到最新的这个主节点（手动）！如果这个时候老大修复了，那就重新连接！
哨兵模式 （自动选举老大的模式）
配置
我们的目前状态是一主二从
-
配置哨兵的配置文件sentinel.conf
# sentinel monitor 被监控的名称 host port 1 sentinel monitor myredis 127.0.0.1 6379 1后面的这个数字1，代表主机挂了，slave投票看让谁接替成为主机，票数最多的，就会成为主机！
-
启动哨兵！
[root@summer root]# redis-sentinel kconfig/sentinel.conf
细节
- 如果主节点宕机，哨兵就会自动去选择一个从节点来当主节点
- 之前宕机的主节点回归之后，不会是主节点了，只能是从节点
哨兵模式的优缺点
优点:
- 哨兵集群，基于主从复制模式，所有的主从配置优点他都有。
- 主从可以切换，故障可以转移，系统的可用性会更好。
- 哨兵模式就是主从模式的升级，手动到自动，更加健壮。
缺点：
- redis不好在线扩容，集群达到上限之后，在线扩容会十分麻烦。
- 实现哨兵模式的配置其实很麻烦，选择很多
哨兵的全部配置
# Example sentinel.conf
# 哨兵sentinel实例运行的端口 默认26379
port 26379
# 哨兵sentinel的工作目录
dir /tmp
# 哨兵sentinel监控的redis主节点的 ip port
# master-name 可以自己命名的主节点名字 只能由字母A-z、数字0-9 、这三个字符".-_"组成。
# quorum 当这些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无法正常启动成功。
#通知脚本
# 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
redis缓存穿透和雪崩
典型问题：缓存穿透，缓存击穿，缓存雪崩。
缓存穿透：
概念
用户查询数据，但是缓存中没有命中，于是就去持久层的数据里面查询。如果有大量的用户都去查询这个数据，就都会去持久层的数据库中去查询，会给数据库造成很大的压力。此时缓存被穿透了。
解决方案
布隆过滤器
缓存空对象
当存储层不命中后，即使返回的空对象也将其缓存起来，同时会设置一个过期时间，之后再访问这个数 据将会从缓存中获取，保护了后端数据源；
问题：
- 空键会占用大量的空间。
- 设置过期时间，减少内存的消耗。但是会存在缓存层和存储层的数据会不一致，对于需要保持一致性业务会有影响。
缓存击穿：
概念
这里需要注意和缓存击穿的区别，缓存击穿，==是指一个key非常热点，在不停的扛着大并发==，大并发集中 对这一个点进行访问，当这个key在失效的瞬间，持续的大并发就穿破缓存，直接请求数据库，就像在一 个屏障上凿开了一个洞。
当某个key在过期的瞬间，有大量的请求并发访问，这类数据一般是热点数据，由于缓存过期，会同时访 问数据库来查询最新数据，并且回写缓存，会导使数据库瞬间压力过大。
解决方案
设置热点数据永不过期
从缓存层面来看，没有设置过期时间，所以不会出现热点 key 过期后产生的问题。
加互斥锁 分布式锁：
使用分布式锁，保证对于每个key同时只有一个线程去查询后端服务，其他线程没有获得分布 式锁的权限，因此只需要等待即可。这种方式将高并发的压力转移到了分布式锁，因此对分布式锁的考 验很大。
缓存雪崩：
概念
缓存雪崩，是指在某一个时间段，缓存集中过期失效。Redis 宕机！
产生雪崩的原因之一，比如在写本文的时候，马上就要到双十二零点，很快就会迎来一波抢购，这波商 品时间比较集中的放入了缓存，假设缓存一个小时。那么到了凌晨一点钟的时候，这批商品的缓存就都 过期了。而对这批商品的访问查询，都落到了数据库上，对于数据库而言，就会产生周期性的压力波 峰。于是所有的请求都会达到存储层，存储层的调用量会暴增，造成存储层也会挂掉的情况。
解决方案
redis高可用
这个思想的含义是，既然redis有可能挂掉，那我多增设几台redis，这样一台挂掉之后其他的还可以继续 工作，其实就是搭建的集群。（异地多活！）
限流降级
这个解决方案的思想是，在缓存失效后，通过加锁或者队列来控制读数据库写缓存的线程数量。比如对 某个key只允许一个线程查询数据和写缓存，其他线程等待。
数据预热
数据加热的含义就是在正式部署之前，我先把可能的数据先预先访问一遍，这样部分可能大量访问的数 据就会加载到缓存中。在即将发生大并发访问前手动触发加载缓存不同的key，设置不同的过期时间，让 缓存失效的时间点尽量均匀。
网友评论