NoSQL之Redis配置与优化

关系型数据库是一个结构化的数据库，创建在关系模型基础上，一般面向于记录。它借助于集合代数等数学概念和方法来处理数据库中的数据。关系模型就是指二维表格模型,因而一个关系型数据库就是由二维表及其之间的联系组成的一个数据组织。现实世界中，各种实体与实体之间的各种联系都可以用关系模型来表示。SQL语句(标准数据查询语言)就是一种基于关系型数据库的语言，用于执行对关系型数据库中数据的检索和操作。

主流的关系型数据库包括 0racle、MySQL、SQL Server、Microsoft Access、DB2 等

（2）非关系型数据库

NoSQL(NoSQL = Not 0nly SQL)，意思是"不仅仅是 SQL"，是非关系型数据库的总称。主流的 NoSQL 数据库有 Redis、MongBD、Hbase、CouhDB 等等。以上这些非关系型数据库，他们的存储方式、存储结构以及使用的场景都是完全不同的。所以我们认为它是一个非关系型数据库的集合，而不是像关系型数据库一样，是一个统称。换言之，除了主流的关系型数据库以外的数据库，都可以认为是非关系型的。NoSQL 数据库凭借着其非关系型、分布式、开源及横向扩展等优势，被认为是下一代数据库产品。

（3）非关系型数据库产生背景

关系型数据库已经诞生很久了，而且一直在使用。面对这样的情况，为什么还会产生 NoSQL?那么，下面就来介绍一下 NoSQL 产生的背景。

随着 Web2.0 网站的兴起，关系型数据库在应对 Web2.0 网站，特别是海量数据和高并发的 SNS(Social Networking Services，即社交网络服务)类型的Web2.0 纯动态网站时，暴露出很多难以解决的问题，例如三高问题。

High performance--对数据库高并发读写需求

Web2.0 网站会根据用户的个性化信息来实时生成动态页面和提供动态信息，因此无法使用动态页面静态化技术。所以数据库的并发负载非常高，一般会达到10000 次/s以上的读写请求。关系型数据库对于上万次的查询请求还是可以勉强支撑的，但出现上万次的写数据请求，硬盘 I0 就已经无法承受了。对于普通的 BBS 网站，往往也会存在高并发的写数据请求。

Huge Storage--对海量数据高效存储与访问需求

类似于 Facebook、Friendfeed 这样的 SNS 网站，每天会产生大量的用户动态信息。如 Friendfeed,一个月就会产生不少于 2.5 亿条用户动态信息，对于关系型数据库来说，在一个包含 2.5 亿条记录的表中执行 SQL 查询，查询效率是非常低的。

High Scalability && High Availability--对数据库高可扩展性与高可用性需求

在 Web 架构中，数据库是最难进行横向扩展的。当应用系统的用户量与访问量与日俱增时，数据库是没办法像 Web 服务一样，简单地通过添加硬件和服务器节点来扩展其性能和负载能力的。尤其对于一些需要 24 小时对外提供服务的网站来说，数据库的升级与扩展往往伴随着停机维护与数据迁移，其工作量是非常庞大的。

关系型数据库和非关系型数据库都有各自的特点与应用场景，两者的紧密结合将会给 Web2.0 的数据库发展带来新的思路。让关系数据库关注在关系上，非关系型数据库关注在存储上。例如，在读写分离的 MySQL 数据库环境中,可以把经常访问的数据存储在非关系型数据库中，提升访问速度。

2.Redis基础

了解关系型数据库与非关系型数据库之后，我们重点来学习非关系型数据库Redis 的相关知识

（1）Redis简介

Redis(RemoteDictionaryServer，远程字典型)是一个开源的、使用C语言编写的 NoSQL 数据库。Redis 基于内存运行并支持持久化，采用 key-value(键值对)的存储形式，是目前分布式架构中不可或缺的一环。

Redis 服务器程序是单进程模型，也就是在一台服务器上可以同时启动多个Redis 进程，而 Redis 的实际处理速度则是完全依靠于主进程的执行效率。若在服务器上只运行一个 Redis 进程，当多个客户端同时访问时，服务器的处理能力是会有一定程度的下降;若在同一台服务器上开启多个 Redis 进程，Redis在提高并发处理能力的同时会给服务器的CPU造成很大压力。即:在实际生产环境中，需要根据实际的需求来决定开启多少个Redis 进程。若对高并发要求更高一些，可能会考虑在同一台服务器上开启多个进程。若CPU 资源比较紧张，采用单进程即可。

Redis 具有以下几个优点:

