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

[FeifeiJin]

我们以前的系统，缓存和数据库同步修改。 系统启动时，加载必要数据到内存里。 所有底层业务都基于缓存数据来进行的。

比如，查询，只从缓存里取，这个倒好改，改成缓存没取到，其查数据库就好了。 删除，它时优先删除缓存里的，根据 key 删除一个缓存对象，并且返回这个缓存对象，再取数据库删除这个对象。

1，现在要先删除数据库，再删除缓存。 2，工作量巨大，各种细枝末节的地方。 3，所有的逻辑都是基于缓存的，没得缓存层改动的逻辑真时多到吐血。

v 友们， 是否有相似经历？

[rushssss]

为啥要这么改

[akira]

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

[metrxqin]

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

[FeifeiJin]

@akira

[FeifeiJin]

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

[FeifeiJin]

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

[FeifeiJin]

@metrxqin
赞成。

[lovedebug]

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

[FeifeiJin]

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

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

[HuHui]

可以参考红薯的 j2cache

[FeifeiJin]

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

[sagaxu]

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

[swulling]

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

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

[keramist]

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

[ghos]

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

[swulling]

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

[cheava]

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

[gemini767]

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

[yunshansimon]

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

[ljzxloaf]

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

[FeifeiJin]

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

[FeifeiJin]

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

[FeifeiJin]

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