1【redis安装】：

点我安装

2【redis是什么】：

NoSql数据库-高性能Key-Value数据库

3【redis特点及优势】：

- 特点：

1.支持数据持久化，可以将内存数据持久化到磁盘，重启可再次加载使用
2.数据类型丰富：String,List,Hash,set,zset
3.支持数据备份，master-slave

- 优势：

1.高性能：读速度110000次/s，写速度81000次/s
2.原子性：要么全部成功，要么失败完全不执行

4【redis.conf配置】：

官方redis.conf（可直接复制替换）：

5【redis客户端使用】：

//这样来启动redis客户端了
$ ./redis-cli
//用set指令来设置key、value
127.0.0.1:6379> set name "roc" 
OK
//来获取name的值
127.0.0.1:6379> get name 
"roc"
//通过客户端来关闭redis服务端
127.0.0.1:6379> shutdown 
127.0.0.1:6379>

6【redis数据结构】：

1. 字符串（strings）
2. 字符串列表（lists）
3. 字符串集合（sets）
4. 有序字符串集合（sorted sets）
5. 哈希（hashes）

7【Java操作redis数据结构】：

import java.util.HashMap;
import java.util.List;
import java.util.Map;

import redis.clients.jedis.Jedis;

public class redis {

    public static void main(String[] args) {

        // 连接redis服务
        Jedis jedis = new Jedis("127.0.0.1", 6379);

        // 密码验证-如果你没有设置redis密码可不验证即可使用相关命令
        // jedis.auth("abcdefg");

        // 简单的key-value 存储
        jedis.set("redis", "myredis");
        System.out.println(jedis.get("redis"));

        // 在原有值得基础上添加,如若之前没有该key，则导入该key
        // 之前已经设定了redis对应"myredis",此句执行便会使redis对应"myredisyourredis"
        jedis.append("redis", "yourredis");
        jedis.append("content", "rabbit");

        // mset 是设置多个key-value值 参数（key1,value1,key2,value2,...,keyn,valuen）
        // mget 是获取多个key所对应的value值 参数（key1,key2,key3,...,keyn） 返回的是个list
        jedis.mset("name1", "yangw", "name2", "demon", "name3", "elena");
        System.out.println(jedis.mget("name1", "name2", "name3"));

        // map
        Map<String, String> user = new HashMap<String, String>();
        user.put("name", "cd");
        user.put("password", "123456");
        // map存入redis
        jedis.hmset("user", user);
        // mapkey个数
        System.out.println(String.format("len:%d", jedis.hlen("user")));
        // map中的所有键值
        System.out.println(String.format("keys: %s", jedis.hkeys("user")));
        // map中的所有value
        System.out.println(String.format("values: %s", jedis.hvals("user")));
        // 取出map中的name字段值
        List<String> rsmap = jedis.hmget("user", "name", "password");
        System.out.println(rsmap);
        // 删除map中的某一个键值 password
        jedis.hdel("user", "password");
        System.out.println(jedis.hmget("user", "name", "password"));

        // list
        jedis.del("listDemo");
        System.out.println(jedis.lrange("listDemo", 0, -1));
        jedis.lpush("listDemo", "A");
        jedis.lpush("listDemo", "B");
        jedis.lpush("listDemo", "C");
        System.out.println(jedis.lrange("listDemo", 0, -1));
        System.out.println(jedis.lrange("listDemo", 0, 1));

        // set
        jedis.sadd("sname", "wobby");
        jedis.sadd("sname", "kings");
        jedis.sadd("sname", "demon");
        System.out.println(String.format("set num: %d", jedis.scard("sname")));
        System.out.println(String.format("all members: %s", jedis.smembers("sname")));
        System.out.println(String.format("is member: %B", jedis.sismember("sname", "wobby")));
        System.out.println(String.format("rand member: %s", jedis.srandmember("sname")));
        // 删除一个对象
        jedis.srem("sname", "demon");
        System.out.println(String.format("all members: %s", jedis.smembers("sname")));
    }
}

8【redis持久化】：

redis提供了两种持久化的方式，分别是RDB（Redis DataBase）和AOF（Append Only File）。

RDB，简而言之，就是在不同的时间点，将redis存储的数据生成快照并存储到磁盘等介质上；

