网站内容更新策略(澄清一个问题，和常见的缓存策略不同，我们的策略将重点放在更新策略而不是)

　　网站内容更新策略(澄清一个问题，和常见的缓存策略不同，我们的策略将重点放在更新策略而不是)

　　上一篇文章简要设计了疯狂的代码缓存配置。可能有点模糊。几个朋友发了几个问题来讨论一下。有必要先澄清一个问题。与常见的缓存策略不同，我们的缓存策略将侧重于更新策略而不是只读策略。只读缓存和普通缓存策略的本质并不难实现。我们需要解决的是非普通缓存、并发更新缓存、可伸缩缓存、分布式缓存更新操作的问题，而对于普通的东西，我们可以很容易地实现，而不必做太多的计算。

　　想象一个问题。对于多用户并发系统，如果每个用户都维护一个缓存策略，同时又保证更新的及时性和处理的必要性，我们很难想出一个有效的处理机制。为了维护每个（每个用户）缓存的副本，缓存的存储性质也决定了进行分布式缓存策略处理的难度和分布式通信更新的难度。普通页面达到有效的缓存命中率，例如某个用户的博客。

　　缓存策略讨论要点小结

　　A. 基于海量非常用数据的缓存策略

　　B.基于数据缓存级别并发更新的缓存策略

　　C.基于并发数据存储的缓存策略

　　D. 分布式缓存策略

　　E. 基于搜索的缓存策略

　　我们不会在这里详细介绍页面静态和类似问题。静态的情况非常适合在用户基数不是很大的系统前期实现，但是在集群的情况下，静态实现的成本、IO成本、维护成本、扩容成本和更新成本都会远超过缓存策略的成本。当然，我们也会有一套基于缓存的静态处理方案，后面会讲到。我们的目的是建立一个可扩展且易于维护的扩展缓存策略。下面就具体问题进行分析。

　　对于问题 A：

　　常见的博客系统就是最好的例子。每个用户的首页都是比较个体的数据，没有太多的共性。对于一个常见的处理方案，我们可能需要维护每个用户访问的缓存副本。对于一些访问量很少的博客网站，这种方法无疑会造成巨大的浪费。

　　对于大量不常见的数据缓存，几种解决方案：

　　1) 量化缓存目标并分配相应的缓存权重。（重量等级）

　　目的很简单，只缓存有效数据。首先，提取活跃用户和高流量用户，将数据分组到去中心化的系统中进行缓存（对于基于好友的SNS系统，我们称之为美女效应）

　　2) 为非连接持久性保留缓存（临时持久性）

　　珍惜并有效使用数据查询，将未命中缓存的查询或无权重的数据（序列化存储静态存储等）持久化，缓存未命中时优先考虑持久化数据而非数据查询。可以理解为临时数据存储，或者临时存储在子服务器的某个位置。

　　3) 基于数据更新的缓存清除（一次性使用）

　　当持久化缓存仍然无效（依赖数据被修改）时，直接删除临时数据（缓存只有在被访问时才被激活和存储，一旦被修改或失效，我们立即丢弃）。

　　4） 缓存更新代理规则

　　由另一个线程维护，并维护线程的有效性，最大限度地分离主程序清理无效缓存和临时持久缓存数据

　　对于问题 B：

　　在小型缓存策略中，对于每个请求，缓存处理对于整个应用程序都是唯一的，可操作的和非物理存储的。在并发更新的过程中，一个小的并发更新会有效的清空所有缓存池，导致缓存命中率极低，初始化率极高，无法发挥缓存策略应有的作用。

　　在这种情况下，处理方案与A.4中提到的方案相同，由一个独立的缓存更新进程处理，应用程序中所有涉及缓存更新的请求都由一个专门的更新代理执行。这个方案比较简单，这里不再赘述。

　　对于问题 C：

　　上一篇文章已经提到了并发数据更新带来的问题，即数据库I/O响应、超时、死锁、线程阻塞。我们使用写缓存来处理这个解决方案。其实这并不是传统意义上的读缓存。我们把它命名为写缓存。我们可以把它想象成一个类似于硬盘缓冲区的问题。这里处理的操作有点多，还涉及到更新只读缓存的问题。

　　根据系统的不同，我们需要从不同的角度进行分析和处理。我们以一个常见的网页游戏为例，简单介绍一下处理机制。这里有两种常见的情况。

　　1）对于网页游戏的终端玩家来说，每个在线用户的数据是不常见的（问题A），在一个战斗场景中，每组数据都在不断变化。更改以数据库日志记录的形式保存的情况显然给数据库带来了很大的压力，我们需要记录的只是战斗的结果。我们根本不需要保存战斗过程。这时，我们使用写缓存来执行相应的数据操作。这个过程很简单，可以通过服务器变量的形式来解决。

　　2）对于网页游戏的服务器角色，如果战斗场景中的用户数非常多，数据更新量非常大，我们可能无法使用方法一中的处理。这时候，我们可以利用缓存进一步抽象在一定的时间段内（比如3分钟）内维护一个唯一的缓存对象，在这段时间内所有的数据操作都由缓存进程记录和更新。异步定时数据保存操作由另一个进程执行。

　　对于问题 D

　　这是一个比较常见的分布式缓存服务器组，而对于缓存服务器来说，要解决的问题是服务器之间的通信问题和保证数据一致性的问题。那么我们有四个处理规则：

　　1）数据缓冲区应该被有效地分组和索引

　　目标是实现数据耦合的最小化甚至无耦合。比如按用户ID划分的数据缓存分布，或者按文章分类划分的缓存分布

　　2）数据缓存应该有效更新

　　如果数据被有效分组，这就是问题 C.2 的解决方案。与C.2不同，因为缓存组不一定在一组服务器中，可能会涉及到缓存和DATABASE数据通信延迟的问题。这时，为了保证缓存服务器立即下发到数据库，需要另外一个缓存检测过程来完成这项工作（数据完整性检查，并备份两个缓存段的数据）

　　3）缓存服务器之间的数据完整性

　　对于不能分组的数据，比如用户认证数据和一个时间段内的数据数据，我们需要保证两组数据是同步的。最好的处理方法是清除相应的缓存段，让其在下次使用时进行初始化。

　　4）缓存服务器之间的连接

　　这取决于物理线路。如果缓存服务器位于世界上，我们还需要一个队列进程来进行同步和数据校正，我们称之为缓存路由。

　　对于问题 E

　　在分布式缓存的情况下，多条件搜索往往会涉及到多台缓存服务器，作者还没有拿出完整的解决方案。作者采用敷衍原则和整合原则。

　　敷衍原则：

　　对于搜索类型的数据，在很多情况下并不是很重要。我们的搜索结果可以稍后提供给用户，允许搜索数据延迟 10 分钟或更长时间。

　　整合原则

　　整合搜索字段和表格，并使用单独的只读查询服务器来分担负载