SQL入门概述1.1

Redis持久化【RDB、AOF】持久化之RDB持久化之AOF

如何选择

Redis主从复制、读写分离case1一主二仆【中心化架构】case2薪火相传【去中心化架构】case3反客为主case4哨兵模式(sentinel)

参考文档

http://redisdoc.com/string/set.html

NoSQL入门概述

SQL)意即“不仅仅是SQL”泛指非关系型的数据库。

随着互联网web2.0网站的兴起传统的关系数据库在应付web2.0网站特别是超大规模和高并发的web2.0纯动态网站已经显得力不从心暴露了很多难以克服的问题而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。

NoSQL

数据库的产生就是为了解决大规模数据集合、多重数据种类带来的挑战尤其是大数据应用难题包括超大规模数据的存储。

读写速度

读1s/8w、写1s/11w

NoSQL数据库种类繁多但是一个共同的特点都是去掉关系数据库的关系型特性。

数据之间无关系这样就非常容易扩展无形之间在架构的层面上带来了可扩展的能力。

大数据量高性能

NoSQL数据库都具有非常高的读写性能尤其在大数据量下同样表现优秀。

这得益于它的无关系性数据库的结构简单。

一般MySQL使用Query

Cache每次表的更新Cache就失效是一种大粒度的Cache在针对web2.0的交互频繁的应用Cache性能不高。

而NoSQL的Cache是记录级的是一种细粒度的Cache所以NoSQL在这个层面上来说就要性能高很多了。

多样灵活的数据模型

NoSQL无需事先为要存储的数据建立字段随时可以存储自定义的数据格式。

而在关系数据库里增删字段是一件非常麻烦的事情。

如果是非常大数据量的表增加字段简直就是一个噩梦。

1.2

传统RDBMS

RDBMS高度组织化结构化数据、结构化查询语言(SQL)数据和关系都存储在单独的表中、数据操纵语言数据定义语言严格的一致性、

基础事务

NoSQL代表着不仅仅是SQL、没有声明性查询语言没有预定义的模式、

键-值对存储列存储文档存储图形数据库最终一致性而非ACID属性、

KV新浪

Redis文档型数据库bson格式比较多CouchDB、MongoDB

PSMongoDB是一个基于分布式文件存储的数据库。

由C语言编写。

旨在为WEB应用提供可扩展的高性能数据存储解决方案。

MongoDB是一个介于关系数据库和非关系数据库之间的产品是非关系数据库当中功能最丰富最像关系数据库的。

列存储数据库Cassandra、Hbase、分布式文件系统

图关系数据库Neo4j、InfoGrid它不是放图形的、放的是关系比如朋友圈社交网络、广告推荐系统、社交网络、推荐系统。

专注于构建关系图谱1.4

分布式数据库CAP原理

CAP【CAP理论就是说在分布式存储系统中最多只能实现两点三选二】C:

Consistency强一致性A:

而由于当前的网络硬件肯定会出现延迟丢包等问题所以分区容忍性P是我们必须需要实现的。

所以我们只能在强一致性C和高可用性A之间进行权衡没有NoSQL系统能同时保证这三点。

CAP理论的核心是一个分布式系统不可能同时很好的满足一致性可用性和分区容错性这三个需求最多只能同时较好的满足两个。

多余大多数web应用其实并不需要强一致性。

因此牺牲C换取P这是目前分布式数据库产品的方向。

因此根据

传统Oracle数据库单点集群满足一致性可用性的系统通常在可扩展性上不太强大。

AP

满足可用性分区容忍性的系统通常可能对一致性要求低一些。

大多数网站架构的选择【数据可以不一定精确牺牲强一致性P一定要保证网站可用实现可用性A电商、金融系统等】CP

Redis、Mongodb满足一致性分区容忍必的系统通常性能不是特别高。

BASE就是为了解决关系数据库强一致性引起的问题而引起的可用性降低而提出的解决方案。

基本可用Basically

Available软状态Soft

consistent它的思想是通过让系统放松对某一时刻数据一致性的要求来换取系统整体伸缩性和性能上改观。

为什么这么说呢缘由就在于大型系统往往由于地域分布和极高性能的要求不可能采用分布式事务来完成这些指标要想获得这些指标我们必须采用另外一种方式来完成这里BASE就是解决这个问题的办法

1.5

