1.1Redis是什么
(1)Redis是一个开源的key-value存储系统。
(2)它支持存储的value类型相对更多,包括string(字符串)、list(链表)、set(集合)、zset(sorted set)和hash(哈希类型)。
(3)Redis会周期性的把更新的数据写入磁盘或者把修改操作写入追加的记录文件
(4)支持高可用和集群模式。
1.2 Redis的应用场景
1.2.1 配合关系型数据库做高速缓存
(1)高频次,热门访问的数据,降低数据库IO
(2)经典的Cache Aside Pattern(旁路缓存模式)
1.2.2 大数据场景
1)缓存数据
(1)需要高频次访问
(2)持久化数据访问较慢
2)临时数据
(1)高频次
(2)读写时效性高
(3)总数据量不大
(4)临时性
(5)用key查询
3)计算结果
(1)高频次写入
(2)高频次查询
(3)总数据量不大
1.2.3 利用其多样的数据结构存储特定的数据
(1)最新N个数据通过List实现按自然事件排序的数据
(2)排行榜,TopN利用zset(有序集合)
(3)时效性的数据,比如手机验证码Expire过期
(4)计数器,秒杀,原子性,自增方法INCR、DECR
(5)去除大量数据中的重复数据,利用set集合
(6)构建队列利用list集合
(7)发布订阅消息系统 pub/sub模式
2 NoSQL数据库
2.1 NoSQL是什么
(1)NoSQL(Not Only SQL ),意即“不仅仅是SQL”,泛指非关系型的数据库。
(2)NoSQL不拘泥于关系型数据库的设计范式,放弃了通用的技术标准,为某一领域特定场景而设计,从而使性能、容量、扩展性都达到了一定程度的突破。
2.2 NoSQL的特点
(1)不遵循SQL标准
(2)不支持ACID
(3)远超于SQL的性能。
2.3 NoSQL的适用场景
(1)对数据高并发的读写
(2)海量数据的读写
(3)对数据高可扩展性的
2.4 NoSQL的不适用场景
(1)需要事务支持
(2)基于SQL的结构化查询存储,处理复杂的关系,需要即席查询。
(3)用不着SQL或者用了SQL也不行的情况,请考虑用NoSql
2.5 NoSQL家族
1)Memcached
(1)很早出现的NoSQL数据库。
(2)数据都在内存中,一般不持久化。
(3)支持简单的key-value模式,数据类型支持单一。
(4)一般是作为缓存数据库辅助持久化的数据库。
2)Redis
(1)几乎覆盖了Memcached的绝大部分功能。
(2)数据都在内存中,支持持久化,主要用作备份恢复。
(3)支持丰富的数据类型,例如 string 、 list 、 set、zset、hash等。
(4)一般是作为缓存数据库辅助持久化的数据库
3)MongoDB
(1)高性能、开源、模式自由的文档型数据库。
(2)数据都在内存中,如果内存不足,把不常用的数据保存到硬盘。
(3)虽然是key-value模式,但是对value(尤其是json)提供了丰富的查询功能。
(4)支持二进制数据及大型对象。
(5)可以根据数据的特点替代RDBMS(关系数据库管理系统),成为独立的数据库。或者配合RDBMS,存储特定的数据。
4)HBase
(1)HBase是Hadoop项目的数据库,主要用于对大量数据进行随机、实时的读写操作。
(2)HBase能支持到数十亿行 × 百万列的数据表。
5)Neo4j
(1)Neo4j是基于图结构的数据库,一般用于构建社交网络、交通网络、地图等。
第三章 Redis官网
(1)Redis官方网站 http://Redis.io
(2)Redis中文官方网站 http://www.Redis.net.cn
(3)帮助手册Redis 命令参考 — Redis 命令参考
第4章 Redis的五大数据类型
4.1String特点
(1)String是Redis最基本的类型,适合保存单值类型,即一个key对应一个value
(2)String类型是二进制安全的。意味着Redis的string可以包含任何数据。比如jpg图片或者序列化的对象。
(3)一个Redis中字符串value最多可以是512M。
4.2 List
4.2.1 特点
(1)单键多值。
(2)Redis List是简单的字符串列表,按照插入顺序排序。你可以添加一个元素到列表的头部(左边)或者尾部(右边)。
(3)它的底层实际是个双向链表,对两端的操作性能很高,通过索引下标的操作中间的节点性能会较差。
4.3 Set
4.3.1 特点
(1)set中的元素是无序不重复的,当你需要存储一个列表数据,又不希望出现重复数据时,set是一个很好的选择,并且set提供了判断某个成员是否在一个set集合内的重要接口。
(2)Redis的Set是string类型的无序集合。它底层其实是一个value为null的hash表,所以添加,删除,查找的复杂度都是O(1)。
4.4 Hash
4.4.1 特点
(1)Redis hash是一个键值对集合。
(2)Redis hash的值是由多个field和value组成的映射表。
(3)类似Java里面的Map<String, Object>。
4.5 zset
4.5.1 特点
(1)Redis有序集合zset与普通集合set非常相似,是一个没有重复元素的字符串集合。不同之处是有序集合的每个成员都关联了一个评分(score),这个评分(score)被用来按照从最低分到最高分的方式排序集合中的成员。集合的成员是唯一的,但是评分可以是重复了。
(2)因为元素是有序的,所以你也可以很快的根据评分(score)或者次序(position)来获取一个范围的元素。访问有序集合的中间元素也是非常快的,因此你能够使用有序集合作为一个没有重复成员的智能列表。
第5章 Redis的相关配置
1)计量单位说明,大小写不敏感
# 1k => 1000 bytes
# 1kb => 1024 bytes
# 1m => 1000000 bytes
# 1mb => 1024*1024 bytes
# 1g => 1000000000 bytes
# 1gb => 1024*1024*1024 bytes
#
# units are case insensitive so 1GB 1Gb 1gB are all the same.
2)bind
默认情况bind=127.0.0.1只能接受本机的访问请求。
不写的情况下,无限制接受任何ip地址的访问,生产环境肯定要写你应用服务器的地址。
如果开启了protected-mode,那么在没有设定bind ip且没有设密码的情况下,Redis只允许接受本机的请求。
#bind 127.0.0.1
Bind hadoop102
protected-mode no
3)port 服务端口号
port 6379
4)daemonize
是否为后台进程。
daemonize yes
5)pidfile
存放pid文件的位置,每个实例会产生一个不同的pid文件。
pidfile /var/run/redis_6379.pid
6)log file
日志文件存储位置。
logfile "/home/atguigu/myredis/redis.log"
7)database
设定库的数量 默认16。
databases 16
8)requirepass
设置密码。
requirepass 123456
127.0.0.1:6379> set k1 v1
(error) NOAUTH Authentication required.
127.0.0.1:6379> auth "123456"
OK
127.0.0.1:6379> set k1 v1
OK
127.0.0.1:6379> get k1
"v1"
9)maxmemory
设置Redis可以使用的内存量。一 旦到达内存使用上限,Redis将会试图移除内部数据,移除规则可以通过maxmemory-policy来指定。如果Redis无法根据移除规则来移除内存中的数据,或者设置了“不允许移除”。
那么Redis则会针对那些需要申请内存的指令返回错误信息,比如SET、LPUSH等。
# maxmemory <bytes>
10)maxmemory-policy
移除策略
# maxmemory-policy noeviction
#volatile-lru:使用LRU算法移除key,只对设置了过期时间的键
#allkeys-lru:使用LRU算法移除key
#volatile-lfu :使用LFU策略移除key,只对设置了过期时间的键.
#allkeys-lfu :使用LFU策略移除key
#volatile-random:在过期集合中移除随机的key,只对设置了过期时间的键
#allkeys-random:移除随机的key
#volatile-ttl:移除那些TTL值最小的key,即那些最近要过期的key
#noeviction:不进行移除。针对写操作,只是返回错误信息
11)Maxmemory-samples
设置样本数量,LRU算法和最小TTL算法都并非是精确的算法,而是估算值,所以你可以设置样本的大小。一般设置3到7的数字,数值越小样本越不准确,但是性能消耗也越小。
# maxmemory-samples 5
第6章 Jedis
Jedis是Redis的Java客户端,可以通过Java代码的方式操作Redis。
6.1 环境准备
1)添加依赖
<dependency>
<groupId>redis.clients</groupId>
<artifactId>jedis</artifactId>
<version>3.3.0</version>
</dependency>
6.2 基本测试
1)测试连通
public class JedisTest {
public static void main(String[] args) {
Jedis jedis = new Jedis("hadoop102",6379);
String ping = jedis.ping();
System.out.println(ping);
jedis.close();
}
}
2)连接池
连接池主要用来节省每次连接redis服务带来的连接消耗,将连接好的实例反复利用。
public static JedisPool pool = null ;
public static Jedis getJedis(){
if(pool == null ){
//主要配置
JedisPoolConfig jedisPoolConfig =new JedisPoolConfig();
jedisPoolConfig.setMaxTotal(10); //最大可用连接数
jedisPoolConfig.setMaxIdle(5); //最大闲置连接数
jedisPoolConfig.setMinIdle(5); //最小闲置连接数
jedisPoolConfig.setBlockWhenExhausted(true); //连接耗尽是否等待
jedisPoolConfig.setMaxWaitMillis(2000); //等待时间
jedisPoolConfig.setTestOnBorrow(true); //取连接的时候进行一下测试 ping pong
pool = new JedisPool(jedisPoolConfig,"hadoop102",6379) ;
}
return pool.getResource();
}
public static void main(String[] args) {
//Jedis jedis = new Jedis("hadoop202",6379);
Jedis jedis = getJedis();
String ping = jedis.ping();
System.out.println(ping);
}
第7章 Redis 持久化
7.1 两种方式
Redis提供了2个不同形式的持久化方式 RDB 和 AOF。
(1)RDB为快照备份,会在备份时将内存中的所有数据持久化到磁盘的一个文件中。
(2)AOF为日志备份,会将所有写操作命令记录在一个日志文件中。
7.2 RDB(Redis Database)
7.2.1 是什么
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里。
7.2.2 如何执行持久化
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
7.2.3 RDB文件
1)RDB保存的文件
在redis.conf中配置文件名称,默认为dump.rdb。
dbfilename dump.rdb
2)RDB文件的保存路径
默认为Redis启动时命令行所在的目录下,也可以修改。
dir /home/atguigu/myredis
7.2.4 RDB保存策略
# save <seconds> <changes>
# Will save the DB if both the given number of seconds and the given
# number of write operations against the DB occurred.
#
# In the example below the behaviour will be to save:
# after 900 sec (15 min) if at least 1 key changed
# after 300 sec (5 min) if at least 10 keys changed
# after 60 sec if at least 10000 keys changed
# Note: you can disable saving completely by commenting out all "save" lines.
save 900 1
save 300 10
save 60 10000
7.2.5 手动保存
(1)save:只管保存,其它不管,全部阻塞。
(2)bgsave:按照保存策略自动保存。
(3)shutdown:时服务会立刻执行备份后再关闭。
(4)flushall:时会将清空后的数据备份。
7.2.6 RDB备份恢复
1)备份
将dump.rdb文件拷贝到要备份的位置。
2)恢复
关闭Redis,把备份的文件拷贝到工作目录下,启动redis,备份数据会直接加载。
7.2.7 RDB其他配置
1)进行rdb保存时,将文件压缩
rdbcompression yes
2)文件校验
在存储快照后,还可以让Redis使用CRC64算法来进行数据校验,可以校验RDB持久化文件是否损坏,但是这样做会增加大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。
rdbchecksum yes
7.2.8 RDB优缺点
1)优点:
节省磁盘空间,恢复速度快。
2)缺点:
虽然Redis在fork时使用了写时拷贝技术,但是如果数据庞大时还是比较消耗性能。在备份周期在一定间隔时间做一次备份,所以如果Redis意外down掉的话,就会丢失最后一次快照后的所有修改。
7.3 AOF(Append Only File)
7.3.1 是什么
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,Redis启动之初会读取该文件重新构建数据,换言之,Redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。
7.3.2 开启AOF
1)AOF默认不开启,需要手动在配置文件中配置
appendonly yes
2)AOF文件
appendfilename "appendonly.aof"
3)AOF文件保存的位置,与RDB的路径一致
dir /home/atguigu/myredis
7.3.3 AOF同步频率
# no: don't fsync, just let the OS flush the data when it wants. Faster.
# always: fsync after every write to the append only log. Slow, Safest.
# everysec: fsync only one time every second. Compromise.
7.3.4 AOF文件损坏恢复
redis-check-aof --fix appendonly.aof
7.3.5 AOF备份
AOF的备份机制和性能虽然和RDB不同, 但是备份和恢复的操作同RDB一样,都是拷贝备份文件,需要恢复时再拷贝到Redis工作目录下,启动系统即加载。
7.3.6 Rewrite
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的重写,只保留可以恢复数据的最小指令集。可以使用命令bgrewriteaof手动开始重写。
重写虽然可以节约大量磁盘空间,减少恢复时间。但是每次重写还是有一定的负担的,因此设定Redis要满足一定条件才会进行重写。
系统载入时或者上次重写完毕时,Redis会记录此时AOF大小,设为base_size,如果Redis的AOF当前大小>= base_size + base_size*100% (默认)且当前大小>=64mb(默认)的情况下,Redis会对AOF进行重写。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
7.3.7 AOF的优缺点
1)优点:
(1)备份机制更稳健,丢失数据概率更低。
(2)可读的日志文本,通过操作AOF文件,可以处理误操作。
2)缺点:
(1)比起RDB占用更多的磁盘空间。
(2)恢复备份速度要慢。
(3)每次写都同步的话,有一定的性能压力。
(4)存在个别bug,造成恢复不了。
7.4 持久化的优先级
AOF的优先级大于RDB,如果同时开启了AOF和RDB,Redis服务启动时恢复数据以AOF为准。
7.5 RDB和AOF用哪个好
(1)官方推荐两个都启用。
(2)如果对数据不敏感,可以选单独用RDB。
(3)不建议单独用 AOF,因为可能会出现Bug。
(4)如果只是做纯内存缓存,可以都不用。