分类“项目架构”下的文章

基于Trac+SVN整合-On Debian

2011/06/08, 11:33 下午

1、安装
aptitude install trac apache2 subversion python swig
aptitude install mod_python python-clearsilver  libapache2-svn

2、创建SVN信息
svnadmin create myapp
htpasswd -c /founder/svn/svntrac.htpasswd user

3、创建Trac项目
trac-admin /founder/trac/my_project initenv 输入 project名称和svn地址
添加权限
chown -R www-data:www-data trac/

3、编辑apache配置文件
vim /etc/apache2/sites-available/default
code：
<Location /svn>
    DAV svn
    SVNListParentPath off
    SVNParentPath /founder/svn
   AuthzSVNAccessFile /founder/svn/dav_svn.authz
   AuthType Basic
    AuthName "Subversion Repository"
    AuthUserFile /founder/svn/svntrac.htpasswd
   Require valid-user
</Location>
<Location "/trac">
    SetHandler mod_python
    PythonInterpreter main_interpreter
    PythonHandler trac.web.modpython_frontend
    PythonOption TracEnvParentDir /founder/trac
    PythonOption TracUriRoot /trac
</Location>
<LocationMatch "/trac/[^/]+/login">
      AuthType Basic
      AuthName "Trac"
      AuthUserFile /founder/svn/svntrac.htpasswd
      Require valid-user
</LocationMatch>

4、重启apache

/etc/init.d/apache2 stop
/etc/init.d/apache2 start

5、trac permission 管理
  增加权限
  trac-admin /path/to/trac_env permission add developer WIKI_ADMIN
  trac-admin /path/to/trac_env permission add bob developer
  删除权限
  trac-admin /founder/trac/gmwsvn permission remove tuzhi WIKI_ADMIN
  查看用户的权限列表
  trac-admin /path/to/trac_env permission list

6、trac的source view的权限限制，加载svn的权限限制
   authz_file = /svn/project1/conf/.authz 

7、trac的中文化
    svn co http://trac-hacks.org/svn/zoomquiettranslation/trunk/0.11.x
    trac-admin /path/to/your/env wiki load default-pages/
    配置trac.ini, 增加如下配置:
    [mainnav]
     wiki.href = /wiki/ZhWikiStart
    [metanav]
    help.href = /wiki/ZhTracGuide
    cp ZhTracGuideToc.py /path/to/your/env/plugins

标签：,
Category: 项目架构  |  评论

软件版本号区分

2011/02/16, 6:27 下午

版本号：
V（Version）： 即版本，通常用数字表示版本号。(如:EVEREST　Ultimate v4.20.1188　Beta　)
Build： 用数字或日期标示版本号的一种方式。(如:VeryCD　eMule　v0.48a　Build 071112)
SP： Service　Pack，升级包。(如:Windows　XP　SP　2/Vista　SP　1)

授权和功能划分：
Trial： 试用版，通常都有时间限制，有些试用版软件还在功能上做了一定的限制。可注册或购买成为正式版
Unregistered： 未注册版，通常没有时间限制，在功能上相对于正式版做了一定的限制。可注册或购买成为正式版。
Demo： 演示版，仅仅集成了正式版中的几个功能，不能升级成正式版。
Lite： 精简版。
Full　version： 完整版，属于正式版。

语言划分：
SC: Simplified　Chinese简体中文版。
CN: 简体中文版
GBK：简体中文汉字内码扩展规范版。
TC: Traditional　Chinese繁体中文版。
CHT: 繁体中文版
BIG5: 繁体中文大五码版。
EN: 英文版
Multilanguage: 多语言版
UTF8： Unicode　Transformation　Format　8　bit，对现有的中文系统不是好的解决方案。

开发阶段划分：
α（Alpha）版: 内测版，内部交流或者专业测试人员测试用。Bug较多，普通用户最好不要安装。
β（Beta）版: 公测版，专业爱好者大规模测试用，存在一些缺陷，该版本也不适合一般用户安装。
γ（Gamma）版: 相当成熟的测试版，与即将发行的正式版相差无几。
RC版: Release　Candidate　的缩写，意思是发布倒计时，候选版本，处于Gamma阶段，该版本已经完成全部功能并清除大部分的 BUG。到了这个阶段只会除BUG，不会对软件做任何大的更改。从Alpha到Beta再到Gamma是改进的先后关系，但RC1、RC2往往是取舍关 系。
Final: 正式版。

