Redis总结

什么是Redis

Redis是一个高性能的NoSql系列的菲关系型数据库
Redis使用C语言开发的开源高性能键值对(key-value)数据库, Redis通过提供多种键值对类型适应不同场景下的存储需求, 数据类型如下:
1. 字符串类型: String
2. 哈希类型  hash
3. 列表类型  list
4. 集合类型 set   不允许重复元素
5. 有序结合类型   sortedset   不允许重复元素, 且元素有序, 每个元素都会关联一个double类型的分数,Redis通过分数进行排序

应用场景

缓存 任务队列(秒杀, 抢购) 应用排行榜 网站访问统计 数据过期处理

NOSQL

NOSQL(not only sql) ,“不仅仅是SQL”, 是一项全新的数据库理念, 泛指非关系型的数据库, Nosql数据库的产生是为了解决大规模数据集合多重数据种类带来的挑战, 尤其是大数据的应用难题.

NOSQL和关系型数据库比较

优点:

成本: nosql数据库简单部署, 基本都是开源软件, 相对价格便宜
查询速度: nosql数据库存储于缓存中, 关系型数据库将数据存储在硬盘中, 自然查询速度远不及nosql.
存储格式: nosql的存储格式时key-value形式, 文档形式, 图片形式等, 所以可以存储基础类型以及对象或者是集合等各种格式, 而数据库则只支持基础类型
扩展性: 关系型数据库有类似join这样的多表查询机制导致扩展困难

缺点:

维护的工具和资料有限, 因为nosql是新技术, 与关系型数据库10几年的技术不可同日而语
不提供对SQL的支持, 将产生更多的学习成本
不提供关系型数据库对事物的处理
总结: 关系型和nosql数据库并非对立而是互补关系, 即通常情况下使用关系型数据库,存储数据, 在nosql数据库中备份存储关系型数据库的数据

主流NOSQL产品

1 . 键值对存储数据库
产品: Tokyo Cabinet/Tyrant Redis Voldemort Berkeley DB
应用: 缓存, 处理大量数据的高访问负载
2 . 列存储数据库
产品: Cassandra HBase Rish
应用: 分布式文件系统
数据模型: 以列簇式存储, 将同一列数据存在一起
3 . 文档型数据库
产品: CouchDB MongoDB
应用: web应用
4 . 图形数据库
Neo4j InfoGrid Infinite Graph
应用: 社交网络
数据结构: 图结构

命令操作

数据操作(五种)

1 . 字符串类型String
存储: set key value eg: set name ‘lisi’
获取: get key eg: get name
删除: del key eg: del name
2 . 哈希类型hash
hset key field value eg: hset stu00 name ‘lisi’
hget key field eg: hget stu00 name
hgetall key eg: hgetall stu00
hdel key field eg: hdel stu00 name
3 . 列表类型list
lpush key value 将元素加入列表左边 lpush set0 ‘lisi’
rpush key value 将元素加入列表右边 rpush set0 ‘zhangsan’
lrange key start end 范围获取 lrange key 0 -1
lpop key 删除最左边元素, 并将元素返回
rpop key 删除最右边元素, 并将元素返回
4 . 集合类型set
sadd key value
smembers key 获取set集合中所有元素
srem key value 删除集合中某个元素
5 . 有序集合类型sortedset
zadd key score value
zrange key start end
zrem key value
set和zset都是String对象的集合, 且元素不允许重复

通用命令
keys * : 查询所有的键
type key : 获取键对应的value得类型
del key : 删除指定的key value

Linux系统Redis相关指令

1. 启动Redis
   进入bin目录, 先确定是否存在redis-server文件
   执行 : ./redis-server & 启动Redis | ./redis-server /etc/redis/6379.conf 启动Redis
   注意 : 在本地连接虚拟机上的Redis连接不上, 可以将防火墙关掉试试
2. 进入Redis命令行
   进图bin目录, 先确定是否存在redis-cli文件
   执行 : ./redis-cli
3. 查看Redis安装路径
   执行 : whereis redis
4. 查看Redis客户端安装路径
   执行 : whereis redis-cli
5. 查看Redis服务安装路径
   执行 : whereis redis-server
6. 查看Redis服务是否正在启动
   ps aux | grep redis-server 或 netstat -tunple | grep 6379

持久化

