1. 項目概述為什么是Lettuce如果你正在構(gòu)建一個基于SpringBoot的現(xiàn)代Java應(yīng)用并且需要用到Redis那么連接池的選擇幾乎是你繞不開的第一個技術(shù)決策。SpringBoot官方從2.0版本開始就將默認(rèn)的Redis客戶端從Jedis切換到了Lettuce。這個看似簡單的“默認(rèn)”二字背后其實隱藏著Spring團(tuán)隊對現(xiàn)代應(yīng)用架構(gòu)趨勢的深刻考量。今天我們就來徹底拆解SpringBoot集成Lettuce連接Redis的完整流程不止于“怎么配”更要講清楚“為什么這么配”以及在實際生產(chǎn)環(huán)境中那些官方文檔不會告訴你的“坑”和“最佳實踐”。Lettuce是一個完全非阻塞的、基于Netty的Redis客戶端。它的核心優(yōu)勢在于支持響應(yīng)式編程模型能夠用少量線程處理大量并發(fā)連接這對于構(gòu)建高吞吐、低延遲的微服務(wù)至關(guān)重要。相比之下傳統(tǒng)的Jedis是阻塞式I/O每個連接在等待Redis響應(yīng)時會阻塞線程。在云原生和容器化環(huán)境下資源尤其是線程是昂貴的Lettuce的異步、非阻塞特性使其成為更自然的選擇。我們接下來的集成、配置和案例都將圍繞如何充分發(fā)揮Lettuce的這一特性展開。2. 環(huán)境準(zhǔn)備與依賴引入不止于spring-boot-starter-data-redis很多教程會告訴你引入spring-boot-starter-data-redis就完事了。這沒錯但如果你想真正掌控你的Redis連接理解背后的依賴關(guān)系是第一步。2.1 核心依賴解析在你的pom.xml中你至少需要以下依賴dependency groupIdorg.springframework.boot/groupId artifactIdspring-boot-starter-data-redis/artifactId /dependency引入這個starter后SpringBoot會自動為你引入spring-data-redis: Spring Data對Redis的抽象和模板支持。lettuce-core: 這就是Lettuce客戶端的本體。注意SpringBoot的父POM已經(jīng)幫你管理好了版本通常是最新穩(wěn)定版。spring-core等相關(guān)基礎(chǔ)依賴。一個關(guān)鍵的實操心得永遠(yuǎn)檢查實際引入的Lettuce版本。你可以通過mvn dependency:tree | grep lettuce來查看。不同版本的Lettuce在功能如Redis 6的ACL支持、Redis 7的新命令和Bug修復(fù)上差異很大。我曾遇到過生產(chǎn)環(huán)境因為Lettuce一個舊版本的連接泄漏Bug導(dǎo)致服務(wù)在流量高峰時僵死。所以在項目初始化或升級SpringBoot版本時確認(rèn)Lettuce版本是一項必做檢查。2.2 何時需要顯式引入連接池這是一個常見的誤解Lettuce本身不需要連接池嗎需要但和Jedis的物理連接池概念不同。Lettuce的連接StatefulRedisConnection本質(zhì)上是可復(fù)用的一個連接可以處理多個操作它內(nèi)部通過Netty的事件循環(huán)組來管理并發(fā)。所以你通常不需要像配置JedisPool那樣去配置一個龐大的物理連接池。但是Lettuce提供了一個稱為GenericObjectPool的包裝器位于commons-pool2用于緩存StatefulRedisConnection對象。這在某些場景下是有用的例如你的應(yīng)用是傳統(tǒng)的、大量使用同步阻塞式調(diào)用的服務(wù)并且連接創(chuàng)建成本較高。這時引入連接池可以避免頻繁創(chuàng)建和銷毀連接的開銷。如果你決定使用連接池需要額外引入dependency groupIdorg.apache.commons/groupId artifactIdcommons-pool2/artifactId /dependency并在配置文件中開啟它后面會詳述。我的經(jīng)驗是對于絕大多數(shù)基于SpringBoot 2.x的Web應(yīng)用尤其是使用了WebFlux或大量Async異步調(diào)用的服務(wù)直接使用Lettuce的原生連接管理即不啟用commons-pool2性能更優(yōu)資源利用率更高。只有在你的代碼模式是純粹的、高并發(fā)的同步阻塞調(diào)用時才需要考慮啟用連接池包裝。3. 基礎(chǔ)配置詳解從application.yml到RedisConnectionFactory配置是集成工作的核心。SpringBoot的自動配置為我們提供了很大的便利但知其然更要知其所以然。3.1 單節(jié)點Redis配置這是最常見的場景。在你的application.yml或application.properties中配置spring: redis: host: localhost # Redis服務(wù)器地址 port: 6379 # 端口默認(rèn)6379 password: yourpassword # 如果設(shè)置了密碼 database: 0 # 使用的數(shù)據(jù)庫索引默認(rèn)0 lettuce: pool: enabled: false # 默認(rèn)false即不使用commons-pool2。如果設(shè)為true則需引入commons-pool2依賴。 max-active: 8 # 連接池最大連接數(shù)當(dāng)enabledtrue時生效 max-idle: 8 # 連接池最大空閑連接 min-idle: 0 # 連接池最小空閑連接 shutdown-timeout: 100ms # 關(guān)閉客戶端時的超時時間當(dāng)SpringBoot應(yīng)用啟動時RedisAutoConfiguration會自動讀取這些屬性并構(gòu)造一個LettuceConnectionFactorybean。這個ConnectionFactory是Spring Data Redis訪問Redis的入口。這里有一個至關(guān)重要的細(xì)節(jié)spring.redis.timeout配置。這個配置項的單位是毫秒它表示連接超時和命令執(zhí)行超時。在Lettuce中這個值被同時用于SocketOptions的connectTimeout和TimeoutOptions的默認(rèn)命令超時。如果你不配置默認(rèn)值是2000ms2秒。在生產(chǎn)環(huán)境中這個值需要根據(jù)你的網(wǎng)絡(luò)狀況和業(yè)務(wù)對Redis的敏感性仔細(xì)評估。設(shè)得太短網(wǎng)絡(luò)輕微波動就會導(dǎo)致大量超時異常設(shè)得太長一個慢查詢或Redis節(jié)點故障可能會拖垮你的應(yīng)用線程。我通常的建議是在內(nèi)網(wǎng)環(huán)境下可以設(shè)置為1000-2000ms跨機(jī)房或云服務(wù)上可能需要適當(dāng)調(diào)高并務(wù)必結(jié)合重試機(jī)制和熔斷降級策略。3.2 哨兵與集群模式配置對于高可用場景配置會有所不同。哨兵模式適用于主從故障自動切換。spring: redis: sentinel: master: mymaster # 哨兵監(jiān)控的主節(jié)點名稱 nodes: # 哨兵節(jié)點地址列表 - sentinel1:26379 - sentinel2:26379 - sentinel3:26379 password: yourpassword # 主從節(jié)點的密碼如果一致Lettuce通過哨兵節(jié)點自動發(fā)現(xiàn)主節(jié)點和從節(jié)點并在主節(jié)點故障時完成切換。踩坑提示確保你配置的master名稱與哨兵中監(jiān)控的名稱完全一致大小寫敏感。另外哨兵節(jié)點本身也可能有密碼如果設(shè)置了需要通過spring.redis.sentinel.password屬性單獨配置這是一個容易被忽略的點。集群模式適用于數(shù)據(jù)分片。spring: redis: cluster: nodes: # 集群節(jié)點列表至少一個 - 192.168.1.101:7001 - 192.168.1.101:7002 - 192.168.1.102:7001 - 192.168.1.102:7002 - 192.168.1.103:7001 - 192.168.1.103:7002 max-redirects: 3 # 執(zhí)行命令時最大重定向次數(shù) password: yourpassword # 集群節(jié)點密碼在集群模式下Lettuce客戶端啟動時會連接你提供的其中一個節(jié)點獲取整個集群的槽位分布圖slot map并維護(hù)與所有主節(jié)點的連接。max-redirects是指當(dāng)客戶端請求的key不在當(dāng)前連接的節(jié)點上時節(jié)點會返回MOVED或ASK重定向錯誤客戶端根據(jù)此錯誤重新向正確節(jié)點發(fā)起請求的次數(shù)上限。3.3 自定義LettuceClientConfiguration如果你想進(jìn)行更精細(xì)的控制例如調(diào)整Netty線程數(shù)、配置SSL、自定義編解碼器或超時策略就需要通過Java Config方式自定義LettuceClientConfiguration。Configuration public class RedisConfig { Bean public LettuceClientConfigurationBuilderCustomizer lettuceCustomizer() { return clientConfigurationBuilder - { // 配置命令超時 TimeoutOptions timeoutOptions TimeoutOptions.builder() .fixedTimeout(Duration.ofSeconds(1)) // 固定超時1秒 .build(); clientConfigurationBuilder.timeoutOptions(timeoutOptions); // 配置客戶端資源如Netty事件循環(huán)組線程數(shù) // 默認(rèn)情況下Lettuce使用共享的、守護(hù)線程的EventLoopGroup。 // 在非WebFlux的Servlet應(yīng)用中通常無需修改。 // ClientResources resources ClientResources.builder() // .ioThreadPoolSize(4) // .computationThreadPoolSize(4) // .build(); // clientConfigurationBuilder.clientResources(resources); // 啟用SSL連接如果Redis配置了TLS // clientConfigurationBuilder.useSsl(); }; } }重要經(jīng)驗關(guān)于ClientResources客戶端資源。在SpringBoot的Servlet應(yīng)用如Spring MVC中默認(rèn)的ClientResources是全局共享的且其內(nèi)部的EventLoopGroup使用的是守護(hù)線程daemon threads。這意味著當(dāng)你的主應(yīng)用關(guān)閉時這些線程不會阻止JVM退出這通常是合理的行為。除非你非常清楚自己在做什么否則不要輕易創(chuàng)建和配置自己的ClientResources實例。錯誤地創(chuàng)建多個ClientResources而不關(guān)閉會導(dǎo)致內(nèi)存和線程泄漏。一個常見的錯誤是在Bean方法中直接new DefaultClientResources()卻沒有在任何地方調(diào)用.shutdown()。4. 核心使用方式RedisTemplate與StringRedisTemplate配置好連接工廠后我們就可以在業(yè)務(wù)代碼中操作Redis了。Spring Data Redis提供了兩個最常用的模板類RedisTemplate和StringRedisTemplate。4.1 RedisTemplate通用序列化操作RedisTemplate是一個泛型類可以操作任意類型的對象。它的關(guān)鍵在于序列化器Serializer。Autowired private RedisTemplateString, Object redisTemplate; public void opsWithRedisTemplate() { // 存儲復(fù)雜對象默認(rèn)使用JdkSerializationRedisSerializer要求對象實現(xiàn)Serializable接口 User user new User(張三, 30); redisTemplate.opsForValue().set(user:1001, user); // 獲取對象 User cachedUser (User) redisTemplate.opsForValue().get(user:1001); // 操作List、Set、Hash等數(shù)據(jù)結(jié)構(gòu) redisTemplate.opsForList().rightPush(myList, item1); redisTemplate.opsForHash().put(userHash, field1, value1); }這里有一個巨大的“坑”默認(rèn)的RedisTemplate使用的序列化器是JdkSerializationRedisSerializer。它會把鍵key和值value都序列化成二進(jìn)制格式。這導(dǎo)致你用redis-cli或其他可視化工具如Redis Desktop Manager直接查看時看到的鍵是亂碼類似\xac\xed\x00\x05t\x00\auser:1001。這非常不利于調(diào)試和排查問題。4.2 StringRedisTemplate字符串專精StringRedisTemplate是RedisTemplate的一個特化版本它的鍵和值序列化器都是StringRedisSerializer。這意味著它只能操作String類型的鍵和值。Autowired private StringRedisTemplate stringRedisTemplate; public void opsWithStringRedisTemplate() { // 存儲字符串 stringRedisTemplate.opsForValue().set(name, 李四); // 獲取字符串 String name stringRedisTemplate.opsForValue().get(name); // 存儲JSON字符串常用 ObjectMapper objectMapper new ObjectMapper(); User user new User(王五, 25); String userJson objectMapper.writeValueAsString(user); stringRedisTemplate.opsForValue().set(user:1002, userJson); // 獲取并反序列化 String json stringRedisTemplate.opsForValue().get(user:1002); User cachedUser objectMapper.readValue(json, User.class); }強(qiáng)烈建議在大多數(shù)業(yè)務(wù)場景下優(yōu)先使用StringRedisTemplate。原因如下可讀性強(qiáng)在Redis中存儲的是明文字符串調(diào)試極其方便。兼容性好JSON是跨語言的標(biāo)準(zhǔn)其他語言如Python、Go的服務(wù)也能輕松讀取你存入的數(shù)據(jù)。避免序列化陷阱JdkSerializationRedisSerializer依賴于Java的類路徑和序列化ID一旦你的實體類結(jié)構(gòu)發(fā)生變化如增加字段反序列化就可能失敗。而JSON序列化如Jackson通常更靈活。4.3 自定義RedisTemplate平衡靈活與可讀如果你既想存儲復(fù)雜對象又希望鍵是可讀的可以自定義一個RedisTemplate。Configuration public class RedisConfig { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory connectionFactory) { RedisTemplateString, Object template new RedisTemplate(); template.setConnectionFactory(connectionFactory); // 使用String序列化器序列化Key StringRedisSerializer stringSerializer new StringRedisSerializer(); template.setKeySerializer(stringSerializer); template.setHashKeySerializer(stringSerializer); // 使用Jackson2JsonRedisSerializer序列化Value Jackson2JsonRedisSerializerObject jsonSerializer new Jackson2JsonRedisSerializer(Object.class); // 解決Jackson反序列化時類型信息缺失的問題 ObjectMapper om new ObjectMapper(); om.setVisibility(PropertyAccessor.ALL, JsonAutoDetect.Visibility.ANY); // 此項必須配置否則反序列化LinkedHashMap等類型時會失敗 om.activateDefaultTyping(om.getPolymorphicTypeValidator(), ObjectMapper.DefaultTyping.NON_FINAL); jsonSerializer.setObjectMapper(om); template.setValueSerializer(jsonSerializer); template.setHashValueSerializer(jsonSerializer); template.afterPropertiesSet(); return template; } }這樣配置后你注入的RedisTemplate鍵是字符串值是JSON兼顧了可讀性和靈活性。注意om.activateDefaultTyping(...)這行代碼會在JSON中寫入類信息如“class”:”com.example.User”這確保了反序列化時能還原成正確的類型但也會使存儲的JSON體積稍大且?guī)в蠮ava類全限定名。如果只是存儲簡單的DTO且跨語言需求不強(qiáng)可以考慮使用不寫入類型信息的GenericJackson2JsonRedisSerializer但反序列化時會得到LinkedHashMap。5. 高級特性與生產(chǎn)級考量基礎(chǔ)集成完成后要上生產(chǎn)環(huán)境還有幾個必須關(guān)注的高級話題。5.1 連接健康檢查與?；钤陂L連接場景下網(wǎng)絡(luò)波動或防火墻超時可能導(dǎo)致連接假死。Lettuce提供了連接保活和驗證機(jī)制。你可以在配置文件中開啟spring: redis: lettuce: # 在從連接池借用連接時進(jìn)行驗證僅當(dāng)pool.enabledtrue時有效 pool: test-on-borrow: true # 定期驗證空閑連接僅當(dāng)pool.enabledtrue時有效 test-while-idle: true更通用的方式是通過LettuceClientConfigurationBuilderCustomizer配置ClientOptionsclientConfigurationBuilder.clientOptions(ClientOptions.builder() .autoReconnect(true) // 自動重連默認(rèn)true .pingBeforeActivateConnection(true) // 在激活連接前發(fā)送PING命令驗證 .publishOnScheduler(true) // 在特定調(diào)度器上發(fā)布消息用于Pub/Sub .socketOptions(SocketOptions.builder() .keepAlive(true) // 啟用TCP keepalive .build()) .timeoutOptions(TimeoutOptions.builder() .fixedTimeout(Duration.ofSeconds(5)) .build()) .build());生產(chǎn)環(huán)境建議務(wù)必開啟autoReconnect和TCP層的keepAlive。對于關(guān)鍵業(yè)務(wù)可以考慮在應(yīng)用層增加一個定時任務(wù)定期執(zhí)行一個簡單的PING或GET一個哨兵key來主動探測Redis服務(wù)的可用性并集成到你的監(jiān)控告警系統(tǒng)中。5.2 響應(yīng)式編程支持這是Lettuce相較于Jedis的核心優(yōu)勢。如果你在使用Spring WebFlux可以無縫使用響應(yīng)式的Redis操作。首先需要引入響應(yīng)式依賴SpringBoot WebFlux starter通常已包含dependency groupIdio.lettuce/groupId artifactIdlettuce-core/artifactId !-- 已由starter引入 -- /dependency然后可以注入ReactiveRedisTemplate或ReactiveRedisConnectionFactoryAutowired private ReactiveRedisTemplateString, String reactiveRedisTemplate; public MonoString reactiveGet(String key) { return reactiveRedisTemplate.opsForValue().get(key); } public FluxString reactiveMultiGet(ListString keys) { return reactiveRedisTemplate.opsForValue().multiGet(keys).flatMapMany(Flux::fromIterable); }響應(yīng)式API能夠更好地利用系統(tǒng)資源避免線程阻塞特別適合IO密集型的操作。注意混合使用阻塞式的RedisTemplate和響應(yīng)式的ReactiveRedisTemplate在同一個應(yīng)用中是安全的它們底層共享同一個配置的LettuceConnectionFactory。5.3 監(jiān)控與指標(biāo)集成了解Redis客戶端的行為對性能調(diào)優(yōu)和故障排查至關(guān)重要。Lettuce可以與Micrometer等指標(biāo)庫集成暴露連接數(shù)、命令延遲等指標(biāo)。如果你使用了Spring Boot Actuator并引入了micrometer-coreLettuce的指標(biāo)會自動通過/actuator/metrics端點暴露查找名為lettuce.command.*、lettuce.connection.*的指標(biāo)。你也可以通過自定義ClientResources來更細(xì)致地控制指標(biāo)收集Bean(destroyMethod shutdown) public ClientResources clientResources() { return ClientResources.builder() .commandLatencyRecorder(new DefaultCommandLatencyRecorder()) .build(); } // 在LettuceClientConfigurationBuilderCustomizer中應(yīng)用這個ClientResources監(jiān)控要點重點關(guān)注command.firstResponse命令首次響應(yīng)時間和command.completion命令完成時間的百分位數(shù)如p95, p99。這些指標(biāo)能直觀反映Redis服務(wù)器的性能以及網(wǎng)絡(luò)狀況。突然的延遲飆升往往意味著Redis負(fù)載過高、網(wǎng)絡(luò)問題或發(fā)生了慢查詢。5.4 常見問題排查與性能調(diào)優(yōu)連接超時ConnectionTimeoutException檢查網(wǎng)絡(luò)使用telnet或nc命令檢查從應(yīng)用服務(wù)器到Redis服務(wù)器的網(wǎng)絡(luò)連通性和端口是否開放。檢查防火墻和安全組確保云服務(wù)器或防火墻規(guī)則允許6379或你的Redis端口的出入站連接。檢查Redis配置確認(rèn)Redis的bind配置如bind 0.0.0.0和protected-mode配置如設(shè)為no或已配置密碼允許遠(yuǎn)程連接。調(diào)整超時時間適當(dāng)增加spring.redis.timeout或SocketOptions.connectTimeout。命令超時RedisCommandTimeoutException檢查Redis性能使用Redis的SLOWLOG命令查看是否有慢查詢。優(yōu)化你的業(yè)務(wù)代碼避免使用KEYS *、全量HGETALL大Hash等阻塞命令。檢查網(wǎng)絡(luò)延遲使用redis-cli --latency測試網(wǎng)絡(luò)延遲。分析命令復(fù)雜度確保你的命令時間復(fù)雜度是O(1)或O(log N)避免大Keyvalue過大和Big Key元素過多的集合?？紤]分片或升級如果數(shù)據(jù)量巨大考慮使用Redis集群進(jìn)行分片或升級Redis服務(wù)器配置。內(nèi)存不足OutOfDirectMemoryError這是Netty的堆外內(nèi)存溢出。Lettuce使用Netty而Netty默認(rèn)使用堆外內(nèi)存Direct Memory進(jìn)行網(wǎng)絡(luò)緩沖。增加JVM堆外內(nèi)存通過JVM參數(shù)-XX:MaxDirectMemorySize增加限制。檢查連接泄漏確保你的StatefulRedisConnection或RedisClusterClient在使用完畢后正確關(guān)閉close()。在Spring容器管理下通常不需要手動關(guān)閉但如果你在非托管環(huán)境中手動創(chuàng)建了客戶端務(wù)必注意。降低并發(fā)/數(shù)據(jù)量檢查是否單次操作的數(shù)據(jù)量過大如存儲一個幾十MB的對象或者并發(fā)連接數(shù)過高。性能調(diào)優(yōu)參數(shù)spring.redis.lettuce.pool如果啟用連接池根據(jù)實際并發(fā)量調(diào)整max-active建議等于或略大于應(yīng)用最大線程數(shù)、max-idle和min-idle。ClientResources.ioThreadPoolSize默認(rèn)等于CPU核數(shù)。對于高并發(fā)、大量連接的應(yīng)用可以適當(dāng)調(diào)大如CPU核數(shù)*2。但通常不建議修改除非經(jīng)過充分壓測。禁用DNS解析如果Redis主機(jī)名是固定的IP可以在連接字符串中直接使用IP避免Lettuce在連接失敗重試時進(jìn)行DNS查詢帶來的延遲。例如redis://192.168.1.100:6379。6. 實戰(zhàn)案例構(gòu)建一個帶緩存注解的用戶服務(wù)讓我們通過一個完整的、貼近實戰(zhàn)的案例將上述所有知識點串聯(lián)起來。我們將構(gòu)建一個簡單的用戶服務(wù)使用Spring Cache抽象并基于我們自定義的RedisTemplate來緩存用戶信息。6.1 項目結(jié)構(gòu)與依賴確保pom.xml包含spring-boot-starter-data-redis、spring-boot-starter-cache和spring-boot-starter-web。6.2 配置類RedisConfig.java包含我們之前定義的自定義RedisTemplate和緩存管理器。Configuration EnableCaching // 啟用緩存注解 public class RedisConfig extends CachingConfigurerSupport { Bean public RedisTemplateString, Object redisTemplate(RedisConnectionFactory connectionFactory) { // ... 同上文自定義RedisTemplate配置 ... return template; } /** * 配置緩存管理器使用我們自定義的RedisTemplate */ Bean public CacheManager cacheManager(RedisConnectionFactory connectionFactory) { RedisCacheConfiguration config RedisCacheConfiguration.defaultCacheConfig() .entryTtl(Duration.ofMinutes(30)) // 默認(rèn)緩存30分鐘 .serializeKeysWith(RedisSerializationContext.SerializationPair.fromSerializer(new StringRedisSerializer())) .serializeValuesWith(RedisSerializationContext.SerializationPair.fromSerializer(new GenericJackson2JsonRedisSerializer())) // 使用GenericJackson2JsonRedisSerializer不寫入類信息 .disableCachingNullValues(); // 不緩存null值 return RedisCacheManager.builder(connectionFactory) .cacheDefaults(config) .transactionAware() // 支持事務(wù) .build(); } }6.3 實體與服務(wù)User.java實體類。UserService.java業(yè)務(wù)服務(wù)類。Service public class UserService { Cacheable(value user, key #id) // 緩存key為user::id public User getUserById(Long id) { // 模擬從數(shù)據(jù)庫查詢 System.out.println(從數(shù)據(jù)庫查詢用戶: id); // ... 數(shù)據(jù)庫查詢邏輯 ... return new User(id, 模擬用戶 id, user id example.com); } CachePut(value user, key #user.id) // 更新緩存 public User updateUser(User user) { // ... 更新數(shù)據(jù)庫邏輯 ... System.out.println(更新數(shù)據(jù)庫用戶: user.getId()); return user; // 返回的結(jié)果會被緩存 } CacheEvict(value user, key #id) // 刪除緩存 public void deleteUserById(Long id) { // ... 刪除數(shù)據(jù)庫邏輯 ... System.out.println(從數(shù)據(jù)庫刪除用戶: id); } Caching(evict { CacheEvict(value user, key #id), CacheEvict(value userList, allEntries true) // 同時清空用戶列表緩存 }) public void deleteUserAndClearList(Long id) { deleteUserById(id); } }6.4 控制器與測試UserController.java提供RESTful API。RestController RequestMapping(/users) public class UserController { Autowired private UserService userService; GetMapping(/{id}) public User getUser(PathVariable Long id) { return userService.getUserById(id); } PutMapping(/{id}) public User updateUser(PathVariable Long id, RequestBody User user) { user.setId(id); return userService.updateUser(user); } DeleteMapping(/{id}) public void deleteUser(PathVariable Long id) { userService.deleteUserById(id); } }啟動應(yīng)用后你可以使用Postman或curl測試首次訪問GET /users/1控制臺會打印“從數(shù)據(jù)庫查詢用戶”響應(yīng)稍慢因為要查庫。再次訪問GET /users/1響應(yīng)極快控制臺無打印數(shù)據(jù)來自Redis緩存。訪問PUT /users/1更新用戶會同時更新數(shù)據(jù)庫和緩存。再次GET /users/1獲取到的是更新后的緩存數(shù)據(jù)。訪問DELETE /users/1刪除用戶會同時刪除數(shù)據(jù)庫記錄和緩存。通過Redis Desktop Manager連接你的Redis服務(wù)器可以看到以user::1為key存儲的是JSON格式的用戶數(shù)據(jù)。整個流程清晰緩存邏輯與業(yè)務(wù)代碼解耦得益于Spring Cache抽象和Lettuce的穩(wěn)定支撐。集成Lettuce的過程從簡單的依賴引入到深入的生產(chǎn)級配置是一個逐步深入理解Redis客戶端工作原理和Spring生態(tài)整合方式的過程。記住沒有一成不變的配置最好的配置來自于對自身業(yè)務(wù)流量模式、數(shù)據(jù)特性和運維環(huán)境的持續(xù)觀察與調(diào)優(yōu)。多看看監(jiān)控指標(biāo)定期進(jìn)行壓測才能讓你的緩存系統(tǒng)真正成為應(yīng)用的性能加速器而不是故障火藥桶。