system由多台计算机和通信的软件组件并通过计算机网络连接本地网络或广域网。

分布式系统是建立在网络之上的软件系统。

正是因为软件的特性所以分布式系统具有高度的内聚性和透明性。

因此网络和分布式系统之间的区别更多的在于高层软件特别是操作系统而不是硬件。

分布式系统可以应用在在不同的平台上如PC、工作站、局域网和广域网上等。

简单来讲

分布式不同的多台服务器上面部署不同的服务模块工程他们之间通过RPC之间通信和调用对外提供服务和组内协作。

集群不同的多台服务器上面部署相同的服务模块通过分布式调度软件进行统一的调度对外提供服务和访问。

1.6

分布式的文件系统【淘宝TFS、Google的GFS、Hadoop的HDFS】

淘宝自家ISearch

Server(远程字典服务器)是完全开源免费的用C语言编写的遵守BSD协议是一个高性能的(key/value)分布式内存数据库基于内存运行并支持持久化的NoSQL数据库是当前最热门的NoSQL数据库之一也被人们称为数据结构服务器。

Redis与其他

缓存产品有以下三个特点Redis支持数据的持久化可以将内存中的数据保持在磁盘中重启的时候可以再次加载进行使用Redis不仅仅支持简单的key-value类型的数据同时还提供listsetzsethash等数据结构的存储Redis支持数据的备份即master-slave模式的数据备份2.2

能干嘛

内存存储和持久化redis支持异步将内存中的数据写到硬盘上同时不影响继续服务取最新N个数据的操作如可以将最新的10条评论的ID放在Redis的List集合里面模拟类似于HttpSession这种需要设定过期时间的功能发布、订阅消息系统定时器、计数器2.3

怎么玩核心

数据类型、基本操作和配置持久化和复制RDB/AOF事务的控制复制主从关系2.4

MAC安装redis

/usr/local/redis-6.2.6./bin/redis-server

etc/redis.conf

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

string类型是二进制安全的。

意思是redis的string可以包含任何数据。

比如jpg图片或者序列化的对象

。

string类型是Redis最基本的数据类型一个redis中字符串value最多可以是512M。

Hash哈希类似java里的MapRedis

hash

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

类似Java里面的MapString,ObjectList列表Redis

列表是简单的字符串列表按照插入顺序排序。

你可以添加一个元素导列表的头部左边或者尾部右边。

它的底层实际是个链表Set集合Redis的Set是string类型的无序集合。

它是通过HashTable实现实现的Zset(sorted

set有序集合)Redis

不同的是每个元素都会关联一个double类型的分数。

redis正是通过分数来为集合中的成员进行从小到大的排序。

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

2.6

常用命令

getset(先get再set)前提是该key已经存在List

Stack/ArrayList

它是一个字符串链表left、right都可以插入添加如果键不存在创建新的链表如果键已存在新增内容如果值全移除对应的键也就消失了。

链表的操作无论是头和尾效率都极高但假如是对中间元素进行操作效率就很惨淡了。

**

Set

总共支持四个级别debug、verbose、notice、warning默认为

notice

为守护进程方式运行而这里又配置为日志记录方式为标准输出则日志将会发送给

/dev/nulllogfile

指定在多长时间内有多少次更新操作就将数据同步到数据文件可以多个条件配合

yesRedis

时间可以关闭该选项但会导致数据库文件变的巨大rdbcompression

yes

后仍然到达最大内存设置将无法再进行写入操作但仍然可以进行读取操作。

Redis

机制会把

在默认情况下是异步的把数据写入磁盘如果不开启可能会在断电时导致一段时间内的数据丢失。

因为

redis

到磁盘上访问多的页面由磁盘自动换出到内存中在后面的文章我会仔细分析

Redis

26、设置访问swap文件的线程数,最好不要超过机器的核数,如果设置为0,那么所有对swap文件的操作都是串行的可能会造成比较长时间的延迟。

默认值为4vm-max-threads

27、设置在向客户端应答时是否把较小的包合并为一个包发送默认为开启glueoutputbuf

yes

28、指定在超过一定的数量或者最大的元素超过某一临界值时采用一种特殊的哈希算法hash-max-zipmap-entries

512

指定包含其它的配置文件可以在同一主机上多个Redis实例之间使用同一份配置文件而同时各个实例又拥有自己的特定配置文件include

/path/to/local.conf

