RedisTemplate的各种操作(set.hash.list.string) 注入以下RedisTemplate @Autowired private RedisTemplate<String,String> redisTemplate; 1.保存和读取Set: 代码示例: SetOperations<String, String> set = redisTemplate.opsForSet(); set.add("set1","22")

redis 字典 前言 借鉴了 黄健宏 的 <<Redis 设计与实现>> 一书, 对 redis 源码进行学习 欢迎大家给予意见, 互相沟通学习 概述 字典是一种用于存储键值对的抽象数据结构 redis 字典使用哈希表作为底层实现 字典结构 定义位置 (src/dict.h) dict 结构 // 字典 typedef struct dict { // 字典类型所使用的操作函数集合 dictType *type; // 私有数据 void *privdata; // 哈希表 di

redis 通用API keys * 遍历所有key 一般不在生产环境中使用 redis单线程,容易阻塞其他命令执行 O(n) dbsize 计算key的总数 O(1)exists 检查key是否存在 O(1)del key 删除指定key-value O(1)expire key seconds key在second秒后过期 O(1)ttl key 查看key剩余的过期时间 O(1)persist key 去掉key的过期时间 O(1) type key 返回key的类型(string has

内存回收: 有时候发现10g的Redis删掉1g的key,内存占用没啥变化,因为内存页分配,有的页面可能还存在key,整个页面不能回收. 主从同步: CAP原理:一致性 可用性 分区容忍性 redis主从是异步同步数据的,所以并不满足一致性要求(redis是最终一致性),主节点修改后,立即返回,即使主从断开,主节点依然正常服务,所以满足可用性. 增量同步:主节点将指令记录在ringbuffer中,从节点执行同步,并向主节点反馈同步到的偏移量,网络环境不好时,buffer中的指令会覆盖,这时候需要

之前,统计每篇博文的阅读数的方式是经过筛选去重之后直接更新数据库,并发压力直接传导到数据库,假设1秒有1000个并发请求,传统方案会在1秒内并发进行1000次数据库更新操作. 为了降低数据库的并发压力,需要重新设计统计服务.思路是即使1秒有1万个并发请求,也只是依次更新数据库,对数据库没有并发压力. 统计服务要做的事情很专一:去重+计数 去重的业务根据具体的需要来设计规则,例如一个用户1个小时内所有访问都只计算一次,没有用户信息的按 IP 地址或者浏览器标识去统计.去重就是把这些标志去重,有多种

https://redis.io/commands/keys 遍历redis里面的所有key ,还能进行模糊匹配, 这样就省去了对key的手动过滤了 比如 keys term_info* ) "term_info:" ) "term_info:" ) "term_info:" ) "term_info:" ) "term_info:" 大致思路 : 1 遍历key ,读取redis 里面的数据, 为写入my

生存时间 设置命令 expire key long:设置数据在long秒后过期. pexpire key long:设置数据在long毫秒后过期. ttl key:查询数据剩余的生存时间.如果数据已过期被删除,返回-2(和版本有关),如果数据没有被设置过期时间,返回-1. persist key:取消数据的生存时间,重新变成永久生存. expireat key long:使用UNIX时间,设置数据存活到long时刻.long是从1980年8月1日开始到生存截止时间的秒数. pexpireat k

redis存json数据时选择string还是hash 我们在缓存json数据到redis时经常会面临是选择string类型还是选择hash类型去存储.接下来我从占用空间和IO两方面来分析这两种类型的优势. 1.占用空间 根据数据结构的共识我们知道hashtable类型是要比string类型更占用空间, 而ziplist类型与string类型占用的空间基本相差不大. 如下图就是ziplist的存储的格式 那我们接下来分别分析redis的string和hash类型占用空间方面的知识 string类

一.背景 在现网环境,一些使用Redis集群的业务随着业务量的上涨,往往需要进行节点扩容操作. 之前有了解到运维同学对一些节点数比较大的Redis集群进行扩容操作后,业务侧反映集群性能下降,具体表现在访问时延增长明显. 某些业务对Redis集群访问时延比较敏感,例如现网环境对模型实时读取,或者一些业务依赖读取Redis集群的同步流程,会影响业务的实时流程时延.业务侧可能无法接受. 为了找到这个问题的根因,我们对某一次的Redis集群迁移操作后的集群性能下降问题进行排查. 1.1 问题描述 这一次

tomcat的核心配置在conf/server.xml中. <Server>   根元素 <Server>即Catalina Servlet组件. <Server port=" shutdown="SHUTDOWN"> 常用属性 Address—Tomcat监听shutdown命令的地址,默认为localhost className—指定实现org.apache.catalina.Server接口的类,默认值为org.apache.cata

一.前言 Redis在我们日常开发中是经常用到的,Redis也是功能非常强大,可以进行缓存,还会有一些排行榜.点赞.消息队列.购物车等等:当然还有分布式锁Redisson,我们使用肯定少不了集群!小编最近学习到一些内存如果满了Redis是怎么操作呢?肯定像我们JVM一样,有回收或者淘汰的机制!今天小编和大家一起学习一下,小编也是看了阳哥的课,觉得讲的很好,记录一下,希望可以帮助到大家!! 二.自己配置Redis内存大小 redis安装上,如果你不配置的话,默认就是按你的电脑内存的大小. 我们打开

本文同时发表在https://github.com/zhangyachen/zhangyachen.github.io/issues/95 redis的hash结构中存储了如下的数据: $input = array( "key" => $key, //唯一的key值 "qid" => $qid, //问题id "value" => $startTime_$endTime, //开始时间_结束时间 ) 需求:每天凌晨跑定时脚本,跑

Redis在2.8.0版本新增了众望所归的scan操作,从此再也不用担心敲入了keys*, 然后举起双手看着键盘等待漫长的系统卡死了··· 命令的官方介绍在这里, 中文版由huangz同学细心翻译了,作者Antirez的介绍在这里:Finally Redis collections are iterable (我又邪恶的想到了之前他那次机器down机的事故了···). 具体的使用参考上面的链接即可,这里大概介绍一下Scan操作的实现原理. Redis的SCAN操作由于其整体的数据设计,无法提供特

续上一篇文章 Redis Scan迭代器遍历操作原理(一)–基础 ,这里着重讲一下dictScan函数的原理,其实也就是redis SCAN操作最有价值(也是最难懂的部分). 关于这个算法的源头,来自于githup这里:Add SCAN command #579,长篇的讨论,确实难懂····建议看看这帖子,antirez 跟pietern 关于这个奇怪算法的讨论··· 这个算法的作者是:Pieter Noordhuis,作者称其为:reverse binary iteration ,不知道我一对

当我们需要遍历Redis所有key或者指定模式的key时,首先想到的是KEYS命令: KEYS pattern   官网对于KEYS命令有一个提示: KEYS 的速度非常快,例如,Redis在一个有1百万个key的数据库里面执行一次查询需要的时间是40毫秒 .但在一个大的数据库中使用它仍然可能造成性能问题,如果你需要从一个数据集中查找特定的 KEYS, 你最好还是用 Redis 的集合结构 SETS 来代替. KEYS命令使用很简单.     redis> MSET one 1 two 2 th

dict.c中的dictScan函数,用来遍历字典,迭代其中的每个元素.该函数使用的算法非常精妙!!!所以必须记录一下. 遍历一个稳定的字典,当然不是什么难事,但Redis中的字典因为有rehash的过程,使字典可能扩展,也可能缩小.这就带来了问题,如果在两次遍历中间,字典的结构发生了变化(扩展或缩小),字典中的元素所在的位置相应的会发生变化,那如何保证字典中原有的元素都可以被遍历?又如何能尽可能少的重复迭代呢? 这就是该算法的精妙所在,使用该算法,可以做到下面两点: a:开始遍历那一刻的所有元

1.注解 package com.yun.smart.annotation; import java.lang.annotation.ElementType; import java.lang.annotation.Retention; import java.lang.annotation.RetentionPolicy; import java.lang.annotation.Target; import java.util.concurrent.TimeUnit; @Target(Elem

回到目录 关于持久化到Redis的消息格式,主要是说在Broker上把消息持久化的过程中,需要存储哪些类型的消息,因为我们的消息是分topic的,而每个topic又有若干个queue组成,而我们的topic和queue由于redis存储结构的原因,我们需要将它们分区对应存储一下,而不能像关系型数据库那样灵活,所以要额外设计几个数据结构来存储它们. 一 Topic字典 二 Topic对应的Queue字典 三 Queue里的消息 四 某个客户端对应某个Queue的消费进度 以上四个结构是我们要说的,

1.背景 Redis的出现确实大大地提高系统大并发能力支撑的可能性,转眼间Redis的最新版本已经是3.X版本了,但我们的系统依然继续跑着2.8,并很好地支撑着我们当前每天5亿访问量的应用系统.想当年Redis的单点单线程特性无法满足我们日益壮大的系统,只能硬着头皮把Redis"集群化"负载.且这套"集群化"方案良好地运行至今.虽难度不高,胜在简单和实用.无论简单还是很简单,记录这种经历是一件非常有趣的事情. 2.问题 系统访问量日益倍增,当前的Redis单点服务确

小喵的唠叨话:最近京东图书大减价,小喵手痒了就买了本<Redis设计与实现>[1]来看看.这里权当小喵看书的笔记啦.这一系列的模式,主要是先介绍Redis的实现原理(可能很大一部分会直接照搬原作者的描述),加上小喵自己的想法,之后配合Redis官网上的各种相关的操作命令(原书上貌似没有很多的介绍命令). 小喵的个人博客地址: http://miaoerduo.com, 随时欢迎各位的大驾. 原文链接: http://www.miaoerduo.com/redis/redis基本操作-strin

本文版权归博客园和作者吴双本人共同所有,转载和爬虫请注明原文链接 http://www.cnblogs.com/tdws/ 下午分享了JavaScript实现单向链表,晚上就来补充下双向链表吧.对链表的实现不是很了解的可以移步:http://www.cnblogs.com/tdws/p/6033209.html 双向链表与链表的不同之处主要在于他的双向查找.因为在这种结构中我们设计了每个节点的prev(向上查找)的引用或指针和next(向下查找)的引用或指针.得益于这种结构你能做到正向和反向的查