大橙子网站建设,新征程启航
为企业提供网站建设、域名注册、服务器等服务
今天就跟大家聊聊有关如何进行redis深度分析,可能很多人都不太了解,为了让大家更加了解,小编给大家总结了以下内容,希望大家根据这篇文章可以有所收获。
创新互联公司专注于惠来企业网站建设,成都响应式网站建设公司,购物商城网站建设。惠来网站建设公司,为惠来等地区提供建站服务。全流程按需制作网站,专业设计,全程项目跟踪,创新互联公司专业和态度为您提供的服务
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) 使用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) 将请求转移至延时队列,过一会再试 这种方式比较适合异步消息处理,将当前冲突的请求扔到另一个队列延后处理以避开冲突。
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实现延迟队列 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(); } } }
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
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就可以派 上用场了。
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请求,然后再去磁盘进 行查询。 邮箱系统的垃圾邮件过滤功能也普遍用到了布隆过滤器,因为用了这个过滤器,所以平时也会遇到某些正常的邮件被放进了垃圾邮件目录中, 这个就是误判所致,概率很低。
除了控制流量,限流还有一个应用目的是用于控制用户行为,避免垃圾请求。比如在UGC社区,用户的发帖、回复、点赞等行为都要严格受 控,一般要严格限定某行为在规定时间内允许的次数,超过了次数那就是非法行为。对非法行为,业务必须规定适当的惩处策略。
//这个限流需求中存在一个滑动时间窗口,想想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的数量 Responsecount = 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)); } } }
Redis4.0提供了一个限流Redis模块,它叫redis-cell。该模块也使用了漏斗算法,并提供了原子的限流指令。有了这个模块,限流问题就 非常简单了。 cl.throttle lwh:reply 15 30 60 1 上面这个指令的意思是允许「用户lwh回复行为」的频率为每 60s 最多 30 次(漏水速率),漏斗的初始容量为 15,也就是说一开始可以连 续回复 15 个帖子,然后才开始受漏水速率的影响。
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集合的大小。
在平时线上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
1) 定时任务 服务器处理要响应IO事件外,还要处理其它事情。比如定时任务就是非常重要的一件事。如果线程阻塞在select系统调用上,定时任务将无 法得到准时调度。那Redis是如何解决这个问题的呢? Redis的定时任务会记录在一个称为最小堆的数据结构中。这个堆中,最快要执行的任务排在堆的最上方。在每个循环周期,Redis都会将最 小堆里面已经到点的任务立即进行处理。处理完毕后,将最快要执行的任务还需要的时间记录下来,这个时间就是select系统调用的timeout参 数。因为Redis知道未来timeout时间内,没有其它定时任务需要处理,所以可以安心睡眠timeout的时间。 Nginx 和 Node 的事件处理原理和 Redis 也是类似的
Redis的作者认为数据库系统的瓶颈一般不在于网络流量,而是数据库自身内部逻辑处理上。所以即使Redis使用了浪费流量的文本协议, 依然可以取得极高的访问性能。 RESP(Redis Serialization Protocol). RESP是Redis序列化协议的简写。它是一种直观的文本协议,优势在于实现异常简单,解析性能 极好。
当父进程对其中一个页面的数据进行修改时,会将被共享的页面复制一份分离出来,然后对这个复制的页面进行修改。这时子进程相应的 页面是没有变化的,还是进程产生时那一瞬间的数据。子进程因为数据没有变化,它能看到的内存里的数据在进程产生的一瞬间就凝固了, 再也不会改变,这也是为什么 Redis 的持久化叫「快照」的原因。接下来子进程就可以非常安心的遍历数据了进行序列化写磁盘了。 Redis4.0混合持久化 重启Redis时,我们很少使用rdb来恢复内存状态,因为会丢失大量数据。我们通常使用AOF日志重放,但是重放AOF日志性能相对rdb来说要 慢很多,这样在Redis实例很大的情况下,启动需要花费很长的时间。Redis4.0为了解决这个问题,带来了一个新的持久化选项——混合持久化。 将rdb文件的内容和增量的AOF日志文件存在一起。这里的AOF日志不再是全量的日志,而是自持久化开始到持久化结束的这段时间发生的增量 AOF日志,通常这部分AOF日志很小。 于是在Redis重启的时候,可以先加载rdb的内容,然后再重放增量AOF日志就可以完全替代之前的AOF全量文件重放,重启效率因此大幅得 到提升。
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?
1) CAP理论 C:Consistent,一致性 A:Availbility,可用性 P:Partition tolerance,分区容忍性 分布式系统的节点往往都是分布在不同的机器上进行网络隔离开的,这意味着必然会有网络断开的风险,这个网络断开的场景的专业词汇 叫着「网络分区」。 在网络分区发生时,两个分布式节点之间无法进行通信,我们对一个节点进行的修改操作将无法同步到另外一个节点,所以数据的「一致 性」将无法满足,因为两个分布式节点的数据不再保持一致。除非我们牺牲「可用性」,也就是暂停分布式节点服务,在网络分区发生时,不 再提供修改数据的功能,直到网络状况完全恢复正常再继续对外提供服务。 一句话概括CAP原理就是——网络分区发生时,一致性和可用性两难全。
看完上述内容,你们对如何进行Redis深度分析有进一步的了解吗?如果还想了解更多知识或者相关内容,请关注创新互联行业资讯频道,感谢大家的支持。