分布式缓存数据库Redis

什么是Redis&Redis版本介绍

  • redis

    Redis 是一个基于内存的高性能key-value数据库,是一个开源(BSD许可)的,内存中的数据结构存储系统,它可以用作数据库、缓存和消息中间件
    
  • Reids的特点

    	Redis本质上是一个Key-Value类型的内存数据库,很像memcached,整个数据库通通加载在内存当中进行操作,定期通过异步操作把数据库数据flush到硬盘上进行保存。因为是纯内存操作,Redis的性能非常出色,每秒可以处理超过 10万次读写操作,是已知性能最快的Key-Value DB。
       Redis的出色之处不仅仅是性能,Redis最大的魅力是支持保存多种数据结构,此外单个value的最大限制是1GB,不像memcached只能保存1MB的数据,因此Redis可以用来实现很多有用的功能,比方说用他的List来做FIFO双向链表,实现一个轻量级的高性 能消息队列服务,用他的Set可以做高性能的tag系统等等。另外Redis也可以对存入的Key-Value设置expire时间,因此也可以被当作一 个功能加强版的memcached来用。
       Redis的主要缺点是数据库容量受到物理内存的限制,不能用作海量数据的高性能读写,因此Redis适合的场景主要局限在较小数据量的高性能操作和运算上。
    
  • 应用场景

    redis应用场景总结redis平时我们用到的地方蛮多的,下面就了解的应用场景做个总结:
    1、热点数据的缓存
    由于redis访问速度块、支持的数据类型比较丰富,所以redis很适合用来存储热点数据,另外结合expire,我们可以设置过期时间然后再进行缓存更新操作,这个功能最为常见,我们几乎所有的项目都有所运用。
    
    2、限时业务的运用(实现验证码60s)
    redis中可以使用expire命令设置一个键的生存时间,到时间后redis会删除它。利用这一特性可以运用在限时的优惠活动信息、手机验证码等业务场景。
    
    3、计数器相关问题
    redis由于incrby命令可以实现原子性的递增,所以可以运用于高并发的秒杀活动、分布式序列号的生成、具体业务还体现在比如限制一个手机号发多少条短信、一个接口一分钟限制多少请求、一个接口一天限制调用多少次等等。
    
    4、排行榜相关问题
    关系型数据库在排行榜方面查询速度普遍偏慢,所以可以借助redis的SortedSet进行热点数据的排序。
    在奶茶活动中,我们需要展示各个部门的点赞排行榜, 所以我针对每个部门做了一个SortedSet,然后以用户的openid作为上面的username,以用户的点赞数作为上面的score, 然后针对每个用户做一个hash,通过zrangebyscore就可以按照点赞数获取排行榜,然后再根据username获取用户的hash信息,这个当时在实际运用中性能体验也蛮不错的。
    
    5、分布式锁(Redission)
    这个主要利用redis的setnx命令进行,setnx:"set if not exists"就是如果不存在则成功设置缓存同时返回1,否则返回0 ,这个特性在俞你奔远方的后台中有所运用,因为我们服务器是集群的,定时任务可能在两台机器上都会运行,所以在定时任务中首先 通过setnx设置一个lock,如果成功设置则执行,如果没有成功设置,则表明该定时任务已执行。 当然结合具体业务,我们可以给这个lock加一个过期时间,比如说30分钟执行一次的定时任务,那么这个过期时间设置为小于30分钟的一个时间 就可以,这个与定时任务的周期以及定时任务执行消耗时间相关。
    当然我们可以将这个特性运用于其他需要分布式锁的场景中,结合过期时间主要是防止死锁的出现。
    
    6、延时操作
    这个目前我做过相关测试,但是还没有运用到我们的实际项目中,下面我举个该特性的应用场景。 比如在订单生产后我们占用了库存,10分钟后去检验用户是够真正购买,如果没有购买将该单据设置无效,同时还原库存。 由于redis自2.8.0之后版本提供Keyspace Notifications功能,允许客户订阅Pub/Sub频道,以便以某种方式接收影响Redis数据集的事件。 所以我们对于上面的需求就可以用以下解决方案,我们在订单生产时,设置一个key,同时设置10分钟后过期, 我们在后台实现一个监听器,监听key的实效,监听到key失效时将后续逻辑加上。 当然我们也可以利用rabbitmq、activemq等消息中间件的延迟队列服务实现该需求。
    
    7、分页、模糊搜索
    redis的set集合中提供了一个zrangebylex方法,语法如下:
    ZRANGEBYLEX key min max [LIMIT offset count]
    通过ZRANGEBYLEX zset - + LIMIT 0 10 可以进行分页数据查询,其中- +表示获取全部数据
    zrangebylex key min max 这个就可以返回字典区间的数据,利用这个特性可以进行模糊查询功能,这个也是目前我在redis中发现的唯一一个支持对存储内容进行模糊查询的特性。
    前几天我通过这个特性,对学校数据进行了模拟测试,学校数据60万左右,响应时间在700ms左右,比mysql的like查询稍微快一点,但是由于它可以避免大量的数据库io操作,所以总体还是比直接mysql查询更利于系统的性能保障。
    
    8、点赞、好友等相互关系的存储
    Redis set对外提供的功能与list类似是一个列表的功能,特殊之处在于set是可以自动排重的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口,这个也是list所不能提供的。 又或者在微博应用中,每个用户关注的人存在一个集合中,就很容易实现求两个人的共同好友功能。
    
    这个在奶茶活动中有运用,就是利用set存储用户之间的点赞关联的,另外在点赞前判断是否点赞过就利用了sismember方法,当时这个接口的响应时间控制在10毫秒内,十分高效。
    
    9、队列(MQ,java---->Queue)
    由于redis有list push和list pop这样的命令,所以能够很方便的执行队列操作。 
    
  • 使用redis有哪些好处

    (1) 速度快,因为数据存在内存中,类似于HashMap,HashMap的优势就是查找和操作的时间复杂度都是O(1) 
    (2) 支持丰富数据类型,支持string,list,set,sorted set,hash 
    (3) 支持事务,操作都是原子性,所谓的原子性就是对数据的更改要么全部执行,要么全部不执行 
    (4) 丰富的特性:可用于缓存,消息,按key设置过期时间,过期后将会自动删除 
    
  • 版本介绍

    第二位数为偶数代表稳定版,奇数则是测试版
    