AOF，则是换了一个角度来实现持久化，那就是将redis执行过的所有写指令记录下来，在下次redis重新启动时，只要把这些写指令从前到后再重复执行一遍，就可以实现数据恢复了。

其实RDB和AOF两种方式也可以同时使用，在这种情况下，如果redis重启的话，则会优先采用AOF方式来进行数据恢复，这是因为AOF方式的数据恢复完整度更高。

如果你没有数据持久化的需求，也完全可以关闭RDB和AOF方式，这样的话，redis将变成一个纯内存数据库，就像memcache一样。

9【redis持久化 – RDB】：

RDB方式，是将redis某一时刻的数据持久化到磁盘中，是一种快照式的持久化方法。

redis在进行数据持久化的过程中，会先将数据写入到一个临时文件中，待持久化过程都结束了，才会用这个临时文件替换上次持久化好的文件。正是这种特性，让我们可以随时来进行备份，因为快照文件总是完整可用的。

对于RDB方式，redis会单独创建（fork）一个子进程来进行持久化，而主进程是不会进行任何IO操作的，这样就确保了redis极高的性能。

如果需要进行大规模数据的恢复，且对于数据恢复的完整性不是非常敏感，那RDB方式要比AOF方式更加的高效。

虽然RDB有不少优点，但它的缺点也是不容忽视的。如果你对数据的完整性非常敏感，那么RDB方式就不太适合你，因为即使你每5分钟都持久化一次，当redis故障时，仍然会有近5分钟的数据丢失。所以，redis还提供了另一种持久化方式，那就是AOF。

RDB原理：

fork和cow。fork是指redis通过创建子进程来进行RDB操作，cow指的是copy on write，子进程创建后，父子进程共享数据段，父进程继续提供读写服务，写脏的页面数据会逐渐和子进程分离开来。

10【redis持久化 – AOF】：

AOF，英文是Append Only File，即只允许追加不允许改写的文件。

如前面介绍的，AOF方式是将执行过的写指令记录下来，在数据恢复时按照从前到后的顺序再将指令都执行一遍，就这么简单。

我们通过配置redis.conf中的appendonly yes就可以打开AOF功能。如果有写操作（如SET等），redis就会被追加到AOF文件的末尾。

默认的AOF持久化策略是每秒钟fsync一次（fsync是指把缓存中的写指令记录到磁盘中），因为在这种情况下，redis仍然可以保持很好的处理性能，即使redis故障，也只会丢失最近1秒钟的数据。

如果在追加日志时，恰好遇到磁盘空间满、inode满或断电等情况导致日志写入不完整，也没有关系，redis提供了redis-check-aof工具，可以用来进行日志修复。

因为采用了追加方式，如果不做任何处理的话，AOF文件会变得越来越大，为此，redis提供了AOF文件重写（rewrite）机制，即当AOF文件的大小超过所设定的阈值时，redis就会启动AOF文件的内容压缩，只保留可以恢复数据的最小指令集。举个例子或许更形象，假如我们调用了100次INCR指令，在AOF文件中就要存储100条指令，但这明显是很低效的，完全可以把这100条指令合并成一条SET指令，这就是重写机制的原理。

在进行AOF重写时，仍然是采用先写临时文件，全部完成后再替换的流程，所以断电、磁盘满等问题都不会影响AOF文件的可用性，这点大家可以放心。

虽然优点多多，但AOF方式也同样存在缺陷，比如在同样数据规模的情况下，AOF文件要比RDB文件的体积大。而且，AOF方式的恢复速度也要慢于RDB方式。

如果你直接执行BGREWRITEAOF命令，那么redis会生成一个全新的AOF文件，其中便包括了可以恢复现有数据的最少的命令集。

如果运气比较差，AOF文件出现了被写坏的情况，也不必过分担忧，redis并不会贸然加载这个有问题的AOF文件，而是报错退出。这时可以通过以下步骤来修复出错的文件：

1.备份被写坏的AOF文件
2.运行redis-check-aof –fix进行修复
3.用diff -u来看下两个文件的差异，确认问题点
4.重启redis，加载修复后的AOF文件

> 如何选择？

