redis基础

redis及应用场景

Redis是使用c语言开发的一个高性能键值数据库，可以通过一些键值类型来存储数据。典型应用是内容缓存，主要用于处理大量数据的高访问负载。

• 缓存（数据查询、短连接、新闻内容、商品内容等等）。
• 分布式集群架构中的session分离。
• 聊天室的在线好友列表。
• 任务队列。（秒杀、抢购、12306等等）
• 应用排行榜。
• 网站访问统计。
• 数据过期处理（可以精确到毫秒）

redis数据类型

• Redis是使用c语言开发的一个高性能键值数据库，可以通过一些键值类型来存储数据。每个对象结构都包含类型字段、编码字段、指向底层数据结构的指针，因此redis可以根据不同的使用场景来为一个对象设置不同的编码字段，从而优化这个对象在不同场景下的效率，redis五种对象类型如下：

• string字符串类型（字符串对象底层数据结构描述：若用string保存整数值，编码字段就设置为int；若保存字符串长度小于等于39字节，就用embstr编码的简单动态字符串来保存；若大于39字节就用简单动态字符串保存。商品编号、订单号采用string的递增数字特性生成。）

  • 赋值 SET key value
  • 取值 GET key
  • 删除值DEL key
  • 递增键值 INCR key
  • 递减键值 DECR key 会返回递增后的值

• list列表类型（列表对象底层数据结构描述：保存的所有字符串元素都小于64字节 && 元素数量小于512就使用压缩列表ziplist否则就使用双端链表linkedlist。应用在商品评论列表）

  • 从左边/右边添加值 LPUSH key value/RPUSH key value
  • 获取列表中的某一片段 LRANGE key start stop（“-1”代表最后边的一个元素）

• map哈希类型（哈希对象底层结构描述：保存的所有键值对的键和值的字符串长度都小于64字节 && 键值对数量小于512个就使用压缩列表ziplist否则就使用字典hashtable。如下图 应用在存储商品信息等）

  • 赋值 HSET key field value
  • 取值 HGET key field
  • 删除值 HDEL key field 返回值是被删除的字段个数
  • 增加字段值 HINCRBY key field increment
    

• set集合类型（集合对象底层数据结构：保存的所有元素都是整数值 && 元素数量不超过512个就使用整数集合intset否则就使用字典hashtable）

  • 赋值 SADD key member
  • 取值 SMEMBERS key（获得集合中的所有元素）
  • 删除值 SREM key member
  • 判断元素是否在集合中 SISMEMBER key member

• sortedset(zset)有序集合类型（有序集合对象底层数据结构：保存的所有元素的成员的长度都小于64字节 && 元素数量小于128个就使用压缩列表ziplist否则就使用skiplist（同时保存了跳跃表与字典，字典查询成员分值O(1)，跳跃表有序，范围查询快）。应用在商品销售量对商品进行排行显示）

  • 赋值 ZADD key score member
  • 获取元素分数 ZSCORE key member
  • 删除值 ZREM key member
  • 获取排名在某个范围元素 ZRANGE key start stop（从小到大排序）
  • 获取元素的排名 ZRANK key member（从小到大排序）

对键处理的常用命令

• keys：keys mylist*（返回满足给定pattern 的所有key）
• exists：exists age（确认一个key 是否存在）
• del： del age（删除一个key）
• rename： rename age age_new（重命名key）
• type：type mylist（这个方法可以非常简单的判断出值的类型）

redis持久化

因为redis使用缓存，数据存在内存中因此要有持久化方案。

• Rdb方式：Redis默认的方式，redis通过快照来将数据持久化到磁盘中。一旦redis非法关闭，那么会丢失最后一次持久化之后的数据。如果数据不重要，则不必要关心。如果数据不能允许丢失，那么要使用aof方式。
  在redis.conf中修改持久化快照的条件，如下：
  
  若900s更新1次数据或者300s十次或者60s10000次，三个条件满足一个就持久化。
• Aof方式：Redis默认是不使用该方式持久化的。Aof方式的持久化，是操作一次redis数据库，则将操作的记录存储到aof持久化文件中。
  开启aof方式的持久化方案只需将redis.conf中的appendonly改为yes。Aof文件存储的名称：
  
• 在使用aof和rdb方式时，如果redis重启，则数据从aof文件加载。
• 主要作为数据库缓存使用时，对数据丢失要求不是很高的情况下，一般不开启AOF 持久化，会影响性能，如果数据不能允许丢失，那么要使用aof方式。
• aof文件重写机制：Redis服务器可以创建一个新的AOF文件来替代现有的AOF文件，新旧两个文件所保存的数据库状态是相同的，但是新的AOF文件不会包含任何浪费空间的冗余命令，通常体积会较旧AOF文件小很多，整个重写过程基本上不影响Redis主进程处理命令请求，可以由用户手动触发，也可以由服务器自动触发。

