1.redis

1.1什么事redis

Redis 是一个开源（BSD许可）的，内存中的数据结构存储系统，它能够用作数据库、缓存和消息中间件。 它反对多种类型的数据结构，如 字符串（strings）， 散列（hashes）， 列表（lists）， 汇合（sets）， 有序汇合（sorted sets） 与范畴查问， bitmaps， hyperloglogs 和 天文空间（geospatial） 索引半径查问。 Redis 内置了 复制（replication），LUA脚本（Lua scripting）， LRU驱动事件（LRU eviction），事务（transactions） 和不同级别的 磁盘长久化（persistence）， 并通过 Redis哨兵（Sentinel）和主动 分区（Cluster）提供高可用性（high availability）。

速度: 读: 11.2万/秒 写:8.6万/秒 50万/秒

1.2redis的做用

引入缓存机制能够无效的缩小用户拜访物理设施的次数,从而进步相应速度;

1.2如何设计缓存?

1.缓存数据如何存储? 应该采纳什么样的数据结构呢? K-V key的唯一性
2.缓存数据的容量大小 应该动静保护缓存数据,将不须要的数据提前删除. LRU算法/LFU算法/随机算法/TTL算法
3.缓存数据保留到内存中,然而内存的特点断电即擦除. 定期将内存数据长久化(写入磁盘中)
4.单台缓存服务器性能有余,所以个别须要搭建集群(实现高可用).
5.应用C语言开发.

2 Redis属性阐明

2.1 Redis长久化策略

2.1.1 为什么要长久化

Redis中的记录都保留在内存中,如果内存断电或者服务器宕机,则内存数据间接失落.业务中不容许产生. 所以须要将数据定期进行保护.

2.1.2 RDB模式

阐明: RDB模式是Redis的默认的长久化策略.无需手动的开启.
特点:
1.Redis会定期的执行RDB长久化操作. 毛病:可能导致内存数据失落.
2.RDB记录的是内存数据的快照,并且后续的快照会笼罩之前的快照.每次只保留最新数据.效率更高.

命令:
1).save 命令 要求立刻执行长久化操作 save会造成线程的阻塞.
2).bgsave 命令 后盾执行长久化操作 后盾运行不会造成阻塞. 异步操作, 不能保障立刻执行

2.1.3 AOF模式

阐明: AOF模式默认条件下是敞开的,须要手动的开启,如果开启了AOF模式则RDB模式将生效.然而如果手动执行save命令,则也会生成RDB文件.

1).开启AOF模式

特点:
1.AOF模式记录程序的执行的过程.所以能够保证数据不失落.
2.因为AOF记录程序运行的过程,所以整个长久化文件绝对大,所以须要定期维护. 效率低

.1.4 RDB与AOF模式长久化比照

1).RDB模式
save 900 1 如果在900秒内,执行了一次更新操作则长久化一次
save 300 10
save 60 10000 操作越快 ,长久化的周期越短.

2).AOF模式
appendfsync always 用户执行一次更新操作,则长久化一次 异步操作
appendfsync everysec 每秒操作一次
appendfsync no 不被动操作 个别不必.

2.1.5 对于RDB与AOF总结

策略: 如果数据容许大量失落,首选RDB模式,
如果数据不容许失落则首选AOF模式.

企业策略: 又要满足效率,同时满足数据不失落.
主机: 采纳RDB模式
从机: 采纳AOF模式

2.1.6问题

问题1:误操作将redis服务器执行了flushAll命令,问你如何解决??

解决方案: 须要将从库中的AOF文件 进行编辑,删除多余的flushAll命令,之后重启redis即可.

问题2:误将aof文件一并删除,问如何解决???
答: 杀人祭天!!!

2.2Redis内存策略

2.2.1 LRU算法

LRU是Least Recently Used的缩写，即最近起码应用，是一种罕用的页面置换算法，抉择最近最久未应用的页面予以淘汰。该算法赋予每个页面一个拜访字段，用来记录一个页面自上次被拜访以来所经验的工夫 t，当须淘汰一个页面时，抉择现有页面中其 t 值最大的，即最近起码应用的页面予以淘汰。
判断维度: 工夫T

2.2.2 LFU算法

LFU（least frequently used (LFU) page-replacement algorithm）。即最不常常应用页置换算法，要求在页置换时置换援用计数最小的页，因为常常应用的页应该有一个较大的援用次数。然而有些页在开始时应用次数很多，但当前就不再应用，这类页将会长工夫留在内存中，因而能够将援用计数寄存器定时右移一位，造成指数衰减的均匀应用次数。
判断维度: 应用次数

2.2.3 随机算法

随机算法

2.2.4 TTL算法

将剩余时间短的数据,提前删除.

2.2.5 Redis的内存优化策略

  1. volatile-lru 在设定超时工夫的数据中采纳LRU算法
  2. allkeys-lru 所有的数据采纳LRU算法删除
  3. volatile-lfu 设定了超时工夫的数据采纳LFU算法删除
  4. allkeys-lfu 所有数据采纳LFU算法删除
  5. volatile-random 设定了超时工夫的数据采纳随机算法
  6. allkeys-random 所有数据的随机算法
  7. volatile-ttl 设定了超时工夫之后采纳TTL算法
  8. noeviction 不做任何操作,只是返回报错信息.

2.3 对于Redis常见问题