对于我们应该选择RDB还是AOF，官方的建议是两个同时使用。这样可以提供更可靠的持久化方案。
如何保证数据一致性，请参见本文

11【redis 设置过期时间】：

Redis中有个设置时间过期的功能，即对存储在 redis 数据库中的值可以设置一个过期时间。作为一个缓存数据库，这是非常实用的。如我们一般项目中的 token 或者一些登录信息，尤其是短信验证码都是有时间限制的，按照传统的数据库处理方式，一般都是自己判断过期，这样无疑会严重影响项目性能。

我们 set key 的时候，都可以给一个 expire time，就是过期时间，通过过期时间我们可以指定这个 key 可以存活的时间。

如果假设你设置了一批 key 只能存活1个小时，那么接下来1小时后，redis是怎么对这批key进行删除的？

定期删除+惰性删除。

- 定期删除：

redis默认是每隔 100ms 就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。注意这里是随机抽取的。为什么要随机呢？你想一想假如 redis 存了几十万个 key ，每隔100ms就遍历所有的设置过期时间的 key 的话，就会给 CPU 带来很大的负载！

-惰性删除 ：

定期删除可能会导致很多过期 key 到了时间并没有被删除掉。所以就有了惰性删除。假如你的过期 key，靠定期删除没有被删除掉，还停留在内存里，除非你的系统去查一下那个 key，才会被redis给删除掉。

12【redis 内存淘汰机制】：

例：MySQL里有2000w数据，Redis中只存20w的数据，如何保证Redis中的数据都是热点数据?

redis 提供 6种数据淘汰策略：

volatile-lru：从已设置过期时间的数据集（server.db[i].expires）中挑选最近最少使用的数据淘汰

volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选将要过期的数据淘汰

volatile-random：从已设置过期时间的数据集（server.db[i].expires）中任意选择数据淘汰

allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）

allkeys-random：从数据集（server.db[i].dict）中任意选择数据淘汰

no-eviction：禁止驱逐数据，也就是说当内存不足以容纳新写入数据时，新写入操作会报错。这个应该没人使用吧！

4.0版本后增加以下两种：

volatile-lfu：从已设置过期时间的数据集(server.db[i].expires)中挑选最不经常使用的数据淘汰

allkeys-lfu：当内存不足以容纳新写入数据时，在键空间中，移除最不经常使用的key

13【redis 主从 – 用法】：

像MySQL一样，redis是支持主从同步的，而且也支持一主多从以及多级从结构。

主从结构，一是为了纯粹的冗余备份，二是为了提升读性能，比如很消耗性能的SORT就可以由从服务器来承担。

redis的主从同步是异步进行的，这意味着主从同步不会影响主逻辑，也不会降低redis的处理性能。

主从架构中，可以考虑关闭主服务器的数据持久化功能，只让从服务器进行持久化，这样可以提高主服务器的处理性能。

同步机制：

从服务器会向主服务器发出SYNC指令，当主服务器接到此命令后，就会调用BGSAVE指令来创建一个子进程专门进行数据持久化工作，也就是将主服务器的数据写入RDB文件中。在数据持久化期间，主服务器将执行的写指令都缓存在内存中。

在BGSAVE指令执行完成后，主服务器会将持久化好的RDB文件发送给从服务器，从服务器接到此文件后会将其存储到磁盘上，然后再将其读取到内存中。这个动作完成后，主服务器会将这段时间缓存的写指令再以redis协议的格式发送给从服务器。

另外，要说的一点是，即使有多个从服务器同时发来SYNC指令，主服务器也只会执行一次BGSAVE，然后把持久化好的RDB文件发给多个下游。在redis2.8版本之前，如果从服务器与主服务器因某些原因断开连接的话，都会进行一次主从之间的全量的数据同步；而在2.8版本之后，redis支持了效率更高的增量同步策略，这大大降低了连接断开的恢复成本。

主服务器会在内存中维护一个缓冲区，缓冲区中存储着将要发给从服务器的内容。从服务器在与主服务器出现网络瞬断之后，从服务器会尝试再次与主服务器连接，一旦连接成功，从服务器就会把“希望同步的主服务器ID”和“希望请求的数据的偏移位置（replication offset）”发送出去。主服务器接收到这样的同步请求后，首先会验证主服务器ID是否和自己的ID匹配，其次会检查“请求的偏移位置”是否存在于自己的缓冲区中，如果两者都满足的话，主服务器就会向从服务器发送增量内容。

