总得来说，不同的场景使用不同的缓存策略，大方向上可以分为细粒度与大粒度缓存
1：细粒度来说，缓存的更新、与同步精确到每一个 model，例如 jfinal 对所有的用户 model 采用的细粒度方案，因为整个社区处处都要用到不同用户的头像、昵称、id 这样的数据，当某个用户的数据更新了，只需要清掉缓存中的对应的用户就行

2：大粒度来说，缓存的是整个 list、paginate 之类的数据，例如对于所有 project 数据，缓存 list，当 project 中任何数据有更新时，清掉缓存中的整个 list 缓存

以上关于缓存粒度的问题细节不再多说，下面给出在使用缓存时的一些经验：
1：先假定缓存不存在，先实现功能，业务功能不依赖于缓存，缓存只作为一个辅助
2：引入业务层，将所有业务放在业务层之中，并且极度重要的是对于某个 model 的数据库操作尽可能放在这个 model 所对应的业务中，不要要数据库操作散步到其它业务中。 好处是当前业务可以很方便地维护自己该负责的缓存，例如：project 这表表对应的是 ProjectService，里面有 getById、deleteById、update 这样的方法，当用户使用 getById 的时候先是从缓存取，缓存没有的时候则从数据库取并存入缓存。然后 deleteById、update 这样的方法中，只需要 remove 掉相应的缓存就可以了，下次 getById 到来时自然会去库中得到最新数据。其它业务需要使用 project 数据时，只能通过 ProjectService 来获取，这样的话，整个 project 的缓存逻辑全部只由 ProjectService 负责，对外界是透明的，极度可靠

3：每个 service 类中都有一个 private void clearCache(int id) 这样的方法，只供该业务的其它方法调用，例如 delete、update 这类方法在最后一行，总是调用一下 clearCache(id)
4：如果其它业务一定要要直接查询数据来获取其它业务的数据，例如在 UserService 中获取本该由 ProjectService 来管理的 project 表中的数据，那么查询得到的结果不能缓存，否则内存中会有多个版本

@JFinal 恩，波总说的这样，我全部理解了，但是涉及到我问题的第一点，不知道波总有没有什么建议可以处理findByOther的缓存数据？我现在想到的只是，必须先去获取findById的数据（可能在缓存中），然后才能获取到指定的colunm，再去删除findByOther的数据

@潇洒太爷 findByOther 可以是整个清掉缓存，这个属于大粒度使用缓存，还可以引入两级缓存，一级让这个 findByOther 只缓存 id 值的列表，如 List idList，通过列表再去二级缓存中去取具体的 model值，好处是不担心 update 操作，总是获取到最新的

至于对于 delete 操作，可以是整体清掉 id list，也可以是在读二级缓存时，发现得到的是 null，此时就断定有数据被 delete，那么 id list 也需要重新查库

做缓存没有很通用的方式，只能根据情况来做选择，但以上谈到的让 XxxService 统一管理 Xxx 的缓存是极重要的，其它的 YyyService 需要 Xxx 数据时，只能通过 XxxService 来获取，不能自己直接查库获取

@JFinal 感谢波总的回复，再仔细捉摸一番

精华问答