我也要谈谈大型网站架构之系列(3)——死了都要说的缓存

  说到缓存,我想大家跟我一样都很兴奋,当我们遭遇网站性能瓶颈的时候,缓存是一剂强心针,也是一粒紧急妈富隆,从而在优化网站

性能方面冠上了第一定律的帽子,我们前年在做淘应用的时候,就遭遇了性能瓶颈,短时间内采用缓存紧急优化,给我们大优化之前争取了

宝贵的时间。

一:缓存的种类

要说缓存有多少种,太多了,比如浏览器缓存,文件缓存,片段缓存,数据库缓存等等,合理利用这些缓存则能大幅度的提高系统性能,

利用不好反而会偷鸡不成蚀把米,给服务器造成巨大的压力,所以这里就存在一个缓存的使用原则的问题。

二:合理的使用缓存

1.  读写小于10:1的情况下,不适合用缓存,我们用缓存的目的就是想分摊下数据库的压力以及利用内存来提速性能,如果读写差不多,或者

压根就没读过,这样的死数据就会造成内存资源的浪费。

2.  既然是缓存,就注定了它的资源是有限的,宝贵的,也就注定了我们必须合理利用它的内存空间,也就被迫的让我们清楚的认识到热点数据,

   不易修改的应该放在缓存,反之不宜放。

3.  大公司在缓存方面做的好的地方就是在一个“控”字上,他们会为缓存专门做一套“缓存系统”,当系统预加载的时候,同时也充当内存数据库

使用,将这些元数据加载到缓存系统中,比如“县市区”,“分类信息”等等作为预热数据。

三:分布式缓存

一般情况下,会有两种形式,第一种就是主从复制的模式,第二种就是分片的模式。

1:主从复制模式

  这种模式曾今在项目中也用过,就是一份内存,多处备份,当其中某一个缓存内容中的数据有变化时,会及时通知其他机器进行缓存更新

或清除,这种模式的缺点在于比较容易受制于单台机器的内存限制,优点在于用心跳机制及时用另一台缓存机器顶替,那个时候我们使用120G

的大内存,得益于项目业务规模的限制,否则当机器内存爆满的时候就比较尴尬了,所以做大型网站还是谨慎使用吧,毕竟这个也是我们曾今做

了一些为了提升性能的尝试。

2:分片的模式

这种模式在大型网站中还是被大量使用的,它的特点就是可以把一大坨数据通过一定的算法和配置分摊到集群中的若干台机器上,如果集群中

的某一台机器挂了,没关系,只会影响到该台机器中的数据,对数据库不会造成很大的影响。一个典型的应用就是memcache,memcache是一

个非常简单,实用,高效的分布式缓存架构,其实memcache最值得一提的就是“路由算法的一致性hash”技术使得我们的memcache集群可以

自由伸缩,不过现在已经有很多的nosql产品,比如redis,couchdb,mongodb等等,让我们在这个世界上有了更多的选择吧。

最近看到园子里面有很多抱怨声,没关系,如果觉得自己屈才了,欢迎来携程试一试,只有你达不到的能力,没有给不起你的薪资。

我也要谈谈大型网站架构之系列(3)——死了都要说的缓存,布布扣,bubuko.com

时间: 2024-08-06 16:06:21

我也要谈谈大型网站架构之系列(3)——死了都要说的缓存的相关文章

我也要谈谈大型网站架构之系列(4)——分布式中的异步通信

我也要谈谈大型网站架构之系列(4)--分布式中的异步通信 我们知道在面向对象编程中,总会想着各种办法来实现代码的解耦,从而让项目中的各种人员面对自己熟悉的业务进行开发, 做到术业有专攻,比如大家非常熟悉的三层架构,MVC,MVP以及MVVM模式,让前端设计专注于html的制作,让后端开发人员 更加专注于业务逻辑的编写,可以看到,我们这么做的目的就是想最大程度的做到系统的可扩展和可维护性,那么我们的大型网站 是不是也要遵守这种模式呢? 一:分层和分割 1:分层 对于分层,我们可能非常熟知了,数据访

我也要谈谈大型网站架构之系列(2)——纵观历史演变(下)

这篇文章本来准备前几天就得写的,谁也没想到这段时间公司的RC太多了,含酸苦逼的加班,加班...所以在大一点的公司上班, 写代码的责任心一定要强,或许就因为你的一些小bug,给公司带来不少损失...这在以前公司真的没多大体会的. 好了,继续说说架构的演变,从第四代架构中可以看到,我们通过做应用程序层的负载均衡可以比较完美的解决了在整个架构中让应 用程序层不再成为瓶颈,通过A10,我们可以让用户的访问请求分发到集群中的任何一台服务器上,当访问量继续膨胀的时候,我们就可 以继续在集群中增加服务器来解决