具有极高的数据读写速度，数据读取的速度最高可达到 110000 次/s，数据写入速度最高可达到 81000 次/s。
支持丰富的数据类型，不仅仅支持简单的 key-value 类型的数据，还支持Strings,Lists,Hashes,Sets 及 Ordered Sets 等数据类型操作。
支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
原子性，Redis 所有操作都是原子性的。
支持数据备份，即 master-salve 模式的数据备份

Redis 作为基于内存运行的数据库，缓存是其最常应用的场景之一。除此之外，Redis 常见应用场景还包括获取最新 N 个数据的操作、排行榜类应用、计数器应用、存储关系、实时分析系统、日志记录。

3.Redis安装部署

Redis 的安装相对于其他服务来说比较简单。首先需要到 Redis 官网(https://www.redis.io)下载相应的源码软件包，然后上传至 Linux 系统的服务器中进行解压、安装。本章中以 redis-4.0.9.tar.gz 为例进行 Redis 服务的安装和配置讲解。

通常情况下，在 Linux 系统中进行源码编译安装，需要先执行./configure进行环境检查与配置，从而生成 Makefile 文件，再执行 make && make instal1命令进行编译安装。而 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 运行状态。

4.配置参数

Redis 主配置文件为/etc/redis/6379.conf，由注释行与设置行两部分组成与大多数 Linux 配置文件一样，注释性的文字以"#"开始，包含了对相关配置内容进行的说明和解释。除了注释行与空行以外的内容即为设置行。可根据生产环境的需求调整相关参数，如下:

除了上述配置参数外，Redis 主配置文件中还包含很多其它的配置参数：

timeout 300 ：当客户端闲置多长时间后关闭连接，如果指定为0，表示关闭该功能
dbfilename dump.rdb：指定本地数据库文件名，默认值为 dump.rdb
dir /var/lib/redis/6379：指定本地数据库存放目录
maxclients 10000：设置同一时间最大客户端连接数，默认为10000Redis 可以同时打开的客户端连接数为 Redis 进程可以打开的最大文件描述符数，如果设置 maxclients0，表示不限制。当客户端连接数到达限制时，Redis会关闭新的连接并向客户端返回 max number ofclients reached 错误信息
rdbcompression yes：指定存储至本地数据库时是否压缩数据,默认为 yes,Redis 采用 LZF 压缩，如果为了节省 CPU 资源，可以关闭该选项，但会导致数据库文件变的巨大
slaveof <masterip><masterport>：当本机为从服务器时，设置主服务的 IP 地址及端口。在 Redis 启动时，从服务器会自动从主服务进行数据同步
masterauth <master-password>：当主服务设置了密码保护时，从服务连接主服务的密码
requirepass foobared：设置 Redis 连接密码，如果配置了连接密码，客户端在连接 Redis 时需要通过 AUTH <password>命令提供密码，默认关闭
maxmemory <bytes>：指定 Redis 最大内存限制。Redis 在启动时会把数据加载到内存中，达到最大内存后，Redis会先尝试清除已到期或即将到期的 Key，当此方法处理后，仍然到达最大内存设置，将无法再进行写入操作，但仍然可以进行读取操作。Redis 新 VM 机制，会把 Key 存放内存，Value 会存放在 Swap 分区
appendonly no：指定是否在每次更新操作后进行日志记录，Redis 在默认情况下是异步地把数据写入磁盘，如果不开启:可能会在断电时导致一段时间内的数据丢失。因为Redis 本身同步数据文件是按上面 save 条件来同步的，所以有的数据会在一段时间内只存在于内存中，默认为 no
appendfilename appendonly.aof：指定更新日志文件名，默认为 appendonly.aof
appendfilename appendonly.aof：指定更新日志文件名，默认为appendonly.aof
appendfsync everysec：指定更新日志条件，共有3个可选值:no:表示等操作系统进行数据缓存同步到磁盘(快)always:表示每次更新操作后手动调用 fsync()将数据写到磁盘(慢，安全)
everysec:表示每秒同步一次(折衷，默认值)
activerehashing yes：指定是否激活重置哈希，默认为开启
include /path/to/local.conf：指定包含其它的配置文件，可以在同一主机上多个Redis 实例之间使用同一份配置文件，而同时各个实例又拥有自己的特定配置文件

5.Redis命令工具

Redis 软件提供了多个命令工具。安装 Redis 服务时，所包含的软件工具会同时被安装到系统中，在系统中可以直接使用。这些命令工具的作用分别如下所示。

redis-server:用于启动 Redis 的工具;
redis-benchmark:用于检测 Redis 在本机的运行效率;
redis-check-aof:修复 AOF 持久化文件;
redis-check-rdb:修复 RDB 持久化文件:
redis-cli: Redis 命令行工具。

（1）redis-cli 命令行工具

Redis 数据库系统也是一个典型的 C/S(客户端/服务器端)架构的应用，要访问 Redis 数据库需要使用专门的客户端软件。Redis 服务的客户端软件就是其自带的 redis-cli 命令行工具。使用 redis-cli 连接指定数据库，连接成功后会进入提示符为"远程主机 IP 地址:端口号>"的数据库操作环境，例如"127.0.0.1:6379>"。用户可以输入各种操作语句对数据库进行管理。如执行ping 命令可以检测 Redis 服务是否启动。

在进行数据库连接操作时，可以通过选项来指定远程主机上的 Redis 数据库。命令语法为 redis-cli-h host -p port -a password，其中-h 指定远程主机、-p 指定 Redis 服务的端口号、-a 指定密码。若不添加任何选项表示,连接本机上的 Redis 数据库;若未设置数据库密码可以省略-a 选项。例如执行以下命令可连接到主机为 192.168.10.161，端口为 6379 的 Redis 数据库，并査看 Redis 服务的统计信息。若要退出数据库操作环境,执行"exit"或"quit'命令即可返还原来的 Shell 环境。

（2）redis-benchmake测试工具

redis-benchmark 是官方自带的 Redis 性能测试工具，可以有效的测试Redis 服务的性能。基本的测试语法为 redis-benchmark [option][optionvalue]。常用选项如下所示。

-h：指定服务器主机名
-p：指定服务器端口
-s：指定服务器socket
-c：指定并发连接数
-n：指定请求数
-d：以字节的形式指定SET/GET值的数据大小
-k：1=keep alived 0=reconnect
-r：SET/GET/INCR使用随机key，SADD使用随机值
-P：通过管道传输<numreq>请求
-q：强制退出 redis。仅显示 query/sec 值;
--cvs：以 CSV 格式输出;
-l：生成循环，永久执行测试;
-t：仅运行以逗号分隔的测试命令列表;
-I：Idle 模式。仅打开 N个 idle 连接并等待。

结合上述选项，可以针对某台Redis服务器进行性能检测，如执行redis-benchmark -h 192.168.10.161-p 6379-c 100-n 100000 命令即可向 IP地址为 192.168.10.161、端口为 6379 的 Redis 服务器发送 100 个并发连接与 100000 个请求测试性能。

还可以测试某些操作的性能，例如执行 redis-benchmark-t set,lpush -n100000-9 命令的作用是测试本机上 Redis 服务在进行 set 与 lpush 操作时的性能。

6.Redis数据库常用命令

前面提到 Redis 数据库采用 key-value(键值对)的数据存储形式。所使用的命令是 set与 get 命令。

set:存放数据，基本的命令格式为set key value
get:获取数据，基本的命令格式为get key。

例如，在 Redis 的命令行模式下执行"set teacher zhanglong"，表示在当前数据库下存放一个 key 为 teacher，value 为 zhanglong 的数据，而执行getteacher"命令即可查看刚才存放的数据。

（1）key相关命令

keys

使用 keys 命令可以取符合规则的键值列表，通常情况可以结合*、?等选项来使用。

exists

exists 命令可以判断键值是否存在

返回值1为存在，0为不存在

del

del命令可以删除当前数据库指定的key

type

使用type命令可以获取key对应的value值类型

rename

rename 命令是对已有 key 进行重命名，其命令格式为:rename 源 key 目标key。使用 rename 命令进行重命名时，无论目标 key 是否存在都进行重命名,且源 key 的值会覆盖目标 key 的值。在实际使用过程中，建议先用 exists 命令查看目标 key 是否存在，然后再决定是否执行 rename 命令，以避免覆盖重要数据。

7.多数据库常用命令

（1）多数据库切换

Redis 支持多数据库，Redis 在没有任何改动的情况下默认包含 16 个数据库，数据库名称是用数字 0-15来依次命名的。使用 select 命令可以进行Redis 的多数据库之间的切换,命令格式为 selectindex,其中 index 表示数据库的序号。而使用 redis-cli 连接 Redis 数据库后,默认使用的是序号为0 的数据库。

如下所示，使用 select 命令切换数据库后，会在前端的提示符中显示当前所在的数据库序号如"127.0.0.1:6379[10]>"表示当前使用的是序号为 10 的数据库。若当前使用的数据库是序号为0的数据库，提示符中则不显示序号，如"127.0.0.1:6379>"表示当前使用的是序号为 0 的数据库。

二：Redis持久化

Redis 是一种高级 key-value 数据库。它跟 Memcached 类似，不过数据可以持久化，而且支持的数据类型很丰富，有字符串、列表、集合和有序集合。支持在服务器端计算集合(difference)等，还支持多种排序功能。所以 Redis 也可以被看成是一个数据结构服务器，

Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为"半持久化模式");也可以把每一次数据变化都写入到一个 appendonly file(aof)里面(这称为"全持久化模式")。