淘汰策略

redis淘汰策略：当内存不足时，Redis会根据配置的缓存策略淘汰部分keys，以保证写入成功。当无淘汰策略时或没有找到适合淘汰的key时，Redis直接返回out of memory错误。

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

2、volatile-ttl：从已设置过期时间的数据集（server.db[i].expires）中挑选剩余时间最少的数据淘汰

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

4、allkeys-lru：从数据集（server.db[i].dict）中挑选最近最少使用的数据淘汰

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

6、no-enviction：不淘汰策略，返回错误信息

注：Redis4.0加入了LFU(least frequency use)淘汰策略，包括volatile-lfu和allkeys-lfu，通过统计访问频率，将访问频率最少，即最不经常使用的KV淘汰。

redis为什么快

• 单线程的reids，redis核心就是如果我的数据全都在内存里，我单线程的去操作就是效率最高的，为什么呢，因为多线程的本质就是CPU模拟出来多个线程的情况，这种模拟出来的情况就有一个代价，就是上下文的切换，对于一个内存的系统来说，它没有上下文的切换就是效率最高的。redis用单个CPU绑定一块内存的数据，然后针对这块内存的数据进行多次读写的时候，都是在一个CPU上完成的，所以它是单线程处理这个事；
• 多路 I/O 复用模型，利用select、poll、epoll可以同时监察多个流的 I/O 事件的能力，在空闲的时候，会把当前线程阻塞掉，当有一个或多个流有I/O事件时，就从阻塞态中唤醒，于是程序就会轮询一遍所有的流（epoll是只轮询那些真正发出了事件的流），并且只依次顺序的处理就绪的流，这种做法就避免了大量的无用操作。这里“多路”指的是多个网络连接，“复用”指的是复用同一个线程。采用多路 I/O 复用技术可以让单个线程高效的处理多个连接请求（尽量减少网络IO的时间消耗）；
• 数据结构简单，对数据操作也简单。

主从结构

• 使用主从架构，实现读写分离，主节点负责写，并将数据同步给其他从节点，从节点负责读；
• 使用主从复制，持久化保证了即使redis服务重启也不会丢失数据，因为redis服务重启后会将硬盘上持久化的数据恢复到内存中，但是当redis服务器的硬盘损坏了可能会导致数据丢失，如果通过redis的主从复制机制就可以避免这种单点故障，实现高可用；
• 主redis中的数据和从redis上的数据保持实时同步，当主redis写入数据时通过主从复制机制会复制到从redis服务上；
• 主从复制不会阻塞master，在同步数据时，master 可以继续处理client 请求；
• 一个redis可以即是主又是从。

#设置为 127.0.0.1 6379 的从节点
# slaveof <masterip> <masterport>
slaveof 127.0.0.1 6379

哨兵结构

集群结构

(1)所有的redis节点彼此互联(PING-PONG机制)，内部使用二进制协议优化传输速度和带宽；
(2)在集群结构中客户端与redis节点直连即可，不需要中间proxy层，客户端不需要连接集群所有节点，连接集群中任何一个可用节点即可。
(3)redis-cluster把所有的物理节点映射到[0-16383]slot（槽）上，当需要在 Redis 集群中放置一个 key-value 时，redis 先对key使用 crc16 算法算出一个结果，然后把结果对 16384 求余数，这样每个 key 都会对应一个编号在 0-16383 之间的哈希槽，redis 会根据节点数量大致均等的将哈希槽映射到不同的节点。
(4) redis-cluster投票容错机制

• 集群中所有master参与投票，如果半数以上master节点与其中一个master节点通信超过(cluster-node-timeout)，认为该master节点挂掉；
• 什么时候整个集群不可用(cluster_state:fail)? 如果集群任意master挂掉,且当前master没有slave，则集群进入fail状态。也可以理解成集群的[0-16383]slot映射不完全时进入fail状态。如果集群超过半数以上master挂掉，无论是否有slave，集群进入fail状态。

数据为什么要序列化

• 核心在于跨平台存储与网络传输；
• 序列化方式有很多种，json、xml 以及 bson、protobuf 都是常用的序列化手段，前面两个是基于文本的，后面两个是基于二进制的。无论是文本格式还是二进制格式，存储的都是二进制。

