SpringBoot项目里同时挂上Redis和MySQL最怕的不是配置写错而是错得特别隐蔽。你盯着报错日志半天最后发现不过是连接池耗尽或者序列化器没配对。今天这篇不聊怎么建表也不聊Redis命令就专门梳理那些“配置要点”里最容易翻车的地方。依赖与自动配置的“隐形成本”SpringBoot的自动配置只负责让你跑起来从不负责让你跑得好。引入spring-boot-starter-data-redis后它默认给你装配Lettuce作为客户端同时塞进来一个JdkSerializationRedisSerializer。你如果只看启动日志一切正常但当你往Redis里写入一个对象再试图用redis-cli去查看时会看到一串难以理解的二进制乱码。这不是Redis的锅是序列化器默认值在作祟。同样的道理MySQL这边通过spring-boot-starter-jdbc或spring-boot-starter-data-jpa引入HikariCP自动配置的默认连接池大小是10。看似安全但在高并发下这个默认值很可能瞬间被打满。所以配置文件里的每一项都需要自己心里有数。“按默认值跑通”和“生产可用”之间隔着一整套针对场景的调优。比如Redis的database默认是0但如果你和别的应用共用实例不显式指定spring.data.redis.database就可能误读别人的缓存。同理MySQL连接串里的useSSLfalse和serverTimezoneAsia/Shanghai错过一个要么报SSL证书错误要么时间差八个小时。这些都不复杂但组合在一起足以让人抓狂。连接池你的应用到底在等谁先看MySQL。HikariCP的配置里最容易被误解的是maximum-pool-size。它不是越大越好而是“够用且留有余量”。默认10个连接如果每个请求占用连接10毫秒那么理论上每秒可以处理1000个请求。但你的业务往往不会这么线性池子太大反而会让数据库端线程数暴涨带来上下文切换损耗。实践中应该结合minimum-idle、connection-timeout和max-lifetime来调配。connection-timeout是客户端从池里借连接等待的最长时间默认30秒这在生产环境太长了建议压到3秒以内让失败快速暴露。Redis这边的连接池又是另一套逻辑。Lettuce默认没有池化它基于Netty的共享连接可以处理大量并发。但如果你的代码里频繁执行阻塞命令或者使用了事务建议显式开启lettuce.pool。开启连接池本身不是给自己买保险而是给线程并发高峰一个缓冲。配置spring.data.redis.lettuce.pool.max-active时别超过500默认8倒是偏保守。更重要的是max-wait代表从池里获取连接时如果没空闲能等待多久。这个值如果设成-1意味着无限等待这往往会让故障在低流量时悄悄蔓延。序列化策略Redis里存的不是你的对象是字节这是Redis集成中最容易出“幽灵问题”的地方。Redis不看你的对象类型它只认字节数组。默认的JdkSerializationRedisSerializer虽然能序列化任何实现了Serializable的对象但它的坏处显而易见可读性极差、体积大、且反序列化时要求类结构完全一致。更坑的是默认的RedisTemplate会把key也序列化导致你存进去的键变成类似\xAC\xED\x00\x05t\x00...的东西。用StringRedisTemplate倒是能避免key乱码但它要求value必须是StringJSON需要自己序列化。如果你不想被这些默认值折磨那就自己定义一个RedisTemplatekey用StringRedisSerializervalue用GenericJackson2JsonRedisSerializer。这样存进去的value是JSON可读性好又能保留类型信息。但别忘了Jackson序列化后反序列化时需要默认构造器如果你的DTO没有无参构造运行时直接报错。这个坑往往在配置阶段发现不了直到流量进来才现形。如果你用Fastjson还得小心里面某些版本的安全漏洞。序列化方案的选择本质上是在可读性、性能、安全性之间三选二没有银弹。缓存穿透、击穿、雪崩配置层面的防御姿势这三个经典问题很多人以为是纯代码逻辑但配置也能帮上忙。缓存穿透的底线防御是“空值也缓存”。在配置Redis的过期时间时对于不存在的数据库记录依然写入一个空值并设置一个较短的TTL比如60秒。这样同一个恶意key反复请求时缓存层就能挡下一部分压力。缓存击穿的应对靠的是“热点数据的永不过期”但永不过期不等于不更新而是后台异步刷新这需要配置额外的刷新线程池。至于缓存雪崩最简单粗暴的策略是给同一类缓存的过期时间加一个随机扰动比如基础TTL为10分钟实际过期时间在9到11分钟之间浮动。这可以在RedisTemplate层面通过自定义CacheManager来实现。没有配置兜底的缓存策略就像没有安全气囊的车代码写得再漂亮也会在事故中露馅。而且这些配置不是一次性的你要根据业务访问特征持续调整。热数据占比高就调大热点缓存的TTL批量写入频繁就得小心过期时间的一致性。事务与一致性Redis不是MySQL的附属品如果你天真地以为Transactional能同时管住MySQL和Redis那你的数据迟早要出问题。Spring的声明式事务基于数据库连接它只能约束同一个数据源里的操作。当你在一个事务方法里先更新MySQL再删除Redis缓存如果Redis操作抛了异常MySQL会回滚但Redis的删除动作已经执行了。表面上没问题但如果是先删缓存再更新数据库更新失败后缓存已经没了后续请求就会直接打到数据库。这就是经典的缓存与数据库不一致的时序问题。配置层面能做的并不是让Redis参与MySQL的本地事务而是严格控制缓存失效策略。业界常用的延迟双删就是在更新数据库后先删一次缓存等待几百毫秒再删第二次。这需要在代码里执行两次删除而两次删除之间的间隔通常通过sleep或延迟队列实现。这显然不是配置能解决的但你可以通过配置合理的缓存过期时间作为最终兜底。缓存过期是一把双刃剑它既可能造成雪崩又是数据最终一致的保障。连接工厂Lettuce的线程模型与超时很多人在配置Redis时只会写host和port忽略了timeout这个参数。SpringBoot的spring.data.redis.timeout指的是连接建立后等待命令响应的最大时间而不是TCP连接超时。如果你的业务中有一个慢命令比如keys它会让这个连接上的后续命令全部排队最终触发超时。Lettuce本身是异步非阻塞的但一旦你的代码用了同步API阻塞在某个命令上整个Netty事件循环都可能受影响。所以生产环境务必给Redis设置一个明确的超时时间比如2秒而不是默认的60秒。另外Lettuce的共享连接默认不会自动重连实际上它会自动恢复但在某些断线场景下连接可能处于半开状态需要配置validateConnection。这可以通过LettuceClientConfigurationBuilderCustomizer来定制比如开启commandTimeout和shutdownTimeout。不要小看这些细枝末节Redis的连接抖动在配置了合理超时和重试后应用侧往往无感知。这里的配置经验也适用于MySQL的超时判断但两者绝不能照搬。MySQL连接池的“隐形杀手”连接泄漏和空闲超时数据库连接池最常见的问题不是不够大而是泄漏。你的代码里如果有一处try { }没有在finally里释放连接池子会被慢慢吃掉最终所有请求卡在connection-timeout上。这种问题在配置上能做的就是调低connection-timeout让请求快速失败告警早触发。另一个容易被忽略的是max-lifetime它需要小于MySQL服务器的wait_timeout。假设MySQL的wait_timeout是8小时HikariCP的max-lifetime默认是30分钟反而没问题。但如果你手动调大了接近服务器超时时间数据库会主动断开空闲连接而HikariCP还认为连接可用造成“假连接”。配置连接池本质是在跟数据库服务器的空闲回收策略跳舞。多环境配置别让测试环境配置污染生产SpringBoot的application-{profile}.yml是配置管理的基础设施但很多人只把它当成文件拆分。实际上Redis与MySQL的配置在多环境下的差异远比想象中复杂。测试环境可能没有SSL生产环境要求加密传输测试环境用单台Redis生产可能用哨兵或Cluster。你需要为不同profile准备独立的配置块并且通过spring.profiles.active来激活。一个值得注意的坑是spring.redis.是旧版配置在SpringBoot2.x之后已经迁移到spring.data.redis.。如果你把网上一堆老帖子的配置直接复制过来会得到“配置无法识别”的警告但应用却依然能跑因为SpringBoot对不同历史配置有兼容。这种表面上无害的兼容恰恰是混乱的根源。监控与健康检查先于用户发现故障配置做完了不等于高枕无忧。你需要让Redis和MySQL的故障在用户感知之前暴露出来。SpringBoot Actuator提供了/actuator/health默认会检查Redis和MySQL的连接状态。但这只解决了“通不通”的问题没有解决“快不快”的问题。你还需要配置management.endpoint.health.show-detailsalways并添加management.metrics.enable.all或针对hikaricp和redis的指标曝光。HikariCP的指标里最关键的是connection-timeout-count和active-connectionsRedis这边redis.command.failed和redis.connections是生命线。这些指标可以通过Micrometer暴露给Prometheus再配上Grafana。但配置监控不是写几行yaml就完事你要为每一条关键指标设置告警阈值。比如MySQL连接池活跃数超过最大池的80%或者Redis命令超时次数每分钟大于5次都该触发告警。没有告警的监控只是事后看板的装饰品。别怕踩坑怕的是不知道坑在哪回到开头那句话。SpringBoot集成Redis和MySQL最难的不是技术而是对默认行为的傲慢与忽视。配置文件的每一行都值得慎重对待因为它们是应用的骨骼。今天聊到的序列化、连接池、超时、事务隔离、监控指标每一项单独拎出来都不难但组合起来就是生产环境的真实考验。不要指望一份通用配置解决所有问题每次调整都应该基于压测数据和监控反馈。你的业务模型决定了缓存策略你的并发模型决定了连接池大小你的故障容忍度决定了超时和重试参数。把这些决策做清楚Redis和MySQL才能成为可靠的左膀右臂而不是运维噩梦的来源。