其他版本：
Enhance: 增强版或者加强版　属于正式版1
Free: 自由版
Release: 发行版　有时间限制
Upgrade: 升级版
Retail: 零售版
Cardware: 属共享软件的一种，只要给作者回复一封电邮或明信片即可。（有的作者并由此提供注册码等），目前这种形式已不多见。
Plus: 属增强版，不过这种大部分是在程序界面及多媒体功能上增强。
Preview: 预览版
Corporation　&　Enterprise: 企业版
Standard: 标准版
Mini: 迷你版也叫精简版只有最基本的功能
Premium: 贵价版
Professional: 专业版
Express: 特别版
Deluxe: 豪华版
Regged: 已注册版
Rip：指从原版文件（一般是指光盘或光盘镜像文件）直接将有用的内容（核心内容）分离出来，剔除无用的文档，例如PDF说明文件啊，视频演示啊 之类的东西，也可以算做是精简版吧…但主要内容功能是一点也不能缺少的！另：DVDrip是指将视频和音频直接从DVD光盘里以文件方式分离出来。
RTM版： 这基本就是最终的版本，英文是　Release　To　Manufactur，意思是发布到生产商。

OEM: Original　Equipment　Manufacturer. You　may　license　products　through　an　Original　Equipment　Manufacturer　 (OEM).　These　products,　such　as　Windows　operating　systems,　come　installed 　when　you　purchase　a　new　computer.　
OEM软件是给电脑生产厂的版本，无需多说。　
FPP/Retail: Full　Packaged　Product. Physical,　shrink-wrapped　boxes　of　licensed　product　that　can　be　purchased 　in　a　local　retail　store　or　any　local　software　retailer.　FPP就是零售版（盒装软件）， 这种产品的光盘的卷标都带有"FPP"字样，比如英文WXP　Pro的FPP版本的光盘卷标就是WXPFPP_EN，其中 WX表示是Windows　XP，P是Professional（H是Home），FPP表明是零售版本，EN是表明是英语。获得途径除了在商店购买之 外，某些MSDN用户也可以得到。
VLO: Volume　Licensing　for　Organizations.You　may　enjoy　potentially　significant 　savings　by　acquiring　multiple　 product　licenses.　Depending　on　the　size　and　type　of　your　organization.　团 体批量许可证（大量采购授权合约），这是为团体购买而制定的一种优惠方式。这种产品的光盘的卷标都带有"VOL"字样，取"Volume"前3个字母，以 表明是批量，比如英文WXP　Pro的VOL版本的光盘卷标就是WXPVOL_EN，其中WX表示是Windows　XP，P是 Professional（VOL没有Home版本），VOL表明是团体批量许可证版本，EN是表明是英语。获得途径主要是集团购买，某些MSDN用户也 可以得到。
RC: Release Candidate（候选版本）的简称
GA: General Availability,正式发布的版本，在国外都是用GA来说明release版本的
M1: Myeclipse的版本中经常出现这种表示。milestone 1里程碑，代表一个阶段性的成果，正式版本发布前能够体现出此版本新特性的版本。

在很多软件下载的时候，你会发觉标识为GA或者CRx等。比如MySQL和JBoss都采用这种标识。那什么是GA呢。GA是Generally Available的缩写，意思是开发团队认为该版本是稳定版（有的软件可能会标识为stable版或者production版，其意思和GA相同），可 以在较为关键的场合使用。如果你是要用在生产中的软件，或者你是一个新手，那么你最好选用GA版本。这是测试最为充分，最为稳定的版本。

标签：
Category: 项目架构  |  3 条评论

开心网系统架构分析

2009/11/01, 3:44 上午

开心网是一个人气蛮高的sns社区，虽然在走下坡路了，在国内依然算是顶尖了，今天我们就来分析一下开心网的设计架构是怎样的。因为手头没有这方面的资料，也没有和开心网的程序员有过什么交流，所以今天所写的一切都是自己的猜测而已。不能对号入座。

关于开心网的系统架构分析

一．入口篇
从http://www.kaixin001.com/，从这个页面可以看到，开心网的图片，是放在http://img.kaixin001.com上 的，做了程序与图片的分离（http://www.kaixin001.com/i…这个不知为什么没有分离）。
下面来看一下开心网前端的服务器情况，nslookup一下，可以看到，一共有下面的17个IP
220.181.66.138，123.103.12.24，123.103.12.25，123.103.12.26，123.103.12.27
123.103.12.28，123.103.12.36，123.103.12.37，123.103.12.38，123.103.12.39
123.103.101.98，123.103.101.107，123.103.101.116，123.103.102.130，220.181.66.131
220.181.66.135，220.181.66.136
（图片服务器用了ChinaCache的CDN，这个不是重点就不详细说了）
以上可以看出，开心网的前端用了DNS轮询。
再来分析一下前端服务器是什么呢？根据用httpwatch查询的结果可以看出，他使用的是apache作为服务器，max-age=1，等于设置缓存，并且开启了gzip压缩。目前只能看到这些了。

