redis的应用场景、优点和项目中的使用

目录缓存数据共享分布式分布式锁全局ID计数器限流位统计购物车用户消息时间线timeline消息队列抽奖点赞、签到、打卡商品标签商品筛选用户关注、推荐模型排行榜1、缓存String类型例如：...

数据类型 使用场景 String ip地址，incrby Hash 存储用户信息 List 新消息的排行，利用List的push命令，将任务存在list集合中，同时使用pop命令将任务从集合去除，模拟消息队列【电商秒杀】 Set 排重，例如加好友，不可以加两次 Zset 以某一个条件做权重进行排序 ...

1.Redis集群工作原理 2.SpringBoot整合Redis集群 3.构建京淘前台管理系统 4.跨域机制

目前Spring Cloud微服务在Web项目中占据了主流地位，如果去面试关于Spring Cloud的岗位时，面试官一般都会提问你的项目是如何优化的，从哪些方面入手去优化。而缓存技术绝对是项目必不可少的，所以我们必须掌握好Java项目的缓存技术。JVM 缓存：JVM 缓存是指 Java 虚拟机为类加载器所创建的缓存。Java 虚拟机通过缓存已经加载的类来提高应用程序的性能。数据库缓存：数据库缓存是指将查询结果缓存在内存中，以便下次查询时可以直接从内存中获取，避免了重复查询数据库的操作。

redis的特性：在内存中存储数据、可编程的、扩展能力、持久化、集群、高可用、快。 redis的应用场景：实时数据存储、缓存、消息队列

摘要： Redis主从集群中的脑裂问题会导致数据丢失，表现为客户端写入原主库的数据在切换后被全量同步清除。脑裂常由主库假故障（如资源争抢或实例阻塞）引发，此时哨兵触发切换但原主库仍在接收写入。通过配置min-slaves-to-write和min-slaves-max-lang参数，可限制主库在从库同步异常时拒绝写入，减少数据丢失风险。建议参数设置需结合从库数量和哨兵超时时间，并注意该方案无法完全避免数据丢失。本质上是Redis异步复制在性能与一致性间的权衡，关键运维措施包括避免主库资源竞争和监控阻塞情况。

先更库，后删缓存。不是因为它完美，而是因为它的最坏情况只是"短暂不一致"，而反过来的最坏情况是"永久脏数据"。能用 MQ 异步删，就别在主链路上同步删。能让 Canal 干的活，就别让业务代码扛。双写一致性的本质不是选顺序，而是承认一定会不一致，然后设计一个能自愈的机制。

│ 客户端A │ ──────────────────────────────────────→ │ Zookeeper │。│ 客户端A │ ───────────────────────────────────────→ │ Redis │。│ 客户端A │ ───────────────────────────────────────→ │ Redis │。printf("\n--- Zookeeper分布式锁 ---\n");printf("--- Redis分布式锁 ---\n");

redis 的 string , list 队列，Set 集，的数据结构讲解

在 Redis 中，SET NX EX是一种将设置键值对、条件判断和过期时间结合在一起的原子操作。

上面命令后面加上 --raw 参数即可正常显示中文redis-cli连接成功后，会看到提示符。如果设置了Redis密码，则需要使用AUTH命令手动验证密码让我们来练习几个最基础的通用命令，来管理 Redis 中的 Key。- 设置一个键值对- 获取一个键的值- 查找所有符合给定模式的 Key（- 判断一个 Key 是否存在- 返回 Key 所存储的值的类型- 为 Key 设置过期时间（单位：秒）- 删除一个或多个 Key。

本文介绍了一种基于Redis的轻量级分布式锁组件的设计与实现，通过注解+AOP+Lua脚本的方式解决高并发场景下的缓存击穿、重复计算和资源竞争问题。该组件提供固定租期和自动续期两种模式，支持SpEL动态Key生成，确保操作的原子性和安全性。核心实现包含自定义注解@RedisLockable、AOP切面、Lua脚本加解锁逻辑以及自动续期机制。优点包括声明式编程、灵活Key设计、双模式选择和原子操作，但也存在线程泄露风险、缺乏重试机制等不足，建议改用ScheduledExecutorService并增加取消回调

