关于数据缓存策略方面的疑惑

Question

以下类型的sql语句，是否需要缓存，怎么缓存，更新策略比较疑惑，望指点

• 关联查询

• 条件范围查询

• 动态条件组合

频繁的数据更新，需要数据实时的系统（CRM）是否适合引入缓存

Answer 1

缓存要把控好，没有十全十美的实现，技术是永不停止的进步。
你的数据更新比较频繁，那就没有必要缓存了，可考虑加redis队列，防止堵塞。也可以配合swoole使用异步加载实现。
多用非关系型数据库，这样性能会提升一些。 如果在高并发情况还是实在不行的话，就再加几台服务器，利用负载均衡 lvs 来可实现减轻部分服务器的负载，redis最好部署分布式。

Answer 2

我觉得缓存策略主要还是有业务决定的吧

Answer 3

更新频繁的数据不适合缓存

Answer 4

频繁更新数据用redis吧，

Answer 5

redis 挡在mysql前面是为了防止请求量过大给mysql造成过高负载而导致服务性能降低或者直接不可服务

这样子做主要是大量查询的情况下，可以直接redis获取就返回不通过mysql
如果新增和更新操作特别频繁，查询操作相对较少，那层redis缓存就没意义了，甚至时累赘。
你每次更新/新增都要写mysql这个是避免不了的，要是加了缓存你还要写缓存，还要确保缓存mysql数据的一致性。

Answer 6

关于查询，通常都可以缓存，只是缓存的时间需要把控好，然后就是更新策略，最简单的策略就是不需要什么策略。请求到达之后先读缓存（如redis），读不到就去读库或者下一级缓存。然后比较有意思的更新策略是主动更新，就是前端请求只去redis里面读数据，没有就返回空，然后后端脚步负责同步数据到缓存中，具体做法可以在每次数据变动之后就记录一下，然后脚步定时读取变动项，然后主动刷缓存。热点数据就那么多，基本上可以满足，如果担心数据一直没更新，前端来读的时候由于缓存过去没读到，那么可以在读不到的时候也记录一下，这样过会儿后端脚步就会刷一份缓存进去，这样就保证了。

实时的更新，如果不允许有秒级的延迟的话，那么就只能不用缓存了，然后建议是使用非关系型数据库了，不然关系型数据库怕是难以支撑。