开心网的web没有用squid或者lvs让我有些意外。从我们做中金博客的经验来说，仅仅依赖DNS轮询是一个非常不保险的东西，DNS轮询分配的压力非常不平均，或许跟开心网的应用都需要登录有关吧。
PS：开心网的首页竟然是一个动态的php。http://www.kaixin001.com/i…

二．程序篇
另外服务器既然有多台进行轮询，就必须考虑一个session共用的问题，session共用现在有几种方式：
1.写入数据库（将数据文件放在内存中，读取速度还是很快的，而且统计时候方便，缺点就是访问量超大的时候，数据库链接有时会满掉。中金博客目前用的就是这种方式）

2.写入使用nfs挂载，将一块空间专门划分出来挂载在每台服务器上，存放session文件，以前李杰说17173的bbs好像是通过这样的方式，2年 前的事了，不知现在是否改了没有，这个方式主要依赖于网络状况，网络断开或者挂载的服务器挂掉就会出现问题了，这个方案同样可以划出一部分内存来做 nfs，避免硬盘的io

3.写入memcache，将session写到memcache中是一个很好的方案，他解决了1，2优点，虽然依赖网络，但是可以做一个群组，不会有单 点故障，且不会出现连接数满掉的情况，但是它也有一个麻烦的地方，就是无法进行统计操作（或许用dbcache可以解决）。原本中金博客是要用这个方法 的，后来因为种种原因没有上线。

上面三种是较常见的session保存方式，相信开心网也是用这三种之一。顺便提一句，不共用session的话，一般情况下，对于用户访问不会出什么问题，因为用户浏览器会缓存dns的结果，在一定的时间内，用户访问到的实际上还是同一台服务器的。

登录到开心网以后，每个模块的网址类似：
http://www.kaixin001.com/!…应该是没有经过rewrite，而是用文件夹放置不同的模块，这个地方没有什么疑问的。

而每个模块都是php的页面，不可能每次都去直接连接数据库，肯定都用了缓存，相信缓存很有可能是用memcache，因为文件缓存的同步是一个复杂且容易出错的方式，对于有几十台Web服务器的应用，实在不适合用本地文件缓存的方式。

下面我们以争车位这个模块来说明memcache缓存是如何实现的（当然是猜想的）。

首先，进入模块后，会显示我家的停车情况，点击好友，会显示好友家的停车情况。
而这个操作实际上是从一个地址http://www.kaixin001.com/p…获得的。这个地址返回的内容是类似php序列化的一个字符串， 这些由js去解析，并展示出来。那程序应该如何操作呢？程序（user.php）接到post请求后，根据id，首先从memcache（假定此时缓存用 memcache）中寻找是否有匹配的记录，若没有，则向数据库请求获取数据，重写回memcache，并返回数据。

而停车的情况呢，程序即写一个停车的队列，表示某某时间A将二手奥拓停放在B的第2号车位，并更新memcache的缓存，此时并不会更新数据库的状态，而这个队列，将通过定时的脚本更新至数据库。

顺便说一下我为什么会认为写入的流程是这样的：有一次我去停车，点击了我的车到某个车位上，页面刷了一下，我惊奇的发现竟然没停上去，当时我想是开心网出 啥问题了，那就等等呗。过了大约一个小时，发现竟然车子好端端的停在那个车位上了。这个情况在那个阶段大约隔几天就会出现一次，按照我说的模式，点击停 车，没有停上去（更新缓存失败了），过了一会又去看，发现已经停在上面了（缓存过期，队列已经更新到数据库）。 所以大概都是这样的方式。当然有的模块可能是将数据直接写入数据库的。但是读出的时候，肯定是有做缓存的。或许又有人说程序可能不直接链接数据库，而是通 过类似WebService的东西去实现数据库操作，是的，有可能，可是大概是做了中金项目的后遗症吧，我对于WebService及Soap的使用的理 解是对于需要开发给外部调用的功能才使用，而本身应用完全没有必要绕这个圈子，会降低很大的性能。所以我宁可相信开心网自己的应用是没有使用 WebService去连接数据库的。

