大橙子网站建设,新征程启航

为企业提供网站建设、域名注册、服务器等服务

如何进行Redis深度分析

今天就跟大家聊聊有关如何进行redis深度分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。

创新互联公司专注于惠来企业网站建设,成都响应式网站建设公司,购物商城网站建设。惠来网站建设公司,为惠来等地区提供建站服务。全流程按需制作网站,专业设计,全程项目跟踪,创新互联公司专业和态度为您提供的服务

0、基础:万丈高楼平地起

1) 当字符串长度小于1M时,扩容都是加倍现有的空间,如果超过1M,扩容时一次只会多扩1M的空间。需要注意的是字符串最大长度为512M。

2) 如果value值是一个整数,还可以对它进行自增操作。自增是有范围的,它的范围是signed long的最大最小值,超过了这个值,Redis会
报错,最大值 9223372036854775807
    
3) Redis的列表相当于Java语言里面的LinkedList,注意它是链表而不是数组。Redis的列表结构常用来做异步队列使用。将需要延后处理
的任务结构体序列化成字符串塞进Redis的列表,另一个线程从这个列表中轮询数据进行处理。
   右边进左边出--> 队列
   右边进右边出--> 栈
   
   如果再深入一点,你会发现 Redis 底层存储的还不是一个简单的linkedlist,而是称之为快速链表quicklist的一个结构。首先在列表
元素较少的情况下会使用一块连续的内存存储,这个结构是ziplist,也即是压缩列表。它将所有的元素紧挨着一起存储,分配的是一块连
续的内存。当数据量比较多的时候才会改成quicklist。因为普通的链表需要的附加指针空间太大,会比较浪费空间,而且会加重内存的碎
片化。比如这个列表里存的只是 int 类型的数据,结构上还需要两个额外的指针prev和next。所以Redis将链表和ziplist结合起来组成了
quicklist。也就是将多个ziplist使用双向指针串起来使用。这样既满足了快速的插入删除性能,又不会出现太大的空间冗余。
   
4) 压缩列表ziplist是一种为节约内存而开发的顺序型数据结构,它被用作列表键和哈希键的底层实现之一。

5) Hash,Redis的字典的值只能是字符串,而且Redis采用渐进式Rehash策略

6) set,Redis的集合相当于Java语言里面的HashSet,内部的键值对是无序的唯一的,其内部实现相当于一个特殊的字典,字典中所有的
value都是一个值NULL。set结构可以用来存储活动中奖的用户ID,因为有去重功能,可以保证同一个用户不会中奖两次。
   
7) zset,它类似于Java的SortedSet和HashMap的结合体,一方面它是一个set,保证了内部value的唯一性,另一方面它可以给每个value
赋予一个score,代表这个value的排序权重。它的内部实现用的是一种叫着跳跃列表的数据结构。zset还可以用来存储学生的成绩,value
值是学生的ID,score是他的考试成绩。我们可以对成绩按分数进行排序就可以得到他的名次。zset可以用来存粉丝列表,value值是粉丝的
用户ID,score是关注时间。我们可以对粉丝列表按关注时间进行排序。
//https://yq.aliyun.com/articles/666398
typedef struct zset {

    // 字典,键为成员,值为分值
    // 用于支持 O(1) 复杂度的按成员取分值操作
    dict *dict;

    // 跳跃表,按分值排序成员
    // 用于支持平均复杂度为 O(log N) 的按分值定位成员操作
    // 以及范围操作
    zskiplist *zsl;
} zset;

1、千帆竞发:Redis分布式锁

1) 使用setnx命令实现分布式锁
   
超时问题?
   Redis 的分布式锁不能解决超时问题,如果在加锁和释放锁之间的逻辑执行的太长,以至于超出了锁的超时限制,就会出现问题。因为这
时候锁过期了,第二个线程重新持有了这把锁,但是紧接着第一个线程执行完了业务逻辑,就把锁给释放了,第三个线程就会在第二个线程
逻辑执行完之间拿到了锁。
   
解决办法:
1.1) Redis分布式锁不要用于较长时间任务。如果真的偶尔出现了,数据出现的小波错乱可能需要人工介入解决。
1.2) 有一个更加安全的方案是为set指令的value参数设置为一个随机数,释放锁时先匹配随机数是否一致,然后再删除key。但是匹配value
和删除key不是一个原子操作,这就需要使用Lua脚本来处理了,因为Lua脚本可以保证连续多个指令的原子性执行。

