聊聊缓存重构的事儿，老系统缓存和数据库数据同步，现在改为按需加载。。要死

为啥要这么改

是内存不够 i 还是程序启动太慢，不是必须的话 没必要去改的啊

20% 的数据 80%的时间都在使用。

@akira

@akira
有做集群，现在启动太慢了。挂了的话，不能迅速启动。
假设我现在有 A/B 两个节点，其中一个挂了，导致另一个负载上升，随之久挂了。
这个时候再启动 C，可能要花半小时。
改完后 B 挂了，可以立即启动一个 C 来支撑运行。
要保证加载速度，所以这样改。

@rushssss
做了集群，启动太慢。挂了重启太耗时。

@metrxqin
赞成。

启动的时候全加载到缓存，只会让老的挂的更快。不如做成多级缓存。另外用的 redis 吗

@lovedebug
以前就是启动的时候全加载了，现在改了。
Redis 也在改造计划中。

可以理解为内存的压力现在部分分散到数据库和 Redis 中。
但没做多级缓存。Redis 和现在 Memory 是同级别的。

可以参考红薯的 j2cache

@HuHui 看了下。思路可行。
但我们是 .net 的项目。

@FeifeiJin 你需要的是热备，不能 abc 都启动吗？挂掉一个，剩下两个也能抗住，有足够时间慢慢恢复。

这就是业务层去做缓存逻辑的弊病。

业务层应该看不到缓存，直接操作。缓存是底层数据层自己实现的。这样改缓存逻辑。只需要改底层就好了。

系统架构有问题 三台服务器负载均衡 挂一台还有两台顶着 最好四台 万无一失

@swulling 其实我觉得应该是根据业务来定义缓存内容，数据层并不知道这个数据适不适合缓存，但是缓存存取逻辑应该由框架统一处理 不应该由手写代码处理。

@ghos 可以传入一些控制参数给数据层，但是使用缓存的方式要做到和没有缓存一样才好。

之前看《大型网站架构演化》作者提出了统一数据访问模块，包括了缓存和数据库的访问处理，业务无感地获取数据，目前也没看到有相应的开源方案或框架

@swulling 过于理想化了，db 肯定要有缓存，但那也应该是热点数据。而不应该来承载整个业务的缓存，业务有自己逻辑，写缓存和读缓存业务并不相同。反而数据由于统一底层承担增加数据损坏的风险。

那要看你的数据操作使用那个级别的对象。最差的情况下，数据操作没有单独的界面，缓存操作充斥各个对象。按照以下步骤进行重构：1.重写一个缓存对象，100%复制原来的从对象名到接口 api 的规范，包裹原来的缓存对象，然后，不做任何修改，转发到原来的 api 上，上线测试。目的：用于找出所有使用的 api。2.为新的缓存对象建立 hook api，类似 before_xxx，和 after_xxx 的调用。将调试日志写到 hooks 里，保证 hooks 都可用。3.将新逻辑写到 hooks 里面。

1.有必要，因为先删缓存再删数据库，数据库失败就 gg ；而先删数据库，即使缓存删除失败也就影响一段时间。可以搜下 58 沈剑的相关博客 2.抽象一下缓存逻辑，也可以找找这类开源框架。这是很普遍的业务场景，早就有成熟方案了

@yunshansimon 这个感觉风险会相对较小。我扩展下这个思路

@ljzxloaf 恩，我去搜搜看，谢谢你

@sagaxu 架构不支持热备。现在就是服务启动过慢。一个 Remoting 服务，启动要二十分钟左右。
以前架构是，启动时把许多数据加载到服务里。比如组织机构人员，20W 数据，而且还有各种关系。
现在不在启动时候加载。