AI 助理
备案控制台
开发者社区 开发与运维 文章 正文

Tomcat应用报redis超时的故事

2017-11-16 2135
版权
版权声明：
本文内容由阿里云实名注册用户自发贡献，版权归原作者所有，阿里云开发者社区不拥有其著作权，亦不承担相应法律责任。具体规则请查看《 阿里云开发者社区用户服务协议》和 《阿里云开发者社区知识产权保护指引》。如果您发现本社区中有涉嫌抄袭的内容，填写 侵权投诉表单进行举报，一经查实，本社区将立刻删除涉嫌侵权内容。
本文涉及的产品
Redis 开源版，标准版 2GB
推荐场景：
搭建游戏排行榜
云数据库 Tair（兼容Redis），内存型 2GB
推荐场景：
通过缓存加速数据库访问
日志服务 SLS，月写入数据量 50GB 1个月
简介：

业务背景介绍　　　　　　　　　　　

系统架构是通过分布式的方式进行部署的，登录的时候不会调用redis数据，假如用户登录成功了，会跳转到其它的项目上，并根据从redis中查到的权限缓存，像是相应的数据模块

问题排查

问题君发飙最初手段

问题一：用户登录失败，系统巨卡无比

问题二：Tomcat抛出 connect timed out错误

2016-09-24 16:44:24,397 - [ERROR] [RedisClient]:269- java.net.SocketTimeoutException: connect timed out
redis.clients.jedis.exceptions.JedisConnectionException: java.net.SocketTimeoutException: connect timed out
        at redis.clients.jedis.Connection.connect(Connection.java:134)
        at redis.clients.jedis.BinaryClient.connect(BinaryClient.java:69)
        at redis.clients.jedis.Connection.sendCommand(Connection.java:79)
        at redis.clients.jedis.BinaryClient.exists(BinaryClient.java:99)
        at redis.clients.jedis.Client.exists(Client.java:29)
        at redis.clients.jedis.Jedis.exists(Jedis.java:92)
        at redis.clients.jedis.ShardedJedis.exists(ShardedJedis.java:48)
        at com.tools.common.redis.client.RedisClient.exists(RedisClient.java:267)
        at com.group.erp.rpc.dubbo.service.impl.ActionRpcServiceImpl.getActionList(ActionRpcServiceImpl.java:23)
        at com.alibaba.dubbo.common.bytecode.Wrapper1.invokeMethod(Wrapper1.java)
        at com.alibaba.dubbo.rpc.proxy.javassist.JavassistProxyFactory$1.doInvoke(JavassistProxyFactory.java:46)
        at com.alibaba.dubbo.rpc.proxy.AbstractProxyInvoker.invoke(AbstractProxyInvoker.java:72)
        at com.alibaba.dubbo.rpc.filter.ExceptionFilter.invoke(ExceptionFilter.java:55)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.filter.ClassLoaderFilter.invoke(ClassLoaderFilter.java:38)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.filter.EchoFilter.invoke(EchoFilter.java:38)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.monitor.support.MonitorFilter.invoke(MonitorFilter.java:73)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.filter.GenericFilter.invoke(GenericFilter.java:68)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.filter.TimeoutFilter.invoke(TimeoutFilter.java:42)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.protocol.dubbo.filter.TraceFilter.invoke(TraceFilter.java:78)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.filter.ContextFilter.invoke(ContextFilter.java:60)
        at com.alibaba.dubbo.rpc.protocol.ProtocolFilterWrapper$1.invoke(ProtocolFilterWrapper.java:91)
        at com.alibaba.dubbo.rpc.protocol.dubbo.DubboProtocol$1.reply(DubboProtocol.java:108)
        at com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.handleRequest(HeaderExchangeHandler.java:84)
        at com.alibaba.dubbo.remoting.exchange.support.header.HeaderExchangeHandler.received(HeaderExchangeHandler.java:170)
        at com.alibaba.dubbo.remoting.transport.dispather.ChannelEventRunnable.run(ChannelEventRunnable.java:78)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)
