关于缓存

第一步不用cache

1，可以不用缓存，数据库优化，应该可以抗的住

目录树，cms属于必然加载的东西，而且更新不大，可以考略cache本地，然后一段时间cacheput

产品页面其实最想缓存，然而问题很大

打折信息，在优产品的地方就有她们（5条join信息，最终也要9条query）也不经常变化

可能会在第一步使用

第二步

2，管理后台更新后直接刷新远程各个网站的数据，并且要求一定刷新成功，数据同步有延迟，刷新时间也要求有延迟（3秒后应该在执行刷新缓存的问题，这样基本所有数据库都同步完成）

cache key采用统一标准，并且有专门的rest请求来刷新cache，手工/自动保存数据

如果刷新cache放在repo层次

如果cache放在service层

如果cache放在aop层（拦截service save，delete，update）

如果cache放在controller层

还有统一管理cache的连接，直接手工刷新cahce

实际操作流程

所有前端都保留一个开放的rest接口,并且rebot.txt禁止收录

前段不该保存一个永久的cache，即使没人刷新，也要自动刷新，只不过时间久一点比如一天一次

如：https://sale.cool/cacheReset/categoryTree

cacheRest为固定前缀，categoryTree为方法名，方法内部调用cachePut标注的方法

如

@CachePut（name=“category”,key=“tree”)

Public Tree(){return tree}

还有cache Delete rest服务

Interface method可以cache，不过key值是个问题，好像不能用enum

标准是这样的：

Cache层其实位于repo和service之间，放在data package中，单独分出一层叫cachelableRepo，这里建立cache，service中建立一个cacheManagerService（用来刷新，清除cache）最终被controller调用

我的方法（粒度很大），简单粗暴，问题多

cache放到service，且schedule，restcontroller调用手工刷新

* cachable应该直接注解在mapper，repo上，少写一层

cacheserviceManager依然需要，统一刷新，删除cache

难点：无法判断刷新的方法并且调用

repo上的cache貌似只能清理，不能刷新，清理直接spring cache manager即可

刷新可以采用，先清理，再重新调用的办法，cachemanagerservice需要分开管理cat，product，discount

各种细节依然要把握好

还有30天重建所有缓存，防止脏数据不断在内存积累

用不用缓存，repo层悬殊很大

必须穷举所有用到的缓存

缓存不能存关联表，只能缓存自己

缓存问题已经可以通过远程解决！！，天真了

缓存需要很小的粒度，和mybatis的延迟加载还有冲突。。。

第一步就忘了它吧，只保留目录和cms的缓存吧

！！！mybatis延迟加载不能被cache，否则deserialize后无法执行，要么直接join，要么改为egar

,这种结果其实是合理的，既然缓存，却是lazy（调用的时候还有sql语句），证明缓存失败了