redis缓存逻辑问题

博客将文章数据放入redis，当文章有修改的时候才清楚缓存，文章数据有个字段为浏览量，因为打开文章即浏览量就要+1，按照逻辑来说文章数据改变了， 应该要写入数据库了，这个逻辑下来那么缓存完全没用了，毕竟一打开这篇文章数据就发生了改变，就要清除缓存从数据库过去。这个问题该怎么处理呢，是我的逻 辑不太对吗？

这是业务逻辑存在问题吧

那么逻辑该如何修改吗？

浏览量是个不需要太精确的数字，可以一段时间更新一次数据库，其他时间只更新缓存

将文章内容和浏览量这样的数据分开使用不同的key来缓存。

我也是这么想的，还有个问题，如果用户选择按浏览量排序文章的话，那么先把缓存中的浏览量更新到数据库中，再从数据库中查找记录(这是我的想法，你觉得如何)

那么获取数据的时候要获取两个缓存，文章和浏览量，再合并数据，是不是有点繁琐

如果你频繁修改一个缓存，缓存也频繁更新。但是问题在于，这个缓存到底会不会被频繁访问到？举个栗子，一个缓存涉及的表的字段，在 1 分钟内就修改 了 20 次，或者是 100 次，那么缓存更新 20 次，100 次；但是这个缓存在 1 分钟内只被读取了 1 次，有大量的冷数据。实际上，如果 你只是删除缓存的话，那么在 1 分钟内，这个缓存不过就重新计算一次而已，开销大幅度降低。

其实删除缓存，而不是更新缓存，99LRC歌词就是一个 lazy 计算的思想，不要每次都重新做复杂的计算，不管它会不会用到，而是让它到需要被使用的时候再重新计算。像 mybatis，hibernate，都有懒加载思想。

不太明白，版主，那你觉得我的逻辑该怎么修改合适呢?

如果你是每次浏览都刷新数据库就不对了，那用redis就没多大意义了。

我的想法访问量没必要做到实时，打算半小时更新数据库一次

这个就要具体情况具体分析了。
比如热门的网站，由于访问量大，不是以时间为条件，而是比如每访问多少次就更新一次。
如果访问量不大的话，半小时也可以，不行再改呗。

首先要做这个排序，如果数据量不大可以将redis中的数据拿出来再排序，其次点的redis也支持可排序的数据类型。
你想用户选择浏览量排序时，就更新数据到缓存，这里如果用户点击频繁，redis就失去其意思了，什么都不做，也只做一次查询，现在变成了一次更新，一次查询，负担更重

浏览量增加了，为什么不单独修改浏览量，而把文章缓存删除掉呢？

浏览量还有有一些逻辑的，比如相同ip或者账号访问多次，也只算一次。
浏览量准确度一般要求不是特别高。缓存起来实时性不特别准，影响也不大。

文章内容为什么放redis，这种比较大的数据建议另外选择存储结构，如果存储过多会触发LRU，如果非要放的话可以选择hash结构，将内容与浏览量放不同的key，更新只更新浏览量就行了。个人建议。

将文章内容和浏览量这样的数据分开使用不同的key来缓存。

这个解决方案是最好的。

这样的话需要从缓存取数据，修改数据，再填入缓存

有考虑过，现在想先把现有的问题解决下再处理这个问题

使用Redis只是希望访问的时候可以快些，感谢建议

访问量我们设计了一个单独的模块来存储,而不是直接保存在文章表上的,这样就避免了你的问题,也减少文章表的读写频率

关键是有很多模块都需要访问量,所以拆分出来也能减少其他模块的工作量,也能单独优化

可以将文章内容，点赞浏览，评论这几个分开，浏览和点赞这种实时变化的数据先存储在redis再定时更新到数据库，请求时直接读取数据库

比如网易的点赞，点一下加1，刷新页面又变回原来的数值了，等一段时间才是正确数值。

也可以写入本地内存，异步线程定时入库，但是如果存在多台服务器，可能出现数据不一致的现象。

关键还是你们对这个浏览量是否要求实时。

这个东西应该不需要实时，只是搭建个人博客，碰到这个问题了，就来问问各位大佬的想法，自己有点凌乱

个人博客，那肯定只有一台服务器，用什么Redis啊？直接存内存就好了，然后5分钟刷一次数据库，实时高效。
多一个中间件，故障概率多一层

如果是要做大做强，那应该拆分成2个服务，
一个文章服务，只负责维护博客的增删改查，根本不管访问、评论、点赞啥的，
该服务把所有的操作，都发消息出去
另一个统计服务，接收消息，进行访问统计、编辑统计、点赞统计啥的，并提供查询接口（缓存实现也是统计服务完成）

设计上的繁琐带来运行上的高效分两表，先缓存再写入

你要讨论的是个数据库服务底层实现有关的问题。redis是个大型服务集群方案，为了提供更大的访问通过能力需要进行非常复杂的优化措施。类似的系统，比 较常见的优化有：针对检索和常用查询进行优化的方案；针对频繁写入和改变进行优化的方案；针对通讯负载进行的优化；针对分发复制与同步进行的优化。这些优 化大都需要消耗大量的系统存储资源，一个几十k的数据集，可能需要占用几百M、甚至上G的内存来进行服务。所以，你们对于数据库系统的解题思路缺乏了解。