Java工程师进阶：深入了解redis

为什么使用缓存？
    高并发：缓存单机承载并发量是mysql单机的几十倍。
    高性能：复杂操作耗时查出来的结果，如果确定后面不经常变动，但是还有很多读请求，那么直接结果放缓存，后面直接读缓存。

常见的缓存问题
    缓存一致性问题
    缓存雪崩
    缓存穿透
    缓存并发竞争

redis和memcached有什么区别？
    1）Redis支持服务器端的数据操作：Redis相比Memcached来说，拥有更多的数据结构和并支持更丰富的数据操作，通常在Memcached里，你需要将数据拿到客户端来进行类似的修改再set回去。这大大增加了网络IO的次数和数据体积。在Redis中，这些复杂的操作通常和一般的GET/SET一样高效。所以，如果需要缓存能够支持更复杂的结构和操作，那么Redis会是不错的选择。
    2）内存使用效率对比：使用简单的key-value存储的话，Memcached的内存利用率更高，而如果Redis采用hash结构来做key-value存储，由于其组合式的压缩，其内存利用率会高于Memcached。
    3）性能对比：由于Redis只使用单核，而Memcached可以使用多核，所以平均每一个核上Redis在存储小数据时比Memcached性能更高。而在100k以上的数据中，Memcached性能要高于Redis，虽然Redis最近也在存储大数据的性能上进行优化，但是比起Memcached，还是稍有逊色。
    4）集群模式：memcached没有原生的集群模式，需要依靠客户端来实现往集群中分片写入数据；但是redis目前是原生支持cluster模式的，redis官方就是支持redis cluster集群模式的，比memcached来说要更好

redis的缺点
    数据库容量受到物理内存的限制，不能用作海量数据的高性能读写。

redis的线程模型是什么？

为什么单线程的redis比多线程的memcached效率要高得多（为什么redis是单线程的但是还可以支撑高并发）？
    1）纯内存操作
    2）核心是基于非阻塞的IO多路复用机制
    3）单线程反而避免了多线程的频繁上下文切换问题

redis都有哪些数据类型？分别在哪些场景下使用比较合适？
    （1）string
    （2）hash
        hash类的数据结构，主要是用来存放一些结构化的数据(简单对象)，可以直接修改对象中的某个字段的值
    （3）list
        有序列表
        可以通过list存储一些列表型的数据结构，类似粉丝列表、文章的评论列表
        可以通过lrange命令，从某个元素开始读取多少个元素，基于list实现分页查询
        消息队列
    （4）set
        无序集合，自动去重
        可以基于set进行交集、并集、差集的操作，比如可以把两个人的好友列表整一个交集，看看俩人的共同好友是谁
    （5）sorted set
        排序的set，去重但是可以排序，有个分数可以自定义排序规则，比如可以用某个时间作为分数，自动按照时间排序

如何保证Redis的高并发和高可用？
    redis高并发：主从架构，一主多从，单主用来写入数据，单机几万QPS，多从用来查询数据，多个从实例可以提供每秒10万的QPS。一主多从，每个实例都容纳了完整的数据，比如redis主就10G的内存量，最多只能容纳10g的数据量。如果你的缓存要容纳的数据量很大，达到了几十g，甚至几百g，那你就需要redis集群，而且用redis集群之后，可以提供可能每秒几十万的读写并发。
    redis高可用：主从架构部署，加上哨兵就可以实现，任何一个实例宕机，自动会进行主备切换。

redis的主从复制原理能介绍一下么？

redis的哨兵原理能介绍一下么？

redis的过期策略都有哪些？
    定期删除+惰性删除
        所谓定期删除，指的是redis默认每隔100ms就随机抽取一些设置了过期时间的key，检查其是否过期，如果过期就删除。假设redis里放了10万个key，都设置了过期时间，你每隔几百毫秒，就检查10万个key，那redis基本上就死了，cpu负载会很高的，消耗在你的检查过期key上了。
        定期删除可能会导致很多过期key到了时间并没有被删除掉，所以还需要惰性删除。在你获取某个key的时候，redis会检查一下 ，这个key如果设置了过期时间那么是否过期了？如果过期了此时就会删除，不会给你返回任何东西。
        如果定期删除漏掉了很多过期key，然后也没及时去查，也就没走惰性删除，此时大量过期key堆积在内存里，会导致redis内存块耗尽。所以需要内存淘汰机制。

