标签：缓存 conf Redis 简单 redis 6379 key 使用

redis持久化操作RDB：

  在指定的时间间隔内将内存中的数据集快照写入磁盘， 也就是行话讲的 Snapshot 快照，它恢复时是将快照文件直接读到内存里。

  Redis 会单独创建（fork）一个子进程来进行持久化，首先会将数据写入到一个临时文件中，待持久化过程都结束了，再用这个临时文件替换上次持久化好的文件。整个过程中，主进程是不进行任何 IO 操作的，这就确保了极高的性能。如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那 RDB 方式要比 AOF 方式更加的高效。RDB 的缺点是最后一次持久化后的数据可能丢失。

Fork 的作用是复制一个与当前进程一样的进程。新进程的所有数据（变量、环境变量、程序计数器等） 数值都和原进程一致，但是是一个全新的进程，并作为原进程的子进程。

在 Linux 程序中，fork () 会产生一个和父进程完全相同的子进程，但子进程在此后多会 exec 系统调用，出于效率考虑，Linux 中引入了 “写时复制技术”。

一般情况父进程和子进程会共用同一段物理内存，只有进程空间的各段的内容要发生变化时，才会将父进程的内容复制一份给子进程。

 

 

 

save

表示写操作的次数。

格式：save 秒 写操作次数

动态停止 RDB：redis-cli config set save “”#save 后给空值，表示禁用保存策略。

 

 

 

优点

• 适合大规模的数据恢复；
• 对数据完整性和一致性要求不高更适合使用；
• 节省磁盘空间；
• 恢复速度快。

缺点

Fork 的时候，内存中的数据被克隆了一份，大致 2 倍的膨胀性需要考虑；

虽然 Redis 在 fork 时使用了写时拷贝技术，但是如果数据庞大时还是比较消耗性能；

在备份周期在一定间隔时间做一次备份，所以如果 Redis 意外 down 掉的话，就会丢失最后一次快照后的所有修改。

 

AOF

以日志的形式来记录每个写操作（增量保存），将 Redis 执行过的所有写指令记录下来（读操作不记录）， 只许追加文件但不可以改写文件，Redis 启动之初会读取该文件重新构建数据，换言之，如果 Redis 重启就会根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

执行流程

• 客户端的请求写命令会被 append 追加到 AOF 缓冲区内；

• AOF 缓冲区根据 AOF 持久化策略 [always,everysec,no] 将操作 sync 同步到磁盘的 AOF 文件中；

• AOF 文件大小超过重写策略或手动重写时，会对 AOF 文件 Rewrite 重写，压缩 AOF 文件容量；

• Redis 服务重启时，会重新 load 加载 AOF 文件中的写操作达到数据恢复的目的。

AOF 和 RDB 同时开启时，系统默认读取 AOF 的数据（数据不会存在丢失）

一些配置：

appendfsync always

​ 始终同步，每次 Redis 的写入都会立刻记入日志；

​ 性能较差但数据完整性比较好。

appendfsync everysec

​ 每秒同步，每秒记入日志一次，如果宕机，本秒的数据可能丢失。

appendfsync no

​ Redis 不主动进行同步，把同步时机交给操作系统。

Rewrite 压缩

当 AOF 文件的大小超过所设定的阈值时，Redis 就会启动 AOF 文件的内容压缩，只保留可以恢复数据的最小指令集。可以使用命令 bgrewriteaof。

优点

• 备份机制更稳健，丢失数据概率更低；
• 可读的日志文本，通过操作 AOF 稳健，可以处理误操作。

缺点

• 比起 RDB 占用更多的磁盘空间；
• 恢复备份速度要慢；
• 每次读写都同步的话，有一定的性能压力；
• 存在个别 Bug，造成不能恢复。

选择

官方推荐两个都启用。

如果对数据不敏感，可以选单独用 RDB。

不建议单独用 AOF，因为可能会出现 Bug。

如果只是做纯内存缓存，可以都不用。

主从复制：

 

 