2) 单机Redis实现分布式锁的缺陷
   比如在Sentinel集群中,主节点挂掉时,从节点会取而代之,客户端上却并没有明显感知。原先第一个客户端在主节点中申请成功了一把
锁,但是这把锁还没有来得及同步到从节点,主节点突然挂掉了。然后从节点变成了主节点,这个新的节点内部没有这个锁,所以当另一个客
户端过来请求加锁时,立即就批准了。这样就会导致系统中同样一把锁被两个客户端同时持有,不安全性由此产生。
不过这种不安全也仅仅是在主从发生failover的情况下才会产生,而且持续时间极短,业务系统多数情况下可以容忍。
   
解决办法:RedLock
   加锁时,它会向过半节点发送 set(key, value, nx=True, ex=xxx) 指令,只要过半节点set成功,那就认为加锁成功。释放锁时,需要
向所有节点发送del指令。不过Redlock算法还需要考虑出错重试、时钟漂移等很多细节问题,同时因为Redlock需要向多个节点进行读写,意
味着相比单实例 Redis 性能会下降一些。
如果你很在乎高可用性,希望挂了一台redis完全不受影响,那就应该考虑 redlock。不过代价也是有的,需要更多的 redis 实例,性能
也下降了,代码上还需要引入额外的library,运维上也需要特殊对待,这些都是需要考虑的成本,使用前请再三斟酌。
   
3) 锁冲突处理
   我们讲了分布式锁的问题,但是没有提到客户端在处理请求时加锁没加成功怎么办。
   
一般有3种策略来处理加锁失败:
3.1) 直接抛出异常,通知用户稍后重试
     这种方式比较适合由用户直接发起的请求,用户看到错误对话框后,会先阅读对话框的内容,再点击重试,这样就可以起到人工延时
的效果。如果考虑到用户体验,可以由前端的代码替代用户自己来进行延时重试控制。它本质上是对当前请求的放弃,由用户决定是否重新
发起新的请求。
     
3.2) sleep一会再重试,不推荐

3.3) 将请求转移至延时队列,过一会再试
     这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突。

2、缓兵之计:延时队列

1)异步消息队列   
   Redis的消息队列不是专业的消息队列,它没有非常多的高级特性,没有ack保证,如果对消息的可靠性有着极致的追求,那么它就不适合使用。
   Redis的list(列表)数据结构常用来作为异步消息队列使用,使用rpush/lpush操作入队列,使用lpop和rpop来出队列。
   
队列空了怎么办?
   可是如果队列空了,客户端就会陷入pop的死循环,不停地pop,没有数据,接着再pop,又没有数据。这就是浪费生命的空轮询。空轮询不但拉
高了客户端的CPU,redis的QPS也会被拉高,如果这样空轮询的客户端有几十来个,Redis的慢查询可能会显著增多。
   
解决办法:
1.1) 使用sleep来解决这个问题,让线程睡一会
2.1) 使用blpop/brpop,阻塞读在队列没有数据的时候,会立即进入休眠状态,一旦数据到来,则立刻醒过来。消息的延迟几乎为零。

空闲连接自动断开怎么办?
解决办法:
   如果线程一直阻塞在哪里,Redis的客户端连接就成了闲置连接,闲置过久,服务器一般会主动断开连接,减少闲置资源占用。这个时候
blpop/brpop会抛出异常来。所以编写客户端消费者的时候要小心,注意捕获异常,还要重试。
   
2) 延时队列
   延时队列可以通过Redis的zset(有序列表)来实现。我们将消息序列化成一个字符串作为zset的value,这个消息的处理时间作为score,
然后用多个线程轮询zset获取到期的任务进行处理,多个线程是为了保障可用性,万一挂了一个线程还有其它线程可以继续处理。因为有
多个线程,所以需要考虑并发争抢任务,确保任务不能被多次执行。

如何进行Redis深度分析

//Redis实现延迟队列
public class RedisDelayingQueue {

    static class TaskItem {
        public String id;
        public T msg;
    }

    private Type TaskType = new TypeReference>(){}.getType();

    private Jedis jedis;

