这次彻底读透 Redis ！( 二 ) _小知识

文章插图

过期删除策略
Redis keys过期有两种方式：被动和主动方式。
当一些客户端尝试访问过期 key 时，Redis 发现 key 已经过期便删除掉这些 key
当然，这样是不够的，因为有些过期的 keys，可能永远不会被访问到。无论如何，这些 keys 应该过期，所以 Redis 会定时删除这些 key
具体就是Redis每秒10次做的事情：

测试随机的20个keys进行相关过期检测。
删除所有已经过期的keys 。
如果有多于25%的keys过期，重复步奏1

这是一个平凡的概率算法，基本上的假设是，Redis的样本是这个密钥控件，并且我们不断重复过期检测，直到过期的keys的百分百低于25%,这意味着，在任何给定的时刻，最多会清除1/4的过期keys 。
Redis 事务事务基本使用
Redis 事务可以一次执行多条命令，Redis 事务有如下特点：

事务是一个单独的隔离操作：事务中的所有命令都会序列化、按顺序地执行。事务在执行的过程中，不会被其他客户端发送来的命令请求所打断。
事务是一个原子操作：事务中的命令要么全部被执行，要么全部都不执行。

Redis 事务通过 MULTI 、exec、DISCARD、WATCH 几个命令来实现，MULTI 命令用于开启事务，EXEC 用于提交事务，DISCARD 用于放弃事务，WATCH 可以为 Redis 事务提供 check-and-set （CAS）行为。

文章插图

事务发生错误
Reids 事务发生错误分为两种情况。
第一种：事务提交前发生错误，也就是在发送命令过程中发生错误，看演示

文章插图

上面我故意将 incr 命令写错，从结果我们可以看到，这条 incr 没有入队，并且事务执行失败，k1 和 k2 都没有值
第二种：事务提交后发生错误，也就是在执行命令过程中发生错误，看演示

文章插图

上面的事务命令中，我给 k1 设置了一个 d，然后执行自增命令，最后获取 k1 的值，我们发现第二条命令执行发生了错误，但是整个事务依然提交成功了，从上面现象中可以得出，Redis 事务不支持回滚操作。如果支持的话，整个事务的命令都不应该被执行。
为什么 Redis 不支持回滚
如果你有使用关系式数据库的经验，那么 “Redis 在事务失败时不进行回滚，而是继续执行余下的命令”这种做法可能会让你觉得有点奇怪。
以下是这种做法的优点：

Redis 命令只会因为错误的语法而失败（并且这些问题不能在入队时发现），或是命令用在了错误类型的键上面：这也就是说，从实用性的角度来说，失败的命令是由编程错误造成的，而这些错误应该在开发的过程中被发现，而不应该出现在生产环境中。
因为不需要对回滚进行支持，所以 Redis 的内部可以保持简单且快速。

有种观点认为 Redis 处理事务的做法会产生 bug ，然而需要注意的是，在通常情况下，回滚并不能解决编程错误带来的问题。举个例子，如果你本来想通过 incr 命令将键的值加上 1 ，却不小心加上了 2 ，又或者对错误类型的键执行了 incr ，回滚是没有办法处理这些情况的。
放弃事务
当执行 discard 命令时，事务会被放弃，事务队列会被清空，并且客户端会从事务状态中退出