NoSQL特点
1.方便扩展(数据之间没有关系,很好扩展)
2.大数量高性能(Redis一秒写8万次,读取11万,Nosql的缓存记录级是一种细粒度缓存,性能会比较高)
3.数据类型是多样型(不需要事先设计数据库!)
4.传统RDBMS(关系型数据库)和NoSQL
传统RDBMS
结构化组织
SQL
数据和关系都存在单独的表中
数据定义语言
严格的一致性
基础的事务等
NoSQL
不仅仅是数据
没有固定的查询语言
赋值对存储,列存储,文档储存,图形数据库(社交关系)
最终一致性
CAP定理和BASE(异地多活)
高性能,高可用,高扩展等
NoSQL的四大分类
KV键值对
Redis
列存储数据库
HBase 分布式文件系统
文档型数据库
MongoDB是一个基于分布式文件系统的数据库,C++编写,主要用来处理大量的文档
MongoDB是一个介于关系型数据库和非关系型数据库中间的产品!MongoDB是菲关系型数据库中功能丰富,最像关系型数据库
图形数据库
他不是存图形,放的是关系 如:社交网络
Neo4j,infoGrid
Redis是什么
开源使用ANSI C语言编写,支持网络,基于内容可持久化日志型,Key-Value数据库,提供多种语言api,免费开源!是当下最热门NoSQL技术,被称为结构化数据库
Redis能干嘛
1.内存存储,持久化,内存中断电即失,所有持久化很重要
2.效率高,可以用于高速缓存
3.发布订阅系统
4.地图信息解析
5.计时器,计数器(浏览量)等等
Redis特性
1.多样的数据类型
2.持久化
3.集群
4.事务
学习Redis中需要用到的东西
1.公众号:狂神说
2.官网:http://www.redis.cn/
3.Redis基本在linux服务器上搭建
Redis使用基本命令
1.select 0-15 切换数据库默认16个
2.dbsize 查看数据多少
3.get key set key 值 获取和设置值
4.keys * 获取所有key
5.flushdb flushall 清空当前库和清空所有
6.EXISTS key 判断key是否存在
7.move key 1 移动key到哪个库
8.EXPIRE key 10 10秒钟key值过期
9.ttl key 查看剩余过期时间
10.type key 查看数据类型
11.APPEND key "" 追加字符串
12.incr key decr key 自增和自减1
13.GETRANGE key 0 3 截取字符串[0-3]
14.SETRANGE key 1 xx 替换指定位置字符串
15.setex key 30 'hello' 设置key30秒过期
16.setnx key '' 不存在在设置(在分布式会常使用)
17.mset key "" key1 "" key2 "" 批量设置(mget获取,原子性操作,要么一起成功要么一起失败)
18.getset key '' 如果不存在值,返回nil,如果存在值,获取原来的值并设置新的值(更新操作)
Redis是单线程的
Redis是基于内存操作,CPU不是Redis性能瓶颈,Redis是根据机器内存和网络带宽,使用的是单线程
Redis为什么单线程还快?
1.误区:高性能服务一定是多线程的?
2.多线程一定比单线程效率高!
3.核心:redis将所有的数据全放在内存中,所以使用单线程操作效率最高,多线程对于内存来说,没有切换是效率最高的
Redis安装
1.官网下载最新版Redis并解压 https://redis.io/download
2.
$ wget http://download.redis.io/releases/redis-2.8.17.tar.gz
$ tar zvf redis-2.8.17.tar.gz
$ cd redis-2.8.17
$ make
3.make完后 redis-2.8.17目录下会出现编译后的redis服务程序redis-server,还有用于测试的客户端程序redis-cli
4.下面启动redis服务.$ ./redis-server
注意这种方式启动redis 使用的是默认配置。也可以通过启动参数告诉redis使用指定配置文件使用下面命令启动。$ ./redis-server redis.conf
在redis.conf里找到daemonize no 将no改为yes
5.redis.conf是一个默认的配置文件。我们可以根据需要使用自己的配置文件。
启动redis服务进程后,就可以使用测试客户端程序redis-cli和redis服务交互了。 比如:$ ./redis-cli
redis> set foo bar
OK
redis> get foo
"bar"
Redis数据类型
Redis支持五种数据类型:string(字符串),hash(哈希),list(列表),set(集合)及zset(sorted set:有序集合)。
Redis三大特殊数据类型:geospatial hyperloglog bitmaps
String
String类似使用场景:value除了是我们的字符串还可以是我们的数字
--计数器
--统计多单位的数量
--粉丝数
--对象缓存存储
List
在redis里面,我们可以把list玩成栈,队列,阻塞队列!所有的list命令都是l开头的,list值可以按照正序反序插入和查询,删除等,也可以通过下标获取值
使用场景:消息排队!消息队列!栈
Set
Set值是不能重复的
使用场景:微博,A用户将所有关注的人放在一个set集合中!将它的粉丝也放在一个集合中!
共同关注,共同爱好,二度好友,推荐好友(六度分割理论)
Hash
hset user name zhangsan
hget user name
...
Zset
在set基础上加一个score值
之前set是k1 v1 v2 v3
现在zset是k1 score1 v1 score2 v2
zadd/zrange
解析Redis配置文件redis.conf
1.开头:配置大小单位,定义了基本的度量单位,只支持bytes,不支持bit,对大小写不敏感
2.INCLUDES包含:Struts2配置文件类似,可以通过includes包含,redis.conf可以作为总阀,包含其他
3.GENERAL通用:
tcp-backlog:设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列 + 已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意Linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和tcp_max_syn_backlog两个值
来达到想要的效果
tcp-keepallve:单位为秒,设置0则不会进行检测,建议设置60
Syslog-enabled:是否把日志输出到syslog中
Syslog-ident:指定syslog里的日志标志
Syslog-facility:指定syslog设备,值可以是USER或LOCAL0-LOCAL7
4.SNAPSHOTTING快照
RDB是整个内存的压缩过的Snapshot,RDB的数据结构,可以配置复合的快照触发条件,
默认
是1分钟内改了1万次,
或5分钟内改了10次,
或15分钟内改了1次
如果想禁用RDB持久化的策略,只要不设置任何save指令,或者给save传入一个空字符串参数也可以
5.SECURITY安全
6.LIMITS限制
Maxclients Maxmemory Maxmemory-policy...
Maxmemory-policy:
noeviction 永不过期缓存
volatile-lru 使用LRU算法移除key,只对设置了过期时间键
allkeys-lru 使用LRU算法移除key
volatile-random 移除随机key
volatile-ttl 移除最小的可以,就是近期要过期
7.APPEND ONLY MODE追加
8.REPLICCATION复制
常见配置redis.conf介绍
参数说明
redis.conf 配置项说明如下:
1. Redis默认不是以守护进程的方式运行,可以通过该配置项修改,使用yes启用守护进程
daemonize no
2. 当Redis以守护进程方式运行时,Redis默认会把pid写入/var/run/redis.pid文件,可以通过pidfile指定
pidfile /var/run/redis.pid
3. 指定Redis监听端口,默认端口为6379,作者在自己的一篇博文中解释了为什么选用6379作为默认端口,因为6379在手机按键上MERZ对应的号码,而MERZ取自意大利歌女Alessia Merz的名字
port 6379
4. 绑定的主机地址
bind 127.0.0.1
5.当 客户端闲置多长时间后关闭连接,如果指定为0,表示关闭该功能
timeout 300
6. 指定日志记录级别,Redis总共支持四个级别:debug、verbose、notice、warning,默认为verbose
loglevel verbose
7. 日志记录方式,默认为标准输出,如果配置Redis为守护进程方式运行,而这里又配置为日志记录方式为标准输出,则日志将会发送给/dev/null
logfile stdout
8. 设置数据库的数量,默认数据库为0,可以使用SELECT 命令在连接上指定数据库id
databases 16
9. 指定在多长时间内,有多少次更新操作,就将数据同步到数据文件,可以多个条件配合
save
Redis默认配置文件中提供了三个条件:
save 900 1
save 300 10
save 60 10000
分别表示900秒(15分钟)内有1个更改,300秒(5分钟)内有10个更改以及60秒内有10000个更改。
10. 指定存储至本地数据库时是否压缩数据,默认为yes,Redis采用LZF压缩,如果为了节省CPU时间,可以关闭该选项,但会导致数据库文件变的巨大
rdbcompression yes
11. 指定本地数据库文件名,默认值为dump.rdb
dbfilename dump.rdb
12. 指定本地数据库存放目录
dir ./
13. 设置当本机为slav服务时,设置master服务的IP地址及端口,在Redis启动时,它会自动从master进行数据同步
slaveof
14. 当master服务设置了密码保护时,slav服务连接master的密码
masterauth
15. 设置Redis连接密码,如果配置了连接密码,客户端在连接Redis时需要通过AUTH 命令提供密码,默认关闭
requirepass foobared
16. 设置同一时间最大客户端连接数,默认无限制,Redis可以同时打开的客户端连接数为Redis进程可以打开的最大文件描述符数,如果设置 maxclients 0,表示不作限制。当客户端连接数到达限制时,Redis会关闭新的连接并向客户端返回max number of clients reached错误信息
maxclients 128
17. 指定Redis最大内存限制,Redis在启动时会把数据加载到内存中,达到最大内存后,Redis会先尝试清除已到期或即将到期的Key,当此方法处理 后,仍然到达最大内存设置,将无法再进行写入操作,但仍然可以进行读取操作。Redis新的vm机制,会把Key存放内存,Value会存放在swap区
maxmemory
18. 指定是否在每次更新操作后进行日志记录,Redis在默认情况下是异步的把数据写入磁盘,如果不开启,可能会在断电时导致一段时间内的数据丢失。因为 redis本身同步数据文件是按上面save条件来同步的,所以有的数据会在一段时间内只存在于内存中。默认为no
appendonly no
19. 指定更新日志文件名,默认为appendonly.aof
appendfilename appendonly.aof
20. 指定更新日志条件,共有3个可选值:
no:表示等操作系统进行数据缓存同步到磁盘(快)
always:表示每次更新操作后手动调用fsync()将数据写到磁盘(慢,安全)
everysec:表示每秒同步一次(折衷,默认值)
appendfsync everysec
21. 指定是否启用虚拟内存机制,默认值为no,简单的介绍一下,VM机制将数据分页存放,由Redis将访问量较少的页即冷数据swap到磁盘上,访问多的页面由磁盘自动换出到内存中(在后面的文章我会仔细分析Redis的VM机制)
vm-enabled no
22. 虚拟内存文件路径,默认值为/tmp/redis.swap,不可多个Redis实例共享
vm-swap-file /tmp/redis.swap
23. 将所有大于vm-max-memory的数据存入虚拟内存,无论vm-max-memory设置多小,所有索引数据都是内存存储的(Redis的索引数据 就是keys),也就是说,当vm-max-memory设置为0的时候,其实是所有value都存在于磁盘。默认值为0
vm-max-memory 0
24. Redis swap文件分成了很多的page,一个对象可以保存在多个page上面,但一个page上不能被多个对象共享,vm-page-size是要根据存储的 数据大小来设定的,作者建议如果存储很多小对象,page大小最好设置为32或者64bytes;如果存储很大大对象,则可以使用更大的page,如果不 确定,就使用默认值
vm-page-size 32
25. 设置swap文件中的page数量,由于页表(一种表示页面空闲或使用的bitmap)是在放在内存中的,,在磁盘上每8个pages将消耗1byte的内存。
vm-pages 134217728
26. 设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的,可能会造成比较长时间的延迟。默认值为4
vm-max-threads 4
27. 设置在向客户端应答时,是否把较小的包合并为一个包发送,默认为开启
glueoutputbuf yes
28. 指定在超过一定的数量或者最大的元素超过某一临界值时,采用一种特殊的哈希算法
hash-max-zipmap-entries 64
hash-max-zipmap-value 512
29. 指定是否激活重置哈希,默认为开启(后面在介绍Redis的哈希算法时具体介绍)
activerehashing yes
30. 指定包含其它的配置文件,可以在同一主机上多个Redis实例之间使用同一份配置文件,而同时各个实例又拥有自己的特定配置文件
include /path/to/local.conf
Redis的持久化
1.RDB
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是行话讲的Snapshot快照,它恢复时是将快照文件直接读到内存里
Redis会单独创建(fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量、程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程
Rdb保存的是dump.rdb文件
配置文件中默认的快照配置:冷拷贝后重新使用,可以cp dump.rdb dump_new.rdb(在另外一台服务器上备份)
Save:save时只管保存,其它不管,全部阻塞
BGSAVE:Redis会在后台异步进行快照操作,快照同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间
执行flushall命令,也会产生dump.rdb文件,但里面是空的,无意义
如何恢复:将备份文件 (dump.rdb) 移动到 redis 安装目录并启动服务即可,CONFIG GET dir获取目录
优势:适合大规模的数据恢复对数据完整性和一致性要求不高
劣势:在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改,Fork的时候,内存中的数据被克隆了一份大致2倍的膨胀性需要考虑
动态所有停止RDB保存规则的方法:redis-cli config set save ""
2.AOF
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作,Aof保存的是appendonly.aof文件
AOF启动/修复/恢复:
启动:修改默认的appendonly no,改为yes,将有数据的aof文件复制一份保存到对应目录(config get dir),恢复:重启redis然后重新加载
异常恢复:修改默认的appendonly no,备份被写坏的AOF文件,Redis-check-aof --fix进行修复,恢复:重启redis然后重新加载
Rewrite
AOF采用文件追加方式,文件会越来越大为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集.可以使用命令bgrewriteaof
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后再rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发
优势:
每修改同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每秒同步:appendfsync everysec 异步操作,每秒记录 如果一秒内宕机,有数据丢失
不同步:appendfsync no 从不同步
劣势:
相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
Aof运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同
总结:
性能建议:
因为RDB文件只用作后备用途,建议只在Slave上持久化RDB文件,而且只要15分钟备份一次就够了,只保留save 900 1这条规则。
如果Enalbe AOF,好处是在最恶劣情况下也只会丢失不超过两秒数据,启动脚本较简单只load自己的AOF文件就可以了。代价一是带来了持续的IO,二是AOF rewrite的最后将rewrite过程中产生的新数据写到新文件造成的阻塞几乎是不可避免的。只要硬盘许可,应该尽量减少AOF rewrite的频率,AOF重写的基础大小默认值64M太小了,可以设到5G以上。默认超过原大小100%大小时重写可以改到适当的数值。
如果不Enable AOF ,仅靠Master-Slave Replication 实现高可用性也可以。能省掉一大笔IO也减少了rewrite时带来的系统波动。代价是如果Master/Slave同时倒掉,会丢失十几分钟的数据,启动脚本也要比较两个Master/Slave中的RDB文件,载入较新的那个。新浪微博就选用了这种架构
Redis事务
可以一次执行多个命令,本质是一组命令的集合,一个事务中所有命令都会序列化,按顺序地串行化执行而不会被其它命令插入,不许加塞,一个队列中,一次性、顺序性、排他性的执行一系列命令
redis事务命令
DISCARD 取消事务,放弃执行事务命令
EXEC 执行事务命令
MULTI 标明事务的开始
UNWATCH 取消watch命令对所有可以的监视
WATCH key[key ...] 监视一个或多个key 如果在事务执行之前被其他命令改动,事务将被打断
1.乐观锁和悲观锁
悲观锁:每次去拿数据的时候都认为别人会修改,所以每次在拿数据的时候都会上锁,这样别人想拿这个数据就会block直到它拿到锁。传统的关系型数据库里边就用到了很多这种锁机制,比如行锁,表锁等,读锁,写锁等,都是在做操作之前先上锁
乐观锁:每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多读的应用类型,这样可以提高吞吐量,乐观锁策略:提交版本必须大于记录当前版本才能执行更新
WATCH:
类似乐观锁,事务提交时,如果Key的值已被别的客户端改变,比如某个list已被别的客户端push/pop过了,整个事务队列都不会被执行
通过WATCH命令在事务执行之前监控了多个Keys,倘若在WATCH之后有任何Key的值发生了变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败
Redis发布订阅
进程间的一种消息通信模式:发送者(pub)发送消息,订阅者(sub)接收消息。
1 可以一次性订阅多个,SUBSCRIBE c1 c2 c3
2 消息发布,PUBLISH c2 hello-redis
3 订阅多个,通配符*, PSUBSCRIBE new*
4 收取消息, PUBLISH new1 redis2015
Redis的复制(哨兵)
我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slaver机制,Master以写为主,Slave以读为主,作用:进行读写分离和容灾恢复
每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
info replication 查看日志
SLAVEOF 127.0.0.1 6379 仆从主机备份复制
常用3招
五个问题理解:
1 切入点问题?slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来,那之前的123是否也可以复制
2 从机是否可以写?set可否?
3 主机shutdown后情况如何?从机是上位还是原地待命
4 主机又回来了后,主机新增记录,从机还能否顺利复制?
5 其中一台从机down后情况如何?依照原有它能跟上大部队吗?
一主二仆:
薪火相传:
上一个Slave可以是下一个slave的Master,Slave同样可以接收其他slaves的连接和同步请求,那么该slave作为了链条中下一个的master,可以有效减轻master的写压力
中途变更转向:会清除之前的数据,重新建立拷贝最新的
反客为主:
SLAVEOF no one 使当前数据库停止与其他数据库的同步,转成主数据库
复制原理
Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步
全量复制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量复制:Master继续将新的所有收集到的修改命令依次传给slave,完成同步
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行
哨兵模式(sentinel):
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
步骤:
进入sentinel.conf文件填写sentinel monitor 被监控数据库名字(自己起名字) 127.0.0.1 6379 1(数字1,表示主机挂掉后salve投票看让谁接替成为主机,得票数多少后成为主机)
启动哨兵:Redis-sentinel /myredis/sentinel.conf
缺点:由于所有的写操作都是先在Master上操作,然后同步更新到Slave上,所以从Master同步到Slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,Slave机器数量的增加也会使这个问题更加严重。