jedis

1、什么是Redis Redis是一个高性能的key-value内存数据库，是一种非关系型数据库。 2、Redis的五种数据类型： redis的五种数据类型分别为：String（字符串）、列表（List）、哈希（Hash）、Set（集合）、ZSet（有序集合） 在Redis5.0以后又加入了stream数据类型，stream的典型应用有生产者消费者队列等(list也能做，但stream更好，比如stream能够支持持久化，而list不能)。 3、Redis的作用 使用缓存的主要目的是提升查询速度和保护数据库等稀缺资源不被占满。 4、Redis的缓存穿透、缓存击穿、缓存雪崩 缓存穿透指的是在Redis中没有请求的数据，导致大量的数据库请求，且数据库中可能依然没有相应的数据。（不排除有恶意的数据库攻击），通常需要给查不到的数据设置一个空值，或者使用布隆过滤器的方式进行拦截。 缓存击穿是指一个热点key被大量访问，由于突然的缓存时间过期等原因，导致的大量的数据库请求，应对策略是对某些热点key不设置过期时间，或者使用锁限制请求。 缓存雪崩是数据库中的大量缓存过期，导致的大量数据库请求。应对策略通常是对不同的key使用随机的过期时间，保证过期时间尽可能的均匀分布，对热点数据不设置过期时间。 5、Redis的使用 启动redis服务：nohup redis-server 登录redis客户端

今天分享一个 RedisTemplate 的问题，感兴趣的可以继续看下去了，不感兴趣的继续撩妹去吧！ 如下图：一位朋友给了我一个报错的图片，为啥为啥取不到值？ 我也有点懵，第一反应就是 RedisTemplate 和 StringRedisTemplate 会不会用的两个不同的 Connection，导致相同的 Key 一个能查到，一个不能查到。 经过反复确认，Connection 没问题，是同一个，还是那句话：每个奇怪问题的背后一定有故事。 只能调试源码了呗，还能怎么办。最后在 redis.clients.jedis.BinaryJedis#hget 中发现了问题，就是 Redis 压根就没有返回数据。 现在的问题就剩下为什么 StringRedisTemplate 的查询可以返回数据，RedisTemplate 的查询却不能返回数据？ 我们来屡一下 StringRedisTemplate 和 RedisTemplate 的关系，StringRedisTemplate 继承了 RedisTemplate，是专门用于字符串操作。 RedisTemplate 一般用于比较复杂的对象操作，区别就在于序列化的不同。 于是我用 redis 客户端查看了存储的数据格式，发现这个 Hash 的格式是字符串。 这也就是为什么用 StringRedisTemplate 可以获取到

本文源码： GitHub·点这里 || GitEE·点这里 一、高并发简介 在互联网的业务架构中，高并发是最难处理的业务之一，常见的使用场景：秒杀，抢购，订票系统；高并发的流程中需要处理的复杂问题非常多，主要涉及下面几个方面： 流量管理，逐级承接削峰； 网关控制，路由请求，接口熔断； 并发控制机制，资源加锁； 分布式架构，隔离服务和数据库； 高并发业务核心还是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多余的直接溢出，这是相对复杂的流程。其次就是多线程并发下访问共享资源，该流程需要加锁机制，避免数据写出现错乱情况。 二、秒杀场景 1、预抢购业务 活动未正式开始，先进行活动预约，先把一部分流量收集和控制起来，在真正秒杀的时间点，很多数据可能都已经预处理好了，可以很大程度上削减系统的压力。有了一定预约流量还可以提前对库存系统做好准备，一举两得。 场景：活动预约，定金预约，高铁抢票预购。 2、分批抢购 分批抢购和抢购的场景实现的机制是一致的，只是在流量上缓解了很多压力，秒杀10W件库存和秒杀100件库存系统的抗压不是一个级别。如果秒杀10W件库存，系统至少承担多于10W几倍的流量冲击，秒杀100件库存，体系可能承担几百或者上千的流量就结束了。下面流量削峰会详解这里的策略机制。 场景：分时段多场次抢购，高铁票分批放出。 3、实时秒杀 最有难度的场景就是准点实时的秒杀活动