Caused by: java.net.SocketTimeoutException: connect timed out
        at java.net.PlainSocketImpl.socketConnect(Native Method)
        at java.net.AbstractPlainSocketImpl.doConnect(AbstractPlainSocketImpl.java:350)
        at java.net.AbstractPlainSocketImpl.connectToAddress(AbstractPlainSocketImpl.java:206)
        at java.net.AbstractPlainSocketImpl.connect(AbstractPlainSocketImpl.java:188)
        at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:392)
        at java.net.Socket.connect(Socket.java:589)
        at redis.clients.jedis.Connection.connect(Connection.java:129)
        ... 34 more

按照常规思路进行排查

查找问题君之网卡流量状况

:sar -n DEV 1

09时00分30秒     IFACE   rxpck/s   txpck/s    rxkB/s    txkB/s   rxcmp/s   txcmp/s  rxmcst/s
09时00分31秒        lo      0.00      0.00      0.00      0.00      0.00      0.00      0.00
09时00分31秒      eth1    873.74    257.58     66.75     49.75      0.00      0.00      0.00

查找问题君之CPU状况

:top

[root@ZWCLC6X-10939 ~]# top
top - 08:58:52 up 1 day, 15:05,  1 user,  load average: 0.00, 0.00, 0.00
Tasks: 187 total,   1 running, 186 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.2%us,  0.2%sy,  0.0%ni, 98.7%id,  0.1%wa,  0.3%hi,  0.5%si,  0.0%st
Mem:  16333752k total, 12914752k used,  3419000k free,   286716k buffers
Swap:  1048572k total,        0k used,  1048572k free,  1013568k cached

查找问题君之内存状况

:free -m

total       used       free     shared    buffers     cached
Mem:         15950      14612       1338          0        279        990
-/+ buffers/cache:      11342       4608 
Swap:         1023        997       26

这里发现了一个问题，服务器的内存资源居高不下，暂且不考虑服务器资源的正常与否

查找问题君之可疑进程状况

ps -ef 显示系统进程

这里不方便把服务器开启了那些进程罗列到此处，还请见谅；最后的分析结果就是，并无异常进程

这就奇怪了，到底是哪的问题呢？继续查找

查找问题君之生产环境应用

生产环境有两个java项目都调用了这个服务器的redis服务，然后找到了这两个项目分别查看日志，几乎在相同时间都抛出了Time out的错误，因此断定应该是redis单方面的问题

查找问题君之生产环境redis服务

查看了redis日志，并没有什么报错请求

[1008] 24 Sep 17:17:20.378 - Accepted XX.XX.XX.XX:40688
[1008] 24 Sep 17:17:20.394 - Accepted XX.XX.XX.XX:40691
[1008] 24 Sep 17:17:20.470 - Accepted XX.XX.XX.XX:40692
[1008] 24 Sep 17:17:20.470 - Accepted XX.XX.XX.XX:40693
[1008] 24 Sep 17:17:20.484 - Accepted XX.XX.XX.XX:55622
[1008] 24 Sep 17:17:20.486 - Accepted XX.XX.XX.XX:40697
[1008] 24 Sep 17:17:20.488 - Accepted XX.XX.XX.XX:55624

查找问题君之redis压力测试

使用redis-benchmark测试了redis的压力，也没有什么问题。

查找问题君之redis慢查询

怀疑是有慢查询 连接数不够用 等待了 导致超时了
有这么几个命令：

　　./redis-cli -h 127.0.0.1 -p 6378 # 这个是连接上本机的6378的redis

　　auth password #如果redis设置的有密码，使用auth进行密码验证

　　CONFIG GET slowlog-log-slower-than #(10000us,Redis中的执行单位是微秒，相当于10ms）

  CONFIG GET slowlog-max-len （最多存储128条慢日志，应该是默认的吧？）

　　SLOWLOG LEN #查看redis存储的慢查询记录，默认查看128条

