1.redis特性(为什么使用redis)：数据存在内存中;单线程;多路复用;协议简单(rtsp)
2.redis支持10W+/s的处理数据量
3.5种数据结构:string list hash set zset
key都是字符串,value是上述5种结构。
hash: 存对象，如 hset user:1(key) id xxx name xxx .....(value) 其中，vaule最大存512M。
value是序列化的对象
zset:有序集合
setnx关键字:相当于if。。。else....判断，如果redis中存在key值，则不插入数据，如果不存在key，则插入key的值
4.redis默认16个库，但是集群中的每个节点，就只有一个库了。集群不用16个库。
5.redis雪崩:当内存中的一个key过期后，此时，大量的客户端访问到这个key，内存中没有这个key，都去数据库里查询，造成了数据库压力过大。称为redis雪崩。解决方案：在代码块中加锁，大量客户端访问key时，通过锁机制限制访问代码块的先后，第一个抢到锁的去查询数据库，其他的直接从内存中获取值。
6.redis穿透:当查询一个随便乱输入的，没有存储的key时，程序会一直查询数据库，给数据库造成压力。解决方案是将数据库中存入缓存的数据放入布隆过滤器中，先在过滤器中查找是否有该条数据，如果有，再从数据库里查询，然后放入缓存中，如果没有，则不会查询数据库。布隆过滤器有自己的算法，性能好。不用考虑这个耗费时间和性能。
7.redis持久化：
rdb:定时持久化，不适合实时持久化，低版本的rdb文件转向高版本可能存在不兼容的现象。
aof:实时保存，里面存的都是命令语句
8.redis的key和value都占内存大小,
key的设计原则：功能模块，表名或业务模块命名，要短。
String类型应用场景：1.做计数，如文章的浏览次数等。利用incr特性做增加
(tomcat一秒支持500个访问数的并发)
实战:redis支持10W+/s的并发量，但是为了降低redis压力，一般redis往tomcat返回值时，进行批量返回，tomcat用完批量的值之后，再去redis中取值，来降低reids访问压力。利用的也是redis的incr特性进行的操作。
9.redis实现分布式锁要点：
用setnx命令，如果key存在，则报错，如果不存在，则插入，以此来对公共资源(key)进行锁机制同步;
设置key的过期时间，防止设置key的程序挂了之后，redis中的key无法删除，造成死锁现象；
每个线程生成一个uuid，当value存入redis中，以便于解锁时找到哪个现场抢到的锁。
解锁时，用lua脚本进行解锁，删除key值的操作。因为lua脚本是原子性的，要么全部成功，要么全部失败，以此来避免删除了key值，但是redis挂掉了，给服务返回了删除失败的情况，这种情况下，服务以为锁还没释放，其实key已经删除了，就有问题了。
10.redis中Set集合可以进行交集，并集，差集等的计算，利用此特性，可以实现一些需求，如微博的微关系等业务。
11.jedis查询redis时，也可以进行分页查询。
12.lua脚本:类似于存储过程，在redis中执行，返回结果,具有原子性，
13.限流:
限制总并发数，说白了性能优化不了了，就进行限流
14.redis高可用:
主从模式:一主一从,主的挂了，从的不能自动成为主的，一般不用
哨兵模式:一个主两个从，自动切换为主的，
6台redis服务器:3主3从，key通过hash值计算，放入redis不同的主节点中，主节点挂了，从节点自动切换。至少两个以上的节点任务主节点挂了，才会进行节点转移