大型网站架构之架构模式

上节讲了<大型网站架构之架构演变>,今天讲下架构的模式,什么是模式呢?每一个模式描述了一个再我们周围不断重复发生的问题及问题解决方案的核心,这样你就能一次次重用该方案而不必去做重复的工作,可见模式的关键在于可重复性. 网站架构模式的目标:面临高并发访问,海量数据处理,高可靠运行等问题和挑战,我们在实践中提出很多解决方案,主要为了实现网站的高性能.高可用.易伸缩.可扩展.安全等架构目标. 网站架构模式具体方案如下: 1.分层 分层是一种常见的架构模式,将系统在横向维度上切分为几个部分,每个部分负

大型网站架构演变史(含技术栈与价值观)

这篇文章是参考李智慧的<大型网站技术架构:核心原理与案例分析>和现蘑菇街CTO曽宪杰的<大型网站系统与Java中间件实践>写的一篇读书笔记. 前言 何谓大型网站?大型网站的特点是什么?大型网站架构发生演变的源动力是什么?大型网站的架构演变经历了哪些阶段?在演变的某个具体阶段使用到常用技术有哪些,为什么要使用这些技术,同时这些技术又解决了什么问题?笔者在初次接触大型网站时思考了以上几个问题,本着缘木求鱼的方式,我打算详细的扒一扒大型网站的演变史.如果对以上的几个问题都理解透彻了,那么

大型网站架构改进历程-转 (刚进博客园就看到这么一篇好文章感触颇深)

存储的瓶颈(1) 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难 完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 大型网站定义 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点 行的人也许会认为是网站在单位时间里的并发量的大小来作为指

大型网站架构改进历程

存储的瓶颈(1) 前不久公司请来了位互联网界的技术大牛跟我们做了一次大型网站架构的培训,两天12个小时信息量非常大,知识的广度和难度也非常大,培训完后我很难 完整理出全部听到的知识,今天我换了个思路是回味这次培训,这个思路就是通过本人目前的经验和技术水平来思考下大型网站技术演进的过程. 大型网站定义 首先我们要思考一个问题,什么样的网站才是大型网站,从网站的技术指标角度考虑这个问题人们很容易犯一个毛病就是认为网站的访问量是衡量的指标,懂点 行的人也许会认为是网站在单位时间里的并发量的大小来作为指

大型网站技术架构(一):大型网站架构演化

第一章:大型网站架构演化 九层之台,始于垒土:千里之行,始于足下. 对于网站的发展,亦是如此,从上世纪90年代开始,互联网经历了20多年的发展,发生了翻天覆地的变化,今天,全球有一半的人使用互联网,从信息检索到实时通信,从电子购物到文化娱乐,互联网渗透到了生活的每一个角落.但是,构建一个高性能的网站,绝非一朝一夕可以完成,我们来看下,作为一个大型网站系统应有的特点: 1.大型网站系统应有的特点 高并发,大流量:需要面对高并发用户,大流量访问.举个例子,去往迪拜的飞机有200张票,但是有100w人

大型网站架构不得不考虑的10个问题

大型网站架构不得不考虑的10个问题 这里的大型网站架构只包括高互动性高交互性的数据型大型网站,基于大家众所周知的原因,我们就不谈新闻类和一些依靠HTML静态化就可以实现的架构了,我们以高负载高数据交换高数据流动性的网站为例,比如海内,开心网等类似的web2.0系列架构.我们这里不讨论是PHP还是JSP或者.NET环境,我们从架构的方面去看问题,实现语言方面并不是问题,语言的优势在于实现而不是好坏,不论你选择任何语言,架构都是必须要面对的. 这里讨论一下大型网站需要注意和考虑的问题 1.海量数据的

《大型网站技术架构-核心原理与案例分析》之一: 大型网站架构演化

最近刚刚读完李智慧的<大型网站技术架构-核心原理与案例分析>,对每章重点内容作了一些笔记,以便加深印象及日后查阅. 一.大型网站软件系统的特点 高并发,大流量:需要面对高并发用户,大流量访问. 高可用:系统7X24小时不间断服务. 海量数据:需要存储.管理海量数据,需要使用大量服务器. 用户分布广泛,网络情况复杂:许多大型互联网都是为全球用户提供服务的,用户分布范围广,各地网络情况千差万别. 安全环境恶劣:由于互联网的开放性,使得互联网站更容易受到攻击,大型网站几乎每天都会被黑客攻击. 需求快