DataBase在指定的时间间隔内将内存中的数据集快照写入磁盘也就是行话讲的Snapshot快照它恢复时是将快照文件直接读到内存里。

2先将数据写入到一个临时文件中待持久化过程都结束了再用这个临时文件替换上次持久化好的文件。

整个过程中主进程是不进行任何IO操作的这就确保了极高的性能。

RDB配置【SNAPSHOPPONG】#save

3600

启用rdb持久化存储stop-writes-on-bgsave-error

yes

如果配置成no不在乎数据不一致或者有其他方法控制rdbcompression

yes

存储快照后还可以让redis使用CRC64算法进行数据校验大约会增加10%的性能小号如果希望得到最优的性能提升可以关闭该功能如何恢复将备份文件

(dump.rdb)

安装目录并启动服务即可RDB优点适合大规模的数据恢复对数据完整性和一致性要求不高

RDB缺点Fork的作用是复制一个与当前进程一样的进程新进程的所有数据变量、环境变量、程序计数器等

数值都和原进程一致大致2倍的膨胀性需要考虑。

在一定间隔时间做一次备份所以如果redis意外down掉的话就会丢失最后一次快照后的所有修改总结RDB是一个非常紧凑的文件。

RDB在保存RDB文件时父进程唯一需要做的就是fork出一个子进程接下来的工作全部由子进程来做父进程不需要再做其他I0操作所以RDB持久化方式可以最大化redis的性能。

与AOF相比在恢复大的数据集的时候RDB方式会更快一一些。

数据丢失风险大。

RDB需要经常fork子进程来保存数据集到硬盘上当数据集比较大的时候fork的过程是非常耗时的吗可能会导致Redis在一些毫秒级不能回应客户端请求。

持久化之AOF

Only

File是以日志的形式来记录每个写操作将Redis执行过的所有写指令记录下来(读操作不记录)

只许追加文件但不可以改写文件redis启动之初会读取该文件重新构建数据换言之redis

重启的话就根据日志文件的内容将写指令从前到后执行一次以完成数据的恢复工作。

AOF配置【APPEND

ONLY

同步持久化redis每次发生数据改变都会被立即记录到磁盘性能较差但数据完整性最好everysec

不进行持久化no-appendfsync-on-rewrite

重写时是否运用appendfsync默认no即可保证数据安全性auto-aof-rewrite-percentage

64mbrewrite

是什么AOF采用文件追加方式文件会越来越大。

为避免出现此种情况新增了重写机制

当AOF文件的大小超过所设定的阈值时Redis就会启动AOF文件的内容压缩

只保留可以恢复数据的最小指令集。

可以使用命令bgrewriteaof

重写原理AOF文件持续增长而过大时会fork出一条新进程来将文件重写(也是先写临时文件最后再rename)

遍历新进程的内存中数据每条记录有一条的Set语句。

重写aof文件的操作并没有读取旧的aof文件

而是将整个内存中的数据库内容用命令的方式重写了一个新的aof文件这点和快照有点类似.

触发机制Redis会记录上次重写时的AOF大小默认配置是当AOF文件大小是上次rewrite后大小的一倍且文件大于64M时触发auto-aof-rewrite-percentage

64mb

AOF缺点相同数据集的数据而言aof文件要远大于rdb文件恢复速度慢于rdbAof运行效率要慢于rdb,每秒同步策略效率较好不同步效率和rdb相同总结AOF文件时一个只进行追加的日志文件Redis可以在AOF文件体积变得过大时自动地在后台对AOF进行重写AOF文件有序地保存了对数据库执行的所有写入操作这些写入操作以Redis协议的格式保存因此AOF文件的内容非常容易被人读懂对文件进行分析也很轻松对于相同的数据集来说AOF文件的体积通常要大于RDB文件的体积根据所使用的fsync

1、RDB持久化方式能够在指定的时间间隔内对数据进行快照存储AOF持久化方式记录每次对服务器的写操作当服务器重启时会重新执行这些命令来恢复原始数据Redis还会对AOF文件进行重写避免文件体积过大。

2、建议同时开启RDB、AOF持久化方式redis会优先载入aof文件来恢复原始数据因为通常情况下aof文件保存的数据集比rdb文件保存的数据集要完整。

但是也不建议只用AOF因为RDB更适合备份数据库了而AOF数据不断变化不好备份。