    private String queueKey;

    public RedisDelayingQueue(Jedis jedis, String queueKey){
        this.jedis = jedis;
        this.queueKey = queueKey;
    }

    public void delay(T msg){
        TaskItem taskItem = new TaskItem();
        taskItem.id = UUID.randomUUID().toString();
        taskItem.msg = msg;
        String s = JSON.toJSONString(taskItem);
        jedis.zadd(queueKey, System.currentTimeMillis() + 5000, s);
    }

    public void loop(){
        while (!Thread.interrupted()){
            //只取一条数据
            Set values = jedis.zrangeByScore(queueKey,0,System.currentTimeMillis(),0,1);
            
            if(values.isEmpty()){
                try {
                    Thread.sleep(500);
                } catch (InterruptedException e) {
                    break;
                }
                continue;
            }

            String s = (String) values.iterator().next();
            //zrem用于移除有序集中一个或多个成员
            if(jedis.zrem(queueKey, s) > 0){
                TaskItem task = JSON.parseObject(s, TaskType);
                this.handleMsg(task.msg);
            }
        }
    }

    private void handleMsg(Object msg) {
        System.out.println(msg);
    }

    public static void main(String[] args) {
        Jedis jedis = new Jedis();
        RedisDelayingQueue queue = new RedisDelayingQueue(jedis, "test-queue");

        Thread producer = new Thread(){
            @Override
            public void run() {
                for (int i = 0; i < 10; i++){
                    queue.delay("lwh" + i);
                }
            }
        };

        Thread consumer = new Thread(){
            @Override
            public void run() {
                queue.loop();
            }
        };

        producer.start();
        consumer.start();

        try {
            producer.join();
            Thread.sleep(6000);
            consumer.interrupt();
            consumer.join();
        } catch (InterruptedException e) {
            e.printStackTrace();
        }
    }
}

3、节衣缩食: 位图

1) 位图 
   位图不是特殊的数据结构,它的内容其实就是普通的字符串,也就是 byte 数组。我们可以使用普通的 get/set 直接获取和设置整个位
图的内容,也可以使用位图操作 getbit/setbit等将 byte 数组看成「位数组」来处理。
   redis位图可以实现零存整取、零存零取等。「零存」就是使用 setbit 对位值进行逐个设置,「整存」就是使用字符串一次性填充所有
位数组,覆盖掉旧值。
   命令形如
   1) setbit s 1 1
   2) getbit s
   3) get s
   4) set s h
   
2) 统计和查找
   Redis提供了位图统计指令bitcount和位图查找指令bitpos,bitcount用来统计指定位置范围内1的个数,bitpos用来查找指定范围内出现
的第一个0或1。比如我们可以通过bitcount统计用户一共签到了多少天,通过bitpos指令查找用户从哪一天开始第一次签到。如果指定了范围
参数[start,end],就可以统计在某个时间范围内用户签到了多少天,用户自某天以后的哪天开始签到。
   
3) bitfield

4、四两拨千斤: HyperLogLog

1) HyperLogLog使用
   统计PV:每个网页一个独立的Redis计数器
   统计UV?
解决办法:
1.1) set去重,页面访问量大的情况下,耗费太多存储空间
1.2) 使用HyperLogLog,不精确去重,标准误差0.81%
    
   HyperLogLog提供了两个指令pfadd和pfcount,根据字面意义很好理解,一个是增加计数,一个是获取计数。pfadd用法和set集合的sadd
是一样的,来一个用户ID,就将用户ID塞进去就是。pfcount和scard用法是一样的,直接获取计数值。
   pfadd test-log user1
   pfadd test-log user2
   
   pfcount test-log
   
   HyperLogLog 除了上面的pfadd和pfcount之外,还提供了第三个指令pfmerge,用于将多个pf计数值累加在一起形成一个新的pf值。比如在
网站中我们有两个内容差不多的页面,运营说需要这两个页面的数据进行合并。其中页面的UV访问量也需要合并,那这个时候pfmerge就可以派
上用场了。

5、层峦叠嶂:布隆过滤器

1) 布隆过滤器
   讲个使用场景,比如我们在使用新闻客户端看新闻时,它会给我们不停地推荐新的内容,它每次推荐时要去重,去掉那些已经看过的内容。
