江苏龙网

  1. 主页 > 生活百科 > >

Redis响应严重延迟，如何解决？( 六 )

Redis响应


对于第一个配置问题 ， 我们可以执行下面的命令 ， 把 appendfsync 改成 everysec：
$ docker exec -it redis redis-cli config set appendfsync everysecOK改完后 ， 切换到终端二中查看 ， 你会发现 ， 现在的请求时间 ， 已经缩短到了 0.9s：
{..., "elapsed_seconds":0.9368953704833984,"type":"good"}
而第二个问题 ， 就要查看应用的源码了 。点击 Github  ， 你就可以查看案例应用的源代码：
def get_cache(type_name):
'''handler for /get_cache'''
for key in redis_client.scan_iter("uuid:*"):
value = https://www.isolves.com/it/sjk/Redis/2021-03-11/redis_client.get(key)
if value =https://www.isolves.com/it/sjk/Redis/2021-03-11/= type_name:
redis_client.sadd(type_name, key[5:])
data = https://www.isolves.com/it/sjk/Redis/2021-03-11/list(redis_client.smembers(type_name))
redis_client.delete(type_name)
return jsonify({"type": type_name, 'count': len(data), 'data': data})
 
果然 ， Python 应用把 Redis 当成临时空间 ， 用来存储查询过程中找到的数据 。不过我们知道 ， 这些数据放内存中就可以了 ， 完全没必要再通过网络调用存储到 Redis 中 。
$ while true; do curl http:
{...,"elapsed_seconds":0.16034674644470215,"type":"good"}
你可以发现 ， 解决第二个问题后 ， 新接口的性能又有了进一步的提升 ， 从刚才的 0.9s  ， 再次缩短成了不到 0.2s 。
当然 ， 案例最后 ， 不要忘记清理案例应用 。你可以切换到终端一中 ， 执行下面的命令进行清理：
小结今天我带你一起分析了一个 Redis 缓存的案例 。
我们先用 top、iostat  ， 分析了系统的 CPU 、内存和磁盘使用情况 ， 不过却发现 ， 系统资源并没有出现瓶颈 。这个时候想要进一步分析的话 ， 该从哪个方向着手呢？
通过今天的案例你会发现 ， 为了进一步分析 ， 就需要你对系统和应用程序的工作原理有一定的了解 。
比如 ， 今天的案例中 ， 虽然磁盘 I/O 并没有出现瓶颈 ， 但从 Redis 的原理来说 ， 查询缓存时不应该出现大量的磁盘 I/O 写操作 。
顺着这个思路 ， 我们继续借助 pidstat、strace、lsof、nsenter 等一系列的工具 ， 找出了两个潜在问题 ， 一个是 Redis 的不合理配置 ， 另一个是 Python 应用对 Redis 的滥用 。找到瓶颈后 ， 相应的优化工作自然就比较轻松了 。
思考最后给你留一个思考题 。从上一节 MySQL 到今天 Redis 的案例分析 ， 你有没有发现 I/O 性能问题的分析规律呢？如果你有任何想法或心得 ， 都可以记录下来 。
当然 ， 这两个案例这并不能涵盖所有的 I/O 性能问题 。你在实际工作中 ， 还碰到过哪些 I/O 性能问题吗？你又是怎么分析的呢？
欢迎在留言区和我讨论 ， 也欢迎把这篇文章分享给你的同事、朋友 。我们一起在实战中演练 ， 在交流中进步 。




推荐阅读


上一篇：个人搞开源怎么赚钱？

下一篇：PS如何对照片进行调色？色相饱和度是什么？轻松理解颜色知识