　　SLOWLOG GET # 查看redis存储的慢查询记录，默认10条

    6) 1) (integer) 166
    2) (integer) 1474962558
    3) (integer) 55972  # 这个是慢查询时间，微秒级别的，1秒=1000毫秒，1毫秒=1000微妙
    4) 1) "SETEX"
       2) "company_info_nan857920"
       3) "7200"
       4) "\x1f\x8b\b\x00\x00\x00\x00\x00\x00\x00\xedUKo\x1bU\x14\xbeq\xc8\xbb\r\xa1\b!\x16\x85\x05\xe2)a\xc7\x8dJ\x12uG\xca\xc2\xe0V\x15)\x0b\x96S\xcf\x8d3\xc5\x9e\x99\xcc\\'\x0e\x0b\xd4\xb4u\x1c'N\x9d\x904\xad\x1b\xf7\x11\xd5\xa1\t4N+L\xe2\xfa\xd1JH\xac\xf9\x0b\x88\xce\xb5g\x16(K\xb6\x9c\xeby\xd8A\xb0cYK\x1e\x9f\xf3\x9d\xef<\xee9g\xae\x1f\xfe\x89\xdaT\x05\xbd\x17\x90\xc2n\x95\x9fvGT... (1218 more

从上面可以看出一个满查询在55毫秒左右，项目的配置文件在10秒左右，所以不存在超时的问题

查找问题君之redis内存

怀疑redis的内存用到上线，因此查看了redis的配置
maxmonery # 我的配置文件没有设置，默认是不限制内存

查找问题君之redis内存使用状况

#./redis-cli  -h 127.0.0.1 -p 6378   # 这个是连接上本机的6378的redis
> info  # 查看redis信息
#Server
XXXXXXXXXXXX

#Clients
XXXXXXXXXXXX

#Memory
used_memory:28507480
used_memory_human:27.19M
used_memory_rss:51208192
used_memory_peak:51844256
used_memory_peak_human:49.44M
used_memory_lua:33792
mem_fragmentation_ratio:1.80
mem_allocator:libc

#Persistence
XXXXXXXXXX

#Stats
XXXXXXXXXX

#Replication
XXXXXXXXXX

#CPU
XXXXXXXXXX

#Keyspace
XXXXXXXXXX

介绍Memory的参数信息:
Tomcat应用报redis超时的故事
查看了redis使用内存很小，才使用了27.19M，排除了redis的内存使用情况

查找问题君之初步定型问题

使用了speedtest-cli 命令测试了本机的网速情况

　　speedtest-cli命令介绍：

　　参考：http://www.linuxde.net/2014/01/15561.html

$ wget https://raw.github.com/sivel/speedtest-cli/master/speedtest_cli.py
$ chmod a+rx speedtest_cli.py
$ sudo mv speedtest_cli.py /usr/local/bin/speedtest-cli
$ sudo chown root:root /usr/local/bin/speedtest-cli

测试结果：
Tomcat应用报redis超时的故事
使用这个命令查看本机网络，貌似有问题，于是那了两台机器之间互传了一个较大的文件，查看了速度，经测试速度在5MB-6MB左右，因此排除了网络问题】

查找问题君之数据持久化导

开始认为是持久化导致的磁盘IO飙升问题，于是更改持久化策略

先说一下持久化分为两种方式，第一种为AOF，第二种为save的方式，格式大概为

方式一：

################################ 快照 #################################

#
# 把数据库存到磁盘上:
#
#   save <seconds> <changes>
#
#   会在指定秒数和数据变化次数之后把数据库写到磁盘上。
#
#   下面的例子将会进行把数据写入磁盘的操作:
#   900秒（15分钟）之后，且至少1次变更
#   300秒（5分钟）之后，且至少10次变更
#   60秒之后，且至少10000次变更
#
#   注意：你要想不写磁盘的话就把所有 "save" 设置注释掉就行了。
#save 900 1
#save 300 10
#save 60 10000

方式二：

############################## 纯累加模式 ###############################