由于 Redis 的数据都存放在内存中，如果没有配置持久化，Redis 重启后数据就全丢失了。所以，需要开启 Redis 的持久化功能，将数据保存到磁盘上,当 Redis 重启后，可以从磁盘中恢复数据。Redis 提供两种方式进行持久化，一种是 RDB 持久化(原理是将 Reids 在内存中的数据库记录定时 dump 到磁盘上的 RDB 持久化),另外一种是 A0F(append only file)持久化(原理是将 Reids的操作日志以追加的方式写入文件)。那么这两种持久化方式有什么区别呢?在实际使用的时候该如何选择呢?下面简单介绍一下二者的区别

1.RDB 优缺点

(1) RDB 优点

一旦采用该方式，那么整个 Redis 数据库将只包含一个文件，这对于文件备份而言是非常完美的。比如，计划每个小时归档一次最近 24 小时的数据，同时还要每天归档一次最近 30 天的数据。通过这样的备份策略，一旦系统出现灾难性故障，可以非常容易地进行恢复。
对于灾难恢复而言，RDB 是非常不错的选择。可以非常轻松的将一个单独的文件压缩后再转移到其它存储介质上。
性能最大化，对于 Redis 的服务进程而言，在开始持久化时，它唯一需要做的只是 fork 出子进程，之后再由子进程完成这些持久化的工作，这样就可以极大的避免服务进程执行 I0 操作了。
相比于 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)。