问题来了,新闻客户端推荐系统如何实现推送去重的?
   当布隆过滤器说某个值存在时,这个值可能不存在;当它说不存在时,那就肯定不存在。
   
基本指令:布隆过滤器有二个基本指令,bf.add添加元素,bf.exists查询元素是否存在,它的用法和set集合的sadd和sismember差不多。
注意bf.add只能一次添加一个元素,如果想要一次添加多个,就需要用到bf.madd指令。同样如果需要一次查询多个元素是否存在,就需要用到
bf.mexists指令。
   
   bf.add test-filter user1
   bf.add test-filter user2
   
   bf.exists test-filter user1
   
   Redis其实还提供了自定义参数的布隆过滤器,需要我们在add之前使用bf.reserve指令显式创建。如果对应的 key已经存在,bf.reserve
会报错。bf.reserve有三个参数,分别是key,error_rate和initial_size。错误率越低,需要的空间越大。initial_size参数表示预计放入
的元素数量,当实际数量超出这个数值时,误判率会上升。

2) 布隆过滤器的原理
   每个布隆过滤器对应到Redis的数据结构里面就是一个大型的位数组和几个不一样的无偏hash函数。所谓无偏就是能够把元素的hash值算得
比较均匀。向布隆过滤器中添加key时,会使用多个hash函数对 key进行hash算得一个整数索引值然后对位数组长度进行取模运算得到一个位
置,每个hash函数都会算得一个不同的位置。再把位数组的这几个位置都置为1就完成了add操作。

3) 布隆过滤器的其他应用
   在爬虫系统中,我们需要对URL进行去重,已经爬过的网页就可以不用爬了。但是URL太多了,几千万几个亿,如果用一个集合装下这些URL
地址那是非常浪费空间的。这时候就可以考虑使用布隆过滤器。它可以大幅降低去重存储消耗,只不过也会使得爬虫系统错过少量的页面。布
隆过滤器在NoSql数据库领域使用非常广泛,我们平时用到的HBase、Cassandra还有LevelDB、RocksDB内部都有布隆过滤器结构,布隆过滤器
可以显著降低数据库的IO请求数量。当用户来查询某个row时,可以先通过内存中的布隆过滤器过滤掉大量不存在的row请求,然后再去磁盘进
行查询。
   邮箱系统的垃圾邮件过滤功能也普遍用到了布隆过滤器,因为用了这个过滤器,所以平时也会遇到某些正常的邮件被放进了垃圾邮件目录中,
这个就是误判所致,概率很低。

6、断尾求生:简单限流

   除了控制流量,限流还有一个应用目的是用于控制用户行为,避免垃圾请求。比如在UGC社区,用户的发帖、回复、点赞等行为都要严格受
控,一般要严格限定某行为在规定时间内允许的次数,超过了次数那就是非法行为。对非法行为,业务必须规定适当的惩处策略。

如何进行Redis深度分析

//这个限流需求中存在一个滑动时间窗口,想想zset数据结构的score值,是不是可以通过score来圈出这个时间窗口来。而且我们只需要
//保留这个时间窗口,窗口之外的数据都可以砍掉。那这个zset的value填什么比较合适呢?它只需要保证唯一性即可,用uuid会比较浪费
//空间,那就改用毫秒时间戳吧。

//但这种方案也有缺点,因为它要记录时间窗口内所有的行为记录,如果这个量很大,比如限定60s内操作不得超过100w次这样的参数,它
//是不适合做这样的限流的,因为会消耗大量的存储空间。
public class SimpleRateLimiter {

    private final Jedis jedis;

    public SimpleRateLimiter(Jedis jedis){
        this.jedis = jedis;
    }

    public boolean isActionAllowed(String userId, String actionKey, int period, int maxCount) throws IOException {
        String key = String.format("hist:%s:%s", userId, actionKey);
        long nowTs = System.currentTimeMillis();

        Pipeline pipeline = jedis.pipelined();
        //开启一个事务
        pipeline.multi();
        //value和score都用毫秒时间戳
        pipeline.zadd(key, nowTs, "" + nowTs);
        //移除时间窗口之外的行为记录,剩下的都是时间窗口内的
        pipeline.zremrangeByScore(key, 0, nowTs - period * 1000);
        //获得[nowTs - period * 1000, nowTs]的key的数量
        Response count = pipeline.zcard(key);
        //每次设置都更新key的过期时间
        pipeline.expire(key, period);

        //在事务中执行上述命令
        pipeline.exec();
        pipeline.close();

        return count.get() <= maxCount;
    }