# 默认情况下，Redis是异步的把数据导出到磁盘上。这种情况下，当Redis挂掉的时候，最新的数据就丢了。
# 如果不希望丢掉任何一条数据的话就该用纯累加模式：一旦开启这个模式，Redis会把每次写入的数据在接收后都写入 appendonly.aof 文件。
# 每次启动时Redis都会把这个文件的数据读入内存里。
#
# 注意，异步导出的数据库文件和纯累加文件可以并存（你得把上面所有"save"设置都注释掉，关掉导出机制）。
# 如果纯累加模式开启了，那么Redis会在启动时载入日志文件而忽略导出的 dump.rdb 文件。
#
# 重要：查看 BGREWRITEAOF 来了解当累加日志文件太大了之后，怎么在后台重新处理这个日志文件。

appendonly yes

# 纯累加文件名字（默认："appendonly.aof"）
# appendfilename appendonly.aof

appendfilename "appendonly.aof"

# fsync() 请求操作系统马上把数据写到磁盘上，不要再等了。
# 有些操作系统会真的把数据马上刷到磁盘上；有些则要磨蹭一下，但是会尽快去做。
#
# Redis支持三种不同的模式：
#
# no：不要立刻刷，只有在操作系统需要刷的时候再刷。比较快。
# always：每次写操作都立刻写入到aof文件。慢，但是最安全。
# everysec：每秒写一次。折衷方案。
#
# 默认的 "everysec" 通常来说能在速度和数据安全性之间取得比较好的平衡。
# 如果你真的理解了这个意味着什么，那么设置"no"可以获得更好的性能表现（如果丢数据的话，则只能拿到一个不是很新的快照）；
# 或者相反的，你选择 "always" 来牺牲速度确保数据安全、完整。
#
# 如果拿不准，就用 "everysec"

# appendfsync always
appendfsync everysec
# appendfsync no

# 如果AOF的同步策略设置成 "always" 或者 "everysec"，那么后台的存储进程（后台存储或写入AOF日志）会产生很多磁盘I/O开销。
# 某些Linux的配置下会使Redis因为 fsync() 而阻塞很久。
# 注意，目前对这个情况还没有完美修正，甚至不同线程的 fsync() 会阻塞我们的 write(2) 请求。
#
# 为了缓解这个问题，可以用下面这个选项。它可以在 BGSAVE 或 BGREWRITEAOF 处理时阻止 fsync()。
#
# 这就意味着如果有子进程在进行保存操作，那么Redis就处于"不可同步"的状态。
# 这实际上是说，在最差的情况下可能会丢掉30秒钟的日志数据。（默认Linux设定）
#
# 如果你有延迟的问题那就把这个设为 "yes"，否则就保持 "no"，这是保存持久数据的最安全的方式。

no-appendfsync-on-rewrite yes

# 自动重写AOF文件
#
# 如果AOF日志文件大到指定百分比，Redis能够通过 BGREWRITEAOF 自动重写AOF日志文件。
#
# 工作原理：Redis记住上次重写时AOF日志的大小（或者重启后没有写操作的话，那就直接用此时的AOF文件），
#           基准尺寸和当前尺寸做比较。如果当前尺寸超过指定比例，就会触发重写操作。
#
# 你还需要指定被重写日志的最小尺寸，这样避免了达到约定百分比但尺寸仍然很小的情况还要重写。
#
# 指定百分比为0会禁用AOF自动重写特性。
auto-aof-rewrite-percentage 100
auto-aof-rewrite-min-size 64mb
# lua
lua-time-limit 5000

注掉了从的持久化，主注掉save模式，开启AOF模式，可是io高的问题依旧没有解决，于是乎就有了下文

查找问题君之磁盘IO状况

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sdb               0.00    59.00  574.00   99.00 21272.00  1272.00    33.50     6.02    9.01   1.34  89.90
sda               0.00     0.00    0.00    3.00     0.00    24.00     8.00     0.00    0.00   0.00   0.00
dm-0              0.00     0.00  568.00  158.00 21080.00  1272.00    30.79     6.04    8.38   1.24  89.90

看到这个界面，好像找到了点头绪，服务器的磁盘IO较高，但是小编这里也提出了疑问,redis的数据全部存放到了sdb银盘上，而且redis的程序也都是在sdb上面，那为什么服务器的sda的

IO资源占用如此之高呢？

顺藤摸瓜>>>就从高IO的线索查找问题根源：

