上篇对疯狂代码缓存配置进行了概要的设计,可能说的有点模糊了,有几个朋友发了几个问题探讨了下,这里有必要先澄清一个问题,和常见的缓存策略不同,我们 的缓存策略将重点放在更新策略而不是只读策略上。只读缓存以及共性缓存策略性质实现的难度并不大,我们要解决的是非共性缓存,并发更新缓存,可扩充性缓 存,分布式缓存更新运算的问题,而对于共性的东西的话我们可以很轻松的实现,而不必做太多的运算。
试想一个问题,对于一个多用户的并发的系统,如果对每个用户都维护一份缓存策略还要保证更新的及时性以及处理的必要性来说的话,我们很难想到一个有效的处 理机制来维护每份(每用户)缓存的副本的,缓存的存储性质也决定了做分布式缓存策略处理的难度和分布式通讯更新的的难度,我们也很难尝试对于一些访问量很 小且少有共性的页面实现有效的缓存命中率,比如某某用户的博客。
简单的总结了一下关于缓存策略讨论的重点
A. 基于海量非共性数据的缓存策略
B. 基于数据缓存级别并发更新的缓存策略
C. 基于数据并发存储的缓存策略
D. 基于分布式的缓存策略
E.基于搜索的缓存策略
我们这里不再赘谈关于页面静态化以及类 似的问题,静态化的情况非常适合在系统初期,用户的基数并不算很大的情况下实现,而在涉及集群的情况下,静态化的实现成本,IO成本,维护成本,扩充成本 以及更新成本会远远的超出缓存策略的成本,当然我们也会有一套建立在缓存基础上的静态化处理方案,这些放在以后再谈。我们的目的是要建立一个可伸缩,便于 维护扩展的缓存策略,下面就具体问题进行分析。
对于问题A:
常见的博客系统就是一个最好的例子,每个用户的首页都是相对个性的数据,共性的地方不多,以常见的处理方案来说的话,我们可能需要维护每个用户访问的缓存副本,而对于一些访问量极小的博客站点来说的话这种方式无疑会造成巨大的浪费。
对于大量非共性的数据缓存来说,几个处理方案:
1) 量化缓存目标并分配相应的缓存权值。(权值分级)
目的很简单,只缓存有效的数据。首先抽取活跃用户,以及高访问量用户,将数据进行分组分权制缓存(对于交友型的SNS系统来说,我们称之为美女效应)
2) 非连接持久性的缓存保持(临时的持久性)
珍惜并有效利用数据查询,将未被缓存命中时的查询或者无权值的数据持久化保存(序列化存贮静态存贮等),当缓存未被命中时优先取得持久化数据而非数据查询。可以理解为临时数据存贮,或者临时存贮于子服务器的某个位置。
3) 基于数据更新的缓存清除(一次性使用)
当持久性缓存保持失效(依赖数据发生修改),直接删除临时数据(缓存只在访问时被激活并储存,一旦修改或者失效,我们立刻抛弃)。
4)缓存更新代理规则
由另外的线程进行维护,并维护线程的有效性,最大限度的分离主程序对无效缓存以及临时持久性缓存数据的清理
对于问题B:
在小型缓存策略中,缓存处理对于整个应用程序对于每个请求来说都是唯一的,可操作的和非物理存储的。而在并发更新的过程中,一个小小的并发更新就会很现实的清空所有的缓存池,造成缓存命中率奇低而初始化率奇高而起不到缓存策略应有的作用。
在这种情况下,处理方案也和A.4中提到的方案是一样的,由独立的缓存更新进程来处理,对于应用程序中所有涉及缓存更新的请求由专门的更新代理来执行。这个处理方案相对简单,不再赘述。
对于问题C:
上篇已经提到关于并发数据更新会带来的问题也就是数据库的I/O响应,超时,死锁,以及线程的阻塞问题。我们用一个写入缓存来处理这个方案,其实这个并非 传统意义上的读缓存,姑且命名为写缓存吧,我们可以形象的理解为类似硬盘缓冲区的问题。这里处理的操作稍微有点多了,还要涉及只读缓存的更新的问题了。
根据系统的不同,我们需要分析处理的角度也不同,我们以常见的webgame为例来简单介绍一下处理机制,这里有两种常见的情况
1) 对于webgame的最终用户玩家来说,每个在线用户的数据是非共性的(问题A),而在一个战斗场景下,每组数据时刻都在变化之中,如果我们对数据的变化 采用数据库日志记录的形式保存的情况显然对Database的压力很大,而我们需要记录的仅仅是战斗的结果,战斗的过程我们完全没有必要进行保存,这个时 候我们就用写入缓存来执行相应的数据操作。这个处理很简单,用服务器变量的形式就能解决他。;
2) 对于webgame的服务器角色来说,如果战斗场景的用户量非常多,而数据更新非常大的情况下,我们采用方法1中的处理也可能力不从心,这个时候我们可以 将缓存来进一步的抽象,在某个时间段内(比如3分钟),维护一个唯一的缓存对象,所有的数据操作都在这个时间段来被缓存进程来记录,来更新。而由另外的一 个进程来进行异步的定时的数据保存操作。
对于问题D
这个是比较常见的分布式缓存服务器组了,而对缓存服务器来说其实要解决的问题就是服务器间之间互相通讯的问题,并保证数据一致性的问题。那么我们的有四个处理规则:
1) 数据缓存应该被有效的分组并索引
目标是实现数据耦合的成都降到最低,甚至没有耦合。比如以用户ID为分割的数据缓存分布,或者以文章分类为分割的缓存分布
2) 数据缓存应该被有效的更新
如果数据被有效的分 组完成后,这个就是问题C.2的方案了,和C.2不同的是,因为缓存组可能未必在一组服务器中,可能涉及缓存和DATABASE数据通讯延迟的问题。这个 时候要保证缓存服务器被即时的传递到databse,那么需要另外的一个缓存检测进程来完成这项工作(数据完整性检查,并备份两个缓存段的数据)
3) 缓存服务器间的数据完整性
对于无法分组的数据,比如时间段内的用户认证数据和资料数据,我们需要保证两组数据同步,最好的处理方法就是清除相应的缓存段,让它在下次使用的时候初始化
4) 缓存服务器间的连通性
这个取决于物理线路,如果缓存服务器在天南地北的话,我们还需要一个队列进程来进行同步和数据矫正,我们称之为缓存路由。
对于问题E
在分布式缓存的情况下,多条件搜索往往涉及多个缓存服务器,处理起来笔者尚未有一套完善的出来方案。笔者用的是敷衍原则和集成原则了
敷衍原则:
对于搜索型的数据来说,很多情况下并不是非常重要,我们的搜索结果完全可以晚一会提供给用户,允许搜索的数据有10分钟或者更长时间的延迟。
集成原则
将搜索字段和表整合出来,用独立的只读查询服务器来分担负荷
分享到:
相关推荐
高性能网站架构设计,针对缓存做出的调整。
内置pdf和word版,如何做架构设计、系统设计(概要设计、详细设计和数据库设计),以及需要有那些规范和参考模板。
对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一部分为读书笔记,一部分是个人经验总结。对大型分布式网站架构有很好的参考价值。(如果感觉对大家有帮助,请帮忙点...
此为大规模用户访问时的系统架构设计概要,简明概要的给出了系统设计所包含的结构模块,与相互之间的关联
组策略高手完全手册高级篇之五:组策略设计方案概要
文档:概要设计文档,可以帮我们处理程序性能瓶颈,程序移植性短板,也方便后期维护拓展,文档输出也方便后期交付和交接。 项目目录: 1 文档简介 1.1 编写目的 1.2 文档范围 1.3 缩略语 2 项目概述 2.1 建设...
先谈下架构设计:架构设计包括了功能性架构和技术架构设计两个部分的内容 初步再来探讨下架构设计和概要设计的区别和边界问题。先谈下架构设计: 架构设计包括了功能性架构和技术架构设计两个部分的内容,功能性...
硬件设计概要设计模板,硬件设计时需要先根据需求写出概要设计,概要设计主要是硬件部分,主要是对需要的硬件分解
概要设计模板概要设计模板概要设计模板概要设计模板概要设计模板概要设计模板概要设计模板概要设计模板概要设计模板
概要设计和详细设计文档模板
标准化应急预案模板系统概要设计报告v3.0 信息系统概要设计报告 总体设计报告 信息系统概要设计报告 总体设计报告 信息系统概要设计报告 总体设计报告
接口概要设计说.doc
该文档是在《软件需求规格说明书》的基础上,通过我方与用户方反复沟通形成的,充分反映了用户需求,如有...概要设计文档是系统设计人员在下一阶段进行系统详细设计的纲领性文件,也是考核系统总体质量的重要技术文档。
概要设计模板概要设计模板概要设计模板概要设计模板
电梯系统 概要设计
本模板在应用于计划阶段的软件系统设计或软件概要设计: 1、 在后台软件或纯软件产品中,可以作为软件总体设计的模板,如果软件项目规模较大,划分了子系统,那么本模板又可以作为子系统的概要设计模板。 2、 软...
如何设计概要设计 如何设计概要设计
概要设计 1.引言 1.1编写的目的。 本文档的阅读对象为软件开发组成员。1.2背景 随着信息检索技术的高速发展,做为信息检索代表的搜索引擎被广泛引用,如google, 百度等,在中国Internet高速发展过程中,越来越受...
软件概要设计说明书模板,适用于软件开发概要所需模板。
软件工程概要设计详细设计.doc软件工程概要设计详细设计.doc软件工程概要设计详细设计.doc