每个模块的实现就不去谈那么多了，这里说的是系统架构，就我的经验来说web前端最重要的就是缓存及其同步问题，若处理的好，整个应用的性能会大幅度提高。

三．数据库
数据库方面的变化相对较少，使用php的网站，90%都会用mysql。开心网的用户数没有官方的数字，我估计不低于500W，而其他的用户相关的记录， 如“我看过的电影”之类的，恐怕只会多，不会少，如此大量的数据放在一张表里面，肯定会出问题，所以必须采用分表存储，这样就涉及到用哪种规则来分表，一 般情况下有2种。用id和日期来分，对于用户，大多还是会用用户id作为规则来分的。

当然，开心网还有一个特殊性，他是由用户中心，及一个一个模块组成的，所以，数据库的组成应该是用户中心为一个库，其他每个模块为独立的库。而每个库都可 以做成master/slave的模式，实现读写分离和备份，考虑到若读操作很大量，则可以在slave前放置一个lvs实现负载均衡（mysql proxy似乎可以实现类似的功能，但是我没用过），以保证数据库的稳定性。当然虽然是独立的库，但是服务器有可能是在同一台，相信开心网还没阔到每个应 用都用独立的数据库服务器的地步。

四．系统架构图
 

网站架构收集

2009/11/01, 3:42 上午

来自sudone.com 服务器系统架构分析日志
csdn.net的系统架构研究 http://sudone.com/archie/csdn_archive.html
图片服务器的hash架构 http://sudone.com/archie/image_hash.html
天涯bbs系统架构分析 http://sudone.com/archie/tianya.cn.html
v.2008.163.com对新架构的尝试 http://sudone.com/archie/v.2008.163.com.html
nginx和squid配合搭建的web服务器前端系统 http://sudone.com/archie/app_nginx_squid.html
nginx作为最前端的web cache系统 http://sudone.com/archie/app-nginx-squid-nginx.html
新型的大型bbs架构（squid+nginx） http://sudone.com/archie/archi_bbs.html
当前比较适用的海量小文件系统架构方案 http://sudone.com/archie/big_filesystem.html
nginx图片服务器的架构方案 http://sudone.com/archie/nginx_pic.html
来源:
http://www.hiadmin.com/ 网站架构收集/
DBA notes上果然好东西很多
许多大型(只是访问量,而不是公司规模)的web 2.0的网站架构
上面都有
现在收集整理一下有关网站架构的资料,其中许多来自DBA notes
这种资料.向来可遇不可求啊
WikiPedia 技术架构学习分享

http://www.dbanotes.net/opensource/wikipedia_arch.html

YouTube 的架构扩展

http://www.dbanotes.net/opensource/youtube_web_arch.html

Internet Archive 的海量存储浅析

http://www.dbanotes.net/database/internet_archive_storage.html

LinkedIn 架构笔记

http://www.dbanotes.net/arch/linkedin.html

Tailrank 网站架构

http://www.dbanotes.net/review/tailrank_arch.html

Twitter 的架构扩展: 100 倍性能提升

http://www.dbanotes.net/arch/twitter_arch.html

财帮子（caibangzi.com）网站架构

http://www.dbanotes.net/arch/caibangzi_web_arch.html

Yupoo! 的网站技术架构

http://www.dbanotes.net/arch/yupoo_arch.html

37Signals 架构

http://www.dbanotes.net/arch/37signals_arch.html

Flickr 的访问统计实现以及其他

http://www.dbanotes.net/arch/flickr_stats_and_dathan.html

PlentyOfFish 网站架构学习

http://www.dbanotes.net/arch/plentyoffish_arch.html

Yahoo！社区架构

http://www.dbanotes.net/arch/yahoo_arch.html

有关 Alexa 与 AOL 部署集群文件系统

http://www.dbanotes.net/arch/alexa_ibrix_san_file_system.html

eBay 的存储一瞥

http://www.dbanotes.net/arch/ebay_storage.html

eBay 的数据量

http://www.dbanotes.net/database/ebay_storage.html

eBay 的数据库分布扩展架构

http://www.dbanotes.net/database/ebay_database_scale_out.html

eBay 的数据层扩展经验

http://www.dbanotes.net/arch/ebay_db_scale_out.html

eBay 的应用服务器规模

http://www.dbanotes.net/web/ebay_application_server.html

性能扩展问题要趁早