检查是什么进程占用了如此高系统盘IO？

iotop
iotop执行命令结果，发现一个占用资源特别高的进程
检查发现，这个进程存在的作用是，当系统的物理内存耗尽时候，系统会激活此进程，以来调用swap分区。

这下有点明白其中的道道了，问题原因大概如下：
Tomcat应用报redis超时的故事
检查都有那些系统应用占用了swap分区，编写脚本：

#!/bin/bash
###############################################################################
# 日期 : 2016-09-27
# 作者 : sean
# Email : linux_no1@126.com
# 版本 : 1.0
# 脚本功能 ： 列出正在占用swap的进程。
###############################################################################
echo -e "PID\t\tSwap\t\tProc_Name"
 for pid in `ls -l /proc | grep ^d | awk '{ print $9 }'| grep -v [^0-9]`
# /proc目录下所有以数字为名的目录（进程名是数字才是进程，其他如sys,net等存放的是其他信息）
 do
      if [ $pid -eq 1 ];then continue;fi # Do not check init process
 # 让进程释放swap的方法只有一个：就是重启该进程。或者等其自动释放。
 # 如果进程会自动释放，那么我们就不会写脚本来找他了，找他都是因为他没有自动释放。
 # 所以我们要列出占用swap并需要重启的进程，但是init这个进程是系统里所有进程的祖先进程
 # 重启init进程意味着重启系统，这是万万不可以的，所以就不必检测他了，以免对系统造成影响。
        grep -q "Swap" /proc/$pid/smaps 2>/dev/null #检查是否占用swap分区
         if [ $? -eq 0 ];then 
          swap=$(awk '/Swap/{ sum+=$2;} END{ print sum }' /proc/$pid/smaps) #统计占用的swap分区的大小 单位是KB 
           proc_name=$(ps aux | grep -w "$pid" | awk '!/grep/{ for(i=11;i<=NF;i++){ printf("%s ",$i); }}')   #取出进程的名字
          if [ $swap -gt 0 ];then     #判断是否占用swap，只有占用才会输出
          echo -e "$pid\t${swap}\t$proc_name"
          fi
          fi
         done | sort -k2 -n | awk -F'\t' '{   
        if($2<1024)
           printf("%-10s\t%15sKB\t%s\n",$1,$2,$3);
        else if($2<1048576)
           printf("%-10s\t%15.2fMB\t%s\n",$1,$2/1024,$3);
        else
      printf("%-10s\t%15.2fGB\t%s\n",$1,$2/1048576,$3);
                                            }'

执行结果，发现

redis的进程全部存放在了swap分区中，果然是这样。

修改内核参数，合理分配内存使用

A.释放物理内存，并且叫新应用获取物理内存。

　　参考地址：http://www.cnblogs.com/minideas/p/3796505.html

　　1.在释放内存之前，检查可用内存多少

　　　　free -m

　　　　输出结果略

　　2.手动释放内存

　　　　echo 1 > /proc/sys/vm/drop_caches

　　3.释放完成后，检查可用内存是否进行了释放

　　　　free -m

　　　　输出结果略

　　经过上述的三个命令，发现内存确实进行了释放。

　　4.重启redis服务

　　5.检查swap分区使用

　　　　重启了redis发现内存走的依旧是swap分区，物理内存还有很多可用内存，但是系统为什么分给应用swap分区呢？

B.修改系统内核参数，叫所有的应用尽量使用物理内存，避免使用swap分区。

　　参考地址：http://davidbj.blog.51cto.com/4159484/1172879/
Tomcat应用报redis超时的故事
仔细看，物理内存还有将近1GB没有使用。但是swap已经开始被使用。怀疑是不是swappiness文件的值没有更改。
说明：在centos里面，swappiness的值的大小对如何使用swap分区是有着很大的联系的。swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。两个极端，对于Centos的默认设置，这个值等于60，建议修改为10。具体这样做:

sysctl vm.swappiness=10  

但是这只是临时的修改，如果系统重启会恢复默认的值60，所有还需要做下一步：  
 echo vm.swappiness=10 >> /etc/sysctl.conf  
