一款方便实用的手机扫描仪：扫描全能王

Redis简要介绍朱自升2016.06.25Page22主要内容RDBMS发展现状及适用情景NoSQL的出现，NoSQL基本原理Redis简介及应用场景Redis基本数据结构及重要操作Redis命令总结Jedis：Java-Redis操作实践：简单博客系统Page33RDBMS现状及适用情景从1969年，埃德加发表关系数据模型论文开始，以MySQL，Oracle，Sybase，PostgreSQL为代表的传统关系数据库在过去的20多年里得到了广泛应用。SQL是一种用于数据查询的描述型语言。SQL允许用户透明的执行查询，不需要考虑数据在哪块儿磁盘上，使用何种算法来处理数据。大多数RDBMS都有一个重要的架构组件：查询优化器。关系数据库遵循关系数据模型，关系模型中不同现实世界的实体被存储到不同的表格中。关系模型和SQL的结合很紧密，并且定义了高度结构化的实体以及实体之间的关系。SQL的查询模型支持用户透明的数据访问。Page44RDBMS适用情景数据定义高度结构化的情景（关系结构严谨，字段固定）数据一致性要求高的情景（事物要求）数据实时性要求不高（无数据大量写入，查询返回结果实时性要求不高）无需进行过多索引更改（添加或删除）的表Page55RDBMS所不擅长的情景大量数据的写入处理（磁盘I/O）为有数据更新的表做索引或表结构（schema）变更对简单查询需要快速返回结果的处理（实时要求高）字段不固定时应用（数据结构为半结构化数据）Page66主要内容RDBMS发展现状及适用情景NoSQL的出现，NoSQL基本原理Redis简介及应用场景Redis基本数据结构及重要操作Redis命令总结实际操作实验：简单博客系统Page77NoSQL简介NoSQL：No！SQL还是NotOnlySQL？NoSQL基本分类：列式数据库，键值数据库，文档数据库，图数据库NoSQL基于的基本原理：CAP，BASE，最终一致性Page88NoSQL基本原理CAP理论：Consistency(一致性),数据一致更新，数据变动都是同步的Availability(可用性),好的响应性能Partitiontolerance(分区容错性)可靠性关系数据库的ACID模型拥有高一致性+可用性很难进行分区：Atomicity原子性：一个事务中所有操作都必须全部完成，要么全部不完成。Consistency一致性.在事务开始或结束时，数据库应该在一致状态。Isolation隔离层.事务将假定只有它自己在操作数据库，彼此不知晓。Durability.一旦事务完成，就不能返回。Page99NoSQL基本原理BASE模型：反ACID模型，完全不同于ACID模型，牺牲高一致性，获得可用性或可靠性：BasicallyAvailable基本可用。Softstate软状态状态可以有一段时间不同步，异步。Eventuallyconsistent最终一致，最终数据是一致的就可以了，而不是时时高一致Page1010Redis简介2008年开始开发，2009年完成，作者SalvatoreSanfilippoRedis官网是这么描述的：Redisisanopensource,advancedkey-valuestore.Itisoftenreferredtoasadatastructureserversincekeyscancontainstrings,hashes,lists,setsandsortedsets.Redis是一个开源的使用ANSIC语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。从2010年3月15日起，Redis的开发工作由VMware主持。Page1111Redis特点速度快Redis使用标准C编写实现，而且将所有数据加载到内存中，所以速度非常快。官方提供的数据表明，在一个普通的Linux机器上，Redis读写速度分别达到81000/s和110000/s。持久化由于所有数据保持在内存中（2.0版本开始可以只将部分数据的value放在内存，见“虚拟内存”），所以对数据的更新将异步地保存到磁盘上，Redis提供了一些策略来保存数据，比如根据时间或更新次数。数据结构可以将Redis看做“数据结构服务器”。目前，Redis支持5种数据结构Page1212Redis特点原子操作Redis对不同数据类型的操作是原子的，因此设置或增加key值，从一个集合中增加或删除一个元素都能安全的操作。支持多种语言Redis支持多种语言，诸如Ruby,Python,TwistedPython,PHP,Erlang,Tcl,Perl,Lua,Java,Scala,Clojure等。主-从复制Redis支持简单而快速的主-从复制。官方提供了一个数据，Slave在21秒即完成了对Amazon网站10Gkeyset的复制。Sharding很容易将数据分布到多个Redis实例中，但这主要看该语言是否支持。目前支持Sharding功能的语言只有PHP、Ruby和Scala。Page1313Redis适用场景数据结构不固定的半结构化数据读写请求数量大且实时性要求高后台RDB数据库压力大，需要缓存的情况数据结构复杂，需要与应用程序内数据结构相对应的情况Page1414数据类型及操作方法string(字符串)list(双向链表)set(无序集合)zset(有序集合)hash(hash表)Page1515string类型string是redis最基本的类型，而且string类型是二进制安全的。意思是redis的string可以包含任何数据。比如jpg图片或者序列化的对象从内部实现来看其实string可以看作byte数组，最大上限是1G字节string类型的值也可视为integer，从而可以让“incr”命令族操作，这种情况下，该integer的值限制在64位有符号数在list、set和zset中包含的独立的元素类型都是string类型Page1616list类型redis的list类型其实就是一个每个子元素都是string类型的双向链表，所以[lr]push和[lr]pop命令的算法时间复杂度都是O(1)，另外list会记录链表的长度，所以llen操作也是O(1).可以通过push,pop操作从链表的头部或者尾部添加删除元素。这使得list既可以用作栈，也可以用作队列list的最大长度是2^32-1个元素Page1717set类型set就是redisstring的无序集合，不允许有重复元素set的最大元素数是2^32-1对set的操作还有交集、并集、差集等Page1818zset类型zset是set的一个升级版本，在set的基础上增加了一个顺序属性，这一属性在添加修改元素时可以指定，每次指定后zset会自动安装指定值重新调整顺序。可以理解为一张表，一列存value，一列存顺序。操作中的key理解为zset的名字。zset的最大元素数是2^32-1。对于已经有序的zset，仍然可以使用sort命令，通过指定asc|desc参数对其进行排序。Page1919hash类型redisHash类型对数据域和值提供了映射，这一结构很方便表示对象在Hash中可以只保存有限的几个“域”，而不是将所有的“域”作为key，这可以节省内存Page2020持久化机制redis一共支持四种持久化方式，分别是：1.定时快照方式(snapshot)——默认方式2.基于语句追加文件的方式(aof)3.虚拟内存(vm)——已放弃4.Diskstore方式——实验中前两种是基于全部数据都在内存中，即小数据量下提供磁盘落地功能后两种方式则是作者在尝试存储数据超过物理内存时，即大数据量的数据存储，后两种持久化方式仍然是在实验阶段，并且vm方式基本已经被作者放弃实际能在生产环境用的只有前两种，换句话说redis目前还只能作为小数据量存储（全部数据能够加载在内存中），海量数据存储方面并不是redis所擅长的领域Page2121定时快照方式(snapshot)快照是默认的持久化方式。这种方式是就是将内存中数据以快照的方式写入到二进制文件中,默认的文件名为dump.rdb。可以通过配置设置自动做快照持久化的方式。可以配置redis在n秒内如果超过m个key被修改就自动做快照，下面是默认的快照保存配置save9001#900秒内如果超过1个key被修改，则发起快照保存save30010#300秒内容如超过10个key被修改，则发起快照保存save6010000Page2222快照过程保存过程如下1.redis调用fork,现在有子进程和父进程。2.父进程继续处理client请求，子进程负责将内存内容写入到临时文件。由于os的写时复制机制（copyonwrite)父子进程会共享相同的物理页面，当父进程处理写请求时os会为父进程要修改的页面创建副本，而不是写共享的页面。所以子进程的地址空间内的数据是fork时刻整个数据库的一个快照。3.当子进程将快照写入临时文件完毕后，用临时文件替换原来的快照文件，然后子进程退出。缺点是定时快照只是代表一段时间内的内存映像，所以系统重启会丢失上次快照与重启之间所有的数据。Page2323基于语句追加方式(aof)aof比快照方式有更好的持久化性，是由于在使用aof持久化方式时,redis会将每一个收到的写命令都通过write函数追加到文件中(默认是appendonly.aof)。当redis重启时会通过重新执行文件中保存的写命令来在内存中重建整个数据库的内容。当然由于os会在内核中缓存write做的修改，所以可能不是立即写到磁盘上。这样aof方式的持久化也还是有可能会丢失部分修改。不过我们可以通过配置文件告诉redis我们想要通过fsync函数强制os写入到磁盘的时机。有三种方式如下（默认是：每秒fsync一次）appendonlyyes//启用aof持久化方式#appendfsyncalways//每次收到写命令就立即写盘，最慢，但保证完全的持久化，不推荐使用appendfsynceverysec//每秒钟强制写入磁盘一次，推荐#appendfsyncno//完全依赖os，性能最好,持久化没保证持久化文件会变的越来越大。例如我们调用incrtest命令100次，文件中必须保存全部的100条命令，其实有99条都是多余的。因为要恢复数据库的状态其实文件中保存一条settest100就够了。为了压缩aof的持久化文件。redis提供了bgrewriteaof命令。收到此命令redis将使用与快照类似的方式将内存中的数据以命令的方式保存到临时文件中，最后替换原来的文件。Page2424AOF过程保存过程如下1.redis调用fork，现在有父子两个进程2.子进程根据内存中的数据库快照，往临时文件中写入重建数据库状态的命令3.父进程继续处理client请求，除了把写命令写入到原来的aof文件中。同时把收到的写命令缓存起来。这样就能保证如果子进程重写失败的话并不会出问题。4.当子进程把快照内容以命令方式写入临时文件中后，子进程发信号通知父进程。然后父进程把缓存的写命令也写入到临时文件。5.现在父进程可以使用临时文件替换老的aof文件，并重命名，后面收到的写命令也开始往新的aof文件中追加。缺点log文件体积过大时系统重启恢复数据非常慢，几十G的数据可能要几小时才能加载完；每条命令都要写log，读写性能会有所下降Page2525虚拟内存(vm)虚拟内存方式是Redis来进行用户空间的数据换入换出的一个策略，此种方式在实现的效果上比较差，主要问题是代码复杂，重启慢，复制慢等等，目前已经被作者放弃。Page2626diskstore方式diskstore方式是作者放