http://www.dbanotes.net/arch/scaling_an_early_stage_startup.html

Scaling an early stage startup

Facebook 的 PHP 性能与扩展性

http://www.dbanotes.net/arch/facebook_php.html

Skype 用 PostgreSQL 支撑海量用户

http://www.dbanotes.net/arch/skype_postgresql.html

闲谈 Web 图片服务器

http://www.dbanotes.net/web/web_image_server.html

说说北京奥运购票系统瘫痪这事儿

http://www.dbanotes.net/review/beijing_olympic_ticketes_system_crash.html

Architectures You’ve Always Wondered About

http://qcon.infoq.com/london-2008/tracks/show_track.jsp?trackOID=82

eBay’s Architectural Principles

http://www.eos1.dk/qcon-london-2008/slides/RandyShoup_eBaysArchitecturalPrinciples.pdf

Building a large scale SaaS app

http://www.eos1.dk/qcon-london-2008/slides/Dan_Hanley_Building_a_large_scale_SaaS_app.pdf

Scaling an early stage startup

互联星空播客架构(原文在张宴blog上,但是后来文章撤下,很可惜.此为转载)

http://www.flashmov.com/blog_1632.html

QQ游戏百万人同时在线服务器架构实现

http://www.libing.net.cn/read.php?41

大型Web2.0站点构建技术初探

http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1890793.aspx

Web站点数据库分布存储浅谈

http://blog.csdn.net/heiyeshuwu/archive/2007/11/18/1891639.aspx

QQ的架构讨论

http://groups.google.com/group/dev4server/browse_thread/thread/0d72668d11c4886b/a6d202489cabf285#a6d202489cabf285

Notes from Scaling MySQL – Up or Out

http://venublog.com/2008/04/16/notes-from-scaling-mysql-up-or-out/

Yapache-Yahoo! Apache 的秘密

http://www.dbanotes.net/web/yapache_yahoo_apache.html

LinkedIn 架构与开发过程

http://www.dbanotes.net/arch/linkedin_soa.html

Scalability Best Practices: Lessons from eBay

http://www.infoq.com/articles/ebay-scalability-best-practices

看 Twitter 人谈架构扩展问题

http://www.dbanotes.net/arch/twitter_interview.html

Facebook 海量数据处理

http://www.dbanotes.net/arch/facebook_photos_arch.html

web 2.0海量小文件cache集群探讨

http://www.ourlinux.net/operation-tips/web20-small-file-cache-cluster/

2008-10-09
Cocolog 从 PostgreSQL 迁移到 MySQL 的经验

http://www.dbanotes.net/arch/cocolog_postgresql_mysql.html

疯狂代码：大型网站架构系列（未完待续）收藏

http://blog.csdn.net/heiyeshuwu/archive/2008/10/01/3006964.aspx

Amazon Architecture

http://highscalability.com/amazon-architecture

Scaling Twitter

http://highscalability.com/scaling-twitter-making-twitter-10000-percent-faster

37signals Architecture

http://highscalability.com/37signals-architecture

Digg Architecture

http://highscalability.com/digg-architecture

Flickr Architecture

http://highscalability.com/flickr-architecture

YouTube Architecture

http://highscalability.com/youtube-architecture

Google Architecture

http://highscalability.com/google-architecture

LiveJournal’s Backend

http://www.danga.com/words/2005_mysqlcon/mysql-slides-2005.pdf

LiveJournal Architecture

http://highscalability.com/livejournal-architecture

eBay Architecture

http://highscalability.com/ebay-architecture

LinkedIn Architecture

http://highscalability.com/linkedin-architecture-0

Category: 项目架构  |  评论

Facebook 如何管理150亿张照片

2009/05/04, 4:49 下午

Facebook 的照片分享很受欢迎，迄今，Facebook 用户已经上传了150亿张照片，加上缩略图，总容量超过1.5PB，而每周新增的照片为2亿2000万张，约25TB，高峰期，Facebook 每秒处理55万张照片，这些数字让如何管理这些数据成为一个巨大的挑战。本文由 Facebook 工程师撰写，讲述了他们是如何管理这些照片的。

旧的 NFS 照片架构
老的照片系统架构分以下几个层：
# 上传层接收用户上传的照片并保存在 NFS 存储层。
# 照片服务层接收 HTTP 请求并从 NFS 存储层输出照片。
# NFS存储层建立在商业存储系统之上。

