一、Redis 简介
Redis 是完全开源免费的，遵守BSD协议，是一个高性能的key-value数据库。
Redis 与其他 key - value 缓存产品有以下三个特点：
1.Redis支持数据的持久化，可以将内存中的数据保存在磁盘中，重启的时候可以再次加载进行使用。
2.Redis不仅仅支持简单的key-value类型的数据，同时还提供list，set，zset，hash等数据结构的存储。
3.Redis支持数据的备份，即master-slave模式的数据备份。
二、Redis使用背景
在我们日常的Java Web开发中，无不都是使用数据库来进行数据的存储，由于一般的系统任务中通常不会存在高并发的情况，所以这样看起来并没有什么问题，可是一旦涉及大数据量的需求，比如一些商品抢购的情景，或者是主页访问量瞬间较大的时候，单一使用数据库来保存数据的系统会因为面向磁盘，磁盘读/写速度比较慢的问题而存在严重的性能弊端，一瞬间成千上万的请求到来，需要系统在极短的时间内完成成千上万次的读/写操作，这个时候往往不是数据库能够承受的，极其容易造成数据库系统瘫痪，最终导致服务宕机的严重生产问题。
为了克服上述的问题，Java Web项目通常会引入NoSQL技术，这是一种基于内存的数据库，并且提供一定的持久化功能。
Redis和MongoDB是当前使用最广泛的NoSQL，而就Redis技术而言，它的性能十分优越，可以支持每秒十几万次的读/写操作，其性能远超数据库，并且还支持集群、分布式、主从同步等配置，原则上可以无限扩展，让更多的数据存储在内存中，更让人欣慰的是它还支持一定的事务能力，这保证了高并发的场景下数据的安全和一致性。
三、Redis优势
1.性能极高 – Redis能读的速度是110000次/s,写的速度是81000次/s 。
2.丰富的数据类型 – Redis支持二进制案例的 Strings, Lists, Hashes, Sets 及 Ordered Sets 数据类型操作。
3.原子性 – Redis的所有操作都是原子性的，同时Redis还支持对几个操作全并后的原子性执行。
4.丰富的特性 – Redis还支持 publish/subscribe, 通知, key 过期等等特性。
四、Redis和其他NoSQL储存的不同
1.Redis有着更为复杂的数据结构并且提供对他们的原子性操作，这是一个不同于其他数据库的进化路径。Redis的数据类型都是基于基本数据结构的同时对程序员透明，无需进行额外的抽象。
2.Redis运行在内存中但是可以持久化到磁盘，所以在对不同数据集进行高速读写时需要权衡内存，因为数据量不能大于硬件内存。在内存数据库方面的另一个优点是， 相比在磁盘上相同的复杂的数据结构，在内存中操作起来非常简单，这样Redis可以做很多内部复杂性很强的事情。 同时，在磁盘格式方面他们是紧凑的以追加的方式产生的，因为他们并不需要进行随机访问。
五、Redis在JavaWeb中的应用
Redis 在 Java Web 主要有两个应用场景：
1.缓存—存储常用的数据；
2.高速读/写—使用它快速读/写；
1.缓存
在日常对数据库的访问中，读操作的次数远超写操作，比例大概在 1:9 到 3:7，所以需要读的可能性是比写的可能大得多的。当我们使用SQL语句去数据库进行读写操作时，数据库就会去磁盘把对应的数据索引取回来，这是一个相对较慢的过程。
如果我们把数据放在 Redis 中，也就是直接放在内存之中，让服务端直接去读取内存中的数据，由于内存的读写速度远比磁盘快，所以读写速度明显就会快上不少，并且会极大减小数据库的压力，但是使用内存进行数据存储开销也是比较大的，限于成本的原因，一般我们只是使用 Redis 存储一些常用和主要的数据，比如用户登录的信息等。
一般而言在使用 Redis 进行存储的时候，我们需要从以下几个方面来考虑：
1.业务数据常用吗？命中率如何？如果命中率很低，就没有必要写入缓存；
2.该业务数据是读操作多，还是写操作多？如果写操作多，频繁需要写入数据库，也没有必要使用缓存；
3.业务数据大小如何？如果要存储几百兆字节的文件，会给缓存带来很大的压力，这样也没有必要；
在考虑了这些问题之后，如果觉得有必要使用缓存，那么就使用它！
使用 Redis 作为缓存的读取逻辑如下图所示：
从上图我们可以知道以下两点：
当第一次读取数据的时候，读取 Redis 的数据就会失败，此时就会触发程序读取数据库，把数据读取出来，并且写入 Redis 中；
当第二次以及以后需要读取数据时，就会直接读取 Redis，读到数据后就结束了流程，这样速度就大大提高了。
从上面的分析可以知道，读操作的可能性是远大于写操作的，所以使用 Redis 来处理日常中需要经常读取的数据，速度提升是显而易见的，同时也降低了对数据库的依赖，使得数据库的压力大大减少。
分析了读操作的逻辑，下面我们来看看写操作的流程：
从流程可以看出，更新或者写入的操作，需要多个 Redis 的操作，如果实际应用场景中，业务数据写次数远大于读次数那么就没有必要使用 Redis。
2.高速读/写的场合
在如今的互联网中，越来越多的存在高并发的情况，最常见的莫过于电商系统中秒杀商品的场景，比如天猫双11、抢李志的演唱会门票等，这些场合都是在某一个瞬间有成千上万的请求到达服务器，如果单纯的使用数据库来进行处理，就算不崩，也会很慢，轻则造成用户体验极差用户量流失，重则数据库瘫痪，服务宕机，而这样的场合都是不允许的！
所以我们需要使用 Redis 来应对这样的高并发需求的场合，我们先来看看一次请求操作的流程图：
我们来进一步阐述这个过程：
当一个请求到达服务器时，只是把业务数据（秒杀商品的库存）在 Redis 上进行读写，而没有对数据库进行任何的操作，这样就能大大提高读写的速度，从而满足高速响应的需求；
但是这些缓存的数据仍然需要持久化，也就是存入数据库之中，所以在一个请求操作完 Redis 的读/写之后，会去判断该高速读/写的业务是否结束，这个判断通常会在秒杀商品的库存为0，红包金额为0时成立，如果不成立，则不会操作数据库；如果成立，则触发事件将 Redis 的缓存的数据以批量的形式一次性写入数据库，从而完成持久化的工作。
六、Redis的安装
1.Window 下安装
下载地址：https://github.com/MSOpenTech/redis/releases
Redis 支持 32 位和 64 位。这个需要根据你系统平台的实际情况选择，这里我们下载 Redis-x64-xxx.zip压缩包到 C 盘，解压后，将文件夹重新命名为 redis。
打开文件夹，内容如下：
打开一个 cmd 窗口 使用 cd 命令切换目录到 C:\redis 运行：
redis-server.exe redis.windows.conf
如果想方便的话，可以把 redis 的路径加到系统的环境变量里，这样就省得再输路径了，后面的那个 redis.windows.conf 可以省略，如果省略，会启用默认的。输入之后，会显示如下界面：
上图的提示信息告诉了我们：① Redis 当前的版本为 3.0.100/位数为64 位；② Redis 运行在 6379 端口；③ Redis 进程的 PID 为 15292；
至此，Redis服务端就启动完成了。接下来进行Redis客户端的启动。
Redis目录下有一个redis-cli.exe 文件，这是 Redis 自带的一个客户端工具，它可以用来连接到我们当前的 Redis 服务器。
启动客户端需要另启一个 cmd 窗口，原来的服务端窗口不要关闭，不然就无法访问服务端了。
切换到 redis 目录下运行:
redis-cli.exe -h 127.0.0.1 -p 6379
设置键值对:
set myKey abc
取出键值对:
get myKey
至此，我们便在 Windows 的环境下安装好了 Redis。
2.Linux环境下安装
下载地址： http://redis.io/download，下载最新稳定版本。
本教程使用的最新文档版本为 2.8.17，下载并安装：
$ wget http://download.redis.io/releases/redis-2.8.17.tar.gz
$ tar xzf redis-2.8.17.tar.gz
$ cd redis-2.8.17
$ make
make完后 redis-2.8.17目录下会出现编译后的redis服务程序redis-server,还有用于测试的客户端程序redis-cli，两个程序位于安装目录 src 目录下：
下面启动redis服务.
$ cd src
$ ./redis-server
注意这种方式启动redis 使用的是默认配置。 也可以通过启动参数告诉redis使用指定配置文件使用下面命令启动。
$ cd src
$ ./redis-server ../redis.conf
redis.conf 是一个默认的配置文件。我们可以根据需要使用自己的配置文件。
启动redis服务进程后，就可以使用测试客户端程序redis-cli和redis服务交互了。 比如：
$ cd src
$ ./redis-cli
redis> set foo bar
OK
redis> get foo
"bar"
七、Redis 配置
Redis 的配置文件位于 Redis 安装目录下，文件名为 redis.conf(Windows 名为 redis.windows.conf)。
你可以通过 CONFIG 命令查看或设置配置项。
语法
Redis CONFIG 命令格式如下：
redis 127.0.0.1:6379> CONFIG GET CONFIG_SETTING_NAME
实例
redis 127.0.0.1:6379> CONFIG GET loglevel
1) "loglevel"
2) "notice"
使用 * 号获取所有配置项：
实例
redis 127.0.0.1:6379> CONFIG GET *
"dbfilename"
"dump.rdb"
"requirepass"
""
"masterauth"
""
"unixsocket"
""
"logfile"
""
"pidfile"
"/var/run/redis.pid"
"maxmemory"
"0"
"maxmemory-samples"
"3"
"timeout"
"0"
"tcp-keepalive"
"0"
"auto-aof-rewrite-percentage"
"100"
"auto-aof-rewrite-min-size"
"67108864"
"hash-max-ziplist-entries"
"512"
"hash-max-ziplist-value"
"64"
"list-max-ziplist-entries"
"512"
"list-max-ziplist-value"
"64"
"set-max-intset-entries"
"512"
"zset-max-ziplist-entries"
"128"
"zset-max-ziplist-value"
"64"
"hll-sparse-max-bytes"
"3000"
"lua-time-limit"
"5000"
"slowlog-log-slower-than"
"10000"
"latency-monitor-threshold"
"0"
"slowlog-max-len"
"128"
"port"
"6379"
"tcp-backlog"
"511"
"databases"
"16"
"repl-ping-slave-period"
"10"
"repl-timeout"
"60"
"repl-backlog-size"
"1048576"
"repl-backlog-ttl"
"3600"
"maxclients"
"4064"
"watchdog-period"
"0"
"slave-priority"
"100"
"min-slaves-to-write"
"0"
"min-slaves-max-lag"
"10"
"hz"
"10"
"no-appendfsync-on-rewrite"
"no"
"slave-serve-stale-data"
"yes"
"slave-read-only"
"yes"
"stop-writes-on-bgsave-error"
"yes"
"daemonize"
"no"
"rdbcompression"
"yes"
"rdbchecksum"
"yes"
"activerehashing"
"yes"
"repl-disable-tcp-nodelay"
"no"
"aof-rewrite-incremental-fsync"
"yes"
"appendonly"
"no"
"dir"
"/home/deepak/Downloads/redis-2.8.13/src"
"maxmemory-policy"
"volatile-lru"
"appendfsync"
"everysec"
"save"
"3600 1 300 100 60 10000"
"loglevel"
"notice"
"client-output-buffer-limit"
"normal 0 0 0 slave 268435456 67108864 60 pubsub 33554432 8388608 60"
"unixsocketperm"
"0"
"slaveof"
""
"notify-keyspace-events"
""
"bind"
""
编辑配置
你可以通过修改 redis.conf 文件或使用 CONFIG set 命令来修改配置。
语法
CONFIG SET 命令基本语法：
redis 127.0.0.1:6379> CONFIG SET CONFIG_SETTING_NAME NEW_CONFIG_VALUE
实例
redis 127.0.0.1:6379> CONFIG SET loglevel "notice"
OK
redis 127.0.0.1:6379> CONFIG GET loglevel
"loglevel"
"notice"
Redis配置具体参数说明：https://www.cnblogs.com/jianmingyuan/p/11089406.html
Redis持久化配置
redis有两种持久化方式：RDB和AOF。
具体差别跟优缺点可参考redis数据的两种持久化方式对比
RDB配置方式
默认情况下，是快照RDB的持久化方式，将内存中的数据以快照的方式写入二进制文件中，默认的文件名是dump.rdb
redis.conf默认配置：
save 900 1
save 300 10
save 60 10000
配置含义：
900秒内，如果超过1个key被修改，则发起快照保存
300秒内，如果超过10个key被修改，则发起快照保存
60秒内，如果1万个key被修改，则发起快照保存
默认配置不方便看效果，可将快照频率设大一点，在redis.conf中增加一行：
save 10 1
保存后，启动redis服务端和客户端。在客户端输入命令：
输入完，发现dump.rdb文件的修改日期变了，并且redis服务端增加了保存日志：
接下来，重启redis服务端和客户端，看数据是否真的持久化了：
取到对应key的value值与之前设置的相同，说明使用RDB快照持久化成功了。
AOF 配置方式
redis.conf默认配置：
appendonly no
配置文件中的appendonly修改为yes，开启AOF持久化。 开启后，启动redis服务端，发现多了一个appendonly.aof文件
使用AOF做持久化，每一个命令以 Redis 协议的格式来保存，新命令会被追加到文件的末尾。 Redis 还可以在后台对 AOF 文件进行重写，使得 AOF文件的体积不会超出保存数据集状态所需的实际大小。实际上，AOF持久化并不会立即将命令写入到硬盘文件中，而是写入到硬盘缓存，在接下来的策略中，配置多久来从硬盘缓存写入到硬盘文件。所以在一定程度一定条件下，还是会有数据丢失，不过你可以大大减少数据损失。
appendfsync always
appendfsync everysec
appendfsync no
配置含义：
always: 每次操作都会立即写入aof文件中
everysec: 每秒持久化一次(默认配置)
no: 不主动进行同步操作，默认30s一次
当然always一定是效率最低的，个人认为everysec就够用了，数据安全性能又高。Redis也允许我们同时使用两种方式，再重启redis后会从AOF中恢复数据，因为AOF比RDB数据损失小。
配置好后，启动redis客户端，输入命令：
最后的flushall是清除所有的键值。打开appendonly.aof文件，可以看到：
去掉最后面的flushall(也可以按照redis协议增加命令)，重启客户端和服务端，看数据是否真的持久化了：
取到的value值与之前设置的一样，说明使用AOF持久化也成功了。
小结：两种持久化模式中，RDB模式指定了持久化的频率，当满足时，将数据保存在磁盘中；而AOF模式将每次操作的命令都保存在磁盘缓存中，然后通过 appendfsync 配置项来规定每隔多长时间将磁盘缓存中的命令集合同步到磁盘存储中。相对来说，AOF文件的体积会大于RDB，但是恢复数据时丢失的数据更少。
由于AOF 文件有序地保存了对数据库执行的所有写入操作， 这些写入操作以 Redis 协议的格式保存， 如果你不小心执行了 FLUSHALL 命令， 但只要 AOF 文件未被重写， 那么只要停止服务器， 移除 AOF 文件末尾的 FLUSHALL 命令， 并重启 Redis ， 就可以将数据集恢复到 FLUSHALL 执行之前的状态。
参考链接：
