redis为啥不使用长连接（redis不能连接）



今天在开发的过程中遇到了一个Redis的问题: 当你在redis中插入一个key值,并且设置了对应过期时间. 当过期时间还没到的时候更新key值会导致过期时间被刷新, 针对这个问题: 我查看了下redis的官方文档, 他们是这么解释的:

也就是，对redis中存在的key进行set或getset会将原来的key进行覆盖，并且是全部属性都覆盖。怀疑set方法时redis内部的操作就是先删除再存储。

这个涉及到redis的删除机制：Redis里面如果有大量的key，怎样才能高效的找出过期的key并将其删除呢，难道是遍历每一个key吗？假如同一时期过期的key非常多，Redis会不会因为一直处理过期事件，而导致读写指令的卡顿。

这里说明一下，Redis是单线程的，所以一些耗时的操作会导致Redis卡顿，比如当Redis数据量特别大的时候，使用keys * 命令列出所有的key。

因此Redis默认使用懒惰删除+定期删除相结合的方式处理过期的key。

• 懒惰删除：请求过期key时，若该key已过期且未删除则会删除；
• 定期删除：轮循进程，该进程轮循查找过期key进行删除

所以，不会立即删除，因为删除key时肯定是主服务来删除(因为redis是单线程的)，所以当他在执行删除指令的时候，他就无法进行其他的操作，立即删除会影响性能；所以呢，他不会立即进行删除；

但是，如果一个key过期之后，无论redis删没删掉这个key外界都是查不到的；只是占用内存与否的问题。

mysql的读写效率没有想象的那么慢，mysql自己是有缓存的，mysql在不联表查取少量数据的情况下，基本与redis没什么差别。

为什么不建议使用mysql长连接，而却允许redis长连接：是因为redis使用的是IO复用模型，单线程可以同时处理多个连接，而mysql开源版一个线程对应一个连接。

• 热点数据
• 临时数据
• 复杂计算结果

Redis：作为一个内存数据库，Redis 具有非常高的读写并发能力，能够处理数十万到数百万的请求每秒。

MySQL：作为一个传统的关系型数据库，MySQL 的并发处理能力相对较低，通常在数千到数万的请求每秒。

不过提升核数并不会提升redis的并发能力i，因为一个redis 只能占用一核cpu。redis的并发量远比mysql要大，因为它没有io操作。

redis的key极少极少需要设置永不过期，如果一个key要设置永不过期，需要斟酌再斟酌。

版权声明：

本文来自互联网用户投稿，该文观点仅代表作者本人，不代表本站立场。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如若内容造成侵权、违法违规、事实不符，请将相关资料发送至xkadmin@xkablog.com进行投诉反馈，一经查实，立即处理！

转载请注明出处，原文链接：https://www.xkablog.com/rfx/30112.html