一、NoSQL概述
1、NoSql入门和概述
1)是什么
NoSQL(NoSQL = Not Only SQL),意思是不仅仅是SQL,泛指非关系型的数据库。
2)为什么使用NoSQL
今天我们可以通过第三方平台(如Google,Facebook等)可以很容易的访问和抓取数据。用户个人信息,社交网络,地理位置,用户产生的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘,那SQL数据库已经不适合这些应用了
,NoSQL数据库的发展却能很好的处理这些大的数据。
3)分表分库+水平拆分+mysql集群
在Memcached的高速缓存,MySQL的主从复制,读写分离的基础之上,这是MySQL的主库的写压力开始出现瓶颈,而数据量的持续猛增,由于MyISAM使用表锁,在高并发下会出现严重的锁问题,大量的高并发MySQL应用开始使用InnoDB引擎代替MyISQM。
同时开始流行使用分表分库来缓解写压力和数据增长的扩展问题。这个时候,分表分库成了一个热门技术,是面试的热门问题也是业界讨论的热门技术问题。也就是在这个时候,MySQL推出了还不太稳定的表分区,虽然MySQL推出了MySQL Cluster集群,但性能也不能很好满足互联网的要求,只能在高可靠性上提供了非常大的保证。
4)传统RDBMS VS NOSQL
RDBMS
高度组织化结构化数据
结构化查询语言(SQL)
数据和关系都存储在单独的表中。
数据操纵语言,数据定义语言
严格的一致性
基础事务
NoSQL
代表着不仅仅是SQL
没有声明性查询语言
没有预定义的模式
键值对存储,列存储,文档存储,图形数据库
最终一致性,而非ACID属性
非结构化和不可预知的数据
CAP定理
高性能,高可用和可伸缩性
2、NoSQL数据库的四大分类
1)KV键值
新浪:BerkeleyDB+redis
美团:redis+tair
阿里、百度:memcache+redis
2)文档型数据库
MongoDB、CouchDB
3)列存储数据库
Cassandra,HBase。分布式文件系统
4)图关系数据库
它不是放图形的,放的是关系比如:朋友圈社交网络、广告推荐系统、社交网络,推荐系统等。专注于构建关系图谱。
Neo4j,InfoGrid
3、在分布式数据库中CAP原理CAP+BASE
1)传统的ACID分别是什么
A(Atomicity)原子性、C(Consistency)一致性、I(Isolation)独立性、D(Durability)持久性
2)CAP原则
C:Consistency(强一致性)、A:Availability(可用性)、P:Partion tolerance(分区容错性)
3)CAP的3取2
CAP的理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须要实现的。
所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这一点。
C:强一致性 A:高可用性 P:分布式容错性
CA 传统Oracle数据库、MySQL数据库。-单点集群,满足一致性,可用性的系统,通常在可扩展性上不太强大。
AP 大多数网站架构的选择。-满足可用性,分区容忍性的系统,通常可能对一致性要求低一些。
CP Redis、Mongodb。-满足一致性,分区容忍性的系统,通常性能不是特别高。
4)BASE
BASE其实是下面三个术语的缩写:
基本可用(Basically Available)
软状态(Soft state)
最终一致(Eventually consistent)
它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。缘由就在于大型系统往往由于地域分布和极高性能的要求,不可能采用分布式事务来完成这些指标,我们必须采用另外一种方式来完成,这里BASE就是解决这个问题的办法。
5)分布式+集群简介
分布式:不同的多台服务器上面部署不同的服务模块(工程),他们之间通过Rpc/Rmi之间通信和调用,对外提供服务和组内协作。(简单的说就是在不同的服务器上放不同处理业务的功能)
集群:不同的多台服务器上面部署相同的服务模块,通过分布式调度软件进行统一的调度,对外提供服务和访问。(简单来说就是复制,一台跑不动就多用几台功能相同的服务器来跑)
6)水平拆分和垂直拆分
1,水平拆分
水平拆分是指由于单一节点无法满足需求,需要扩展为多个节点,多个节点具有一致的功能,组成一个服务池,一个节点服务一部分请求量,所有节点共同处理大规模高并发的请求量。水平拆分一般是以业务领域为维度的。
2,垂直拆分
垂直拆分指按照功能进行拆分,秉着“专业的人干专业的事”的原则,把一个复杂的功能拆分为多个单一、简单的功能,不同单一简单功能组合在一起,和未拆分前完成的功能是一样的。由于每个功能职责单一、简单,使得维护和变更都变得更简单、容易、安全,所以更易于产品版本的迭代,还能够快速的进行敏捷发布和上线。
二、Redis安装
1、下载地址及安装操作
https://blog.csdn.net/Lin_Willen/article/details/103083683
2、Redis基础知识
1)默认16个数据库,类似数组下表从零开始,初始默认使用零号库
2)Select命令切换数据库
3)Dbsize查看当前数据库的key的数量
4)Flushdb:清空当前库
5)Flushall:通杀全部库 ***谨慎使用
6)Redis索引都是从零开始
3、启动
不一定要在/usr/local/bin目录下,在任何路径下都可以启动redis、一般还是在bin目录下启动
4、关闭
三、Redis数据类型
1、Redis的五大数据类型
1)String(字符串)
string是redis最基本的类型,一个key对应一个value,一个redis中字符串value最多可以是512M。
2)Hash(哈希,类似java里的Map)
hash是一个键值对集合。
hash是一个string类型的field和value的映射表,hash特别适合用于存储对象。
类似java里面的Map<String,Object>
3)List(列表)
list是简单的字符串列表,按照插入顺序排序。可以添加一个元素到列表的头部(左边)或者尾部(右边)。
它的底层是一个链表。
4)Set(集合)
Set是string类型的无序集合。它是通过HashTable实现的。
5)Zset(sorted set:有序集合)
zset和set一样也是string类型元素的集合,且不允许重复的成员。不同的是每个元素都会关联一个double类型的分数。
redis正是通过分数来为集合中的成员进行从小到大排序。zset的成员是唯一的,但分数(score)却可以重复。
2、Redis常见数据类型操作命令
地址:http://redisdoc.com/index.html
3、Redis键(key)
1)keys *
2)exists key的名字,判断某个key是否存在
3)move key db -->当前库就没有了,被移出了
4)expire key 秒钟:为给定的key设置过期时间
5)ttl key查看还有多少秒过期,-1表示永不过期,-2表示已过期
6)type key 查看你的key是什么类型
4、Redis字符串(String)
口诀:单值单value
1)set/get/del/append/strlen
2)Incr/decr/incrby/decrby,一定要是数字才能进行加减
3)getrange/setrange getrange表示获取范围,比如[0,3],setrange表示将某一个范围位置的值替换掉
4)setex(set with expire)键秒值/setnx(set if not exist)
5)mset/mget/msetnx m表示more
6)getset(先get在set)
5、Redis列表(List)
口诀:单值多value
1)lpush/rpush/lrange
2)lpop/rpop
3)lindex,按照索引下表获得元素(从上到下)
4)llen
5)lrem key 删N个value
6)ltrim key 开始index 结束index,截取指定范围的值后再赋值给key
7)rpoplpush 源列表 目的列表
8)lset key index value
9)linsert key before/after 值1 值2
性能总结:
它是一个字符链表,left,right都可以插入添加。
如果键不存在,创建新的链表。
如果键已经存在,新增内容。
如果值全移除,对应的键也就消失了。
链表的操作无论是头和尾效率都极高,但假如是对中间元素进行操作,效率就很惨淡了。
6、Redis哈希(Hash)
口诀:KV模式不变,但V是一个键值对
1)hset/hget/hmset/hgetall/hdel
2)hlen
3)hexists key 在key里面的某个值的key
4)hkey/hvals
5)hincrby/hincrbyfloat
6)hsetnx
7、Redis集合(Set)
口诀:单值多value
1)sadd/smembers/sismember
2)scard,获取集合里面的元素个数
3)srem key value 删除集合中元素
4)srandmember key 某个整数(随机出几个数)
5)spop key 随机出栈
6)smove key2 key2 在key1里某个值 作用是将key1里的某个值赋给key2
7)数学集合类
差集:sdiff
在set01中且不在set02中的
交集:sinter
并集:sunion
8、Redis有序集合Zset(sorted set)
和set的区别:在set基础上加上一个score值,之前set是k1 v1 v2 v3,现在zset是k1 score v1 score v2
1)zadd/zrange/zrange withscores
2)zrangebyscore key 开始score 结束score
(不包含
limit作用是返回限制 limit开始下标步 多少步
3)zrem key 某score下对应的value值,作用是删除元素
4)zcard/zcount key score区间/zrank key values值,作用是获得下标值/zscore key 对应值,获得分数
5)zrevrank key values值,作用是逆序获得下标值
6)zrevrange
见上图
7)zrevrangebyscore key 结束score 开始score
四、解析配置文件redis.conf
1、它在哪
一般不在里面直接配置,而是copy一份出来在另外的地方配置
2、Units单位
配置大小单位,开头定义了一些基本的度量单位,只支持bytes,不支持bit,对大小写不敏感
3、INCLUDES包含
可以通过includes包含,redis.conf可以作为总闸,包含其他的配置文件。
4、GENERAL通用
1)Daemonize
守护线程启动
2)Pidfile
进程管道文件
/var/run/redis.conf
3)Port
6397
4)Tcp-backlog
tcp-backing 551
设置tcp的backlog,backlog其实是一个连接队列,backlog队列总和=未完成三次握手队列+已经完成三次握手队列。
在高并发环境下你需要一个高backlog值来避免慢客户端连接问题。注意linux内核会将这个值减小到/proc/sys/net/core/somaxconn的值,所以需要确认增大somaxconn和tcp_max_syn_backing两个值来达到想要的效果。
5)Timeout
0 不关闭,超时连接
6)Bind
7)Tcp-keepalive
单位为秒,如果设置为0,则不会进行Keepalive检测,建议设置成60
心跳机制!!!
8)Loglevel
debug
verbose
notice
warning 生产模式
级别越高,日志越少
9)Logfile
10)Syslog-enabled
是否把日志输出到syslog中
11)Syslog-ident
指定syslog里的日志标志
12)Syslog-facility
指定syslog设备,值可以是user或local0-local7
默认0
13)Databases
默认16个库
5、SNAPSHOTTING快照
1)save 秒钟 写操作次数
RDB是整个内存压缩过的Snapshot,RDB的数据结构,可以配置复合的快照触发条件,默认
1分钟内改变了1万次以上,
或5分钟内改了10次以上,
或15分钟内改了1次以上。
如果想禁用RDB持久化策略,只要不设置任何save指令,或者给save传入一个空字符串参数也可以。
如果有一个key想要立刻保存,可以执行save,命令立刻生成dump.rdb文件
2)Stop-writes-on-bgsave-error
默认是yes,如果配置成no,表示不在乎数据不一致或者有其他的手段发现和控制。
3)rdbcompression(一般不动)
默认是yes
rdbcompression:对于存储到磁盘中的快照,可以设置是否进行压缩存储。如果是的话,redis会采用LZF算法进行压缩。如果不想消耗CPU来进行压缩的话,可以设置为no关闭此功能。
4)rdbchecksum
默认是yes
rdbchecksum:在存储快照后,还可以让redis使用CRC64算法来进行数据校验,但是这样做会增大大约10%的性能消耗,如果希望获取到最大的性能提升,可以关闭此功能。
5)dfgilename
备份文件的名字
6、REPLICATION复制
info replication
7、SECURITY安全
8、LIMITS限制
9、APPEND ONLY MODE追加
appendonly —— 默认no,改yes开启aof
appendfilename——aof文件名
Appendfsync
Always:同步持久化,每次发生数据变更会立即记录到磁盘,性能较差但数据完整性比较好
Everysec:出厂默认推荐,异步操作,每秒记录,如果一秒内宕机,有数据丢失
No
No-appendfsync-on-rewrite:重写时是否可以运行Appendfsync,用默认no即可,保证数据安全性。
Auto-aof-rewrite-min-size:设置重写的基准值
Auto-aof-rewrite-perentage:设置重写的基准值
10、常见配置redis.conf介绍
五、Redis的持久化
1、RDB(Redis DataBase)
1)是什么
在指定的时间间隔内将内存中的数据集快照写入磁盘,也就是Snapshot快照,它恢复时将快照文件直接读到内存里。
Redis会单独创建(Fork)一个子进程来进行持久化,会先将数据写入到一个临时文件中,待持久化过程都结束了,再用这个临时文件替换上次持久化好的文件。
整个过程中,主进程是不进行任何IO操作的,这就确保了极高的性能
如果需要进行大规模数据的恢复,且对于数据恢复的完整性不是非常敏感,那RDB方式要比AOF方式更加的高效。RDB的缺点是最后一次持久化后的数据可能丢失。
2)fork
Fork的作用是复制一个与当前进程一样的进程。新进程的所有数据(变量、环境变量‘程序计数器等)数值都和原进程一致,但是是一个全新的进程,并作为原进程的子进程。
3)RDB保存的是dump.rdb文件
4)配置位置
5)如何触发RDB快照
①先将原先的dump.rdb删除re -f dump.rdb,在redis.conf配置文件文件中配置save 120 10,在两分钟内修改10次key,两分钟后就会自动生成dump.rdb文件
②将dump.rdb备份,因为在工作中不可能把备份的文件跟操作的机器放在一起。
③执行flushall命令,会产生dump.rdb文件,但里面是空的,无意义。执行shutdown的时候就会立刻生成dump.rdb文件
④将dump_bk.rdb文件复制一份命名为dump.rdb,再次打开Redis,将会获取之前存的值
⑤Save:save时只管保存,其他不管,全部阻塞
BGSAVE:Redis会在后台异步进行快照操作,快照操作同时还可以响应客户端请求。可以通过lastsave命令获取最后一次成功执行快照的时间。
6)如何恢复
将备份文件(dump.rdb)移动到redis安装目录并启动服务即可。
CONFIG GET dir获取目录
7)优势与劣势
优势:适合大规模的数据恢复,对数据完整性和一致性要求不高
劣势:在一定间隔时间做一次备份,所以如果redis意外down掉的话,就会丢失最后一次快照后的所有修改。Fork的时候,内存中的数据被克隆了一份,大约2倍的膨胀性需要考虑。
8)总结
RDB是一个非常紧凑的文件
RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程,接下来的工作全部由子进程来做,父进程不需要再做其他IO操作,所有RDB持久化方式可以最大化redis的性能。
与AOF相比,在恢复大的数据集的时候,RDB方式会更快一些。
缺点:
数据丢失风险大
RDB需要经常fork子进程来保存数据集到硬盘上,当数据集比较大的时候,fork的过程是非常耗时的,可能导致Redis在一些毫秒级不能响应客户端请求。
2、AOF(Append Only File)
1)是什么
以日志的形式来记录每个写操作,将Redis执行过的所有写指令记录下来(读操作不记录),只许追加文件但不可以改写文件,redis启动之初会读取该文件重新构建数据,换言之,redis重启的话根据日志文件的内容将写指令从前到后执行一次已完成数据的恢复工作。
AOF保存的是appendonly.aof文件
aof跟rdb可以共存,但是Redis启动加载的时候先加载aof
2)配置位置
默认是no,改yes就打开aof
3)AOF启动/修复/恢复
4)Rewrite
①是什么
AOF采用文件追加方式,文件会越来越大,为避免出现此种情况,新增了重写机制,当AOF文件的大小超过所设定的阈值时,Redis就会启动AOF文件的内容压缩,只保留可以恢复数据的最小指令集。可以使用命令gbrewriteaof
②重写原理
AOF文件持续增长而过大时,会fork出一条新进程来将文件重写(也是先写临时文件最后在rename),遍历新进程的内存中数据,每条记录有一条的Set语句。重写aof文件的操作,并没有读取旧的aof文件,而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件,这点和快照有点类似。
③触发机制
Redis会记录上次重写时的AOF大小,默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发。(工作中不止64M,起步3G)
5)优势与劣势
优势:
每秒同步:appendfsync always 同步持久化 每次发生数据变更会被立即记录到磁盘 性能较差但数据完整性比较好
每修改同步:appendfsync everysec 异步操作 ,每秒记录 如果一秒内宕机,有数据丢失。
不同步:appendfsync no 从不同步
劣势:
相同数据集的数据而言aof文件要远大于rdb文件,恢复速度慢于rdb
AOF运行效率要慢于rdb,每秒同步策略效率较好,不同步效率和rdb相同。
6)总结
AOF文件时一个只进行追加的日志文件
Redis可以在AOF文件体积变得过大时,自动地在后台对AOF进行重写
AOF文件有序地保存了对数据执行的所有写入操作,这些写入操作以Redis协议的格式保存,因此AOF文件的内容非常容易被人读懂,对文件进行分析也很轻松。
缺点:
对相同的数据集来说,AOF文件的体积通常要大于RDB文件的体积。
根据所使用的fsync策略,AOF的速度可能会慢于RDB。
3、总结(Which one)
六、Redis的事务
1、是什么
可以一次执行多个命令,本质是一组命令的集合。一个事务中的所有命令都会序列化,按顺序地串行化执行而不会被其他命令插入,不许加塞。
2、作用
一个队列中,一次性、顺序性、排他性地执行一系列命令
3、怎么玩
1)常用命令
DISCARD:取消事务,放弃执行事务块内的所有命令。
EXEC:执行所有事务块的命令。
MULTI:标记一个事务块的开始。
UNWATCH:取消WATCH命令对多有key的监视。
WATCH key [key......]:监视一个(或多个)key,如果在事务执行之前这个key被其他命令所改动,那么事务将打断。
2)正常执行
3)放弃事务
4)全体连坐
只要执行期间出现命令错误,整个事务都不会执行成功
5)冤头债主
命令不报错,但是实际是错的(比如案例中,给字符串加1)
6)watch监控
①悲观锁/乐观锁/CAS(Check And Set)
悲观锁:顾名思义,每次去拿数据的时候都被认为别人会修改,所以每次在拿数据的时候都会被锁上,这样别人想拿这个数据就会block直到它拿到锁,传统的关系型数据库里边就用到了很多这种锁机制,比如行锁、表锁等,读锁、写锁等,都是在做操作之前先锁上。
乐观锁:每次去拿数据的时候都认为别人不会修改,所以不会上锁,但是在更新的时候会判断一下在此期间别人有没有去更新这个数据,可以使用版本号等机制。乐观锁适用于多度的应用类型,这样可以提高吞吐量。
乐观锁策略:提交版本必须大于记录当前版本才能执行更新。
②Watch指令,类似乐观锁,事务提交时,如果Key的值已经被别的客户端改变,比如某个list已经被别的客户端push/pop过了,整个事务队列都不会被执行。
通过WATCH命令在事务执行之前监控了多个keys,倘若在WATCH之后有任何key的值的变化,EXEC命令执行的事务都将被放弃,同时返回Nullmulti-bulk应答以通知调用者事务执行失败。
7)三阶段
开启:以MULTI开始一个事务
入队:将多个命令入队到事务中,接到这些命令并不会立即执行,而是放到等待执行的事务队列里面。
执行:由EXEC命令触发事务
8)3特性
单独的隔离操作:事务中的所有命令都会被序列化、按顺序地执行。事务在执行的构成中,不会被其他客户端发送来的命令请求所打断。
没有隔离级别的概念:队列中的命令没有提交之前都不会实际的被执行,因为事务提交前任何指令都不会被实际执行,也就不存在“事务内的查询要看到事务里的更新,在事务外查询不能看到”这个让人万分头痛的问题。
不保证原子性:redis同一个事务中如果有一条命令执行失败,其后的命令仍然会被执行,没有回滚。
七、Redis的复制(Master/Slave、主人/奴隶)
1、是什么
就是我们所说的主从复制,主机数据更新后根据配置和策略,自动同步到备机的master/slver机制,Master以写为主,Slave以读为主。
2、能干嘛
读写分离、容灾恢复
3、怎么玩
1)配从(库)不配主(库)
2)从库配置:slaveof主库IP主库端口
每次与master断开之后,都需要重新连接,除非你配置进redis.conf文件
Info replication 查看Redis信息
3)修改配置文件细节操作
①拷贝多个redis.conf文件
②开启daemonize yes
③Pid文件名字
④指定端口
⑤Log文件名字
⑥Dump.rdb名字
4)常用3招
①一主二仆
如果在主库79中再次set数据,比如set k4 v4,在从库80,81中照样能获取数据,这是因为增量控制,会同步主库中的数据。
主库允许写,读操作,而从库只有读操作,不允许写
如果主库宕机了,从库依旧是slave状态,他们会默默等待主库的归来,主库归来后,从库就会自动连接上主库,这时主库再写数据从库就会同步数据
从库每次与主库断开之后,都需要重新连接(用slaveof),否则收不到主库的数据,除非你配置进redis.conf文件
②薪火相传
上一个Slave可以是下一个slave的Master,slave同样可以接受其他slaves的连接和同步请求,那么该slave作为链条中下一个的master,可以有效减轻master的写压力。
中途变更转向:会清楚之前的数据,重新建立拷贝最新的。
slaveof 新主库IP 新主库端口
80还是不能写
③反客为主
SLAVEOF no one:使当前数据库通知与其他数据库的同步,转成主数据库。
在②的基础上,79宕机了,80执行slaveof no one命令,使80成为新的主库,81有两种选择,第一继续默默的等待79归来,第二81执行slaveof 127.0.0.1 6380,认80位主库,假如我们选择了第二,80跟81就形成了一个新的体系。这时如果79启动归来,那它跟80和81没有任何关系。
4、复制原理
Slave启动成功连接到master后会发送一个sync命令
Master接到命令启动后台的存盘进程,同时收集所有接收到的用于修改数据集命令,在后台进程执行完毕之后,master将传送整个数据文件到slave,以完成一次完全同步。
全量控制:而slave服务在接收到数据库文件数据后,将其存盘并加载到内存中。
增量控制:master继续将新的所有收集到的修改命令一次传给slave,完成同步
但是只要是重新连接master,一次完全同步(全量复制)将被自动执行。
5、哨兵模式(setinel)
(1)是什么
反客为主的自动版,能够后台监控主机是否故障,如果故障了根据投票数自动将从库转换为主库
(2)怎么玩
1)调整结构,6379带着80、81
2)自定义的/myredis目录下新建sentinel.conf文件,名字决不能错。
3)配置哨兵。填写内容
sentinel monitor被监控数据库名字(自己起名字)127.0.0.1 6379 1
上面最后一个数字1,表示主机挂掉后slave投票看让谁解题成为主机,得票数多的成为主机
4)启动哨兵
Redis-sentinel /myredis/sentinel.conf
5)原有的master挂了,投票新选,如果平票会再次重新选择,直到出新的master。
6)问题:如果之前的master重启回来,会不会双master冲突?
不会,如果原先的主库回来了,他就要做81的从库,不会有双master,跟之前的反客为主不一样。
6、复制的缺点
由于所有的写操作都是先在Master上操作,然后同步更新到slave上,所以从master同步到slave机器有一定的延迟,当系统很繁忙的时候,延迟问题会更加严重,slave机器数量的增加也会使这个问题更加严重。