3、只做缓存可以都不使用RDB、AOF性能建议因为RDB文件只做后备用途建议只在slave上持久化RDB而且重要15分钟备份一次就够了【只保留

save

1】如果启用AOF好处是在最坏情况下也只会丢失1s数据启动脚本简单加载自己的aof文件就可以恢复代价一是带来了持续的IO二是rewrite的最后将rewrite过程中产生的新数据写到新文件会造成不可避免的阻塞应当尽量减少rewrite的频率建议auto-aof-rewrite-min-size

设置为5G默认超过原来的100%进行重写。

如果不启用AOF仅靠master-slave

Replication实现高可用也可以能节省一大笔IO、以及重写rewrite带来的系统波动代价是如果master/slave同时倒掉会丢失十几分钟的数据启动脚本也要比较两个master/slave的RDB文件。

5

Redis事务Transacttion

是什么可以一次执行多个命令本质是一组命令的集合。

一个事务中的所有命令都会序列化按顺序地串行化执行而不会被其它命令插入不许加塞。

能干嘛一个队列中一次性、顺序性、排他性的执行一系列命令。

常用命令

MULTI

Watch指令类似乐观锁事务提交时如果Key的值已被别的客户端改变

比如某个list已被别的客户端push/pop过了整个事务队列都不会被执行

通过WATCH命令在事务执行之前监控了多个Keys倘若在WATCH之后有任何Key的值发生了变化

EXEC命令执行的事务都将被放弃同时返回Nullmulti-bulk应答以通知调用者事务执行失败。

PS悲观锁/乐观锁/CAS(Check

顾名思义就是很悲观每次去拿数据的时候都认为别人会修改所以每次在拿数据的时候都会上锁这样别人想拿这个数据就会block直到它拿到锁。

传统的关系型数据库里边就用到了很多这种锁机制比如行锁表锁等读锁写锁等都是在做操作之前先上锁。

【高一致性低并发】

乐观锁(Optimistic

顾名思义就是很乐观每次去拿数据的时候都认为别人不会修改所以不会上锁但是在更新的时候会判断一下在此期间别人有没有去更新这个数据可以使用版本号等机制。

乐观锁适用于多读的应用类型这样可以提高吞吐量。

乐观锁策略:提交版本必须大于记录当前版本才能执行更新。

【高并发低一致性】

事务特性单独的隔离操作事务中的所有命令都会序列化、按顺序地执行。

事务在执行的过程中不会被其他客户端发送来的命令请求所打断。

没有隔离级别的概念队列中的命令没有提交之前都不会实际的被执行因为事务提交前任何指令都不会被实际执行

也就不存在”事务内的查询要看到事务里的更新在事务外查询不能看到”这个让人万分头痛的问题不保证原子性redis同一个事务中如果有一条命令执行失败其后的命令仍然会被执行没有回滚不遵循传统的ACID中的AI6

Redis主从复制、读写分离

是什么也就是我们所说的主从复制主机数据更新后根据配置和策略自动同步到备机的master/slaver机制Master以写为主Slave以读为主主要负责读写分离、容灾恢复。

怎么玩slaveof

主库IP

【配从(库)不配主(库)】准备工作启动多个Redis服务器部分配置文件参数修改如下

daemonize

yes、pid文件名字、port指定端口、logfile日志名称、dump.rdb配置文件名字case1一主二仆【中心化架构】

常见问题

1、slave1、slave2是从头开始复制还是从切入点开始复制?比如从k4进来那之前的123是否也可以复制

答不能跟上每次与master断开之后都需要重新连接除非你配置进redis.conf文件具体位置redis.conf搜寻####

REPLICATION

上一个Slave可以是下一个slave的MasterSlave同样可以接收其他

slaves的连接和同步请求那么该slave作为了链条中下一个的master,

可以有效减轻master的写压力奴隶的奴隶还是奴隶中途变更转向会清除之前的数据重新建立拷贝最新的

slaveof

一组sentinel能同时监控多个master反客为主的自动版能够后台监控主机是否故障如果故障了根据投票数自动将从库转换为主库

怎么玩(使用步骤)

数字1表示主机挂掉后salve投票看让谁接替成为主机得票数多少后成为主机

4、启动哨兵

replication查查看问题如果之前挂了的master重启回来会不会双master冲突

不会原master变成slave