【转】疯狂代码.docVIP

上篇对疯狂代码缓存配置进行了概要的设计，可能说的有点模糊了，有几个朋友发了几个问题探讨了下，这里有必要先澄清一个问题，和常见的缓存策略不同，我们的缓存策略将重点放在更新策略而不是只读策略上。只读缓存以及共性缓存策略性质实现的难度并不大，我们要解决的是非共性缓存，并发更新缓存，可扩充性缓存，分布式缓存更新运算的问题，而对于共性的东西的话我们可以很轻松的实现，而不必做太多的运算。 试想一个问题，对于一个多用户的并发的系统，如果对每个用户都维护一份缓存策略还要保证更新的及时性以及处理的必要性来说的话，我们很难想到一个有效的处理机制来维护每份（每用户）缓存的副本的，缓存的存储性质也决定了做分布式缓存策略处理的难度和分布式通讯更新的的难度，我们也很难尝试对于一些访问量很小且少有共性的页面实现有效的缓存命中率，比如某某用户的博客。 简单的总结了一下关于缓存策略讨论的重点 A.???? 基于海量非共性数据的缓存策略 B.????? 基于数据缓存级别并发更新的缓存策略 C.???? 基于数据并发存储的缓存策略 D.???? 基于分布式的缓存策略 E．基于搜索的缓存策略 我们这里不再赘谈关于页面静态化以及类似的问题，静态化的情况非常适合在系统初期，用户的基数并不算很大的情况下实现，而在涉及集群的情况下，静态化的实现成本，IO成本，维护成本，扩充成本以及更新成本会远远的超出缓存策略的成本，当然我们也会有一套建立在缓存基础上的静态化处理方案，这些放在以后再谈。我们的目的是要建立一个可伸缩，便于维护扩展的缓存策略，下面就具体问题进行分析。 对于问题A： 常见的博客系统就是一个最好的例子，每个用户的首页都是相对个性的数据，共性的地方不多，以常见的处理方案来说的话，我们可能需要维护每个用户访问的缓存副本，而对于一些访问量极小的博客站点来说的话这种方式无疑会造成巨大的浪费。 对于大量非共性的数据缓存来说，几个处理方案： 1)????? 量化缓存目标并分配相应的缓存权值。（权值分级） 目的很简单，只缓存有效的数据。首先抽取活跃用户，以及高访问量用户，将数据进行分组分权制缓存（对于交友型的SNS系统来说，我们称之为美女效应） 2)????? 非连接持久性的缓存保持（临时的持久性） 珍惜并有效利用数据查询，将未被缓存命中时的查询或者无权值的数据持久化保存（序列化存贮静态存贮等），当缓存未被命中时优先取得持久化数据而非数据查询。可以理解为临时数据存贮，或者临时存贮于子服务器的某个位置。 3)? 基于数据更新的缓存清除（一次性使用） 当持久性缓存保持失效（依赖数据发生修改），直接删除临时数据（缓存只在访问时被激活并储存，一旦修改或者失效，我们立刻抛弃）。 4）缓存更新代理规则 由另外的线程进行维护，并维护线程的有效性，最大限度的分离主程序对无效缓存以及临时持久性缓存数据的清理 对于问题B： 在小型缓存策略中，缓存处理对于整个应用程序对于每个请求来说都是唯一的，可操作的和非物理存储的。而在并发更新的过程中，一个小小的并发更新就会很现实的清空所有的缓存池，造成缓存命中率奇低而初始化率奇高而起不到缓存策略应有的作用。 在这种情况下，处理方案也和A.4中提到的方案是一样的，由独立的缓存更新进程来处理，对于应用程序中所有涉及缓存更新的请求由专门的更新代理来执行。这个处理方案相对简单，不再赘述。 对于问题Ｃ： 上篇已经提到关于并发数据更新会带来的问题也就是数据库的I/O响应，超时，死锁，以及线程的阻塞问题。我们用一个写入缓存来处理这个方案，其实这个并非传统意义上的读缓存，姑且命名为写缓存吧，我们可以形象的理解为类似硬盘缓冲区的问题。这里处理的操作稍微有点多了，还要涉及只读缓存的更新的问题了。 根据系统的不同，我们需要分析处理的角度也不同，我们以常见的webgame为例来简单介绍一下处理机制，这里有两种常见的情况 1） 对于 webgame的最终用户玩家来说，每个在线用户的数据是非共性的(问题A),而在一个战斗场景下，每组数据时刻都在变化之中，如果我们对数据的变化采用数据库日志记录的形式保存的情况显然对Database的压力很大，而我们需要记录的仅仅是战斗的结果，战斗的过程我们完全没有必要进行保存，这个时候我们就用写入缓存来执行相应的数据操作。这个处理很简单，用服务器变量的形式就能解决他。 2） 对于 webgame的服务器角色来说，如果战斗场景的用户量非常多，而数据更新非常大的情况下，我们采用方法1中的处理也可能力不从心，这个时候我们可以将缓存来进一步的抽象，在某个时间段内（比如3分钟），维护一个唯一的缓存对象，所有的数据操作都在这个时间段来被缓存进程来记录，来更新。而由另外的一个进程来进行异步的定时的数