内存淘汰机制都有哪些？
    1）noeviction：当内存不足以容纳新写入数据时，新写入操作会报错
    2）allkeys-lru：当内存不足以容纳新写入数据时，在键空间中，移除最近最少使用的key（这个是最常用的）
    3）allkeys-random：当内存不足以容纳新写入数据时，在键空间中，随机移除某个key
    4）volatile-lru：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，移除最近最少使用的key（这个一般不太合适）
    5）volatile-random：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，随机移除某个key
    6）volatile-ttl：当内存不足以容纳新写入数据时，在设置了过期时间的键空间中，有更早过期时间的key优先移除

手写一下LRU代码实现？

redis的持久化有哪几种方式？不同的持久化机制都有什么优缺点？持久化机制具体底层是如何实现的？
    redis持久化的意义，在于故障恢复，如果没有持久化的话，redis遇到灾难性故障的时候，就会丢失所有的数据
    大量的请求过来，缓存全部无法命中，出现缓存雪崩问题，所有请求就会去mysql数据库这种数据源头中去找，mysql承接高并发，然后就挂了

1、RDB和AOF两种持久化机制的介绍
    RDB持久化机制，对redis中的数据执行周期性的持久化
    AOF机制对每条写入命令作为日志，以append-only的模式写入一个日志文件中，在redis重启的时候，可以通过回放AOF日志中的写入指令来重新构建整个数据集
    如果我们想要redis仅仅作为纯内存的缓存来用，那么可以禁止RDB和AOF所有的持久化机制
    通过RDB或AOF，都可以将redis内存中的数据给持久化到磁盘上面来，然后可以将这些数据备份到别的地方去，比如说阿里云，云服务
    如果redis挂了，服务器上的内存和磁盘上的数据都丢了，可以从云服务上拷贝回来之前的数据，放到指定的目录中，然后重新启动redis，redis就会自动根据持久化数据文件中的数据，去恢复内存中的数据，继续对外提供服务
    如果同时使用RDB和AOF两种持久化机制，那么在redis重启的时候，会使用AOF来重新构建数据，因为AOF中的数据更加完整

2、RDB持久化机制的优点
    （1）RDB会生成多个数据文件，每个数据文件都代表了某一个时刻中redis的数据，这种多个数据文件的方式，非常适合做冷备，可以将这种完整的数据文件发送到一些远程的安全存储上去，比如说Amazon的S3云服务上去，在国内可以是阿里云的ODPS分布式存储上，以预定好的备份策略来定期备份redis中的数据
    （2）RDB对redis对外提供的读写服务，影响非常小，可以让redis保持高性能，因为redis主进程只需要fork一个子进程，让子进程执行磁盘IO操作来进行RDB持久化即可
    （3）相对于AOF持久化机制来说，直接基于RDB数据文件来重启和恢复redis进程，更加快速

3、RDB持久化机制的缺点
    （1）如果想要在redis故障时，尽可能少的丢失数据，那么RDB没有AOF好。一般来说，RDB数据快照文件，都是每隔5分钟，或者更长时间生成一次，这个时候就得接受一旦redis进程宕机，那么会丢失最近5分钟的数据
    （2）RDB每次在fork子进程来执行RDB快照数据文件生成的时候，如果数据文件特别大，可能会导致对客户端提供的服务暂停数毫秒，或者甚至数秒