Redis的获取和下载安装

  • 下载地址

    http://www.redis.cn/download.html
    
  • 历史版本地址

    http://download.redis.io/releases
    
  • 下载4.0的版本

    #没有wget
    yum install wget
    #获取安装包(其实可以使用网易镜像或者阿里镜像下载)
    wget -P /usr/local/src/ http://download.redis.io/releases/redis-4.0.0.tar.gz
    
  • 下载、解压、编译Redis

    #如果安装报错gcc:命令未找到(因为redis基于c语言编写)
    #先查看是否安装c++的编译器
    yum -y install gcc-c++
    #执行 make clean 后再次 执行 make
    make clean
    #致命错误:jemalloc/jemalloc.h:没有那个文件或目录
    make MALLOC=libc
    
    $ wget http://download.redis.io/releases/redis-4.0.0.tar.gz
    $ tar xzf redis-4.0.0.tar.gz
    $ cd redis-4.0.0
    $ make
    

Redis的启动和卸载

#启动redis服务端
./redis-server

#启动redis客户端
./redis-cli

#测试(查询所有的键)
keys *

#守护进程启动
[root@localhost redis-4.0.0]# cp redis.conf ./src/
vi redis.conf
# By default Redis does not run as a daemon. Use 'yes' if you need it.
# Note that Redis will write a pid file in /var/run/redis.pid when daemonized.
daemonize yes
#再次启动
./redis-server redis.conf
[root@localhost src]# ./redis-cli 
127.0.0.1:6379> keys *
(empty list or set)
127.0.0.1:6379> exit
#结束进程
[root@localhost src]# ps -ef | grep redis
root       5664   5645  0 17:08 pts/1    00:00:00 ./redis-cli
root       5734      1  0 17:28 ?        00:00:00 ./redis-server 127.0.0.1:6379
root       5766   1327  0 17:33 pts/0    00:00:00 grep --color=auto redis
[root@localhost src]# kill -9 5664
[root@localhost src]# kill -9 5734
[root@localhost src]# ps -ef | grep redis
root       5768   1327  0 17:34 pts/0    00:00:00 grep --color=auto redis
[root@localhost src]#
#卸载的话直接删除redis的安装文件夹就行了

Redis和Memcache的对比

1)、存储方式 Memecache把数据全部存在内存之中,断电后会挂掉,数据不能超过内存大小。 Redis有部份存在硬盘上,这样能保证数据的持久性。 
2)、数据支持类型 Memcache对数据类型支持相对简单。 Redis有复杂的数据类型。 
3)、使用底层模型不同 它们之间底层实现方式 以及与客户端之间通信的应用协议不一样。 Redis直接自己构建了VM 机制 ,因为一般的系统调用系统函数的话,会浪费一定的时间去移动和请求

Redis的数据结构_字符串

string 是 redis 最基本的类型,你可以理解成与 Memcached 一模一样的类型,一个 key 对应一个 value。

string 类型是二进制安全的。意思是 redis 的 string 可以包含任何数据。比如jpg图片或者序列化的对象。

string 类型是 Redis 最基本的数据类型,string 类型的值最大能存储 512MB。 (Redis是单线程的,这也是为什么能够去实现分布式锁的一个重要条件)