2.3.1 缓存穿透

阐明: 用户高并发环境下拜访数据库和缓存中都不存在的数据称之为缓存穿透景象.


解决方案:
1). 禁用IP 限度IP拜访.
2). 限流 每秒最多拜访3次
3). 布隆过滤器

布隆过滤器

布隆过滤器（Bloom Filter）是1970年由布隆提出的。它实际上是一个很长的二进制向量和一系列随机映射函数。布隆过滤器能够用于检索一个元素是否在一个汇合中。它的长处是空间效率和查问工夫都比个别的算法要好的多，毛病是有肯定的误识别率和删除艰难。

原理:

布隆过滤器优化:
问题:如何解决hash碰撞问题
知识点: 因为hash碰撞问题,可能由多个key有雷同的地位,所以得出结论,布隆过滤器认为数据存在,那么数据可能存在.如果布隆过滤器认为数据不存在,则数据肯定不在.

如何升高hash碰撞的几率:
答:
1.扩容二进制向量位数.
2.减少hash函数的个数
当位数减少/函数适当减少,则能够无效的升高hash碰撞的几率. 默认值 0.03

2.3.2 什么是缓存击穿

阐明: 某个(一个)热点数据在缓存中忽然生效.导致大量的用户间接拜访数据库.导致并发压力过高造成异样.

解决方案:
1.尽可能将热点数据的超时工夫 设定的长一点
2.设定多级缓存 超时工夫采纳随机算法.

2.3.3 什么是缓存雪崩

阐明: 在缓存服务器中,因为大量的缓存数据生效,导致用户拜访的命中率过低.导致间接拜访数据库.
问题剖析:

  1. fluashAll命令可能导致缓存雪崩.
  2. 设定超时工夫时,应该采纳随机算法
  3. 采纳多级缓存能够无效避免.

3.linux零碎装置redis

3.1 上传Redis

1).上传redis

2).解压redis服务
[root@localhost src]# tar -xvf redis-5.0.4.tar.gz

3).挪动文件/批改文件名称

3.2 装置Redis

阐明:在Redis根目录中执行如下命令

1).make

2). make install

3.3 批改redis配置文件

批改redis根目录下的redis.conf文件
1).去除IP绑定

2).批改保护模式

3).开启后盾启动

3.4 Redis服务器命令

阐明: Redis服务在运行时,必须依赖于配置文件 redis.conf. 操作redis时最好在根目录中操作
1).启动redis
redis-server redis.conf

2).进入redis客户端
redis-cli -p 6379
ctrl + c 退出客户端

3).敞开redis服务器

办法二:

 redis-cli -p 6379 shutdown

阐明:如果操作端口是默认端口(6379) 6379能够不写;

4 redis分片机制

4.1 redis性能优化

阐明: 单台redis内存容量是无限的.然而如果有海量的数据要求实现缓存存储,则应该应用多个Redis节点.

4.2 Redis分片机制定义

4.3 Redis分片机制配置

4.3.1 配置布局

阐明: 筹备3台redis服务器 别离为 6379/6380/6381

4.3.2 筹备3个配置文件


批改各自端口号 改为6380 6381

4.3.3 启动redis服务器

4.3.4 查看redis启动状态

5.Redis哨兵机制

5.1 Redis分片机制问题

阐明: 如果redis分片中有一个节点宕机,则可能会影响整个服务的运行. redis分片没有实现高可用.

5.2 Redis主从构造搭建

5.2.1 复制配置文件

5.2.2 筹备3台redis

5.2.3 主从搭建

命令1: info replication

命令2: slaveof IP PORT 主从挂载命令

查看主从构造状态


对于主从构造阐明:
主和从都晓得 以后的主从的状态, 并且只有主机能够写操作.从机只能读操作.

5.2 Redis哨兵机制工作原理

1).当哨兵启动时,首先会监控主机,从主机中获取以后所有的节点的状态,同时哨兵开启心跳检测机制.
2).当主机产生宕机的景象时,因为哨兵有PING-PONG机制 发现主机宕机,则哨兵开始进行选举.
3).当选举胜利之后,新的主机入选之后,其余的节点当新主机的从.

5.3 编辑哨兵配置文件


1）敞开保护模式

2).开启后盾运行

3).编辑监控配置

4).批改选举工夫

5.4 启动哨兵服务

命令: redis-sentinel sentinel.conf

6.集群机制

就是联合分片和哨兵机制,且用不到哨兵服务,主机宕机由残余的主机选取主机,就不必放心哨兵宕机而影像整个服务运行,个别一主两或三从,起码三个主机

6.1搭建集群:

打算三台主机三台从机,端口号7000~7005;

  1. 在redis下创立一个cluster文件夹,在cluster目录下创立7000~7005六个目录,在其中一个目录下复制一个redis.conf文件(redis集体目录下的,没被净化过)
  2. 批改配置文件,详情见redis集群搭建步骤,将批改好的配置文件复制给其余五个目录,之后将这五个目录下的配置文件中的7000换成对应的数据(:%S/7000/7001/g)
  3. 通过创立脚本命令来启动/敞开
  4. 创立redis集群:redis-cli --cluster create --cluster-replicas 1 192.168.126.129:7000 192.168.126.129:7001 192.168.126.129:7002 192.168.126.129:7003 192.168.126.129:7004 192.168.126.129:7005

6.2搭建胜利