1. 读写分离，性能扩展
2. 容灾快速恢复
3. 一主多从！

搭建一主两从

1. 创建文件目录

   /opt/etc

2. 将 redis.conf 复制到当前目录

   cp /etc/redis.conf /opt/etc/

3. 创建 3 个 redis.conf 配置文件

   redis6379.conf
   redis6380.conf
   redis6381.conf

   # redis6379.conf
   include /opt/etc/redis.conf
   pidfile /var/run/redis_6379.pid
   port 6379
   dbfilename dump6379.rdb
   
   # redis6380.conf
   include /opt/etc/redis.conf
   pidfile /var/run/redis_6380.pid
   port 6380
   dbfilename dump6380.rdb
   
   # redis6381.conf
   include /opt/etc/redis.conf
   pidfile /var/run/redis_6381.pid
   port 6381
   dbfilename dump6381.rdb

4. 启动 3 台 redis 服务器 redis-cli -p redis6379.conf
5. 查看主机运行情况 info replication
6. 配从不配主

   slaveof  <ip><port>
   # 成为某个实例的从服务器

7. 成功搭建

   一主二仆

   主机 6379，从机 6380 和 6381。

   1. 假设从机 6380 挂掉。

   当6380重启后，6380不再是6379的从机，而是作为新的master；
   当再次把6380作为6379的从机加入后，从机会把数据从头到尾复制。

    

   2. 假设主机 6379 挂掉。

   6380和6381仍然是6379的从机，不会做任何事；
   当6379重启后，既然是主服务器。

    

   薪火相传

   

    

    

   上一个 slave 可以是下一个 slave 的 master，slave 同样可以接收其他 slave的连接和同步请求，那么该 slave 作为了链条中下一个的 master，可以有效减轻 master 的写压力，去中心化降低风险。

   slaveof <ip><port>

    

   中途变更转向：会清除之前的数据，重新建立拷贝最新的。

   当某个 slave 宕机，后面的 slave 都没法备份。

   即当主机挂掉，从机还是从机，但是无法继续写数据。

   反客为主

   当一个 master 宕机后，后面的 slave 可以立刻升为 master，其后面的 slave 不用做任何修改。

   slaveof no one

    

   哨兵模式

   反客为主的自动版，即能够后台监控主机是否故障，如果故障了根据投票数自动将从库转换为主库。

   1. 创建 sentinel.conf 文件

   /opt/etc/sentinel.conf

    
   2. 配置哨兵

   sentinel monitor mymaster 172.16.88.168 6379 1
   
   # mymaster：监控对象起的服务器名称
   # 1：至少有多少个哨兵同意迁移的数量。 

    
   3. 启动哨兵

   redis-sentinel  /opt/etc/sentinel.conf 主机挂掉，会从机选举中产生新的主机。选举的规则

   选举规则

   • 根据优先级别，slave-priority/replica-priority，优先选择优先级靠前的。

   • 根据偏移量，优先选择偏移量大的。

   • 根据 runid，优先选择最小的服务。

   复制延时

   由于所有的写操作都是先在 master 上操作，然后同步更新到 slave 上，所以从 master 同步到 slave 从机有一定的延迟，当系统很繁忙的时候，延迟问题会更加严重，slave 机器数量的增加也会使这个问题更加严重。

   复制原理

   • slave 启动成功连接到 master 后会发送一个 sync 命令（同步命令）。

   • master 接到命令启动后台的存盘进程，对数据进行持久化操作，同时收集所有接收到的用于修改数据集命令，在后台进程执行完毕之后，master 将传送整个数据文件（rdb）到 slave，以完成一次完全同步。

   • 当主服务进行写操作后，和从服务器进行数据同步。

   • 全量复制：而 slave 服务在接收到数据库文件数据后，将其存盘并加载到内存中。

   • 增量复制：master 继续将新的所有收集到的修改命令依次传给 slave，完成同步。

   • 只要是重新连接 master，一次完全同步（全量复制）将被自动执行。

   集群

   容量不够，redis 如何进行扩容？

   并发写操作， redis 如何分摊？

   主从模式，薪火相传模式，主机宕机，导致 ip 地址发生变化，应用程序中配置需要修改对应的主机地址、端口等信息。

   解决方法：

   • 代理主机（ 之前 ）

   •  

      

      

     • 无中心化集群配置（ redis3.0 ）

        

        

       Redis 集群实现了对 Redis 的水平扩容，即启动 N 个 Redis 节点，将整个数据库分布存储在这 N 个节点中，每个节点存储总数据的 1/N 。

       Redis 集群通过分区（partition）来提供一定程度的可用性（availability），即使集群中有一部分节点失效或者无法进行通讯， 集群也可以继续处理命令请求。

       搭建 Redis 集群

       1. 创建配置文件

       # 以redis6379.conf为例
       include /opt/etc/redis.conf
       pidfile /var/run/redis_6379.pid # 更改
       port 6379 # 更改
       dbfilename dump6379.rdb # 更改
       cluster-enabled yes # 打开集群模式
       cluster-config-file nodes-6379.conf # 设置节点配置文件名称，需要更改
       cluster-node-timeout 15000 # 设置节点失联事件，超过该时间（ms），集群自动进行主从切换

       2. 启动
       3. 将 6 个节点合成一个集群

          # 进入redis安装目录
          /opt/redis-6.2.6/src
          
          # 执行
          redis-cli --cluster create --cluster-replicas 1 172.16.88.168:6379 172.16.88.168:6380 172.16.88.168:6381 172.16.88.168:6389 172.16.88.168:6390 172.16.88.168:6391

          4. 采用集群策略连接

          redis-cli -c -p PORT
          cluster nodes # 命令查看集群信息

          问题

          redis cluster 如何分配这六个节点?

          一个集群至少要有三个主节点。

          选项 --cluster-replicas 1，表示希望为集群中的每个主节点创建一个从节点。

          分配原则尽量保证每个主数据库运行在不同的 IP 地址，每个从库和主库不在一个 IP 地址上。

          一个 Redis 集群包含 16384 个插槽（hash slot）， 数据库中的每个键都属于这 16384 个插槽的其中一个。

          集群使用公式 CRC16(key) % 16384 来计算键 key 属于哪个槽， 其中 CRC16(key) 语句用于计算键 key 的 CRC16 校验和 。

          集群中的每个节点负责处理一部分插槽。 例如， 如果一个集群可以有主节点， 其中：

          • 节点 A 负责处理 0 号至 5460 号插槽。
          • 节点 B 负责处理 5461 号至 10922 号插槽。
          • 节点 C 负责处理 10923 号至 16383 号插槽。
            

            如何在集群中录入值？

            在 redis-cli 每次录入、查询键值，redis 都会计算出该 key 应该送往的插槽，如果不是该客户端对应服务器的插槽，redis 会报错，并告知应前往的 redis 实例地址和端口。

            redis-cli 客户端提供了 –c 参数实现自动重定向。

            例如 redis-cli -c –p 6379 登入后，再录入、查询键值对可以自动重定向。

            如何查询集群中的值？

            每个主机只能查询自己范围内部的插槽。

            cluster keyslot <key>：查询某个 key 的 **slot **。

            cluster countkeysinslot <slot>：查询某个 slot 是否有值。

            CLUSTER GETKEYSINSLOT <slot><count>：返回 count 个 slot 槽中的键。

            
            

            故障恢复？

            如果主节点下线？从节点能否自动升为主节点？注意：15 秒超时。

            • 当 6379 挂掉后，6389 成为新的主机。

            主节点恢复后，主从关系会如何？主节点回来变成从机。

            • 当 6379 重启后，6379 成为 6389 的从机。

            如果所有某一段插槽的主从节点都宕掉，redis 服务是否还能继续?

            • 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage=yes，那么 ，整个集群都挂掉。
            • 如果某一段插槽的主从都挂掉，而 cluster-require-full-coverage=no，那么，该插槽数据全都不能使用，也无法存储。

            redis.conf 中的参数 cluster-require-full-coverage

            优点

            • 实现扩容；
            • 分摊压力；
            • 无中心配置相对简单。

            缺点

            • 多键操作是不被支持的；
            • 多键的 Redis 事务是不被支持的。lua 脚本不被支持；
            • 由于集群方案出现较晚，很多公司已经采用了其他的集群方案，而代理或者客户端分片的方案想要迁移至redis cluster，需要整体迁移而不是逐步过渡，复杂度较大。
              

              应用问题解决

              缓存穿透

               

               

              现象

              key 对应的数据在数据源并不存在，每次针对此 key 的请求从缓存获取不到，请求都会压到数据源，从而可能压垮数据源。

              比如用一个不存在的用户 id 获取用户信息，不论缓存还是数据库都没有，若黑客利用此漏洞进行攻击可能压垮数据库。

              造成：

              1. 应用服务器压力变大。
              2. redis 命中率下降 ⟶⟶ 查询数据库 。

              如何解决

              • 对空值缓存

                如果一个查询返回的数据为空（不管是数据是否不存在），仍然把这个空结果（null）进行缓存，设置空结果的过期时间会很短，最长不超过五分钟。

              • 设置可访问的名单（白名单）：

                使用 bitmaps 类型定义一个可以访问的名单，名单 id 作为 bitmaps 的偏移量，每次访问和 bitmap 里面的 id 进行比较，如果访问 id 不在 bitmaps 里面，进行拦截，则不允许访问。

              • 采用布隆过滤器

                布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量（位图）和一系列随机映射函数（哈希函数）。

                布隆过滤器可以用于检索一个元素是否在一个集合中。它的优点是空间效率和查询时间都远远超过一般的算法，缺点是有一定的误识别率和删除困难。

                将所有可能存在的数据哈希到一个足够大的 bitmaps 中，一个一定不存在的数据会被这个 bitmaps 拦截掉，从而避免了对底层存储系统的查询压力。

              • 进行实时监控

                当发现 Redis 的命中率开始急速降低，需要排查访问对象和访问的数据，和运维人员配合，可以设置黑名单限制服务。

              缓存击穿

               

               

              key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。

              1. 数据库访问压力瞬间增大。
              2. redis 中没有出现大量 key 过期，redis 正常运行。
              3. （即某个经常访问的 key 过期，突然有大量访问这个数据）

              如何解决

              • 预先设置热门数据

                在 redis 高峰访问之前，把一些热门数据提前存入到 redis 里面，加大这些热门数据 key 的时长。

              • 实时调整

                现场监控哪些数据热门，实时调整 key 的过期时长。

              • 使用锁

              缓存雪崩

              key 对应的数据存在，但在 redis 中过期，此时若有大量并发请求过来，这些请求发现缓存过期一般都会从后端DB 加载数据并回设到缓存，这个时候大并发的请求可能会瞬间把后端 DB 压垮。

              缓存雪崩与缓存击穿的区别在于这里针对很多 key 缓存，前者则是某一个 key。

              1. 数据库压力变大。
              2. 即极少的时间段，查询大量 key 的集中过期情况。

              如何解决

              • 构建多级缓存架构

                nginx 缓存 + redis 缓存 + 其他缓存（ehcache等）

              • 使用锁或队列：

                用加锁或者队列的方式保证来保证不会有大量的线程对数据库一次性进行读写，从而避免失效时大量的并发请求落到底层存储系统上。不适用高并发情况。

              • 设置过期标志更新缓存：

                记录缓存数据是否过期（设置提前量），如果过期会触发通知另外的线程在后台去更新实际 key 的缓存。

              • 将缓存失效时间分散开：

                比如我们可以在原有的失效时间基础上增加一个随机值，比如 1～5 分钟随机，这样每一个缓存的过期时间的重复率就会降低，就很难引发集体失效的事件。

标签：缓存,conf,Redis,简单,redis,6379,key,使用
From： https://www.cnblogs.com/zhangtaibing/p/16724063.html