zset实现延迟队列

参考：https://my.oschina.net/u/3266761/blog/1930360
用score表示将来任务执行时间的时间戳，在某个时间将它插入Zset集合中，它便会按照时间戳大小进行排序，也就是对执行时间前后进行排序，这样的话，起一个死循环线程不断地进行取第一个key值，如果当前时间戳大于等于该key值的socre就将它取出来进行消费删除，就可以达到延时执行的目的, 不需要遍历整个Zset集合，以免造成性能浪费

redission的分布式锁

• web系统一个请求只能打到一个tomcat容器中，分布式环境下，每个实例都对应一个tomcat，我们常用的多线程的锁是单个JVM级别的，分布式环境下会有并发问题，因此需要分布式锁；
• 核心思路：redis的 SETNX 是『SET if Not eXists』如果不存在，则 SET返回 1，否则返回 0，利用返回值就可以加分布式锁啦。

   /**
     * 分布式锁例子，基于redis，redis单线程，底层类似nio，分布式情况下，只有一个线程能访问到redis
     * redis的 SETNX 是『SET if Not eXists』(如果不存在，则 SET)，设置成功，返回 1 。设置失败，返回 0 。利用其返回值加锁
     * @return
     */
    @GetMapping("/redissionLock")
    public String redissionLock(){

        //加锁
        RBucket<String> bucket = redissonClient.getBucket("lock");
        boolean lock = bucket.trySet("yanyingnan");
        if(!lock){
            return "分布式争抢中，请稍等！";
        }

        if(number > 0){
            number --;
            System.out.println("number-- 成功" + number);
        } else {
            System.out.println("number 已经是0啦" + number);
        }

        //释放锁
        bucket.delete();


        return "testRedissionLock";
    }


    /**
     * 分布式锁例子（优化1），基于redis，redis单线程，底层类似nio，分布式情况下，只有一个线程能访问到redis
     * 1、finally中保证一定要释放锁，避免死锁
     * 2、加上过期时间，避免死锁
     * @param map
     * @return
     */
    @GetMapping("/redissionLock")
    public String redissionLock(){

        RBucket<String> bucket = redissonClient.getBucket("lock");
        try {
            //加锁
            boolean lock = bucket.trySet("yanyingnan", 10, TimeUnit.SECONDS);
            if(!lock){
                return "分布式争抢中，请稍等！";
            }

            if(number > 0){
                number --;
                System.out.println("number-- 成功" + number);
            } else {
                System.out.println("number 已经是0啦" + number);
            }

        } finally {
            //释放锁
            bucket.delete();
        }


        return "testRedissionLock";
    }


    /**
     * 分布式锁例子（优化2），基于redis，redis单线程，底层类似nio，分布式情况下，只有一个线程能访问到redis
     * 1、每一个线程的锁的值为随机生成的uuid 防止一个线程没执行完，过期时间到了自动解锁了，另一个线程加锁进入后，第一个线程释放了另一个线程的锁
     * @param map
     * @return
     */
    @GetMapping("/redissionLock")
    public String redissionLock(){

        RBucket<String> bucket = redissonClient.getBucket("lock");
        String uuid = UUID.randomUUID().toString();
        try {
            //加锁
            boolean lock = bucket.trySet("uuid", 10, TimeUnit.SECONDS);
            if(!lock){
                return "分布式争抢中，请稍等！";
            }

            if(number > 0){
                number --;
                System.out.println("number-- 成功" + number);
            } else {
                System.out.println("number 已经是0啦" + number);
            }

        } finally {
            //先确定是自己的锁，释放锁
            if(uuid.equals(bucket.get()))
            bucket.delete();
        }


        return "testRedissionLock";
    }

    /**
     * 分布式锁例子（优化3），基于redis，redis单线程，底层类似nio，分布式情况下，只有一个线程能访问到redis
     * 1、为了防止线程没执行完就自动释放锁了，当前线程开启一个新线程，定时判断当前的锁是否释放了，如果没有就将过期时间还设置为原来的值，定时时间是过期时间的1/3
     * 这也就是redission的底层原理
     * @return
     */
    @GetMapping("/redissionLock")
    public String redissionLock(){

        RLock lock = redissonClient.getLock("lock");
        try {
            //加锁
            lock.lock(10, TimeUnit.SECONDS);

            if(number > 0){
                number --;
                System.out.println("number-- 成功" + number);
            } else {
                System.out.println("number 已经是0啦" + number);
            }

        } finally {
            lock.unlock();
        }


        return "testRedissionLock";
    }