1 . Redis是一个内存数据库, 因此当计算机重启之后, 内存中数据丢失, 此时我们可以将Redis内存中的的数据持久化保存到硬盘的文件中。
2. RDB：默认方式，也称为快照方式，每隔一段时间执行一次全量备份， Redis将快照保存在磁盘上，保存到一个名为dump.rdb文件, 也可以手动调用save或bgsave命令
优点: 非常适合做备份和回滚到指定的时间点, 可以将数据恢复到指定时间点的版本, 相对AOF来说, RDB模式性能更高, 重启速度更快.
缺点: 相对于AOF会丢失更多的数据, 因为在备份时间点之间的数据会丢失, 如果设置为一分钟,那么如果Redis在下一个节点之前重启, 以为还没有进行备份, 所以这一分钟内的数据会丢失
3. AOF ,通过记录Redis的写操作, 在Redis重启时根据记录重新进行写操作.
优点: 可以最大限度恢复数据完整性,
缺点: 占用内存更大, 如果在写操作时断电, AOF中记录错误的命令, 在数据恢复时, 会忽略此操作.
4. 混合方式 RDB和AOF混合使用, 将RDB文件的内容和AOF日志文件存放在一起, 此时的AOF的日志是从持久化开始到持久化结束时间段内发生的增量AOF日志.

缓存穿透

是指查询数据库一定不存在的数据, 正常使用缓存的流程是: 数据查询先进行缓存查询, 如果key不存在或key已经过期, 再对数据库进行查询, 并把查询到的对象放进Redis中实现缓存, 如果查询的结果为空, 则不放进缓存.
代码实现步骤:
将对象查询条件所谓参数输入搜索方法
执行缓存查询
如查询结果为不为空, 直接返回
如果查询结果为空, 直接去持久化数据库查询
问题出在传入参数, 如果插入的参数为-1这样, 一定不存在的条件值, 那么查询结果必然是空的, 因而每次查询缓存无果, 又要去查询持久化数据库, 如果有人利用此漏洞进行而行攻击, 会对数据库造成压力, 甚至导致数据库崩溃.
解决方案:
查询结果为空时, 也将其放入缓存, 但是要设定缓存过期时间短一点, 这样即使有人恶性攻击, 最多60秒查询一次.

缓存雪崩

是指在一定时间内, 缓存集中过期失效, 导致搜索压力直接到持久化数据库
为题出现原因:
在某一段时间内, 比较集中的将数据放进缓存, 而且设置过期时间相同, 在有效时间一过, 这些数据集中过期, 此时再进行搜索访问的话, 就会直接去持久化数据库了, 会对持久化数据库造成压力高峰.

问题解决:
将数据分类, 不同类型的数据, 缓存不同的数据, 还可以在同类性的数据中加一个随机因子, 访问比较多的类型数据设置存活时间长一些, 尽可能的分散缓存过期时间.

拓展:
集中过期的雪崩问题, 只是对数据库产生周期性的压力, 所以集中式缓存崩溃并不是致命的, 比较致命的缓存服务器某个节点宕机或断网, 这对数据库服务器产生的压力是不可预知的, 很可能把数据库压垮.

缓存击垮

是指一个key正常热点, 在不停的承担着大并发, 大并发对这一点进行访问, 当这个key在是失效的瞬间, 持续的大并发就会穿透缓存, 就像在屏障上凿开了一个洞.

缓存更新

自定义缓存淘汰策略 :定时清除过期缓存
当用户请求过来时, 在判断这个所用到的缓存是否过期, 如果过期就去底层系统得到新数据更新缓存
缓存降级:当访问量剧增, 服务器出现问题(如果响应慢或不响应)或非核心服务影响到核心流程的性能时, 为了保证核心服务可用 ,将非核心服务降级

自动降级: 使用Hystrix (熔断器) 或 Spring Cloud Feign

操作

在springcloud项目中
使用org.springframework.data.redis.core.StringRedisTemplate;操作Redis
StringRedisTemplate和RedisTemplate区别
https://www.cnblogs.com/slowcity/p/9002660.html

Redis集群

主从结构

资源来自 : https://blog.csdn.net/xiaolinnulidushu/article/details/104106380

主从结构至少要两台服务器, 并且只存在一个主服务器master, 其余都是从服务器slave, 存在一主一从和一主多从结构, 根据实际开发场景而定.
为了保证数据一致性, 规定master负责数据的读写, slave只负责读取, 同时数据的同步方向只能是master向slave同步, 只有这样才能保证所有的从服务器的数据与主服务器一致, 综上所述呢: 一个master可对应多个slave, 但是,一个slave只能对应一个master. 这种复制操作, 通常称为"主从复制"

Redis的主从复制实现有两种方式:

方式1 : slaveof 命令
直接在想要设置为slave节点的服务器上运行slaveof ip port 命令即可, 命令中ip和端口是主节点master的ip和端口
其中客户端执行了slaveof命令之后, Redis会立即异步给客户端一个OK响应, 但是Redis当中还是需要经过一系列的复制过程, 比如主从服务的连接、连接之后再从master上将数据全量复制到新该slave节点中。
另外，如果不想取消该slave节点的从节点身份， 可以执行slaveof no one 命令即可， 这样当前slave节点就和master节点断开连接
注意 ：
当该Redis服务器被设置为slave节点服务器的时候会先清空当前Redis中的数据，并且同时会将当前的Redis设置为只读状态