    public static void main(String[] args) throws IOException, InterruptedException {
        Jedis jedis=new Jedis("localhost",6379);
        SimpleRateLimiter limiter=new SimpleRateLimiter(jedis);
        for (int i = 0; i < 20; i++) {
            //每个用户在1秒内最多能做五次动作
            System.out.println(limiter.isActionAllowed("lwh","reply",1,5));
        }
    }
}

7、一毛不拔:漏斗限流

   Redis4.0提供了一个限流Redis模块,它叫redis-cell。该模块也使用了漏斗算法,并提供了原子的限流指令。有了这个模块,限流问题就
非常简单了。
   
   cl.throttle lwh:reply 15 30 60 1
       
   上面这个指令的意思是允许「用户lwh回复行为」的频率为每 60s 最多 30 次(漏水速率),漏斗的初始容量为 15,也就是说一开始可以连
续回复 15 个帖子,然后才开始受漏水速率的影响。

8、近水楼台:GeoHash

   Redis在3.2版本以后增加了地理位置GEO模块,意味着我们可以使用Redis来实现摩拜单车「附近的 Mobike」、美团和饿了么「附近的
餐馆」这样的功能了。
   业界比较通用的地理位置距离排序算法是GeoHash算法,Redis也使用GeoHash算法。GeoHash算法将二维的经纬度数据映射到一维的整数,
这样所有的元素都将在挂载到一条线上,距离靠近的二维坐标映射到一维后的点之间距离也会很接近。当我们想要计算「附近的人时」,首先
将目标位置映射到这条线上,然后在这个一维的线上获取附近的点就行了。
   在Redis里面,经纬度使用52位的整数进行编码,放进了zset里面,zset的value是元素的key,score是GeoHash的52位整数值。zset的
score虽然是浮点数,但是对于52位的整数值,它可以无损存储。在使用Redis进行Geo查询时,我们要时刻想到它的内部结构实际上只是一
个zset(skiplist)。通过zset的score 排序就可以得到坐标附近的其它元素 (实际情况要复杂一些,不过这样理解足够了),通过将score
还原成坐标值就可以得到元素的原始坐标。
   
   1) 添加,geoadd指令携带集合名称以及多个经纬度名称三元组
       geoadd company 116.48105 39.996794 juejin
       geoadd company 116.514203 39.905409 ireader
   
   2) 距离,geodist指令可以用来计算两个元素之间的距离
       geodist company juejin ireader km
       
   3) 获取元素位置,geopos指令可以获取集合中任意元素的经纬度坐标
	   geopos company juejin
	   
   我们观察到获取的经纬度坐标和geoadd进去的坐标有轻微的误差,原因是geohash对二维坐标进行的一维映射是有损的,通过映射再还原
回来的值会出现较小的差别。对于「附近的人」这种功能来说,这点误差根本不是事。
   
   4) 附近的公司,georadiusbymember指令是最为关键的指令,它可以用来查询指定元素附近的其它元素
       //范围20公里以内最多3个元素按距离正排,它不会排除自身
   	   georadiusbymember company ireader 20 km count 3 asc
   	   
   	   //三个可选参数 withcoord withdist withhash 用来携带附加参数
   	   //withdist可以显示距离
   	   //withcoord显示坐标
   	   georadiusbymember company ireader 20 km withcoord withdist withhash count 3 asc

   5) Redis还提供了根据坐标值来查询附近的元素,这个指令更加有用,它可以根据用户的定位来计算「附近的车」,「附近的餐馆」等。
它的参数和georadiusbymember基本一致,除了将目标元素改成经纬度坐标值。
	   georadius company 116.514202 39.905409 20 km withdist count 3 asc   
	
注意事项:
   在一个地图应用中,车的数据、餐馆的数据、人的数据可能会有百万千万条,如果使用Redis的Geo数据结构,它们将全部放在一个zset
