[TOC]
# redis-spring-boot-starter
前面项目中,咱们使用了[db-core]([https://www.kancloud.cn/owenwangwen/open-capacity-platform/1048264](https://www.kancloud.cn/owenwangwen/open-capacity-platform/1048264))为整个项目提供通用的数据库处理, db-core提供了druid数据源,mybatis的操作,也支持了redis的操作,功能不单一,将代码分离,自定义redis-spring-boot-starter
## 功能
* lettuce连接池
* redis操作工具类
* geohash 经纬度定位
* redisson分布式锁
## 代码分析
* 代码一览
![](https://img.kancloud.cn/1e/20/1e204bc6b960a331c66f52b5cdca4064_1629x704.png)
* RedisAutoConfig
![](https://img.kancloud.cn/5b/b2/5bb2e5b571c09be61c7abd11eb3fb2f0_1749x833.png)
回顾db-spring-boot-starter的章节
* @EnableAutoConfiguration 作用:从classpath中搜索所有META-INF/spring.factories配置文件
并且其中org.springframework.boot.autoconfigure.EnableAutoConfiguration key对应的配置项加载到spring容器
## 序列化
### redis序列化配置
![](https://img.kancloud.cn/d0/ba/d0bae96e680ae6fa2908175ede96f979_509x375.png)
### oauth序列化配置
![](https://img.kancloud.cn/0b/3e/0b3e61a7c9cc283adc99d243e401ce76_534x726.png)
### 测试脚本
原生序列化方案[序列化100000次]耗时:14389ms size:=1276000000
原生序列化方案[反序列化100000次]耗时:16298ms size:=1276000000
hessian序列化方案[序列化100000次]耗时:10479ms size:=792000000
hessian序列化方案[反序列化100000次]耗时:5480ms size:=792000000
Kryo序列化方案[序列化100000次]耗时:9330ms size:=1013000000
Kryo序列化方案[反序列化100000次]耗时:8582ms size:=1013000000
```
public static void main(String[] args) {
Map map = new HashMap();
for(int i = 0 ; i <=100 ; i++) {
map.put("a"+i, "a"+i);
}
Serializer jdkSerializer = SerializerManager.getSerializer(SerializerManager.JDK) ;
Serializer kryoObjectSerializer = SerializerManager.getSerializer(SerializerManager.KRYO) ;
Serializer hessianSerializer = SerializerManager.getSerializer(SerializerManager.HESSIAN2) ;
long size = 0;
long time1 = System.currentTimeMillis();
byte[] jdkserialize = null ;
byte[] redisserialize = null ;
byte[] kryoserialize = null ;
for (int i = 0; i < 1000000; i++) {
jdkserialize =jdkSerializer.serialize(map);
size += jdkserialize.length;
}
System.out.println("原生序列化方案[序列化100000次]耗时:"
+ (System.currentTimeMillis() - time1) + "ms size:=" + size);
long time2 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
Map aa =(Map) jdkSerializer.deserialize(jdkserialize) ;
}
System.out.println("原生序列化方案[反序列化100000次]耗时:"
+ (System.currentTimeMillis() - time2) + "ms size:=" + size);
long time3 = System.currentTimeMillis();
size = 0;
for (int i = 0; i < 1000000; i++) {
redisserialize =hessianSerializer.serialize(map);
size += redisserialize.length;
}
System.out.println("hessian序列化方案[序列化100000次]耗时:"
+ (System.currentTimeMillis() - time3) + "ms size:=" + size);
long time4 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
Map aa =(Map) hessianSerializer.deserialize(redisserialize) ;
}
System.out.println("hessian序列化方案[反序列化100000次]耗时:"
+ (System.currentTimeMillis() - time4) + "ms size:=" + size);
long time5 = System.currentTimeMillis();
size = 0;
for (int i = 0; i < 1000000; i++) {
kryoserialize =kryoObjectSerializer.serialize(map);
size += kryoserialize.length;
}
System.out.println("Kryo序列化方案[序列化100000次]耗时:"
+ (System.currentTimeMillis() - time5) + "ms size:=" + size);
long time6 = System.currentTimeMillis();
for (int i = 0; i < 1000000; i++) {
Map aa =(Map) kryoObjectSerializer.deserialize(kryoserialize) ;
}
System.out.println("Kryo序列化方案[反序列化100000次]耗时:"
+ (System.currentTimeMillis() - time6) + "ms size:=" + size);
}
```
## redis cluster中的代码优化
项目中 3主3从 redis集群出现单节点宕机,造成master迁移,但是发现应用无法正常连接redis ,分析了代码,发现默认Lettuce是不会刷新拓扑io.lettuce.core.cluster.models.partitions.Partitions#slotCache,最终造成槽点查找节点依旧找到老的节点,自然访问不了了。
![](https://img.kancloud.cn/a1/00/a1005083f3cb1daa2df0017143559843_1711x668.png)
## geohash 经纬度定位
~~~
/**
* 添加经纬度信息 map.put("北京" ,new Point(116.405285 ,39.904989)) //redis 命令:geoadd
* cityGeo 116.405285 39.904989 "北京"
*/
public Long addGeoPoint(String key, Map<Object, Point> map) {
return redisTemplate.opsForGeo().add(key, map);
}
/**
* 查找指定key的经纬度信息 redis命令:geopos cityGeo 北京
*
* @param key
* @param member
* @return
*/
public Point geoGetPoint(String key, String member) {
List<Point> lists = redisTemplate.opsForGeo().position(key, member);
return lists.get(0);
}
/**
* 返回两个地方的距离,可以指定单位 redis命令:geodist cityGeo 北京 上海
*
* @param key
* @param srcMember
* @param targetMember
* @return
*/
public Distance geoDistance(String key, String srcMember, String targetMember) {
Distance distance = redisTemplate.opsForGeo().distance(key, srcMember, targetMember, Metrics.KILOMETERS);
return distance;
}
/**
* 根据指定的地点查询半径在指定范围内的位置 redis命令:georadiusbymember cityGeo 北京 100 km WITHDIST
* WITHCOORD ASC COUNT 5
*
* @param key
* @param member
* @param distance
* @return
*/
public GeoResults geoRadiusByMember(String key, String member, double distance) {
return redisTemplate.opsForGeo().radius(key, member, new Distance(distance, Metrics.KILOMETERS),
RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates()
.sortAscending());
}
/**
* 根据给定的经纬度,返回半径不超过指定距离的元素 redis命令:georadius cityGeo 116.405285 39.904989
* 100 km WITHDIST WITHCOORD ASC COUNT 5
*
* @param key
* @param circle
* @param distance
* @return
*/
public GeoResults geoRadiusByCircle(String key, Circle circle, double distance) {
return redisTemplate.opsForGeo().radius(key, circle, new Distance(distance, Metrics.KILOMETERS),
RedisGeoCommands.GeoRadiusCommandArgs.newGeoRadiusArgs().includeDistance().includeCoordinates()
.sortAscending());
}
//删除元素
public Long deleteGeoMember(String key, String member) {
return redisTemplate.boundZSetOps(key).remove(member);
}
~~~
## 分布式锁redssion
### 集成方式
![](https://img.kancloud.cn/2d/60/2d6097bd35c5ccb4c2bb9ec34d3cef75_1610x600.png)
### 大致使用
![](https://img.kancloud.cn/18/d5/18d5a5e294b767fbd1330e3b19f20f16_1366x494.png)
### 代码分析
* 获取锁
![](https://img.kancloud.cn/5c/d1/5cd16cf63729b7c861e4b8f764d7d746_1218x257.png)
> 调用getLock()方法后实际返回一个RedissonLock对象
* 加锁
![](https://img.kancloud.cn/b7/76/b77653f1bb4d644f77d8172d71e6c22d_1263x810.png)
![](https://img.kancloud.cn/a5/4a/a54ab6fa5c42be0d670d3d9ef545442c_1201x805.png)
> 在RedissonLock对象的lock()方法主要调用tryAcquire()方法,由于leaseTime == -1,于是走tryLockInnerAsync()方法,
* 加锁细节
![](https://img.kancloud.cn/57/58/5758163e561c3b3032b836fd9a5f58ff_1118x366.png)
> 结合上面的参数声明,我们可以知道,这里KEYS\[1\]就是getName(),ARGV\[2\]是getLockName(threadId),假设前面获取锁时传的name是“anyLock”,假设调用的线程ID是Thread-1,假设成员变量UUID类型的id是85b196ce-e6f2-42ff-b3d7-6615b6748b5d:65那么KEYS\[1\]=anyLock,ARGV\[2\]=85b196ce-e6f2-42ff-b3d7-6615b6748b5d:Thread-1 ,因此,这段脚本的意思是1、判断有没有一个叫“anyLock”的key2、如果没有,则在其下设置一个字段为“85b196ce-e6f2-42ff-b3d7-6615b6748b5d:Thread-1”,值为“1”的键值对 ,并设置它的过期时间3、如果存在,则进一步判断“85b196ce-e6f2-42ff-b3d7-6615b6748b5d:Thread-1”是否存在,若存在,则其值加1,并重新设置过期时间4、返回“anyLock”的生存时间(毫秒)
* 加锁redis结构
![](https://img.kancloud.cn/12/b2/12b2c938d03de90b5b38ff12c467089c_1253x220.png)
> 这里用的数据结构是hash,hash的结构是: key 字段1 值1 字段2 值2 。。。用在锁这个场景下,key就表示锁的名称,也可以理解为临界资源,字段就表示当前获得锁的线程所有竞争这把锁的线程都要判断在这个key下有没有自己线程的字段,如果没有则不能获得锁,如果有,则相当于重入,字段值加1(次数)
* 解锁
![](https://img.kancloud.cn/14/de/14dee1fe94bd01a114c6235c208022be_1210x665.png)
> 我们还是假设name=anyLock,假设线程ID是Thread-1,同理,我们可以知道KEYS\[1\]是getName(),即KEYS\[1\]=anyLock,KEYS\[2\]是getChannelName(),即KEYS\[2\]=redisson\_lock\_\_channel:{anyLock},ARGV\[1\]是LockPubSub.unlockMessage,即ARGV\[1\]=0,ARGV\[2\]是生存时间,ARGV\[3\]是getLockName(threadId),即ARGV\[3\]=85b196ce-e6f2-42ff-b3d7-6615b6748b5d:Thread-1,因此,上面脚本的意思是:1、判断是否存在一个叫“anyLock”的key2、如果不存在,向Channel中广播一条消息,广播的内容是0,并返回1。3、如果存在,进一步判断字段85b196ce-e6f2-42ff-b3d7-6615b6748b5d:Thread-1是否存在。4、若字段不存在,返回空,若字段存在,则字段值减1,5、若减完以后,字段值仍大于0,则返回0。6、减完后,若字段值小于或等于0,则广播一条消息,广播内容是0,并返回1;可以猜测,广播0表示资源可用,即通知那些等待获取锁的线程现在可以获得锁了
* 等待
```
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
long threadId = Thread.currentThread().getId();
Long ttl = tryAcquire(leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
return;
}
RFuture<RedissonLockEntry> future = subscribe(threadId);
if (interruptibly) {
commandExecutor.syncSubscriptionInterrupted(future);
} else {
commandExecutor.syncSubscription(future);
}
try {
while (true) {
ttl = tryAcquire(leaseTime, unit, threadId);
// lock acquired
if (ttl == null) {
break;
}
// waiting for message
if (ttl >= 0) {
try {
future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
} catch (InterruptedException e) {
if (interruptibly) {
throw e;
}
future.getNow().getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
}
} else {
if (interruptibly) {
future.getNow().getLatch().acquire();
} else {
future.getNow().getLatch().acquireUninterruptibly();
}
}
}
} finally {
unsubscribe(future, threadId);
}
// get(lockAsync(leaseTime, unit));
}
```
> 这里会订阅Channel,当资源可用时可以及时知道,并抢占,防止无效的轮询而浪费资源当资源可用用的时候,循环去尝试获取锁,由于多个线程同时去竞争资源,所以这里用了信号量,对于同一个资源只允许一个线程获得锁,其它的线程阻塞
* 总结
![](https://img.kancloud.cn/0c/e5/0ce569c7fef58d1f9752ba39979f0a72_1740x788.png)
![](https://img.kancloud.cn/7e/fb/7efb414cf1715a4aa609b11ee3924170_607x384.png)
## Cache Aside Pattern
* 读的时候,先读缓存,缓存没有的话,那么就读数据库,然后取出数据后放入缓存,同时返回响应
![](https://img.kancloud.cn/29/c6/29c6bf333087ad69dedeb0a657df5966_1827x709.png)
* 更新的时候,先删除缓存,然后再更新数据库
- 前言
- 1.项目说明
- 2.项目更新日志
- 3.文档更新日志
- 01.快速开始
- 01.maven构建项目
- 02.环境安装
- 03.STS项目导入
- 03.IDEA项目导入
- 04.数据初始化
- 05.项目启动
- 06.付费文档说明
- 02.总体流程
- 1.oauth接口
- 2.架构设计图
- 3.微服务介绍
- 4.功能介绍
- 5.梳理流程
- 03.模块详解
- 01.老版本1.0.1分支模块讲解
- 01.db-core模块
- 02.api-commons模块
- 03.log-core模块
- 04.security-core模块
- 05.swagger-core模块
- 06.eureka-server模块
- 07.auth-server模块
- 08.auth-sso模块解析
- 09.user-center模块
- 10.api-gateway模块
- 11.file-center模块
- 12.log-center模块
- 13.batch-center模块
- 14.back-center模块
- 02.spring-boot-starter-web那点事
- 03.自定义db-spring-boot-starter
- 04.自定义log-spring-boot-starter
- 05.自定义redis-spring-boot-starter
- 06.自定义common-spring-boot-starter
- 07.自定义swagger-spring-boot-starter
- 08.自定义uaa-server-spring-boot-starter
- 09.自定义uaa-client-spring-boot-starter
- 10.自定义ribbon-spring-boot-starter
- 11.springboot启动原理
- 12.eureka-server模块
- 13.auth-server模块
- 14.user-center模块
- 15.api-gateway模块
- 16.file-center模块
- 17.log-center模块
- 18.back-center模块
- 19.auth-sso模块
- 20.admin-server模块
- 21.zipkin-center模块
- 22.job-center模块
- 23.batch-center
- 04.全新网关
- 01.基于spring cloud gateway的new-api-gateway
- 02.spring cloud gateway整合Spring Security Oauth
- 03.基于spring cloud gateway的redis动态路由
- 04.spring cloud gateway聚合swagger文档
- 05.技术详解
- 01.互联网系统设计原则
- 02.系统幂等性设计与实践
- 03.Oauth最简向导开发指南
- 04.oauth jdbc持久化策略
- 05.JWT token方式启用
- 06.token有效期的处理
- 07.@PreAuthorize注解分析
- 08.获取当前用户信息
- 09.认证授权白名单配置
- 10.OCP权限设计
- 11.服务安全流程
- 12.认证授权详解
- 13.验证码技术
- 14.短信验证码登录
- 15.动态数据源配置
- 16.分页插件使用
- 17.缓存击穿
- 18.分布式主键生成策略
- 19.分布式定时任务
- 20.分布式锁
- 21.网关多维度限流
- 22.跨域处理
- 23.容错限流
- 24.应用访问次数控制
- 25.统一业务异常处理
- 26.日志埋点
- 27.GPRC内部通信
- 28.服务间调用
- 29.ribbon负载均衡
- 30.微服务分布式跟踪
- 31.异步与线程传递变量
- 32.死信队列延时消息
- 33.单元测试用例
- 34.Greenwich.RELEASE升级
- 35.混沌工程质量保证
- 06.开发初探
- 1.开发技巧
- 2.crud例子
- 3.新建服务
- 4.区分前后台用户
- 07.分表分库
- 08.分布式事务
- 1.Seata介绍
- 2.Seata部署
- 09.shell部署
- 01.eureka-server
- 02.user-center
- 03.auth-server
- 04.api-gateway
- 05.file-center
- 06.log-center
- 07.back-center
- 08.编写shell脚本
- 09.集群shell部署
- 10.集群shell启动
- 11.部署阿里云问题
- 10.网关安全
- 1.openresty https保障服务安全
- 2.openresty WAF应用防火墙
- 3.openresty 高可用
- 11.docker配置
- 01.docker安装
- 02.Docker 开启远程API
- 03.采用docker方式打包到服务器
- 04.docker创建mysql
- 05.docker网络原理
- 06.docker实战
- 6.01.安装docker
- 6.02.管理镜像基本命令
- 6.03.容器管理
- 6.04容器数据持久化
- 6.05网络模式
- 6.06.Dockerfile
- 6.07.harbor部署
- 6.08.使用自定义镜像
- 12.统一监控中心
- 01.spring boot admin监控
- 02.Arthas诊断利器
- 03.nginx监控(filebeat+es+grafana)
- 04.Prometheus监控
- 05.redis监控(redis+prometheus+grafana)
- 06.mysql监控(mysqld_exporter+prometheus+grafana)
- 07.elasticsearch监控(elasticsearch-exporter+prometheus+grafana)
- 08.linux监控(node_exporter+prometheus+grafana)
- 09.micoservice监控
- 10.nacos监控
- 11.druid数据源监控
- 12.prometheus.yml
- 13.grafana告警
- 14.Alertmanager告警
- 15.监控微信告警
- 16.关于接口监控告警
- 17.prometheus-HA架构
- 18.总结
- 13.统一日志中心
- 01.统一日志中心建设意义
- 02.通过ELK收集mysql慢查询日志
- 03.通过elk收集微服务模块日志
- 04.通过elk收集nginx日志
- 05.统一日志中心性能优化
- 06.kibana安装部署
- 07.日志清理方案
- 08.日志性能测试指标
- 09.总结
- 14.数据查询平台
- 01.数据查询平台架构
- 02.mysql配置bin-log
- 03.单节点canal-server
- 04.canal-ha部署
- 05.canal-kafka部署
- 06.实时增量数据同步mysql
- 07.canal监控
- 08.clickhouse运维常见脚本
- 15.APM监控
- 1.Elastic APM
- 2.Skywalking
- 01.docker部署es
- 02.部署skywalking-server
- 03.部署skywalking-agent
- 16.压力测试
- 1.ocp.jmx
- 2.test.bat
- 3.压测脚本
- 4.压力报告
- 5.报告分析
- 6.压测平台
- 7.并发测试
- 8.wrk工具
- 9.nmon
- 10.jmh测试
- 17.SQL优化
- 1.oracle篇
- 01.基线测试
- 02.调优前奏
- 03.线上瓶颈定位
- 04.执行计划解读
- 05.高级SQL语句
- 06.SQL tuning
- 07.数据恢复
- 08.深入10053事件
- 09.深入10046事件
- 2.mysql篇
- 01.innodb存储引擎
- 02.BTree索引
- 03.执行计划
- 04.查询优化案例分析
- 05.为什么会走错索引
- 06.表连接优化问题
- 07.Connection连接参数
- 08.Centos7系统参数调优
- 09.mysql监控
- 10.高级SQL语句
- 11.常用维护脚本
- 12.percona-toolkit
- 18.redis高可用方案
- 1.免密登录
- 2.安装部署
- 3.配置文件
- 4.启动脚本
- 19.消息中间件搭建
- 19-01.rabbitmq集群搭建
- 01.rabbitmq01
- 02.rabbitmq02
- 03.rabbitmq03
- 04.镜像队列
- 05.haproxy搭建
- 06.keepalived
- 19-02.rocketmq搭建
- 19-03.kafka集群
- 20.mysql高可用方案
- 1.环境
- 2.mysql部署
- 3.Xtrabackup部署
- 4.Galera部署
- 5.galera for mysql 集群
- 6.haproxy+keepalived部署
- 21.es集群部署
- 22.生产实施优化
- 1.linux优化
- 2.jvm优化
- 3.feign优化
- 4.zuul性能优化
- 23.线上问题诊断
- 01.CPU性能评估工具
- 02.内存性能评估工具
- 03.IO性能评估工具
- 04.网络问题工具
- 05.综合诊断评估工具
- 06.案例诊断01
- 07.案例诊断02
- 08.案例诊断03
- 09.案例诊断04
- 10.远程debug
- 24.fiddler抓包实战
- 01.fiddler介绍
- 02.web端抓包
- 03.app抓包
- 25.疑难解答交流
- 01.有了auth/token获取token了为啥还要配置security的登录配置
- 02.权限数据存放在redis吗,代码在哪里啊
- 03.其他微服务和认证中心的关系
- 04.改包问题
- 05.use RequestContextListener or RequestContextFilter to expose the current request
- 06./oauth/token对应代码在哪里
- 07.验证码出不来
- 08./user/login
- 09.oauth无法自定义权限表达式
- 10.sleuth引发线程数过高问题
- 11.elk中使用7x版本问题
- 12.RedisCommandTimeoutException问题
- 13./oauth/token CPU过高
- 14.feign与权限标识符问题
- 15.动态路由RedisCommandInterruptedException: Command interrupted
- 26.学习资料
- 海量学习资料等你来拿
- 27.持续集成
- 01.git安装
- 02.代码仓库gitlab
- 03.代码仓库gogs
- 04.jdk&&maven
- 05.nexus安装
- 06.sonarqube
- 07.jenkins
- 28.Rancher部署
- 1.rancher-agent部署
- 2.rancher-server部署
- 3.ocp后端部署
- 4.演示前端部署
- 5.elk部署
- 6.docker私服搭建
- 7.rancher-server私服
- 8.rancher-agent docker私服
- 29.K8S部署OCP
- 01.准备OCP的构建环境和部署环境
- 02.部署顺序
- 03.在K8S上部署eureka-server
- 04.在K8S上部署mysql
- 05.在K8S上部署redis
- 06.在K8S上部署auth-server
- 07.在K8S上部署user-center
- 08.在K8S上部署api-gateway
- 09.在K8S上部署back-center
- 30.Spring Cloud Alibaba
- 01.统一的依赖管理
- 02.nacos-server
- 03.生产可用的Nacos集群
- 04.nacos配置中心
- 05.common.yaml
- 06.user-center
- 07.auth-server
- 08.api-gateway
- 09.log-center
- 10.file-center
- 11.back-center
- 12.sentinel-dashboard
- 12.01.sentinel流控规则
- 12.02.sentinel熔断降级规则
- 12.03.sentinel热点规则
- 12.04.sentinel系统规则
- 12.05.sentinel规则持久化
- 12.06.sentinel总结
- 13.sentinel整合openfeign
- 14.sentinel整合网关
- 1.sentinel整合zuul
- 2.sentinel整合scg
- 15.Dubbo与Nacos共存
- 31.Java源码剖析
- 01.基础数据类型和String
- 02.Arrays工具类
- 03.ArrayList源码分析
- 32.面试专题汇总
- 01.JVM专题汇总
- 02.多线程专题汇总
- 03.Spring专题汇总
- 04.springboot专题汇总
- 05.springcloud面试汇总
- 文档问题跟踪处理