redis系列——入门内容（一）
一、基本介绍
1、NoSql介绍
为了解决高并发、高可用、高可扩展，大数据存储等一系列问题而产生的数据库解决方案，就是NoSql。NoSql，叫非关系型数据库，它的全名Not only sql。它不能替代关系型数据库，只能作为关系型数据库的一个良好补充。关系型数据库中的表都是存储一些结构化的数据，每条记录的字段的组成都一样，即使不是每条记录都需要所有的字段，但数据库会为每条数据分配所有的字段。而非关系型数据库以键值对(key-value)存储，它的结构不固定，每一条记录可以有不一样的键，每条记录可以根据需要增加一些自己的键值对，这样就不会局限于固定的结构，可以减少一些时间和空间的开销。 其中Nosql数据库分类如下：
- 键值(Key-Value)存储数据库
相关产品： Tokyo Cabinet/Tyrant、Redis、Voldemort、Berkeley DB
典型应用： 内容缓存，主要用于处理大量数据的高访问负载。
数据模型： 一系列键值对
优势： 快速查询
劣势： 存储的数据缺少结构化
- 列存储数据库
相关产品：Cassandra, HBase, Riak
典型应用：分布式的文件系统
数据模型：以列簇式存储，将同一列数据存在一起
优势：查找速度快，可扩展性强，更容易进行分布式扩展
劣势：功能相对局限
- 文档型数据库
相关产品：CouchDB、MongoDB
典型应用：Web应用（与Key-Value类似，Value是结构化的）
数据模型： 一系列键值对
优势：数据结构要求不严格
劣势： 查询性能不高，而且缺乏统一的查询语法
- 图形(Graph)数据库
相关数据库：Neo4J、InfoGrid、Infinite Graph
典型应用：社交网络
数据模型：图结构
优势：利用图结构相关算法。
劣势：需要对整个图做计算才能得出结果，不容易做分布式的集群方案。
2、Redis介绍
1.基本说明
Redis是用C语言开发的一个开源的高性能键值对（key-value）数据库。它通过提供多种键值数据类型来适应不同场景下的存储需求，目前为止Redis支持的键值数据类型如下：
- 字符串类型【String】
- 散列类型【map】
- 列表类型【list】
- 集合类型【set】
- 有序集合类型【sortedset】
2.历史发展
2008年，意大利的一家创业公司Merzia推出了一款基于MySQL的网站实时统计系统LLOOGG，然而没过多久该公司的创始人 Salvatore Sanfilippo便 对MySQL的性能感到失望，于是他决定亲自为LLOOGG量身定做一个数据库，并于2009年开发完成，这个数据库就是Redis。 不过Salvatore Sanfilippo并不满足只将Redis用于LLOOGG这一款产品，而是希望更多的人使用它，于是在同一年Salvatore Sanfilippo将Redis开源发布，并开始和Redis的另一名主要的代码贡献者Pieter Noordhuis一起继续着Redis的开发，直到今天。
Salvatore Sanfilippo自己也没有想到，短短的几年时间，Redis就拥有了庞大的用户群体。Hacker News在2012年发布了一份数据库的使用情况调查，结果显示有近12%的公司在使用Redis。国内如新浪微博、街旁网、知乎网，国外如GitHub、Stack Overflow、Flickr等都是Redis的用户。
VMware公司从2010年开始赞助Redis的开发， Salvatore Sanfilippo和Pieter Noordhuis也分别在3月和5月加入VMware，全职开发Redis。
3.应用场景
- 缓存（数据查询、短连接、新闻内容、商品内容等等）。（最多使用）
- 分布式集群架构中的session分离。
- 聊天室的在线好友列表。
- 任务队列。（秒杀、抢购、12306等等）
- 应用排行榜。
- 网站访问统计。
- 数据过期处理（可以精确到毫秒）
二、Redis的安装配置
1、redis安装
Redis下载地址为：http://download.redis.io/releases/redis-3.0.0.tar.gz ；官网地址：http://redis.io/ 。安装前我们先要配置编译环境：
sudo yum install gcc-c++下载源码：
wget http://download.redis.io/releases/redis-4.0.9.tar.gz解压源码：
tar -zxvf redis-4.0.9.tar.gz进入到解压目录：
cd redis-4.0.9执行make编译Redis：
make MALLOC=libc注意：make命令执行完成编译后，会在src目录下生成6个可执行文件，分别是redis-server、redis-cli、redis-benchmark、redis-check-aof、redis-check-rdb、redis-sentinel。
安装Redis：
make install PREFIX=/usr/local/InstallationSoftware/redis2、 redis的启动
1.前端启动
前端启动的命令为（首先进入bin目录）：
启动界面如下 ：
前端启动的关闭：
- 强制关闭：Ctrl+c
- 正常关闭：./redis-cli shutdown
前端启动的问题：一旦客户端关闭，则redis服务也停掉。
2.后端启动
首先需要将redis解压之后的源码包中的redis.conf文件拷贝到我们安装的bin目录下，然后使用vim修改redis.conf文件。将daemonize no改为daemonize yes
然后使用命令后端启动redis
看是否启动成功
关闭后端启动的方式为：
强制关闭：kill -9 7944
正常关闭：./redis-cli shutdown
注意：在项目中，建议使用正常关闭。因为redis作为缓存来使用的话，将数据存储到内存中，如果使用正常关闭，则会将内存数据持久化到本地之后，再关闭。如果是强制关闭，则不会进行持久化操作，可能会造成部分数据的丢失。
3.脚本启动
如果是做一些实验的话，用redis-server启动一下redis是可以的，但在生产环境上是没有意义的。我们要把redis作为一个系统的daemon进程去运行的，每次系统启动，redis进程一起启动。在redis解压目录中的utils目录下，有个redis_init_script脚本。将redis_init_script脚本拷贝到linux的/etc/init.d目录中（改下路径），将redis_init_script重命名为redis_6379，6379是我们希望这个redis实例监听的端口号。然后修改redis_6379脚本的第6行的REDISPORT，设置为相同的端口号（默认就是6379），同时修改EXEC和CLIEXEC为自己的路径。创建两个目录：/etc/redis（存放redis的配置文件），/var/redis/6379（存放redis的持久化文件）。修改redis配置文件（默认在根目录下，redis.conf），拷贝到/etc/redis目录中，修改名称为6379.conf。修改conf中的部分配置为生产环境
daemonize yes #让redis以daemon进程运行
pidfile /var/run/redis_6379.pid #设置redis的pid文件位置
port 6379 #设置redis的监听端口号
dir /var/redis/6379 #设置持久化文件的存储位置
bind 192.168.234.131 #绑定的ip启动redis，执行
cd /etc/init.d
chmod 777 redis_6379
./redis_6379 start确认redis进程是否启动，ps -ef | grep redis
下面让redis跟随系统启动自动启动，在redis_6379脚本中，最上面，加入两行注释
# chkconfig: 2345 90 10
# description: Redis is a persistent key-value database然后执行，即可
chkconfig redis_6379 on三、 redis.conf 的配置信息
| 参数 | 说明 |
| daemonize | 如果需要在后台运行，把该项改为yes |
| pidfile | 配置多个pid的地址 默认在/var/run/redis.pid |
| bind | 绑定ip，设置后只接受来自该ip的请求 |
| port | 监听端口，默认是6379 |
| loglevel | 分为4个等级：debug verbose notice warning |
| logfile | 用于配置log文件地址 |
| databases | 设置数据库个数，默认使用的数据库为0 |
| save | 设置redis进行数据库镜像的频率。 |
| rdbcompression | 在进行镜像备份时，是否进行压缩 |
| dbfilename | 镜像备份文件的文件名 |
| Dir | 数据库镜像备份的文件放置路径 |
| Slaveof | 设置数据库为其他数据库的从数据库 |
| Masterauth | 主数据库连接需要的密码验证 |
| Requriepass | 设置 登陆时需要使用密码 |
| Maxclients | 限制同时使用的客户数量 |
| Maxmemory | 设置redis能够使用的最大内存 |
| Appendonly | 开启append only模式 |
| Appendfsync | 设置对appendonly.aof文件同步的频率（对数据进行备份的第二种方式） |
| vm-enabled | 是否开启虚拟内存支持 （vm开头的参数都是配置虚拟内存的） |
| vm-swap-file | 设置虚拟内存的交换文件路径 |
| vm-max-memory | 设置redis使用的最大物理内存大小 |
| vm-page-size | 设置虚拟内存的页大小 |
| vm-pages | 设置交换文件的总的page数量 |
| vm-max-threads | 设置VM IO同时使用的线程数量 |
| Glueoutputbuf | 把小的输出缓存存放在一起 |
| hash-max-zipmap-entries | 设置hash的临界值 |
| Activerehashing | 重新hash |
四、对QPS进行压测
如果我们想要对自己刚刚搭建好的redis做一个基准的压测，测一下redis的性能和QPS（query per second）。redis自己提供的redis-benchmark压测工具，是最快捷最方便的，当然啦，这个工具比较简单，用一些简单的操作和场景去压测。该工具在redis的源码包src中，
./redis-benchmark -h 192.168.31.187
-c Number of parallel connections (default 50)
-n Total number of requests (default 100000)
-d Data size of SET/GET value in bytes (default 2) 这个要根据自己的高峰期的访问量来调整一些参数，比如在高峰期，瞬时最大用户量会达到10万+，-c 100000，-n 10000000，-d 50。我这里就用默认配置测一下自己的虚拟机结果如下：
[root@redis_01 src]# ./redis-benchmark -h 192.168.234.129
====== PING_INLINE ======
100000 requests completed in 1.83 seconds
50 parallel clients
3 bytes payload
keep alive: 1
89.64% <= 1 milliseconds
97.91% <= 2 milliseconds
99.35% <= 3 milliseconds
99.88% <= 4 milliseconds
100.00% <= 4 milliseconds
54704.60 requests per second
====== PING_BULK ======
100000 requests completed in 1.80 seconds
50 parallel clients
3 bytes payload
keep alive: 1
89.67% <= 1 milliseconds
98.20% <= 2 milliseconds
99.60% <= 3 milliseconds
99.99% <= 4 milliseconds
100.00% <= 4 milliseconds
55493.89 requests per second
====== SET ======
100000 requests completed in 2.39 seconds
50 parallel clients
3 bytes payload
keep alive: 1
80.40% <= 1 milliseconds
94.78% <= 2 milliseconds
98.47% <= 3 milliseconds
99.62% <= 4 milliseconds
99.80% <= 12 milliseconds
99.81% <= 13 milliseconds
99.85% <= 14 milliseconds
99.90% <= 15 milliseconds
99.95% <= 16 milliseconds
100.00% <= 16 milliseconds
41858.52 requests per second
====== GET ======
100000 requests completed in 1.89 seconds
50 parallel clients
3 bytes payload
keep alive: 1
88.78% <= 1 milliseconds
97.86% <= 2 milliseconds
99.26% <= 3 milliseconds
99.81% <= 4 milliseconds
99.97% <= 7 milliseconds
100.00% <= 7 milliseconds
53022.27 requests per second
====== INCR ======
100000 requests completed in 2.37 seconds
50 parallel clients
3 bytes payload
keep alive: 1
81.38% <= 1 milliseconds
94.57% <= 2 milliseconds
98.35% <= 3 milliseconds
99.38% <= 4 milliseconds
99.62% <= 5 milliseconds
99.65% <= 6 milliseconds
99.70% <= 7 milliseconds
99.80% <= 8 milliseconds
99.80% <= 9 milliseconds
99.83% <= 10 milliseconds
99.86% <= 11 milliseconds
99.90% <= 13 milliseconds
99.96% <= 15 milliseconds
100.00% <= 15 milliseconds
42176.30 requests per second
====== LPUSH ======
100000 requests completed in 2.52 seconds
50 parallel clients
3 bytes payload
keep alive: 1
78.92% <= 1 milliseconds
94.05% <= 2 milliseconds
98.00% <= 3 milliseconds
99.27% <= 4 milliseconds
99.45% <= 5 milliseconds
99.45% <= 6 milliseconds
99.47% <= 7 milliseconds
99.55% <= 8 milliseconds
99.60% <= 11 milliseconds
99.64% <= 12 milliseconds
99.70% <= 13 milliseconds
99.80% <= 14 milliseconds
99.88% <= 15 milliseconds
99.92% <= 16 milliseconds
99.95% <= 17 milliseconds
99.97% <= 18 milliseconds
100.00% <= 19 milliseconds
39714.06 requests per second
====== RPUSH ======
100000 requests completed in 2.45 seconds
50 parallel clients
3 bytes payload
keep alive: 1
81.01% <= 1 milliseconds
94.65% <= 2 milliseconds
98.07% <= 3 milliseconds
99.23% <= 4 milliseconds
99.48% <= 5 milliseconds
99.52% <= 6 milliseconds
99.64% <= 7 milliseconds
99.70% <= 13 milliseconds
99.85% <= 14 milliseconds
99.90% <= 15 milliseconds
99.95% <= 16 milliseconds
99.95% <= 30 milliseconds
100.00% <= 30 milliseconds
40766.41 requests per second
====== LPOP ======
100000 requests completed in 2.33 seconds
50 parallel clients
3 bytes payload
keep alive: 1
83.04% <= 1 milliseconds
95.55% <= 2 milliseconds
98.42% <= 3 milliseconds
99.37% <= 4 milliseconds
99.52% <= 5 milliseconds
99.65% <= 6 milliseconds
99.65% <= 10 milliseconds
99.70% <= 12 milliseconds
99.72% <= 13 milliseconds
99.80% <= 14 milliseconds
99.83% <= 15 milliseconds
99.85% <= 16 milliseconds
99.90% <= 20 milliseconds
99.90% <= 21 milliseconds
99.94% <= 22 milliseconds
99.95% <= 26 milliseconds
99.99% <= 27 milliseconds
100.00% <= 27 milliseconds
42863.27 requests per second
====== RPOP ======
100000 requests completed in 2.28 seconds
50 parallel clients
3 bytes payload
keep alive: 1
83.38% <= 1 milliseconds
95.56% <= 2 milliseconds
98.41% <= 3 milliseconds
99.46% <= 4 milliseconds
99.70% <= 5 milliseconds
99.75% <= 13 milliseconds
99.76% <= 14 milliseconds
99.90% <= 17 milliseconds
99.92% <= 18 milliseconds
100.00% <= 18 milliseconds
43840.42 requests per second
====== SADD ======
100000 requests completed in 1.92 seconds
50 parallel clients
3 bytes payload
keep alive: 1
89.08% <= 1 milliseconds
97.33% <= 2 milliseconds
99.10% <= 3 milliseconds
99.73% <= 4 milliseconds
99.90% <= 5 milliseconds
100.00% <= 6 milliseconds
100.00% <= 6 milliseconds
52110.47 requests per second
====== SPOP ======
100000 requests completed in 1.80 seconds
50 parallel clients
3 bytes payload
keep alive: 1
90.44% <= 1 milliseconds
98.10% <= 2 milliseconds
99.53% <= 3 milliseconds
99.95% <= 7 milliseconds
100.00% <= 8 milliseconds
100.00% <= 8 milliseconds
55463.12 requests per second
====== LPUSH (needed to benchmark LRANGE) ======
100000 requests completed in 2.42 seconds
50 parallel clients
3 bytes payload
keep alive: 1
80.83% <= 1 milliseconds
95.31% <= 2 milliseconds
98.37% <= 3 milliseconds
99.51% <= 4 milliseconds
99.60% <= 6 milliseconds
99.70% <= 7 milliseconds
99.70% <= 13 milliseconds
99.84% <= 14 milliseconds
99.85% <= 15 milliseconds
99.89% <= 16 milliseconds
99.90% <= 18 milliseconds
99.95% <= 33 milliseconds
100.00% <= 34 milliseconds
100.00% <= 34 milliseconds
41305.25 requests per second
====== LRANGE_100 (first 100 elements) ======
100000 requests completed in 3.06 seconds
50 parallel clients
3 bytes payload
keep alive: 1
55.41% <= 1 milliseconds
93.58% <= 2 milliseconds
98.68% <= 3 milliseconds
99.79% <= 4 milliseconds
99.96% <= 5 milliseconds
100.00% <= 5 milliseconds
32658.39 requests per second
====== LRANGE_300 (first 300 elements) ======
100000 requests completed in 6.17 seconds
50 parallel clients
3 bytes payload
keep alive: 1
3.37% <= 1 milliseconds
52.56% <= 2 milliseconds
85.62% <= 3 milliseconds
96.04% <= 4 milliseconds
99.49% <= 5 milliseconds
99.92% <= 6 milliseconds
99.95% <= 8 milliseconds
99.97% <= 9 milliseconds
100.00% <= 10 milliseconds
16215.34 requests per second
====== LRANGE_500 (first 450 elements) ======
100000 requests completed in 8.35 seconds
50 parallel clients
3 bytes payload
keep alive: 1
0.00% <= 1 milliseconds
25.11% <= 2 milliseconds
61.67% <= 3 milliseconds
84.97% <= 4 milliseconds
95.57% <= 5 milliseconds
99.47% <= 6 milliseconds
99.94% <= 7 milliseconds
99.99% <= 8 milliseconds
100.00% <= 8 milliseconds
11973.18 requests per second
====== LRANGE_600 (first 600 elements) ======
100000 requests completed in 10.65 seconds
50 parallel clients
3 bytes payload
keep alive: 1
0.00% <= 1 milliseconds
10.27% <= 2 milliseconds
36.59% <= 3 milliseconds
65.09% <= 4 milliseconds
83.84% <= 5 milliseconds
94.71% <= 6 milliseconds
98.99% <= 7 milliseconds
99.85% <= 8 milliseconds
99.97% <= 9 milliseconds
99.99% <= 10 milliseconds
100.00% <= 10 milliseconds
9392.32 requests per second
====== MSET (10 keys) ======
100000 requests completed in 4.98 seconds
50 parallel clients
3 bytes payload
keep alive: 1
15.10% <= 1 milliseconds
77.37% <= 2 milliseconds
90.90% <= 3 milliseconds
95.76% <= 4 milliseconds
96.87% <= 5 milliseconds
97.11% <= 6 milliseconds
97.15% <= 7 milliseconds
97.20% <= 8 milliseconds
97.24% <= 9 milliseconds
97.30% <= 10 milliseconds
97.56% <= 11 milliseconds
97.68% <= 12 milliseconds
97.70% <= 13 milliseconds
97.79% <= 14 milliseconds
98.05% <= 15 milliseconds
98.63% <= 16 milliseconds
99.01% <= 17 milliseconds
99.35% <= 18 milliseconds
99.41% <= 19 milliseconds
99.45% <= 24 milliseconds
99.47% <= 25 milliseconds
99.56% <= 26 milliseconds
99.57% <= 27 milliseconds
99.67% <= 28 milliseconds
99.70% <= 62 milliseconds
99.74% <= 63 milliseconds
99.75% <= 75 milliseconds
99.80% <= 90 milliseconds
99.85% <= 92 milliseconds
99.87% <= 93 milliseconds
99.90% <= 103 milliseconds
99.95% <= 114 milliseconds
100.00% <= 114 milliseconds
20084.35 requests per second我们可以看到redis提供的高并发，至少到上万没问题，基本上几万差不多。当然跟生产环境还有区别的，生产环境上，大量的网络请求的调用，网络本身就有开销，redis的吞吐量就不一定那么高了。从上面压测结果上，我们也能发现QPS的两个杀手：
- 复杂操作，比如特别多的lrange等操作；
- value很大，比如做商品详情页的cache，可能是需要把大串数据，拼接在一起，作为一个json串，大小可能都几k。