集合中。在Redis的集群环境中,集合可能会从一个节点迁移到另一个节点,如果单个key的数据过大,会对集群的迁移工作造成较大的影响,
在集群环境中单个key对应的数据量不宜超过1M,否则会导致集群迁移出现
卡顿现象,影响线上服务的正常运行。

   所以,这里建议Geo的数据使用单独的Redis实例部署,不使用集群环境。如果数据量过亿甚至更大,就需要对Geo数据进行拆分,按国家
拆分、按省拆分,按市拆分,在人口特大城市甚至可以按区拆分。这样就可以显著降低单个zset集合的大小。

9、大海捞针:Scan

   在平时线上Redis维护工作中,有时候需要从Redis实例成千上万的key中找出特定前缀的key列表来手动处理数据,可能是修改它的值,也
可能是删除key。这里就有一个问题,如何从海量的key中找出满足特定前缀的key列表来?
   Redis提供了一个简单暴力的指令keys用来列出所有满足特定正则字符串规则的key。缺点:没有offset、limit参数,事件复杂度O(n),key
过多时会导致卡顿
   
   Redis为了解决这个问题,它在2.8版本中加入了大海捞针的指令——scan。scan相比keys具备有以下特点:
1)、复杂度虽然也是 O(n),但是它是通过游标分步进行的,不会阻塞线程
2)、提供limit参数,可以控制每次返回结果的最大条数,limit只是一个hint,返回的结果可多可少
3)、同keys一样,它也提供模式匹配功能
4)、服务器不需要为游标保存状态,游标的唯一状态就是scan返回给客户端的游标整数
5)、返回的结果可能会有重复,需要客户端去重复,这点非常重要
6)、遍历的过程中如果有数据修改,改动后的数据能不能遍历到是不确定的
7)、单次返回的结果是空的并不意味着遍历结束,而要看返回的游标值是否为零

   scan提供了三个参数,第一个是cursor整数值,第二个是key的正则模式,第三个是遍历的limit hint。第一次遍历时,cursor值为0,然
后将返回结果中第一个整数值作为下一次遍历的cursor。一直遍历到返回的cursor值为0时结束。
    scan 0 match key99* count 1000     --> 返回cursor13796作为下次遍历的cursor
    scan 13976 match key99* count 1000

    scan 指令返回的游标就是第一维数组的位置索引,我们将这个位置索引称为槽 (slot)。如果不考虑字典的扩容缩容,直接按数组下标挨
个遍历就行了。limit参数就表示需要遍历的槽位数,之所以返回的结果可能多可能少,是因为不是所有的槽位上都会挂接链表,有些槽位可能
是空的,还有些槽位上挂接的链表上的元素可能会有多个。每一次遍历都会将limit数量的槽位上挂接的所有链表元素进行模式匹配过滤后,一
次性返回给客户端。
    
    scan 的遍历顺序非常特别。它不是从第一维数组的第0位一直遍历到末尾,而是采用了高位进位加法来遍历。之所以使用这样特殊的方式
进行遍历,是考虑到字典的扩容和缩容时避免槽位的遍历重复和遗漏。
    
    在平时的业务开发中,要尽量避免大key的产生。有时候会因为业务人员使用不当,在Redis实例中会形成很大的对象,比如一个很大的
hash,一个很大的zset这都是经常出现的。这样的对象对Redis的集群数据迁移带来了很大的问题,因为在集群环境下,如果某个key太大,
会数据导致迁移卡顿。另外在内存分配上,如果一个key太大,那么当它需要扩容时,会一次性申请更大的一块内存,这也会导致卡顿。如果
这个大key被删除,内存会一次性回收,卡顿现象会再一次产生。
    不过Redis官方已经在redis-cli指令中提供了大key扫描功能。第二条指令每隔 100 条 scan 指令就会休眠 0.1s,ops 就不会剧烈抬升,
但是扫描的时间会变长。
    redis-cli -h 127.0.0.1 -p 7001 –-bigkeys
    redis-cli -h 127.0.0.1 -p 7001 –-bigkeys -i 0.1

如何进行Redis深度分析

如何进行Redis深度分析

10、鞭辟入里:线程IO模型

1) 定时任务
   服务器处理要响应IO事件外,还要处理其它事情。比如定时任务就是非常重要的一件事。如果线程阻塞在select系统调用上,定时任务将无