因为每张照片都以文件形式单独存储，这样庞大的照片量导致非常庞大的元数据规模，超过了 NFS 存储层的缓存上限，导致每次招聘请求会上传都包含多次I/O操作。庞大的元数据成为整个照片架构的瓶颈。这就是为什么 Facebook 主要依赖 CDN 的原因。为了解决这些问题，他们做了两项优化：
# Cachr: 一个缓存服务器，缓存 Facebook 的小尺寸用户资料照片。
# NFS文件句柄缓存：部署在照片输出层，以降低 NFS 存储层的元数据开销。

新的 Haystack 照片架构
新的照片架构将输出层和存储层合并为一个物理层，建立在一个基于 HTTP 的照片服务器上，照片存储在一个叫做 haystack 的对象库，以消除照片读取操作中不必要的元数据开销。新架构中，I/O 操作只针对真正的照片数据（而不是文件系统元数据）。haystack 可以细分为以下几个功能层：
# HTTP 服务器
# 照片存储
# Haystack 对象存储
# 文件系统
# 存储空间

存储
Haystack 部署在商业存储刀片服务器上，典型配置为一个2U的服务器，包含：
# 两个4核CPU
# 16GB – 32GB 内存
# 硬件 RAID，含256-512M NVRAM 高速缓存
# 超过12个1TB SATA 硬盘

每个刀片服务器提供大约10TB的存储能力，使用了硬件 RAID-6, RAID 6在保持低成本的基础上实现了很好的性能和冗余。不佳的写性能可以通过高速缓存解决，硬盘缓存被禁用以防止断电损失。
文件系统
Haystack 对象库是建立在10TB容量的单一文件系统之上。文件系统中的每个文件都在一张区块表中对应具体的物理位置，目前使用的文件系统为 XFS。
Haystack 对象库
Haystack 是一个简单的日志结构，存储着其内部数据对象的指针。一个 Haystack 包括两个文件，包括指针和索引文件：

Haystack 对象存储结构

指针和索引文件结构


Haystack 写操作
Haystack 写操作同步将指针追加到 haystack 存储文件，当指针积累到一定程度，就会生成索引写到索引文件。为了降低硬件故障带来的损失，索引文件还会定期写道存储空间中。

Haystack 读操作
传到 haystack 读操作的参数包括指针的偏移量，key，代用Key,Cookie 以及数据尺寸。Haystack 于是根据数据尺寸从文件中读取整个指针。

Haystack 删除操作
删除比较简单，只是在 Haystack 存储的指针上设置一个已删除标志。已经删除的指针和索引的空间并不回收。

照片存储服务器
照片存储服务器负责接受 HTTP 请求，并转换成相应的 Haystack 操作。为了降低I/O操作，该服务器维护着全部 Haystack 中文件索引的缓存。服务器启动时，系统就会将这些索引读到缓存中。由于每个节点都有数百万张照片，必须保证索引的容量不会超过服务器的物理内存。

对于用户上传的图片，系统分配一个64位的独立ID，照片接着被缩放成4种不同尺寸，每种尺寸的图拥有相同的随机 Cookie 和 ID，图片尺寸描述（大，中，小，缩略图）被存在代用key 中。接着上传服务器通知照片存储服务器将这些资料联通图片存储到 haystack 中。

每张图片的索引缓存包含以下数据

Haystack 使用 Google 的开源 sparse hash data 结构以保证内存中的索引缓存尽可能小。
照片存储的写/修改操作
写操作将照片数据写到 Haystack 存储并更新内存中的索引。如果索引中已经包含相同的 Key，说明是修改操作。

照片存储的读操作
传递到 Haystack 的参数包括 Haystack ID，照片的 Key, 尺寸以及 Cookie，服务器从缓存中查找并到 Haystack 中读取真正的数据。

照片存储的删除操作
通知 Haystack 执行删除操作之后，内存中的索引缓存会被更新，将便宜量设置为0，表示照片已被删除。

重新捆扎
重新捆扎会复制并建立新的 Haystack，期间，略过那些已经删除的照片的数据，并重新建立内存中的索引缓存。

HTTP 服务器
Http 框架使用的是简单的 evhttp 服务器。使用多线程，每个线程都可以单独处理一个 HTTP 请求。

结束语
Haystack 是一个基于 HTTP 的对象存储，包含指向实体数据的指针，该架构消除了文件系统元数据的开销，并实现将全部索引直接存储到缓存，以最小的 I/O 操作实现对照片的存储和读取。

标签：
Category: 项目架构  |  评论
12345678 » 最后一页