增量同步功能，需要服务器端支持全新的PSYNC指令。这个指令，只有在redis-2.8之后才具有。

14【redis的事务处理】：

事务：事务是指“一个完整的动作，要么全部执行，要么什么也没有做”。
下面这四个指令构成了redis事务处理的基础：
即MULTI、EXEC、DISCARD、WATCH。

1. MULTI用来组装一个事务；
2. EXEC用来执行一个事务；
3. DISCARD用来取消一个事务；
4. WATCH用来监视一些key，一旦这些key在事务执行之前被改变，则取消事务的执行。

例子：

redis> MULTI //标记事务开始
OK
redis> INCR user_id //多条命令按顺序入队
QUEUED
redis> INCR user_id
QUEUED
redis> INCR user_id
QUEUED
redis> PING
QUEUED
redis> EXEC //执行
1) (integer) 1
2) (integer) 2
3) (integer) 3
4) PONG

在上面的例子中，我们看到了QUEUED的字样，这表示我们在用MULTI组装事务时，每一个命令都会进入到内存队列中缓存起来，如果出现QUEUED则表示我们这个命令成功插入了缓存队列，在将来执行EXEC时，这些被QUEUED的命令都会被组装成一个事务来执行。

对于事务的执行来说，如果redis开启了AOF持久化的话，那么一旦事务被成功执行，事务中的命令就会通过write命令一次性写到磁盘中去，如果在向磁盘中写的过程中恰好出现断电、硬件故障等问题，那么就可能出现只有部分命令进行了AOF持久化，这时AOF文件就会出现不完整的情况，这时，我们可以使用redis-check-aof工具来修复这一问题，这个工具会将AOF文件中不完整的信息移除，确保AOF文件完整可用。

15【缓存雪崩和缓存穿透问题解决方案】：

缓存雪崩：

缓存同一时间大面积的失效，所以，后面的请求都会落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决办法：

• 事前：尽量保证整个 redis 集群的高可用性，发现机器宕机尽快补上。选择合适的内存淘汰策略。
• 事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL崩掉

• 事后：利用 redis 持久化机制保存的数据尽快恢复缓存

  
  
  缓存雪崩

缓存穿透：

简介：一般是黑客故意去请求缓存中不存在的数据，导致所有的请求都落到数据库上，造成数据库短时间内承受大量请求而崩掉。

解决办法： 有很多种方法可以有效地解决缓存穿透问题，最常见的则是采用布隆过滤器，将所有可能存在的数据哈希到一个足够大的bitmap中，一个一定不存在的数据会被 这个bitmap拦截掉，从而避免了对底层存储系统的查询压力。另外也有一个更为简单粗暴的方法（我们采用的就是这种），如果一个查询返回的数据为空（不管是数 据不存在，还是系统故障），我们仍然把这个空结果进行缓存，但它的过期时间会很短，最长不超过五分钟。

嘀嘀嘀——参考链接

16【redis配置（redis.conf）简介】：

redis配置文件被分成了几大块区域，它们分别是：

1. 通用（general）
2. 快照（snapshotting）
3. 复制（replication）
4. 安全（security）
5. 限制（limits)
6. 追加模式（append only mode)
7. LUA脚本（lua scripting)
8. 慢日志（slow log)
9. 事件通知（event notification）

默认情况下，redis并不是以daemon形式来运行的。
通过daemonize配置项可以控制redis的运行形式，如果改为yes，那么redis就会以daemon形式运行。

daemonize no

当以daemon形式运行时，redis会生成一个pid文件，默认会生成在/var/run/redis.pid。
当然，你可以通过pidfile来指定pid文件生成的位置，比如：
pidfile /path/to/redis.pid

默认情况下，redis会响应本机所有可用网卡的连接请求。当然，redis允许你通过bind配置项来指定要绑定的IP，比如：

bind 192.168.1.2 10.8.4.2
注释掉，代表全部可连