4、AOF持久化机制的优点
    （1）AOF可以更好的保护数据不丢失，一般AOF会每隔1秒，通过一个后台线程执行一次fsync操作，最多丢失1秒钟的数据
    （2）AOF日志文件以append-only模式写入，所以没有任何磁盘寻址的开销，写入性能非常高，而且文件不容易破损，即使文件尾部破损，也很容易修复
    （3）AOF日志文件即使过大的时候，出现后台重写操作，也不会影响客户端的读写。因为在rewrite log的时候，会对其中的指导进行压缩，创建出一份需要恢复数据的最小日志出来。再创建新日志文件的时候，老的日志文件还是照常写入。当新的merge后的日志文件ready的时候，再交换新老日志文件即可。
    （4）AOF日志文件的命令通过非常可读的方式进行记录，这个特性非常适合做灾难性的误删除的紧急恢复。比如某人不小心用flushall命令清空了所有数据，只要这个时候后台rewrite还没有发生，那么就可以立即拷贝AOF文件，将最后一条flushall命令给删了，然后再将该AOF文件放回去，就可以通过恢复机制，自动恢复所有数据

5、AOF持久化机制的缺点
    （1）对于同一份数据来说，AOF日志文件通常比RDB数据快照文件更大
    （2）AOF开启后，支持的写QPS会比RDB支持的写QPS低，因为AOF一般会配置成每秒fsync一次日志文件，当然，每秒一次fsync，性能也还是很高的
    （3）以前AOF发生过bug，就是通过AOF记录的日志，进行数据恢复的时候，没有恢复一模一样的数据出来。所以说，类似AOF这种较为复杂的基于命令日志/merge/回放的方式，比基于RDB每次持久化一份完整的数据快照文件的方式，更加脆弱一些，容易有bug。不过AOF就是为了避免rewrite过程导致的bug，因此每次rewrite并不是基于旧的指令日志进行merge的，而是基于当时内存中的数据进行指令的重新构建，这样健壮性会好很多。

6、RDB和AOF到底该如何选择
    （1）不要仅仅使用RDB，因为那样会导致你丢失很多数据
    （2）也不要仅仅使用AOF，因为那样有两个问题，第一，你通过AOF做冷备，没有RDB做冷备，来的恢复速度更快; 第二，RDB每次简单粗暴生成数据快照，更加健壮，可以避免AOF这种复杂的备份和恢复机制的bug
    （3）综合使用AOF和RDB两种持久化机制，用AOF来保证数据不丢失，作为数据恢复的第一选择; 用RDB来做不同程度的冷备，在AOF文件都丢失或损坏不可用的时候，还可以使用RDB来进行快速的数据恢复

redis集群模式的工作原理能说一下么？在集群模式下，redis的key是如何寻址的？分布式寻址都有哪些算法？了解一致性hash算法吗？

了解什么是redis的雪崩和穿透？redis崩溃之后会怎么样？系统该如何应对这种情况？如何处理redis的穿透？
    事前：redis高可用，主从+哨兵，redis cluster，避免全盘崩溃
    事中：本地ehcache缓存 + hystrix限流&降级，避免MySQL被打死
    事后：redis持久化，快速恢复缓存数据

缓存雪崩
    所有redis宕机，所有请求到数据库（抗压能力弱）

缓存穿透
    判断恶意访问：
        redis:ip记录
            redisTemplate.boundsValueOps(ip).set(count+1);
            if(redisTemplate.boundsValueOps(ip).get()==null){//第一次访问
                redisTemplate.boundsValueOps(ip).set(1);
                redisTemplate.expire(ip,60,TimeUnit.seconds);//60秒以后消失
            }else{
                int count=redisTemplate.boundsValueOps(ip).get();
                if(count>=60){
                return null;
                }
            }
        
    解决办法一：
        redisTemplate.boundsValueOps("url+paramerters").set(null/"")比较常用，暴力
    解决办法二：
        bloomFilter布隆过滤器，先查询bloomFilter,在查询redis没有，查询数据库没有，把请求路径以及参数放入bloomFilter

