Hunter的大杂烩 技术学习笔记

2008-07-15

分区 vs 联邦 vs shard

Filed under: 架构 — hunter @ 10:57 pm

from: http://lethargy.org/~jesus/archives/95-Partitioning-vs.-Federation-vs.-Sharding.html
A partition is a structure that divides a space into two parts.
分区是指将一个数据结构在空间上存储为多个部分;
A federation is a set of things (usually states or regions) that together compose a

centralized unit but each individually maintains some aspect of autonomy.
联邦指的是若干个数据库各自根据需要保存不同的信息,并组成统一的对外平台。每个存储单位
是独立的。
Federation 顾名思义,更多的是不同类型数据的部署方案,比如付费用户和非付费用户的存储
集群;
(more…)

2008-06-29

网摘20080629

Filed under: 架构 — hunter @ 9:54 pm

最近搜到一些不错的资料,随手做些读书笔记

 

http://www.zefhemel.com/archives/2004/09/01/the-share-nothing-architecture
Scalability is “the capability of a system to increase performance under an increased load when resources (typically hardware) are added.” (source: Wikipedia)
第一段解释伸缩性是什么意思,伸缩性不等同性能,当你的服务器投入是两倍的时候,
性能能提升两倍,当你的服务器在增加的时候,业务不停顿… 这才是伸缩性

A big scalability problem with caching data is called the cache-coherence problem.
第二段解释一个严重影响伸缩性方面的问题,cache一致性

第三段推销shared-nothing架构:至少在web server上什么数据也不要共享,session
可以通过文件(NFS远程访问)或者数据库来集中维护,而数据库有较好的扩展性(ebay
就是这样做的)

(more…)

2008-06-21

大型互联网网站架构心得之一

Filed under: 架构 — hunter @ 9:51 pm

from:http://blog.csdn.net/LoveCherry/archive/2008/06/19/2564096.aspx

我们知道,对于一个大型网站来说,可伸缩性是非常重要的,怎么样在纵向和横向有良好的可伸缩性,就需要在做架构设计的时候考虑到一个分的原则,我想在多个方面说一下怎么分:

首先是横向的分:
1. 大的网站化解为多个小网站:当我们一个网站有多个功能的时候,可以考虑把这个网站拆分成几个小模块,每一个模块可以是一个网站,这样的话我们到时候就可以很灵活地去把这些网站部署到不同的服务器上。
2. 静态动态分离:静态文件和动态文件最好分离开成2个网站,我们知道静态网站和动态网站对服务器来说压力的侧重不同,前者可能重IO后者重CPU,那么我们在选择硬件的时候也可以有侧重,而且静态和动态内容的缓存策略也不一样。典型的应用,我们一般会有独立的文件或图片服务器。
3. 按照功能来分:比如有一个模块是负责上传的,上传操作很消耗时间,如果和其它应用混在一起的话很可能,一点点访问就会使服务器瘫痪,这种特殊的模块应该分开。安全的不安全的也要分开,还需要考虑到以后SSL的购买。
4. 我们不一定要全部用自己的服务器,搜索、报表可以依靠别人的服务,比如google的搜索和报表服务,自己做的不一定比得过别人,服务器带宽都省了。
(more…)

2008-06-08

是否应该避免架构重写?

Filed under: 技术话题,架构 — hunter @ 2:04 pm

infoq上总是有不错的文档

就我个人的经验,作为程序员总是觉得别人的代码不好,有冲动把他重构,但是作为管理者,

则更多需要考虑投入产出的问题。

从整体架构上来说,完全重构的风险太大,局部进行重构优化是王道。

from: http://www.infoq.com/cn/news/2008/05/software-rewrite-4-architecture

由于软件应对需求变化的能力越来越差,通过更新架构进行软件重建的做法变得越来越有吸引力。这种做法是相当有风险的,因此具体策略的选择显得相当重要。Andy Singelton最近的一篇博客就此问题进行了讨论。文章认为成本、技术复杂性、潜在的商业风险是在进行战略选择时不得不认真权衡的三个因素。对此他提出了三种解决方案,并简要分析了每种方法的优缺点:

(more…)

Facebook Chat的架构

Filed under: 架构 — hunter @ 1:06 pm

 facebook chat的在处理海量事件通知时与QQ比较接近,这些都是大规模分布式体系无法绕

过的鸿沟吧。

Erlang看来似乎有必要好好学一下,seda类型的并发查询框架,在很多地方都有适用的环节。

对于部署,tx比较推崇“灰度”升级概念,似乎比facebook的要高级一些,呵呵

from:http://www.infoq.com/cn/news/2008/05/facebookchatarchitecture

最近在Facebook工程师博客上,软件工程师Eugene Letuchy写了一篇关于Facebook Chat项目的决策细节的文章。

当产品的客户有可能在一夜之间从零增加到七千万的时候,可扩展性就变为从一开始就必须考虑的问题。

(more…)

« Newer PostsOlder Posts »

Powered by WordPress