为了避免用户导致冲突甚至内核崩溃，用户应用与内核时分离的：用户空间只执行受限的命令，而且不能直接调用系统资源，必须通过内核提供的内核空间可以执行特权命令，调用一切系统资源Linux系统为了提高IO效率，会在用户空间和内核空间都加入缓冲区:写数据时，要把用户缓冲数据拷贝到内核缓冲区，然后写入设备读数据时，要从设备读取数据到内核缓冲区，然后拷贝到用户缓冲区顾名思义，非阻塞IO的recvfrom操作会立即返回结果而不是阻塞用户进程。

1.id是会展示给用户的，如果id的规律性太强会让用户观察出一定的信息2.受表单数据的限制：订单量是和容易积累的，在多年的运营下，订单量很可能超过了单表所能存储的最大数量，此时开始新的一个表来存储的时候，自增的ID就会出现重复的情况前三十一位为时间戳，记录下单时间，以秒为单位序列号：秒内的计数器，支持每秒产生2的三十二次方个id确保唯一性的方法：不同时间（不在同一秒）的id依靠时间戳来决定相同时间（在同一秒）的id依靠序列号来分辨变化的key，1.因为如果时间的key都是同一个，那么，同一秒内的时间戳（包括

Redis 在场景Redis 能力关键命令解决什么问题分布式限流原子计数器INCREXPIRE多实例共享限流计数在线心跳带 TTL 的状态存储SETEX高频写入 + 自动过期 + 批量查询分布式锁（扩展）互斥锁SETNXEXPIRE+ Lua 脚本多实例下资源互斥（库存扣减/定时任务去重）接口抽象Limiter接口让内存和 Redis 两种实现无缝切换，调用方完全不感知优雅降级：Redis 不可用时自动回退到内存方案，服务不崩溃，只是限流精度下降做减法。

更高级方案。自动总结用户：Java开发准备面试目标大厂100条聊天记录80%以上当你的项目发展到这一步时，你已经不仅仅是在做一个 Spring AI Demo，而是在构建一个真正可上线的 AI 平台。ChatClient↓↓RAG↓↓↓Agent↓MCP↓性能优化↓企业级AI架构。

如果只给一个最朴素的判断标准，我会说：稳定不是零报错，而是报错好查、切换好换、成本好算。便宜也不是单价最低，而是你把重试、超时、人工排查和团队协作都算进去之后，总成本仍然可控。个人开发者更适合先看接入门槛和错误提示是否清楚，先把脚本、Dify、Cursor 这些常见入口跑通。团队用户更应该看权限、日志、预算和统一管理。企业用户则优先看合规、审计、分权和备选方案，而不是只盯着价格。我自己的经验是，真正好用的 AI API 接口，不是让你完全不报错，而是让你知道错在哪、改哪、怎么切。

3节点的Elasticsearch集群提供高可用存储Logstash负责日志采集和处理Filebeat作为轻量级日志采集器Kibana提供可视化分析界面Redis/Kafka作为消息缓冲队列这套系统可支持大规模日志采集和分析场景，并可根据实际需求进行横向扩展。在实际生产环境中，建议根据日志量动态调整各组件资源配置，并建立完善的监控告警体系。

策略本质定时删除用 CPU 换内存，太贵，不用惰性删除用内存换 CPU，太懒，单用会漏定期删除抽样巡逻，可控可调，是主力Redis 组合拳定期巡逻 + 惰性把关 + Fast 应急 = 性能与内存的最优解Redis 的过期删除，不是某一种策略的胜利，而是两种策略互相补短的艺术。理解这一点，才算真正读懂了 Redis 的内存管理哲学。