This topic created in 37 days ago, the information mentioned may be changed or developed.
更新数据库的同时 紧跟着更新缓存, 这个缓存不是 redis 缓存, 而是一个 local 的 hashmap
譬如, 数据库的结构体是 ConfigModel 这个 map 是[id]ConfigModel 的类型.
这两步操作是否可以放到一起, 到 repo 层来处理
譬如 ConfigRepo.UpdateConfig(configModel){
ConfigModel.updateDB(configModel)
localCache.update(configModel)
}
还是说两个操作要分开, 在 service 中分别调用?
6 replies • 2026-06-18 15:42:20 +08:00
 |
|
1
crysislinux Jun 18 via Android
你可以在 service 发一个写入的 event ，cache 的部分加一个 hook 来处理 event ，这样逻辑上就解耦了
|
 |
|
2
zhudan Jun 18
 还在研究这玩意儿呢，是我穿越了么  |
 |
|
4
zh3256 Jun 18 via Android
代码分层是为了对人更友好，目前的情况可以试着对大模型更友好一些，减少分层，让模型一次尽量拿全信息。
|
 |
|
5
Ayanokouji Jun 18  4
强一致性可以考虑事务，将缓存放到事务中，优雅点的的写法，可以参考 spring 的 transaction event ，使用 event 。
非强一致性，这样写也不会有多大问题，大不了查询的时候再查一遍，除非你业务能达到缓存穿透的并发量，不然两者没啥差别。
ps：求学有什么可嘲笑，啥都不懂就能用好大模型了吗
|
 |
|
6
credo123 Jun 18
我这面是直接在 repository 层方法里处理了。缓存（ redis/caffine ）+DB （ JPA/mybatis ）。repository 监控指标也底层改了下，监测到有 sql 执行才会记录指标。
开发人员多的情况下，一个 model 层对应的缓存处理只在 repository 层方便所有人通用。如果是在 service ，代码多起来很难看，很难通用。如果是 springCache 那种，注解散在各个 service 中，实际开发会很难受。
service 就处理业务，别让他参合 DB 层的东西了，不管是 DB 的缓存还是直接取 DB 的数据。
我也考虑过，再多一个缓存层，后来想来想去觉得没必要就没搞。
|
Select Language