Redis 数据库是一个非关系型数据库,在正式学习Redis 之前,先来了解关系型数据库 与非关系型数据库的概念。
关系数据库与非关系型数据库
1.关系型数据库
关系型数据库是一个结构化的数据库,创建在关系模型基础上,一般面向于记录。它借 助于集合代数等数学概念和方法来处理数据库中的数据。关系模型就是指二维表格模型,因 而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。现实世界中,各种 实体与实体之间的各种联系都可以用关系模型来表示。SQL 语句(标准数据查询语言)就 是一种基于关系型数据库的语言,用于执行对关系型数据库中数据的检索和操作。主流的关系型数据库包括Oracle 、MySQL 、SQL Server 、Microsoft Access 、DB2等等。
2. 非关系型数据库
NoSQL(NoSQL=Not Only SQL),意思是“不仅仅是SQL ”,是非关系型数据库的总称。主流的NoSQL数据库有Redis、MongBD、Hbase、CouhDB等等。以上这些非关系型数据库,他们的存储方式、存储结构以及使用的场景都是完全不同的。所以我们认为它是一个非关系型数据库的集合,而不是像关系型数据库一样,是一个统称。换言之,除了主流的关系型数据库以外的数据库,都可以认为是非关系型的。NoSQL 数据库凭借着其非关系型、分布式、开源及横向扩展等优势,被认为是下一代数据库产品。
3.非关系型数据库产生背景
(1) High performance 对数据库高并发读写需求
Web2.0 网站会根据用户的个性化信息来实时生成动态页面和提供动态信息,因此无法使用动态页面静态化技术。所以数据库的并发负载非常高,一般会达到10000 次Is 以上的读写请求。关系型数据库对于上万次的查询请求还是可以勉强支撑的,但出现上万次的写数据请求,硬盘IO就已经无法承受了。对于普通的BBS 网站,往往也会存在高并发的写数据请求。
(2) Huge Storage——对海量数据高效存储与访问需求
类似于Facebook、Friendfeed这样的SNS网站,每天会产生大量的用户动态信息。如Friendfeed,一个月就会产生不少于2.5 亿条用户动态信息,对于关系型数据库来说,在一个包含2.5 亿条记录的表中执行SQL 查询,查询效率是非常低的。
(3) HighScalability &&High Availability—— 对数据库高可扩展性与高可用性需求
在Web 架构中,数据库是最难进行横向扩展的。当应用系统的用户量与访问量与日俱增时,数据库是没办法像 Web 服务一样,简单地通过添加硬件和服务器节点来扩展其性能和负载能力的。尤其对于一些需要24 小时对外提供服务的网站来说,数据库的升级与扩展往往伴随着停机维护与数据迁移,其工作量是非常庞大的。
关系型数据库和非关系型数据库都有各自的特点与应用场景,两者的紧密结合将会给Web2.0 的数据库发展带来新的思路。让关系数据库关注在关系上,非关系型数据库关注在存储上。例如,在读写分离的MySQL数据库环境中,可以把经常访问的数据存储在非关系型数据库中,提升访问速度。
Redis 基础
1.Redis简介
Redis(RemoteDictionaryServer, 远程字典型)是一个开源的、使用C 语言编写的NoSQL数据库。Redis 基于内存运行并支持持久化,采用key-value(键值对)的存储形式, 是目前分布式架构中不可或缺的一环。
Redis 服务器程序是单进程模型,也就是在一台服务器上可以同时启动多个Redis 进程, 而 Redis 的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个 Redis 进程,当多个客户端同时访问时,服务器的处理能力是会有一定程度的下降;若在同 一台服务器上开启多个 Redis 进程,Redis 在提高并发处理能力的同时会给服务器的CPU 造成很大压力。
Redis具有以下几个优点:
具有极高的数据读写速度,数据读取的速度最高可达到110000 次/s, 数据写入速度最 高可达到81000 次/s。
支持丰富的数据类型,不仅仅支持简单的key-value 类型的数据,还支持Strings,Lists, Hashes,Sets 及Ordered Sets 等数据类型操作。
支持数据的持久化,可以将内存中的数据保存在磁盘中,重启的时候可以再次加载进行使用。
原子性,Redis 所有操作都是原子性的。
支持数据备份,即master-salve模式的数据备份。
Redis作为基于内存运行的数据库,缓存是其最常应用的场景之一。除此之外,Redis 常见应用场景还包括获取最新N 个数据的操作、排行榜类应用、计数器应用、存储关系、 实时分析系统、日志记录。
2.Redis 安装部署
在Linux系统中进行源码编译安装,需要先执行./configure 进行环境检查 与配置,从而生成Makefile文件,再执行 make &&make install 命令进行编译安装。而Redis 源码包中直接提供了 Makefile 文件,所以在解压完软件包后,可直接进入解压后的软件包 目录,执行 make 与make install命令进行安装。
make install只是安装了二进制文件到系统中,并没有启动脚本和配置文件。软件包中默认提供了一个install_server.sh脚本文件,通过该脚本文件可以设置Redis 服务所需要的 相关配置文件。当脚本运行完毕,Redis 服务就已经启动,默认侦听端口为6379。
Redis 安装完成,可通过 Redis 的服务控制脚本/etc/init.d/redis_6379 来 对 Redis 服务进行控制,如停止Redis 服务、启动Redis 服务、重启Redis 服务、查看Redis 运行状态。
3. 配置参数
Redis 命令工具
redis-server: 用于启动Redis的工具;
redis-benchmark: 用于检测Redis 在本机的运行效率;
redis-check-aof: 修复AOF持久化文件;
redis-check-rdb: 修复RDB持久化文件;
redis-cli:Redis 命令行工具。
1.redis-cli 命令行工具
Redis 数据库系统也是一个典型的CIS (客户端/服务器端)架构的应用,要访问Redis 数据库需要使用专门的客户端软件。
2.redis-benchmark 测试工具
redis-benchmark 是官方自带的Redis 性能测试工具,可以有效的测试Redis服务的性能。基本的测试语法为 redis-benchmark [option][option value]。常用选项如下所示。
-h: 指定服务器主机名;
-p: 指定服务器端口;
-s: 指定服务器 socket;
-C: 指定并发连接数;
-n: 指定请求数;
-d: 以字节的形式指定SET/GET 值的数据大小;
-k:1=keep alive O=reconnect;
-r:SET/GET/INCR 使用随机 key,SADD 使用随机值;
-P:通过管道传输q>请求;
-q: 强制退出 redis。仅显示 querylsec值;
--CSv: 以 CSV 格式输出;
-I: 生成循环,永久执行测试;
-t: 仅运行以逗号分隔的测试命令列表;
-I:Idle 模式。仅打开 N 个idle 连接并等待。
Redis 数据库常用命令
s et: 存放数据,基本的命令格式为set key value。
get: 获取数据,基本的命令格式为get key。
1.key 相关命令
(1) keys、(2) exists 、(3)del、(4) type、(5) rename、(6) renamenx、(7) dbsize
2.多数据库常用命令
(1)多数据库间切换
Redis 支持多数据库,Redis 在没有任何改动的情况下默认包含16 个数据库,数据库 名称是用数字0-15 来依次命名的。使用select 命令可以进行 Redis 的多数据库之间的切换, 命令格式为selectindex,其中index表示数据库的序号。而使用redis-cli 连接Redis 数据库 后,默认使用的是序号为0的数据库。
(2)多数据库间移动数据
Redis 的多数据库在一 定程度上是相对独立的,例如在数据库0上面存放k1 的数据, 在其它1-15 的数据库上是无法查看到的。
(3)清除数据库内数据
Redis 数据库的整库数据删除主要分为两个部分:清空当前数据库数据,使用FLUSHDB 命令实现;清空所有数据库的数据,使用FLUSHALL命令实现。但是,数据清空操作比较 危险,生产环境下一般不建议使用。
Redis 持久化
Redis 是一种高级key-value数据库。它跟Memcached类似,不过数据可以持久化, 而且支持的数据类型很丰富,有字符串、列表、集合和有序集合。支持在服务器端计算集合 (difference)等,还支持多种排序功能。所以 Redis 也可以被看成是一个数据结构服务器。
Redis 的所有数据都是保存在内存中,然后不定期的通过异步方式保存到磁盘上(这称 为“半持久化模式”);也可以把每一次数据变化都写入到一个append only file(aof)里面(这称 为“全持久化模式”)。
RDB和 AOF的区别
RDB和 AOF 的优缺点
1.RDB 优 缺 点
(1) RDB 优点
一旦采用该方式,那么整个Redis 数据库将只包含一个文件,这对于文件备份而言是非常完美的。比如,计划每个小时归档一次最近24 小时的数据,同时还要每天归档一次最近30 天的数据。通过这样的备份策略,一旦系统出现灾难性故障,可以非常容易地进行恢复。
对于灾难恢复而言,RDB 是非常不错的选择。可以非常轻松的将一个单独的文件压缩 后再转移到其它存储介质上。性能最大化,对于Redis的服务进程而言,在开始持久化时,它唯一需要做的只是fork出子进程,之后再由子进程完成这些持久化的工作,这样就可以极大的避免服务进程执行IO操作了。相比于AOF 机制,如果数据集很大,RDB 的启动效率会更高。
(2 )RDB 缺点
如果想保证数据的高可用性,即最大限度的避免数据丢失,那么 RDB 将不是一个很好的选择。因为系统一旦在定时持久化之前出现宕机现象,此前没有来得及写入磁盘的数据都将丢失。
由于RDB 是通过fork 子进程来协助完成数据持久化工作的,因此当数据集较大时,可能会导致整个服务器停止服务几百毫秒,甚至是1秒钟。
2.AOF 优缺点
(1) AOF的优点
AOF 机制可以带来更高的数据安全性,即数据持久性。Redis 中提供了3种同步策略,即每秒同步、每次修改同步和不同步。事实上,每秒同步也是异步完成的,其效率也是非常高的,弊端是一旦系统出现宕机现象,那么这一秒钟之内修改的数据将会丢失。而每次修改同步,可以将其视为同步持久化,即每次发生的数据变化都会被立即记录到磁盘中,这种方式在效率上是最低的。
由于该机制对日志文件的写入操作采用的是append 模式,因此在写入过程中即使出现宕机现象,也不会破坏日志文件中已经存在的内容。然而如果本次操作只是写入了一半数据就出现了系统崩溃问题,那么在Redis 下一次启动之前,可以通过redis-check-aof 工具来解决数据一致性的问题。
如果日志过大 ,Redis 可以自动启用rewrite机制。即Redis以append 模式不断地将修改数据写入到老的磁盘文件中,同时Redis还会创建一个新的文件用于记录此期间有哪些修改命令被执行。因此在进行rewrite切换时可以更好的保证数据安全性。
AOF包含一个格式清晰、易于理解的日志文件用于记录所有的修改操作。事实上,也 可以通过该文件完成数据的重建。
(2 )AOF 的缺点
对于相同数量的数据集而言,AOF 文件通常要大于RDB文件。RDB 在恢复大数据集 时的速度比AOF 的恢复速度要快。
根据同步策略的不同,AOF在运行效率上往往会慢于RDB。每秒同步策略的效率是比较高的,同步禁用策略的效率和RDB一样高效。
二者选择的标准,就是看系统是愿意牺牲一些性能,换取更高的缓存一致性(AOF ),还是愿意写操作频繁的时候,不启用备份来换取更高的性能,待手动运行save 的时候,再做备份(RDB)。