public static boolean set(String key, String value, int seconds) { Jedis jedis = null; try { jedis = jedisPool.getResource(); if (seconds > 0){ // 添加数据缓存，缓存有效时间 = 真实时间 + 1 天 jedis.set(key, seconds + 60 * 60 * 24, value); // 添加过期时间缓存，缓存有效时间 = 真实时间 jedis.set("lock_" + key, seconds, System.currentTimeMillis() + ""); } else { jedis.set(key, value); jedis.set("lock_" + key, System.currentTimeMillis() + ""); } return true; } catch (JedisException e) { if (jedis != null) { returnBrokenResource(jedis); jedis = null; } throw e; } finally { if (jedis != null) { returnResource(jedis); } } } public static

　　在上一篇博客---- Redis详解（八）------ 主从复制 ,我们简单介绍了Redis的主从架构,但是这种主从架构存在一个问题,当主服务器宕机,从服务器不能够自动切换成主服务器,为了解决这个问题,我们又介绍了哨兵模式,本篇博客我们继续深入的介绍一下这种模式. 1、架构图 　　 2、服务器列表 　　 3、搭建主从模式 　　 ①、主要配置项 　　主服务器(上图的Node1)配置文件 redis.config 主要配置项: #配置端口 port 6379 #以守护进程模式启动 daemonize yes #pid的存放文件 pidfile /var/run/redis_6379.pid #日志文件名 logfile "redis_6379.log" #存放备份文件以及日志等文件的目录 dir "/opt/redis/data" 　　从服务器配置文件主要配置项基本和主服务器保持一致,需要修改端口 port ;另外存放位置和日志文件名也可以根据需要修改. 　　为了表示主从关系,还需要在从服务器配置文件中添加一行 重要配置 : #配置主服务器IP,端口 slaveof 192.168.14.101 6379 　　 ②、验证主从关系 　　配置完成后,我们通过 redis-server redis.conf 命令启动Redis.然后通过 redis-cli -p 端口

client list客户端相关信息： fd: socket文件描述符 qbuf: 输入缓冲区（作用：临时存储客户端发送的命令） obl（固定缓冲区，使用字节数组）、oll（动态缓冲区，使用列表）、omen（使用的字节数）输出缓冲区（作用：保存命令执行的结果返回给客户端） 注： 单个客户端输入缓冲区大小超过1G会被关闭。 输出缓冲区：<class> 客户端分为三种类型，分别为普通客户端、slave客户端、发布订阅客户端。 输出缓冲区：<hard limit> 输出缓冲区大小大于该值会立刻关闭。 输出缓冲区：<soft limit>和<soft seconds> 输出缓冲区大小大于soft limit并持续soft seconds秒，会被关闭。 缓冲区+内存存储量超过maxmemory会出现数据丢失、键淘汰及OOM现象。通过client list或info client进行问题排查。 客户端相关配置： config set maxclients：动态设置客户端最大连接数 config set timeout 30：当idle超过timeout，客户端会被关闭 client kill ip:port：杀掉指定ip地址和端口的客户端 client pause timeout：阻塞客户端timeout毫秒数 monitor：用于监控Redis正在执行的指令，能监听所有命令

上篇文章（ Redis地理算法GEO解析和应用 ）我们对redis GEO算法进行解析以及相关shell命令的使用，这篇文章将带你进行实战应用。 依赖 注：jedis可以不引入，这里只是为了方便查看源码进行解析 <!-- https://mvnrepository.com/artifact/org.springframework.boot/spring-boot-starter-data-redis --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> <version>2.3.0.RELEASE</version> </dependency> <!-- https://mvnrepository.com/artifact/redis.clients/jedis --> <!-- 方便查看源码 --> <dependency> <groupId>redis.clients</groupId> <artifactId>jedis</artifactId> <version>3.3.0</version> </dependency> 数据源配置 spring: redis: host: localhost

本文源码： GitHub·点这里 || GitEE·点这里 一、高并发简介 在互联网的业务架构中，高并发是最难处理的业务之一，常见的使用场景：秒杀，抢购，订票系统；高并发的流程中需要处理的复杂问题非常多，主要涉及下面几个方面： 流量管理，逐级承接削峰； 网关控制，路由请求，接口熔断； 并发控制机制，资源加锁； 分布式架构，隔离服务和数据库； 高并发业务核心还是流量控制，控制流量下沉速度，或者控制承接流量的容器大小，多余的直接溢出，这是相对复杂的流程。其次就是多线程并发下访问共享资源，该流程需要加锁机制，避免数据写出现错乱情况。 二、秒杀场景 1、预抢购业务 活动未正式开始，先进行活动预约，先把一部分流量收集和控制起来，在真正秒杀的时间点，很多数据可能都已经预处理好了，可以很大程度上削减系统的压力。有了一定预约流量还可以提前对库存系统做好准备，一举两得。 场景：活动预约，定金预约，高铁抢票预购。 2、分批抢购 分批抢购和抢购的场景实现的机制是一致的，只是在流量上缓解了很多压力，秒杀10W件库存和秒杀100件库存系统的抗压不是一个级别。如果秒杀10W件库存，系统至少承担多于10W几倍的流量冲击，秒杀100件库存，体系可能承担几百或者上千的流量就结束了。下面流量削峰会详解这里的策略机制。 场景：分时段多场次抢购，高铁票分批放出。 3、实时秒杀 最有难度的场景就是准点实时的秒杀活动

spring-boot 整合 redis，有问题，欢迎留言 注： redis 服务器要先开启! 或者连接远程服务器上的 Redis,但是依然要开启服务，不然会一直 TimeOut! pom文件: <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-data-redis</artifactId> </dependency> 配置 application.properties # redis # Redis数据库索引（默认为0） spring.redis.database=0 # Redis服务器地址 spring.redis.host=localhost # Redis服务器连接端口 spring.redis.port=6379 # Redis服务器连接密码（默认为空） spring.redis.password= # 连接池最大连接数（使用负值表示没有限制） spring.redis.jedis.pool.max-active=20 # 连接池最大阻塞等待时间（使用负值表示没有限制） spring.redis.jedis.pool.max-wait=-1 # 连接池中的最大空闲连接 spring.redis.jedis.pool.max-idle=10 #

最近打算买一本书，《redis的开发与运维》。 公司的网购系统好像有点抗不住压力了，需要去监控一下。 cachecloud https://cachecloud.github.io/ centos安装 CentOS7 linux下yum安装redis以及使用 安装最新版的redis centos7 yum install redis (spring boot 低版本 ) spring.redis.host=192.168.59.131 spring.redis.port=6379 #spring.redis.password=root #根据需要 # Redis数据库索引（默认为0） spring.redis.database=0 # 连接池最大连接数（使用负值表示没有限制） spring.redis.pool.max-active=8 # 连接池最大阻塞等待时间（使用负值表示没有限制） spring.redis.pool.max-wait=-1 # 连接池中的最大空闲连接 spring.redis.pool.max-idle=8 # 连接池中的最小空闲连接 spring.redis.pool.min-idle=0 # 连接超时时间（毫秒） spring.redis.timeout=0 (spring boot 高版本配置) # REDIS (RedisProperties) #