Redis大key问题指的是某个key对应的value值所占的内存空间比较大，导致Redis的性能下降、内存不足、数据不均衡以及主从同步延迟等问题。 到底多大的数据量才算是大key？

工作中常常会遇到这样的场景，如订单到期未支付取消，到期自动续费等，我们发现延迟队列非常适合在这样的场景中使用。常见的延迟队列的优秀实现有rabbitMQ的死信队列，RocketMQ的延迟队列等

我们假定设置两个队列，一个队列维护正式工单，另一个队列维护挂起工单。对于挂起操作，我们通过Redis设置key有效时间，当key失效时，客户端监听失效事件，获取工单，实现 挂起工单队列的移除，正式队列的入队即可。 整个业务实现，可以分为三个大模块。 队列模块，通过WorkOrd…

延迟消息队列在我们的日常工作中经常会被用到，比如支付系统中超过 30 分钟未支付的订单，将会被取消，这样就可以保证此商品库存可以释放给其他人购买，还有外卖系统如果商家超过 5 分钟未接单的订单，将会被

我正在参加「掘金·启航计划」，这是我的第 2 篇文章。 Redis 中的有序集合(Sorted Set)就是用跳表（Skip list）来实现的。

数据结构没有什么不同，在应用程序中他们就像是可以组织数据的书架，不同的数据结构将为您提供不同的便利和好处，你需要仔细权衡自己的需求之后妥善的使用它们。布隆过滤器就是践行这句话的代表。

昨天写了一篇Redis布隆过滤器相关的命令的文章，今天来说一说springboot中如何简单在代码中使用布隆过滤器吧。

基于 Redis 的分布式锁优化 基于 setnx 实现的分布式锁存在的问题： 不可重入：同一个线程无法多次获取同一把锁（eg：方法A调用方法B，在方法A中先获取锁，然后去调用方法B，方法B也需要获取

最近项目中，有这样的一个需求：查找每个酒店最近的一个热点（地铁站、火车站、机场、景点），并显示与其距离。而项目正是采用Redis的GEO实现