百度百科 - Redis
征服Redis (JAVAEye)
Redis 的安装配置介绍
java使用redis简单说明
[ri' des] 瑞戴斯
Redis是一种高级key-value数据库。它跟memcached类似，不过数据可以持久化，而且支持的数据类型很丰富。有字符串，链表，集 合和有序集合。支持在服务器端计算集合的并，交和补集(difference)等，还支持多种排序功能。所以Redis也可以被看成是一个数据结构服务 器。
Redis的所有数据都是保存在内存中，然后不定期的通过异步方式保存到磁盘上(这称为“半持久化模式”)；也可以把每一次数据变化都写入到一个append only file(aof)里面(这称为“全持久化模式”)。
Redis与Memcached的比较
使用Memcached，让我感触颇深的是Object Size的问题，由于SQL未作优化直接映射对象，导致缓存对象大于1MB，Memcached就抛了异常。而Redis默认缓存对象512MB，最大支持1GB。至少在缓存对象时，可以有更大的伸缩空间了！ 此外，是数据类型。Memcached比较简单，而Redis可以支持更多复杂的数据类型，如HASH、SET、SortedSet等等。
没有必要过多的关心性能，因为二者的性能都已经足够高了。由于Redis只使用单核，而Memcached可以使用多核，所以在比较上，平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。说了这么多，结论是，无论你使用哪一个，每秒处理请求的次数都不会成为瓶颈。（比如瓶颈可能会在网卡）
如果要说内存使用效率，使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。当然，这和你的应用场景和数据特性有关。
如果你对数据持久化和数据同步有所要求，那么推荐你选择Redis，因为这两个特性Memcached都不具备。即使你只是希望在升级或者重启系统后缓存数据不会丢失，选择Redis也是明智的。
当然，最后还得说到你的具体应用需求。Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果你需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
问题：
1、使用 redis 还需要 数据库吗
要啊，内存容量太小了，而且一断电不就丢数据了，还有redis不支持复杂的查询。
2、redis 有数据库表的概念吗?
我$redis->set("tet","abcd");的时候，如果后期有人修改网站，也不知道我是用了什么key。那他也redis->set("test",'1234')。那怎么办？
另外这个redis有表的概念吗？在设计网站的时候，要有会员表啦，产品表什么的，这个有吗？
redis就是kv存储，没有数据库表的概念，你写的东西一定要设置时限，或者写好文档，如果你走了，后期没人维护，非常浪费资源。还有就是redis是存内存的，非常快速但是昂贵，建议你用redis存储时先算一下数据量，看看你内存能不能装下，需要几台机器，几台备份机，服务器一旦重启数据全无，使用时小心
3、如何使用redis做mysql的缓存
应用Redis实现数据的读写，同时利用队列处理器定时将数据写入mysql。
同时要注意避免冲突，在redis启动时去mysql读取所有表键值存入redis中，往redis写数据时，对redis主键自增并进行读取，若mysql更新失败，则需要及时清除缓存及同步redis主键。
这样处理，主要是实时读写redis，而mysql数据则通过队列异步处理，缓解mysql压力，不过这种方法应用场景主要基于高并发，而且redis的高可用集群架构相对更复杂，一般不是很推荐。
===============================================================================
10个常见的Redis面试“刁难”问题
Redis有哪些数据结构？
字符串String、字典Hash、列表List、集合Set、有序集合SortedSet。
如果你是Redis中高级用户，还需要加上下面几种数据结构HyperLogLog、Geo、Pub/Sub。
如果你说还玩过Redis Module，像BloomFilter，RedisSearch，Redis-ML，面试官得眼睛就开始发亮了。
使用过Redis分布式锁么，它是什么回事？
先拿setnx来争抢锁，抢到之后，再用expire给锁加一个过期时间防止锁忘记了释放。
这时候对方会告诉你说你回答得不错，然后接着问如果在setnx之后执行expire之前进程意外crash或者要重启维护了，那会怎么样？
这时候你要给予惊讶的反馈：唉，是喔，这个锁就永远得不到释放了。紧接着你需要抓一抓自己得脑袋，故作思考片刻，好像接下来的结果是你主动思考出来的，然后回答：我记得set指令有非常复杂的参数，这个应该是可以同时把setnx和expire合成一条指令来用的！对方这时会显露笑容，心里开始默念：摁，这小子还不错。
假如Redis里面有1亿个key，其中有10w个key是以某个固定的已知的前缀开头的，如果将它们全部找出来？
使用keys指令可以扫出指定模式的key列表。
对方接着追问：如果这个redis正在给线上的业务提供服务，那使用keys指令会有什么问题？
这个时候你要回答redis关键的一个特性：redis的单线程的。keys指令会导致线程阻塞一段时间，线上服务会停顿，直到指令执行完毕，服务才能恢复。这个时候可以使用scan指令，scan指令可以无阻塞的提取出指定模式的key列表，但是会有一定的重复概率，在客户端做一次去重就可以了，但是整体所花费的时间会比直接用keys指令长。
使用过Redis做异步队列么，你是怎么用的？
一般使用list结构作为队列，rpush生产消息，lpop消费消息。当lpop没有消息的时候，要适当sleep一会再重试。
如果对方追问可不可以不用sleep呢？list还有个指令叫blpop，在没有消息的时候，它会阻塞住直到消息到来。
如果对方追问能不能生产一次消费多次呢？使用pub/sub主题订阅者模式，可以实现1:N的消息队列。
如果对方追问pub/sub有什么缺点？在消费者下线的情况下，生产的消息会丢失，得使用专业的消息队列如rabbitmq等。
如果对方追问redis如何实现延时队列？我估计现在你很想把面试官一棒打死如果你手上有一根棒球棍的话，怎么问的这么详细。但是你很克制，然后神态自若的回答道：使用sortedset，拿时间戳作为score，消息内容作为key调用zadd来生产消息，消费者用zrangebyscore指令获取N秒之前的数据轮询进行处理。
到这里，面试官暗地里已经对你竖起了大拇指。但是他不知道的是此刻你却竖起了中指，在椅子背后。
如果有大量的key需要设置同一时间过期，一般需要注意什么？
如果大量的key过期时间设置的过于集中，到过期的那个时间点，redis可能会出现短暂的卡顿现象。一般需要在时间上加一个随机值，使得过期时间分散一些。
Redis如何做持久化的？
bgsave做镜像全量持久化，aof做增量持久化。因为bgsave会耗费较长时间，不够实时，在停机的时候会导致大量丢失数据，所以需要aof来配合使用。在redis实例重启时，优先使用aof来恢复内存的状态，如果没有aof日志，就会使用rdb文件来恢复。
如果再问aof文件过大恢复时间过长怎么办？你告诉面试官，Redis会定期做aof重写，压缩aof文件日志大小。如果面试官不够满意，再拿出杀手锏答案，Redis4.0之后有了混合持久化的功能，将bgsave的全量和aof的增量做了融合处理，这样既保证了恢复的效率又兼顾了数据的安全性。这个功能甚至很多面试官都不知道，他们肯定会对你刮目相看。
如果对方追问那如果突然机器掉电会怎样？
取决于aof日志sync属性的配置，如果不要求性能，在每条写指令时都sync一下磁盘，就不会丢失数据。但是在高性能的要求下每次都sync是不现实的，一般都使用定时sync，比如1s1次，这个时候最多就会丢失1s的数据。
Pipeline有什么好处，为什么要用pipeline？
可以将多次IO往返的时间缩减为一次，前提是pipeline执行的指令之间没有因果相关性。使用redis-benchmark进行压测的时候可以发现影响redis的QPS峰值的一个重要因素是pipeline批次指令的数目。
Redis的同步机制了解么？
Redis可以使用主从同步，从从同步。第一次同步时，主节点做一次bgsave，并同时将后续修改操作记录到内存buffer，待完成后将rdb文件全量同步到复制节点，复制节点接受完成后将rdb镜像加载到内存。加载完成后，再通知主节点将期间修改的操作记录同步到复制节点进行重放就完成了同步过程。
是否使用过Redis集群，集群的原理是什么？
Redis Sentinal着眼于高可用，在master宕机时会自动将slave提升为master，继续提供服务。
Redis Cluster着眼于扩展性，在单个redis内存不足时，使用Cluster进行分片存储。
=================================================================================
一、为什么使用
解决应用服务器的cpu和内存压力
减少io的读操作，减轻io的压力
关系型数据库的扩展性不强，难以改变表结构
二、优点：
nosql数据库没有关联关系，数据结构简单，拓展表比较容易
nosql读取速度快，对较大数据处理快
三、适用场景：
数据高并发的读写
海量数据的读写
对扩展性要求高的数据
四、不适场景：
需要事务支持（非关系型数据库）
基于sql结构化查询储存，关系复杂
五、Redis结构：
Redis是一个开源的key—value型数据库，支持string、list、set、zset(有序集合)和hash类型数据。对这些数据的操作都是原子性的，redus为了保证效率会定期持久化数据。
六、使用场景：
配合关系型数据库做高速缓存
缓存高频次访问的数据，降低数据库io
分布式架构，做session共享
可以持久化特定数据。
利用zset类型可以存储排行榜
利用list的自然时间排序存储最新n个数据
七、Linux下redis：
redis目录：usr/local/bin
linux下redis常用命令：
redis-benchmark：性能测试工具
redis-server：启动redis服务器
redis-cli：启动redis客户端，操作入口
八、Redis基础知识
端口：6379
默认16个数据库，下标从0开始
单线程：redis是单线程+io多路复用：检查文件描述的就绪状态
redis数据类型：String set list hash zset
Memchached：多线程+锁
九、Redis命令：
key操作
keys *查看当前库所有的键
exists
del
expire
ttl
move
dbsize查看数据库key的数量
flushdb清空当前库
flushall通杀所有库
String类型：String是二进制安全的，可以包含任何数据源，最大512m
get
set
append
strlen < key >获取值得长度
setnx
incr
decr
incrby/decrby
String批量处理：
mset
mget
msetnx
getrange
setrange
setex
getset
List：链表
1、特点：
单键多值
Redis列表是简单的字符串列表，从左或者从右插入
底层是双向链表，对两端的操作性能很高，通过下标查询性能很低
lpush/rpush
lpop/rpop
rpoplpush
lrange
lindex
llen
linsert
Set：类似list的无序集合，保证列表中不会有重复数据，底层是一个value为null的hash表
sadd
smembers
sismember
scard
srem
spop
srandmember
smove
sinter
sunion
hash：键值对集合，类似map
hset
hget
hmset
hexists
hkeys
hvals
zset：与set集合非常相似，每个成员都关联了score，可以用来排序
zadd
zrange
zrangebyscore
zrevrangerbyscore
zincrby
zrem
zcount
zcord
zrank
十一、Redis事务：
输入multi，输入的命令都会依次进入到队列中，但不会执行，直到输入exec，redis会将之前命令队列中的命令依次执行，通过discard可以放弃组队。
主要作用：序列化操作，串联多个命令防止别的命令插队
悲观锁：每次拿到数据的时候都会上锁，或者等待别人处理完再去拿锁，传统的关系型数据库里边很多用到了这种锁机制，比如行锁、表锁、读锁、写锁
乐观锁：每次拿数据的时候总认为别人不会修改数据，所以不会上锁。但是更新的时候回去判断别人有没有更改数据，使用版本号机制。乐观锁适用于多读的应用类型，可以提高吞吐量。
Redis使用乐观锁：redis就是利用check-and-set机制实现事务
三大特性：
单独的隔离操作：事务中的所有命令都会序列化，按顺序执行。不会被其他客户端打断
没有隔离级别概念：队列中的命令没有提交之前不会被执行，事务外不能查看事务内的更新
不能保证原子性：跳过错误，依旧执行，没有回滚
十二、Redis订阅/发布：
是进程中的一种消息通信模式，发送者pub发送消息，订阅者sub接收消息 剩下的略。。。
十三、Redis主从复制：
是什么：主从复制就是主机数据更新后根据配置和策略，自动同步到备份机的master/slaver机制，master写为主，slave读为主
用处：
读写分离，性能拓展。
容灾快速恢复
配置服务器（配从不配主）：
拷贝多个redis.conf文件
开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字
Appendonly 关掉或者换名字
十四、Jedis：
所需jar包：
common-pool-1.6jar包
jedis-2.1
获取jedis对象：Jedis jedis = new Jedis（“ip” ，端口号）；
十五、集群分布：
实现对redis的水平拓展，启动n’的redis节点，将整个数据分布在这n个节点中
配置conf文件：
拷贝多个redis.conf文件
开启daemonize yes
Pid文件名字
指定端口
Log文件名字
Dump.rdb名字
Appendonly 关掉或者换名字
配置cluster文件：
cluster-enable yes 打开集群模式
cluster-config-file xxx.conf 设置生成的节点配置文件名
cluster-node-timeout 15000设置节点失联时间，超多该时间（毫秒），集群自动进入主从切换
====================================================================================
Redis过期键的删除策略
对于过期键一般有三种删除策略
https://www.cnblogs.com/lukexwang/p/4694094.html
定时删除：在设置键的过期时间的同时，创建一个定时器(timer)，让定时器在键的过期时间来临时，立即执行对键的删除操作；
惰性删除：放任键过期不管，但是每次从键空间中获取键时，都检查取得的键是否过期，如果过期的话，就删除该键；如果没有过期，那就返回该键；
定期删除：每隔一段时间，程序就对数据库进行一次检查，删除里面的过期键。至于删除多少过期键，以及要检查多少个数据库，则由算法决定。
下面我们来看看三种策略的优缺比较：
定时删除策略对内存是最友好的：
通过使用定时器，定时删除策略可以保证过期键会尽可能快地被删除，并释放过期键所占用的内存；但另一方面，定时删除策略的缺点是，他对CPU是最不友好的：在过期键比较多的情况下，删除过期键这一行为可能会占用相当一部分CPU时间，在内存不紧张但是CPU时间非常紧张的情况下，将CPU时间用在删除和当前任务无关的过期键上，无疑会对服务器的响应时间和吞吐量造成影响；
惰性删除策略对CPU时间来说是最友好的：
程序只会在取出键时才对键进行过期检查，这可以保证删除过期键的操作只会在非做不可的情况下进行；惰性删除策略的缺点是，它对内存是最不友好的：如果一个键已经过期，而这个键又仍然保留在数据库中，那么只要这个过期键不被删除，它所占用的内存就不会释放；
定时删除占用太多CPU时间，影响服务器的响应时间和吞吐量；
惰性删除浪费太多内存，有内存泄漏的危险。
定期删除策略是前两种策略的一种整合和折中：定期删除策略每隔一段时间执行一次删除过期键操作，并通过限制删除操作执行的时长和频率来减少删除操作对CPU时间的影响；通过定期删除过期键，定期删除策略有效地减少了因为过期键而带来的内存浪费；定期删除策略的难点是确定删除操作执行的时长和频率。
Redis的过期键删除策略：Redis服务器实际使用的是惰性删除和定期删除两种策略。