#会涉及到分布式锁
Setnx(SET if Not eXists)

[root@localhost src]# ./redis-cli 
127.0.0.1:6379> set name 'ange'
OK
127.0.0.1:6379> get name
"ange"

Redis的数据结构_哈希

一般是用来存放对象的

Redis hash 是一个键值(key=>value)对集合。

Redis hash 是一个 string 类型的 field 和 value 的映射表,hash 特别适合用于存储对象。

127.0.0.1:6379> hset user name 'ange'
(integer) 1
127.0.0.1:6379> hset user age 18
(integer) 1
127.0.0.1:6379> hset user sex 1
(integer) 1
127.0.0.1:6379> hkeys user
1) "name"
2) "age"
3) "sex"
127.0.0.1:6379> hlen user
(integer) 3
127.0.0.1:6379> hget user name
"ange"
127.0.0.1:6379> hdel user name
(integer) 1
127.0.0.1:6379> hkeys user
1) "age"
2) "sex"
127.0.0.1:6379> hget user name
(nil)
127.0.0.1:6379>

Redis的数据结构_列表

Redis 列表是简单的字符串列表,允许重复的值,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边)。列表最多可存储 232 - 1 元素 (4294967295, 每个列表可存储40多亿)。

127.0.0.1:6379> lpush teachers 'ange'
(integer) 1
127.0.0.1:6379> lpush teachers 'pika'
(integer) 2
127.0.0.1:6379> lpush teachers 'rock'
(integer) 3
127.0.0.1:6379> lrange teachers 0 1
1) "rock"
2) "pika"
127.0.0.1:6379> lrange teachers 0 -1
1) "rock"
2) "pika"
3) "ange"
127.0.0.1:6379> rpop teachers
"ange"
127.0.0.1:6379> lrange teachers 0 -1
1) "rock"
2) "pika"
127.0.0.1:6379> lpop teachers
"rock"
127.0.0.1:6379> lrange teachers 0 -1
1) "pika"
127.0.0.1:6379>

#lpop 从左开始删除   rpop从右开始删除

Redis的数据结构_集合

Redis 的 Set 是 string 类型的无序集合,但是值是唯一的。

集合是通过哈希表实现的,所以添加,删除,查找的复杂度都是 O(1)。

127.0.0.1:6379> sadd num 1
(integer) 1
127.0.0.1:6379> sadd num 2
(integer) 1
127.0.0.1:6379> sadd num 3
(integer) 1
127.0.0.1:6379> smembers num
1) "1"
2) "2"
3) "3"
127.0.0.1:6379> spop num
"3"
127.0.0.1:6379> sadd num 3
(integer) 1
127.0.0.1:6379> sadd num 2
(integer) 0

Redis的数据结构_有序集合

Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。

不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

zset的成员是唯一的,但分数(score)却可以重复。

127.0.0.1:6379> zadd teacher 1 'ange'
(integer) 1
127.0.0.1:6379> zadd teacher 2 'pika'
(integer) 1
127.0.0.1:6379> zadd teacher 3 'rokc'
(integer) 1
127.0.0.1:6379> zrange teacher 0 -1
1) "ange"
2) "pika"
3) "rokc"
127.0.0.1:6379> zrange teacher 0 -1 withscores
1) "ange"
2) "1"
3) "pika"
4) "2"
5) "rokc"
6) "3"
127.0.0.1:6379> zadd teacher 3 'rock'
(integer) 1
127.0.0.1:6379> zrange teacher 0 -1 withscores
1) "ange"
2) "1"
3) "pika"
4) "2"
5) "rock"
6) "3"
7) "rokc"
8) "3"
127.0.0.1:6379> zrem teacher 'ange'
(integer) 1
127.0.0.1:6379> zrange teacher 0 -1 withscores
1) "pika"
2) "2"
3) "rock"
4) "3"
5) "rokc"
6) "3"

Redis的数据结构对比

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-k16oVJfZ-1574734691836)(D:\TinkingCat\Redis\assets\093929_EfUQ_93789.png)]

Redis的持久化策略

reids是一个key-value存储系统,为了保证效率,缓存在内存中,但是redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件,以保证数据的持久化。

所以:redis是一个支持持久化的内存数据库,可以将内存中的数据同步到磁盘保证持久化。

Redis的持久化策略:2种

rdb:快照形式是直接把内存中的数据保存到一个dump文件中,定时保存,保存策略
aof:把所有的对redis的服务器进行修改的命令都存到一个文件里,命令的集合

RDB

默认情况下,是快照rdb的持久化方式,将内存中的数据以快照的方式写入二进制文件中,默认的文件名是dump.rdb

redis.conf配置:
save 900 1 
save 300 10
save 60 10000

默认是如上配置:900秒之内,如果超过1个key被修改,则发起快照保存;

