redis技术总结

redis为什么那么快?

如何从海量Key里面查询出某一固定前缀的key?

留意细节:摸清楚数据规模,问清楚边界
答：如果该机器是生产环境正在对外提供服务，不建议使用keys * pattern的方法进行查询，可能会使服务器卡顿，而出现事故。

　　一般生产服务器建议使用Scan命令，例如：　　SCAN 0 MATCH aaa* COUNT 5 表示从游标0开始查询aaa开头的key，每次返回5条，但是这个5条不一定，只是给Redis打了个招呼，具体返回数量看Redis心情。
游标从0开始,每执行一次游标会变并且返回,然后继续拿着返回游标执行Scan命令,最后游标如果返回0,则表明遍历结束,所以可以用一个hashset去接受返回的元素,最后获得全部元素,不会出现卡顿。

如何通过redis实现分布式锁?

如何解决setnx长期有效的问题？
因为其他线程需要拿到锁,所以要设置过期时间,让key失效,其它线程才能拿到锁

但是这样有一个缺陷(在设置时间那里如果出了问题),就是设置key,和为key设置key的过期时间得不到满足,这样的话也会导致释放不了锁

解决方案:使用另外一个语法,将设置key和时间绑定到了一起,这样一来问题就得到了解决

如何解决大量的key同时过期的注意事项
设置时间加上随机值,尽量使过期时间尽量分散一些,这个问题就可以得到解决

如何使用redis做异步队列?
方案一:

代码:

缺点:

方案二:

代码:
第一个客户端：

第二个客户端:

缺点:

第三种方案
发布订阅模式就是几个客户端订阅一个频道,这个频道发一条消息,其它客户端都能接受。

代码:
订阅频道:两个客户端订阅同一个频道,另外一个客户端订阅令一个频道。

发布消息:

订阅此频道的两个客户端收到消息

缺点:
消息已经发送,订阅此频道的客户端如果挂掉了,再一次上线是不能接受到消息的。实现此功能还须使用消息队列

redis如何持久化?

第一种rdb文件方式

在redis服务启动的时候会加载redis.conf的信息

每900s如果有一次写请求就会执行一次备份

当备份进程出错的时候主进程就停止写操作

压缩rdb文件

手动rdb持久化
rdb文件(快照)

生成rdb文件(快照)

如果想保存某个时间点的rdb文件,就使用时间戳的方式

自动rdb持久化

rdb的缺点

第二种持久化方式:AOF(默认是关闭的)

改为yes就生效了

和rdb一样,每一秒备份一次还是一旦缓存区发生变化就备份,no就是时机交给操作系统决定
一般用每秒保存一直

AOF文件因为是记录的每一次操作指令,比如计数100次这种,其实一个命令就可以完成,所以redis内部可以重写这个老的AOF文件。

新的AOF不会依赖老的AOF文件,而是直接当前内存里面的命令生成。

redis数据的恢复
在RDB和AOF文件共存的情况下的恢复流程:
redis启动时会首先去找AOF文件,如果有AOF文件就忽略掉RDB文件

RDB和AOF的优缺点:

redis4.0之后可以混合使用RDB和AOF

RDB-AOF 混合持久化：这种持久化能够通过 AOF 重写操作创建出一个同时包含 RDB 数据和 AOF 数据的 AOF 文件， 其中 RDB 数据位于 AOF 文件的开头， 它们储存了服务器开始执行重写操作时的数据库状态： 至于那些在重写操作执行之后执行的 Redis 命令， 则会继续以 AOF 格式追加到 AOF 文件的末尾， 也即是 RDB 数据之后。恢复策略是首先Redis数据库加载RDB文件，将数据库恢复到最新一次快照时的状态，然后模拟客户端，将AOF文件中的命令执行一遍，使数据库恢复到上次关机或故障时的状态，这样数据库的恢复就完成了。