法得到准时调度。那Redis是如何解决这个问题的呢?
   Redis的定时任务会记录在一个称为最小堆的数据结构中。这个堆中,最快要执行的任务排在堆的最上方。在每个循环周期,Redis都会将最
小堆里面已经到点的任务立即进行处理。处理完毕后,将最快要执行的任务还需要的时间记录下来,这个时间就是select系统调用的timeout参
数。因为Redis知道未来timeout时间内,没有其它定时任务需要处理,所以可以安心睡眠timeout的时间。
   Nginx 和 Node 的事件处理原理和 Redis 也是类似的

11、交头接耳:通信协议

   Redis的作者认为数据库系统的瓶颈一般不在于网络流量,而是数据库自身内部逻辑处理上。所以即使Redis使用了浪费流量的文本协议,
依然可以取得极高的访问性能。
   RESP(Redis Serialization Protocol). RESP是Redis序列化协议的简写。它是一种直观的文本协议,优势在于实现异常简单,解析性能
极好。

12、未雨绸缪:持久化

   当父进程对其中一个页面的数据进行修改时,会将被共享的页面复制一份分离出来,然后对这个复制的页面进行修改。这时子进程相应的
页面是没有变化的,还是进程产生时那一瞬间的数据。子进程因为数据没有变化,它能看到的内存里的数据在进程产生的一瞬间就凝固了,
再也不会改变,这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。
   
   Redis4.0混合持久化
   重启Redis时,我们很少使用rdb来恢复内存状态,因为会丢失大量数据。我们通常使用AOF日志重放,但是重放AOF日志性能相对rdb来说要
慢很多,这样在Redis实例很大的情况下,启动需要花费很长的时间。Redis4.0为了解决这个问题,带来了一个新的持久化选项——混合持久化。
将rdb文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间发生的增量
AOF日志,通常这部分AOF日志很小。
   于是在Redis重启的时候,可以先加载rdb的内容,然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放,重启效率因此大幅得
到提升。

13、开源节流:小对象压缩

1) 小对象压缩
   如果Redis内部管理的集合数据结构很小,它会使用紧凑存储形式压缩存储。如果它存储的是hash结构,那么key和 value会作为两个entry
相邻存在一起。如果它存储的是zset,那么value和score会作为两个entry相邻存在一起。
   存储界限 当集合对象的元素不断增加,或者某个value值过大,这种小对象存储也会被升级为标准结构。
   
2) 内存回收机制
   Redis并不总是可以将空闲内存立即归还给操作系统。
   如果当前Redis内存有10G,当你删除了1GB的key后,再去观察内存,你会发现内存变化不会太大。原因是操作系统回收内存是以页为单位,
如果这个页上只要有一个key还在使用,那么它就不能被回收。Redis虽然删除了1GB的key,但是这些key分散到了很多页面中,每个页面都还有
其它key存在,这就导致了内存不会立即被回收。
   不过,如果你执行flushdb,然后再观察内存会发现内存确实被回收了。原因是所有的key都干掉了,大部分之前使用的页面都完全干净了,
会立即被操作系统回收。
   Redis虽然无法保证立即回收已经删除的key的内存,但是它会重用那些尚未回收的空闲内存。这就好比电影院里虽然人走了,但是座位还在,
下一波观众来了,直接坐就行。而操作系统回收内存就好比把座位都给搬走了。这个比喻是不是很6?

14、有备无患:主从同步

1) CAP理论
   C:Consistent,一致性
   A:Availbility,可用性
   P:Partition tolerance,分区容忍性
   
   分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的,这意味着必然会有网络断开的风险,这个网络断开的场景的专业词汇
叫着「网络分区」。
   在网络分区发生时,两个分布式节点之间无法进行通信,我们对一个节点进行的修改操作将无法同步到另外一个节点,所以数据的「一致
性」将无法满足,因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」,也就是暂停分布式节点服务,在网络分区发生时,不
再提供修改数据的功能,直到网络状况完全恢复正常再继续对外提供服务。
   一句话概括CAP原理就是——网络分区发生时,一致性和可用性两难全。

看完上述内容,你们对如何进行Redis深度分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。


新闻名称:如何进行Redis深度分析
网页URL:http://dzwzjz.com/article/jjgeop.html
在线咨询
服务热线
服务热线:028-86922220
TOP