如何保证缓存与数据库的双写一致性？
    redis缓解数据库压力，少部分数据不一致，尽量实时同步
    一般来说，就是如果你的系统不是严格要求缓存+数据库必须一致性的话，缓存可以稍微的跟数据库偶尔有不一致的情况，最好不要做这个方案，读请求和写请求串行化，串到一个内存队列里去，这样就可以保证一定不会出现不一致的情况
    串行化之后，就会导致系统的吞吐量会大幅度的降低，用比正常情况下多几倍的机器去支撑线上的一个请求。
    
redis的并发竞争问题是什么？如何解决这个问题？了解Redis事务的CAS方案吗？

生产环境中的redis是怎么部署的？（主从架构？集群架构？用了哪种集群方案？有没有做高可用保证？有没有开启持久化机制确保可以进行数据恢复？线上redis给几个G的内存？设置了哪些参数？压测后你们redis集群承载多少QPS？）
    redis cluster，10台机器，5台机器部署了redis主实例，另外5台机器部署了redis的从实例，每个主实例挂了一个从实例，5个节点对外提供读写服务，每个节点的读写高峰qps可能可以达到每秒5万，5台机器最多是25万读写请求/s。
    机器是什么配置？32G内存+8核CPU+1T磁盘，但是分配给redis进程的是10g内存，一般线上生产环境，redis的内存尽量不要超过10g，超过10g可能会有问题。5台机器对外提供读写，一共有50g内存。
    因为每个主实例都挂了一个从实例，所以是高可用的，任何一个主实例宕机，都会自动故障迁移，redis从实例会自动变成主实例继续提供读写服务
    你往内存里写的是什么数据？每条数据的大小是多少？商品数据，每条数据是10kb。100条数据是1mb，10万条数据是1g。常驻内存的是200万条商品数据，占用内存是20g，仅仅不到总内存的50%。
    目前高峰期每秒就是3500左右的请求量

服务降级：
    双11当天不提供退款，服务关闭
    服务器提供给商品下单
限流：
    谷歌提供：令牌机制，桶机制
    
    依赖：
        <dependency>
            <groupId>com.google.guava</groupId>
            <artifactId>guava</artifactId>
            <version>22.0</version>
        </dependency>        
    demo:    @Test
    public void testxianliu()
    {
        /**
         * 创建一个限流器，设置每秒放置的令牌数：2个。速率是每秒可以2个的消息。
         * 返回的RateLimiter对象可以保证1秒内不会给超过2个令牌，并且是固定速率的放置。达到平滑输出的效果
         */
        RateLimiter rateLimiter = RateLimiter.create(2);//0.5秒释放一个，每秒处理两个请求

        while (true)
        {
            /**
             * acquire()获取一个令牌，并且返回这个获取这个令牌所需要的时间。如果桶里没有令牌则等待，直到有令牌。
             * acquire(N)可以获取多个令牌             */
             if (!rateLimiter.tryAcquire(300, TimeUnit.MILLISECONDS)) {  //未获取到
                 System.out.println("短期无法获取令牌，真不幸，排队也瞎排");                   
             }                          
            System.out.println(rateLimiter.acquire());
            System.out.println("csl is very nice");            
        }
    }

    
    实际开发：
        RateLimiter rateLimiter = RateLimiter.create(10);  //每秒处理10个请求
       
      @RequestMapping("/buy")  
    public Object miao(int count, String code) {  
        //判断能否在1秒内得到令牌，如果不能则立即返回false，不会阻塞程序  
        if (!rateLimiter.tryAcquire(1000, TimeUnit.MILLISECONDS)) {  
            System.out.println("短期无法获取令牌，真不幸，排队也瞎排");  
            return "失败";  
        }  
        if (goodInfoService.update(code, count) > 0) {  
            System.out.println("购买成功");  
            return "成功";  
        }  
        System.out.println("数据不足，失败");  
        return "失败";  
    }  
    
批量导入问题：
    get,set,add,put,members.....
    批量插入：
        原始：循环插入，每次插入一条记录，每次连接一个redis，1000
        fashion:redis提供批量操作，命令放一起发送一次请求，1