方式2 : 配置文件方式
将当前Redis设置为slave节点, 也可以通过配置文件的方式实现, 在设置完成配置文件后, 重启Redis即可, 涉及到的配置项为:

• slaveof ip port : 和命令的方式一样, 端口和ip指向master节点
• slaveof - read - only : 配置为yes, 固定slave节点只读状态
• masterauth : 如果主节点有密码的话需要在这里配置密码

当设置完成并且从起之后, 可以使用命令: info replication 来查看当前Redis服务的状态

主从复制原理

Redis的主从结构的数据一致是通过主从复制来实现的,主从复制有两种方式进行数据同步: 全量复制和部分复制, 在介绍两种复制的具体流程和触发时机之前要先知道三个概念: run_id | 主从复制偏移量 | 主从复制积压缓存区
run_id : 每次edis服务器重新启动的时候都会生成一个新的唯一的run_id, 类似当前运行的Redis服务器的身份标识, 可以通过info server查看当前Redis服务的run_id
主从复制偏移量 : 在主从结构中master和salve的对这个字段的命名有点差异, 可以通过info replication命令查看, master节点有字节输出就会不断增加复制偏移量, 在部分复制时这是一个关键参考值.
主从复制积压缓冲区 : 维护在master中的一个FIFO队列, 在master每次向外传输时, 也会向该队列中传输, 该队列中会有对应的偏移量和其对应的字节记录, 部分复制的内层就是从这里同步到从节点的

slave同步master数据是通过请求master执行psync完成的主从数据同步, 从节点初次执行slaveof命令的时候, 肯定需要进行全量复制的过程, 一下是全量复制的过程 :

当从节点执行slaveof命令之后, Redis内部就启动上面的操作

1. slave节点初次请求psync命令, 此时从节点是没有保存过的master的run_id值的, 也没有保存过master的复制偏移量
2. master节点接收到psync请求, 发现没有run_id和offset说明需要全量复制数据, 此时响应给salve节点进行全量复制标识, 并且携带者自己的run_id和当前的复制偏移量给到salve
3. slave接收到全量复制的标示之后保存master的run_id和offset信息
4. master持久化RDB文件到salve接收的完成整个期间, master是正常接收客户端的相互请求的,这时候如果master有新的更新的话会把更新数据记录在复制积压缓存区, 待从节点加载RDB完成之后, 再将缓存区的变更数据发送给节点进行同步
5. salve节点拿到master的同步数据之后, 先是清空当前缓存的数据
6. slave清空缓存的数据之后开始加载master同步过来的数据
   全量复制流程是非常费时的, 原因如下:
   1 . 从master节点分析 : 在将Redis持久化的文章里面说过, 如果生产环境上的缓存数量非常大, 那么进行RDB持久化是一个非常耗时的操作, 尽管是通过一部的bgsave操作, 而且除此之外一个比较耗时的是RDB文件通过网络进行通信
   2 . 从slave节点分析 : slave节点进行全量复制的时候还得先清空所有缓存数据, 如果缓存数据量比较大也是需要一段时间的, 另外就是加载RDB也是非常耗时, 还有就是如果开启AOF重写的话,意味着slave还要进行耗时的AOF重写操作

注意:
按照同步的时机来分的话, 可以将其分为: slave刚启动的与master连接时的初始化同步 | 正常运行过程中的数据修改同步
初始化的数据同步就是全量复制, 但是, 部分复制并非是正常运行过程中的数据修改时的主从数据实时同步的方式

部分复制使用psync {runId} {offset} 命令实现, 当主从结构正常运行时突然出现网络闪断或者抖动时导致命令丢失等异常情况时, master节点在这段不能正常实时给slave同步数据的期间会将更新的数据记录在复制积压缓冲区, 当slave节点重新与master建立正常连接后, slave节点会向master节点要求补发丢失的命令数据, 流程图如下:

• 1 .出现主从节点连接丢失
• 2 .在主从中断期间master是正常响应客户端的, 但是更新的数据不能正常响应给slave节点, 这时候是将更新数据记录在复制积压缓存区中
• 3 .主从恢复连接
• 4 .恢复连接之后, 因为不是初次与master建立主从关系, slave还保存着master额run_id和偏移量offset, 所以请求psync命令时携带这两个参数
• 5 .master节点收到psync后, 首先核对runid是否和自己当前的runid是否一致, 如果一致则说明之前的复制的这个主节点; 之后再根据参数offset在复制积压缓冲区查找, 如果偏移量之后的数据存在缓冲区中, 则响应slave节点CONTINUE(继续), 表示可以进行部分复制; 如果核对后发现不一致, 有一点不满足就执行全量复制
• 6 .主节点根据偏移量把复制积压缓冲区里的数据发送给从节点, 达到数据一致

部分复制目的就是当出现网络中断等异常情况导致主从节点不能正常同步实时数据的情况下, 在补发丢失的数据式尽量减少全量复制操作从而提升效率和性能

Sentinel哨兵模式

学习中, 待续…