这样就可以了。

最后重新加载swap虚拟内存：

swapoff -a    //关闭虚拟内存  
swapon  -a    //开启虚拟内存

但是上面操作后，重启了redis应用，系统依旧分给了redis swap分区。

C. 最后重启服务器，并再次启动redis服务，最后问题得到了解决。swap分区为0了









本文转自 xinsir999 51CTO博客，原文链接：http://blog.51cto.com/xinsir/2050754，如需转载请自行联系原作者
文章标签：
云数据库 Tair（兼容 Redis）
日志服务
NoSQL
Redis
Java
监控
应用服务中间件
关键词：
云数据库 Tair（兼容 Redis）超时
云数据库 Tair（兼容 Redis）应用
Tomcat应用
应用云数据库 Tair（兼容 Redis）
云数据库 Tair（兼容 Redis）tomcat
相关实践学习
基于Redis实现在线游戏积分排行榜
本场景将介绍如何基于Redis数据库实现在线游戏中的游戏玩家积分排行榜功能。
云数据库 Redis 版使用教程
云数据库Redis版是兼容Redis协议标准的、提供持久化的内存数据库服务，基于高可靠双机热备架构及可无缝扩展的集群架构，满足高读写性能场景及容量需弹性变配的业务需求。 产品详情：https://www.aliyun.com/product/kvstore &nbsp; &nbsp; ------------------------------------------------------------------------- 阿里云数据库体验：数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库&nbsp;ECS 实例和一台目标数据库&nbsp;RDS实例。跟着指引，您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接，领取免费ECS&amp;RDS资源，30分钟完成数据库上云实战！https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
余二五
目录
相关文章
土木林森
|
3月前
|
缓存 NoSQL Java
Redis深度解析：解锁高性能缓存的终极武器，让你的应用飞起来
【8月更文挑战第29天】本文从基本概念入手，通过实战示例、原理解析和高级使用技巧，全面讲解Redis这一高性能键值对数据库。Redis基于内存存储，支持多种数据结构，如字符串、列表和哈希表等，常用于数据库、缓存及消息队列。文中详细介绍了如何在Spring Boot项目中集成Redis，并展示了其工作原理、缓存实现方法及高级特性，如事务、发布/订阅、Lua脚本和集群等，帮助读者从入门到精通Redis，大幅提升应用性能与可扩展性。
土木林森
69 0
游客r43put2rqnbp4
|
18天前
|
NoSQL Java API
美团面试：Redis锁如何续期？Redis锁超时，任务没完怎么办？
在40岁老架构师尼恩的读者交流群中，近期有小伙伴在面试一线互联网企业时遇到了关于Redis分布式锁过期及自动续期的问题。尼恩对此进行了系统化的梳理，介绍了两种核心解决方案：一是通过增加版本号实现乐观锁，二是利用watch dog自动续期机制。后者通过后台线程定期检查锁的状态并在必要时延长锁的过期时间，确保锁不会因超时而意外释放。尼恩还分享了详细的代码实现和原理分析，帮助读者深入理解并掌握这些技术点，以便在面试中自信应对相关问题。更多技术细节和面试准备资料可在尼恩的技术文章和《尼恩Java面试宝典》中获取。
游客r43put2rqnbp4
31 0
美团面试：Redis锁如何续期？Redis锁超时，任务没完怎么办？
diygwcom
|
28天前
|
应用服务中间件 数据库
Tomcat 的数据库连接池设置与应用
Tomcat 的数据库连接池设置与应用
diygwcom
37 3
椰椰椰耶
|
28天前
|
存储 消息中间件 NoSQL
【redis】redis的特性和主要应用场景
【redis】redis的特性和主要应用场景
椰椰椰耶
90 1
路边两盏灯
|
3月前
|
Kubernetes NoSQL Redis
【Azure Redis】部署在AKS中的应用连接Redis时候出现Unable to connect to Redis server
【Azure Redis】部署在AKS中的应用连接Redis时候出现Unable to connect to Redis server
路边两盏灯
55 0
【Azure Redis】部署在AKS中的应用连接Redis时候出现Unable to connect to Redis server
路边两盏灯
|
3月前
|
NoSQL 网络协议 Linux
【Azure Redis】Lettuce客户端遇见连接Azure Redis长达15分钟的超时
【Azure Redis】Lettuce客户端遇见连接Azure Redis长达15分钟的超时
路边两盏灯
53 0
路边两盏灯
|
3月前
|
NoSQL 网络协议 Linux
【Azure Redis】Redis客户端出现15分钟的超时异常
【Azure Redis】Redis客户端出现15分钟的超时异常
路边两盏灯
17 0
路边两盏灯
|
3月前
|
缓存 NoSQL Linux
【Azure Redis 缓存】应用中出现连接Redis服务错误(production.ERROR: Connection refused)的排查步骤
【Azure Redis 缓存】应用中出现连接Redis服务错误(production.ERROR: Connection refused)的排查步骤
路边两盏灯
28 0
路边两盏灯
|
3月前
|
缓存 前端开发 Java
【Azure 应用服务】App Service 使用Tomcat运行Java应用，如何设置前端网页缓存的相应参数呢(-Xms512m -Xmx1204m)？
【Azure 应用服务】App Service 使用Tomcat运行Java应用，如何设置前端网页缓存的相应参数呢(-Xms512m -Xmx1204m)？
路边两盏灯
19 0
路边两盏灯
|
3月前
|
NoSQL 网络协议 Shell
【Azure 应用服务】App Service 项目部署成功后，应用连接 Azure Redis时报错 Could not get a resource from the pool
【Azure 应用服务】App Service 项目部署成功后，应用连接 Azure Redis时报错 Could not get a resource from the pool
路边两盏灯
49 0