redis的默认服务端口是6379，你可以通过port配置项来修改。如果端口设置为0的话，redis便不会监听端口了。如下:

port 6379

当一个redis-client一直没有请求发向server端，那么server端有权主动关闭这个连接，可以通过timeout来设置“空闲超时时限”，0表示永不关闭。

timeout 0

TCP连接保活策略，可以通过tcp-keepalive配置项来进行设置，单位为秒，假如设置为60秒，则server端会每60秒向连接空闲的客户端发起一次ACK请求，以检查客户端是否已经挂掉，对于无响应的客户端则会关闭其连接。所以关闭一个连接最长需要120秒的时间。如果设置为0，则不会进行保活检测。

tcp-keepalive 0

redis支持通过loglevel配置项设置日志等级，共分四级，即debug、verbose、notice、warning。

loglevel notice

redis也支持通过logfile配置项来设置日志文件的生成位置。如果设置为空字符串，则redis会将日志输出到标准输出。假如你在daemon情况下将日志设置为输出到标准输出，则日志会被写到/dev/null中。

logfile ""

快照，主要涉及的是redis的RDB持久化相关的配置，我们来一起看一看。

我们可以用如下的指令来让数据保存到磁盘上，即控制RDB快照功能：

复制代码代码如下:

save <seconds> <changes>


save 900 1 //表示每15分钟且至少有1个key改变，就触发一次持久化
save 300 10 //表示每5分钟且至少有10个key改变，就触发一次持久化

save 60 10000 //表示每60秒至少有10000个key改变，就触发一次持久化

如果你想禁用RDB持久化的策略，只要不设置任何save指令就可以，或者给save传入一个空字符串参数也可以达到相同效果，就像这样：

save ""

如果用户开启了RDB快照功能，那么在redis持久化数据到磁盘时如果出现失败，默认情况下，redis会停止接受所有的写请求。这样做的好处在于可以让用户很明确的知道内存中的数据和磁盘上的数据已经存在不一致了。如果redis不顾这种不一致，一意孤行的继续接收写请求，就可能会引起一些灾难性的后果。
如果下一次RDB持久化成功，redis会自动恢复接受写请求。

默认情况下为10000个客户端。当你无法设置进程文件句柄限制时，redis会设置为当前的文件句柄限制值减去32，因为redis会为自身内部处理逻辑留一些句柄出来。

如果达到了此限制，redis则会拒绝新的连接请求，并且向这些连接请求方发出“max number of clients reached”以作回应。

maxclients 10000

我们甚至可以设置redis可以使用的内存量。一旦到达内存使用上限，redis将会试图移除内部数据，移除规则可以通过maxmemory-policy来指定。

对于内存移除规则来说，redis提供了多达6种的移除规则。他们是：

1. volatile-lru：使用LRU算法移除过期集合中的key
2. allkeys-lru：使用LRU算法移除key
3. volatile-random：在过期集合中移除随机的key
4. allkeys-random：移除随机的key
5. volatile-ttl：移除那些TTL值最小的key，即那些最近才过期的key。
6. noeviction：不进行移除。针对写操作，只是返回错误信息。

无论使用上述哪一种移除规则，如果没有合适的key可以移除的话，redis都会针对写请求返回错误信息。

maxmemory-policy volatile-lru

17【看懂redis配置 – 慢日志】：

redis慢日志是指一个系统进行日志查询超过了指定的时长。这个时长不包括IO操作，比如与客户端的交互、发送响应内容等，而仅包括实际执行查询命令的时间。

针对慢日志，你可以设置两个参数，一个是执行时长，单位是微秒，另一个是慢日志的长度。当一个新的命令被写入日志时，最老的一条会从命令日志队列中被移除。

单位是微秒，即1000000表示一秒。负数则会禁用慢日志功能，而0则表示强制记录每一个命令。

slowlog-log-slower-than 10000

慢日志最大长度，可以随便填写数值，没有上限，但要注意它会消耗内存。你可以使用SLOWLOG RESET来重设这个值。

slowlog-max-len 128

Redis好用链接：

• Redis集群创建链接
• Redis主从配置
• Redis之在Linux上安装和简单的使用
• Redis可视化工具Redis Desktop Manager >官网下载
  百度网盘下载