3.Redis 持久化配置

（1）RDB 持久化配置

Redis 会将数据集的快照 dump 到 dump.rdb 文件中。此外，也可以通过配置文件来修改 Redis 服务器 dump 快照的频率。在打开 6379.conf 文件之后,搜索 save，可以看到如下所示配置信息。

save 900 1:在 900 秒(15 分钟)内，如果至少有 1个 key 发生变化，则 dump 内存快照
save 300 10:在 300 秒(5 分钟)内，如果至少有 10 个 key 发生变化，则 dump 内存快照
save 60 10000:在 60 秒(1 分钟)内，如果至少有 10000 个 key 发生变化，则 dump 内存快照

（2）AOF 持久化配置

appendonly no 改为 yes 开启 aof.在 Redis 的配置文件中存在三种同步方式，它们分别是:

appendfsync always:每次有数据修改发生时都会写入 AOF 文件。
appendfsynceverysec:每秒钟同步一次，该策略为AOF的缺省策略
appendfsync no:从不同步，高效但是数据不会被持久化。

4.AOF重写

Redis 会不断地将被执行的命令记录到 AOF 文件里面，所以随着 Redis 不断运行，AOF 文件的体积也会不断增长。在极端情况下，体积不断增大的 AOF 文件甚至可能会用完硬盘的所有可用空间。Redis在重启之后需要通过重新执行AOF 文件记录的所有写命令来还原数据集，所以如果 AOF 文件的体积非常大，那么还原操作执行的时间就可能会非常长。

为了解决 AOF 文件体积不断增大的问题，用户可以向Redis 发送BGREWRITEAOF 命令。BGREWRITEAOF 命令会通过移除 AOF 文件中的几余命令来重写(rewrite)A0F 文件，使 AOF 文件的体积尽可能地变小。

BGREWRITEAOF 的工作原理和 BGSAVE 创建快照的工作原理非常相似:Redis会创建一个子进程，然后由子进程负责对 AOF 文件进行重写。因为 AOF 文件重写也需要用到子进程,所以快照持久化因为创建子进程而导致的性能问题和内存占用问题，在 AOF 持久化中也同样存在。

与快照持久化通过设置 save 选项来自动执行 BGSAVE 一样，AOF 持久化也可以通过设置 auto-aof-rewrite-percentage 选项和 auto-aof-rewrite-min-size 选项来自动执行 BGREWRITEAOF。

举个例子，假设用户对 Redis 设置了配置选项 auto-aof-rewrite-percentage 100和 auto-aof-rewrite-min-size 64mb，并且启动了 AOF 持久化，那么当 AOF 文件的体积大于64MB，并且 AOF 文件的体积比上一次重写之后的体积大了至少一倍(100%)的时候，Redis将执行BGREWRITEAOF 命令。如果 AOF重写执行的过于频繁的话，用户可以考虑将 auto-aof-rewrite-percentage 选项的值设置为 100 以上，这种做法可以让 Redis 在 AOF 文件的体积变得更大之后才执行重写操作，不过也会让Redis在启动时还原数据集所需的时间变得更长。