热门文章

最新文章

  • 1
    Tomcat 7.0 64位免安装解压版 安装及配置
  • 2
    tomcat 开机后台运行
  • 3
    tomcat配置安装1
  • 4
    eclipse 发布web工程，修改tomcat端口
  • 5
    Tomcat安装与配置（笔记）
  • 6
    Tomcat start过程分析
  • 7
    SSH框架+mysql+tomcat 服务器 中文乱码解决方案
  • 8
    Tomcat环境变量,端口号,编码格式,项目路径,默认页的配置
  • 9
    python 合并当天tomcat异常日志
  • 10
    Idea开发Tomcat应用的热部署配置
  • 1
    【redis源码学习】持久化机制，java程序员面试算法宝典pdf
    70
  • 2
    实战：第十一篇：StringRedisTemplate获取redis信息，面试官突击一问
    44
  • 3
    Redis为什么会这么快？Redis到底有多快？【大厂经典面试题】
    427
  • 4
    利用Redis构建高性能的缓存系统
    97
  • 5
    Linux安装Redis（详细教程）
    302
  • 6
    Redis实现数据持久性主要依赖两种机制
    39
  • 7
    Redis中的常用命令非常丰富，涵盖了各种数据类型的基本操作以及服务器管理和维护的相关指令
    57
  • 8
    Redis的主要内存淘汰策略
    75
  • 9
    Redis的几种主要集群方案
    292
  • 10
    保证Redis的高可用性是一个涉及多个层面的任务，主要包括数据持久化、复制与故障转移、集群化部署等方面
    226

    • 相关课程

    更多
  • 大数据实战项目：反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第一阶段
  • 大数据实战项目 - 反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第六阶段
  • 大数据实战项目 - 反爬虫系统（Lua+Spark+Redis+Hadoop框架搭建）第七阶段
  • Redis入门实战演练
  • 云数据库 Redis 版使用教程
  • Redis数据库入门

    • 相关电子书

    更多
  • Redis集群演化的心路历程——从2.x到3.0时代
  • 微博的Redis定制之路
  • 云数据库Redis版的开源之路

    • 相关实验场景

    更多
  • 如何通过数据库Redis内网访问
  • Tair for Redis数据闪回：任意时间点数据恢复
  • 如何开通Redis的专属集群
  • 基于Redis实现在线游戏积分排行榜
    • 下一篇
    阿里云无影云电脑免费试用，最长可试用3个月