300秒内,如果超过10个key被修改,则发起快照保存

1分钟之内,如果1万个key被修改,则发起快照保存

这种方式不能完全保证数据持久化,因为是定时保存,所以当redis服务down掉,就会丢失一部分数据,而且数据量大,写操作多的情况下,会引起大量的磁盘IO操作,会影响性能。

所以,如果这两种方式同时开启,如果对数据进行恢复,不应该用rdb持久化方式对数据库进行恢复。[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-QAi7fB10-1574734691837)(D:\TinkingCat\Redis\assets\20160830101545693.png)]

AOF

使用aof做持久化,每一个写命令都通过write函数追加到appendonly.aof中.

配置方式:启动aof持久化的方式

appendonly yes  

两种持久化策略,各有各的优缺点,依需求而定。

混合持久化

重启 Redis 时,我们很少使用 rdb 来恢复内存状态,因为会丢失大量数据。我们通常使用 AOF 日志重放,但是重放 AOF 日志性能相对 rdb 来说要慢很多,这样在 Redis 实例很大的情况下,启动需要花费很长的时间。 Redis 4.0 为了解决这个问题,带来了一个新的持久化选项——混合持久化。AOF在重写(aof文件里可能有太多没用指令,所以aof会定期根据内存的最新数据生成aof文件)时将重写这一刻之前的内存rdb快照文件的内容和增量的 AOF修改内存数据的命令日志文件存在一起,都写入新的aof文件,新的文件一开始不叫appendonly.aof,等到重写完新的AOF文件才会进行改名,原子的覆盖原有的AOF文件,完成新旧两个AOF文件的替换;
AOF根据配置规则在后台自动重写,也可以人为执行命令bgrewriteaof重写AOF。 于是在 Redis 重启的时候,可以先加载 rdb 的内容,然后再重放增量 AOF 日志就可以完全替代之前的 AOF 全量文件重放,重启效率因此大幅得到提升。
相关配置:

#redis 4.0引入
# 是否开启混合持久化
aof-use-rdb-preamble yes

过期键删除和淘汰策略

Redis的数据存在内存中,保证数据的高效,万一内存满了呢?Redis的内存管理,从两方面下手:

  • 过期键的处理
  • 淘汰策略

一,过期删除策略

redis数据库键的过期时间都保存在过期字典中,根据系统时间和存活时间判断是否过期。(一直存放)

redis有三种不同的删除策略:

1,定时删除:实现方式,创建定时器

2,惰性删除:每次获取键时,检查是否过期

3,定期删除:每隔一段时间,对数据库进行一次检查,删除过期键,由算法决定删除多少过期键和检查多少数据库

二,优缺点

1,定时删除,对内存友好,但是对cpu很不友好

2,惰性删除,对cpu友好,对内存很不友好

3,定期删除,是两种折中,但是,如果删除太频繁,将退化为定时删除,如果删除次数太少,将退化为惰性删除。

淘汰策略

# MAXMEMORY POLICY: how Redis will select what to remove when maxmemory
# is reached. You can select among five behaviors:
#最大内存策略:当到达最大使用内存时,你可以在下面5种行为中选择,Redis如何选择淘汰数据库键

#当内存不足以容纳新写入数据时

# volatile-lru -> remove the key with an expire set using an LRU algorithm
# volatile-lru :在设置了过期时间的键空间中,移除最近最少使用的key。这种情况一般是把 redis 既当缓存,又做持久化存储的时候才用。

# allkeys-lru -> remove any key according to the LRU algorithm
# allkeys-lru : 移除最近最少使用的key (推荐)

# volatile-random -> remove a random key with an expire set
# volatile-random : 在设置了过期时间的键空间中,随机移除一个键,不推荐

# allkeys-random -> remove a random key, any key
# allkeys-random : 直接在键空间中随机移除一个键,弄啥叻

# volatile-ttl -> remove the key with the nearest expire time (minor TTL)
# volatile-ttl : 在设置了过期时间的键空间中,有更早过期时间的key优先移除 不推荐

# noeviction -> don't expire at all, just return an error on write operations
# noeviction : 不做过键处理,只返回一个写操作错误。 不推荐

# Note: with any of the above policies, Redis will return an error on write
#       operations, when there are no suitable keys for eviction.
# 上面所有的策略下,在没有合适的淘汰删除的键时,执行写操作时,Redis 会返回一个错误。下面是写入命令:
#       At the date of writing these commands are: set setnx setex append
#       incr decr rpush lpush rpushx lpushx linsert lset rpoplpush sadd
#       sinter sinterstore sunion sunionstore sdiff sdiffstore zadd zincrby
#       zunionstore zinterstore hset hsetnx hmset hincrby incrby decrby
#       getset mset msetnx exec sort

# 过期策略默认是:
# The default is:
# maxmemory-policy noeviction
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值