@THESDZ 学习到了，非常感谢

@dqzcwxb 是的，这就是我所不满意 Spring Cache 所作的：“将命名空间下所有缓存删除”；这篇文章中“针对一个表的某些操作不在他独立的 namespace 下进行。”这句话也就是之前所说外键之间的无奈，所以我仍然认为 service 中进行外键数据填充操作是最佳实践。
不过言归正传，Kache 因为缓存实体是分离的，对于条件方法之间的缓存是以索引的形式再次指向实体的结构，因此当实体更新时不会像 spring cache 将缓存全盘删除，而是仅仅将多个条件方法的“索引缓存”（类似一个 list<指针>）删除掉，相较于 spring cache 来说可以避免缓存的重复序列化而可以再删除后写入缓存时只需要存入索引缓存即可，避免数据序列化和冗余。并且因为获取缓存脚本与本身缓存结构，缓存删除与读取是无锁并行的。

@233373 最近了解的一个嵌入式开源社区貌似有把前后端代码开源：
前端： https://github.com/rymcu/nebula
后端： https://github.com/rymcu/forest
社区网站： https://rymcu.com/

@dqzcwxb 在过期时间上的处理话，在存入缓存时会先向 redis 中去重，得到缺少的数据再存入，而重复的 id 则会延长存活时间。而刷新策略目前属于较为悲观的该类型所有索引缓存全删，不过相对于 spring cache 的缓存删除成本来说小很多。目前的数据冗余判断依据是依照数据库中主键的概念，做不到非常深层次的数据重用。

@fzdwx 因为看到了你的浏览记录，感觉 websocket spring boot starter 很不错，所以 star 了一下

@fpure 项目驱动学习，原型只是一个 AOP ，再逐渐变成 spring starter 再分离变成 Proxy 与 spring starter

@dqzcwxb 本身定位的话仍然是主要面向数据库 IO 的，而您说的问题大多是牵扯到外键，本身这个框架是可以与 Spring Cahe 结合，可以做到 Spring Cache 负责 Service 层用于外键的 Bean 装填处理，而 Kache 应当做好的是对数据库的一层旁路，用于最大化避免数据重新走入数据库之中，目前 Kache 对于数据的感应都是通过应用的，也是兼容分布式的，但是如果是外置工具操作数据库的话确实可能会导致数据变化而 Kache 无法感知，后继有使用 binlog 等手段的可能。
简而概之就是尽可能不要要外键填充的操作放入的持久化操作之中，否则持久化的方法难以复用并且会导致数据千变万化，Kache 本身注解有个 involve 属性用于干涉其他 Bean 类型缓存的清除，但尚未有完美解决这个问题的方案