"经常看到说mrtg的，说论坛里面的资料不对，其实不是不对，是有些说的不详细而已，我刚开始作的时候也是费了不少时间的，整理一下，发到这里吧，希望能 为后来的兄弟们省下时间 前言：我实验的机器是FreeBSD4.10，其他版本的应该也一样，其他unix like系统估计也是可以的，因为我只用过FreeBSD，不敢 肯定。另外我这篇文章的前提是你的机器上已经安装了apache，并能正常使用，如果没有请参考网上其他文 章安装，本文就不再赘述。\n一：先介绍如何用mrtg来监控本机的流量 1：安装 snmp\ncd /usr/ports/net-mgmt/p5-SNMP(好像没有这个目录的,可以用路径:/usr/ports/net-mgmt/net-snmp/”这) make install clean 当中会叫你填写你的email、操作系统等等，直接回车即可。\n可以用以下命令启动snmp，/usr/local/etc/rc.d/snmpd.sh start\n2：安装 mrtg\ncd /usr/ports/net-mgmt/mrtg make install clean\n3：配置 index.cfg …"

""

"csdn作为国内最大的程序开发社区，影响了足足一代人。它是国内优秀杂志《程序员》的网站，我从前非常喜欢《程序员》这本杂志，里面的文章都非常优秀， 那时只有5元钱的我每个月花10块钱买本这样的杂志，看个三五年，都舍不得丢下。\n但是今天观察了下csdn站点的架构，发现做的比较简单，看来开发者比较喜欢从程序着手，着重优化代码和数据库，对系统整体架构思考的时间不多。\n我着重看了几个二级域名：www、news、bbs/community和blog，其中www、news这些静态文件都有通过squid缓存，用的 app_squid架构，然后是dns轮询做分流。\n在这里顺便讨论下为什么很多大型网站都喜欢用dns轮询来作首页，而不采用lvs或其它负载均衡策略。这是因为负载均衡都是把所有的访问先集中到一个ip 上，因为只有一个ip，所以无意间这个ip的稳定性就关系重大了。ip稳定性会受很多因素影响：n个交换机、线路、机器等等，颇为复杂。而首页很有可能会 用到异地的负载均衡，这么来不用dns，方案就很难设计了。现在的常用浏览器和下载软件，都有对dns的故障处理机制，所以dns也是可以屏蔽掉一些故障 的，虽然 …"

"图片服务通常数据容量较大，而且访问也频繁，鉴于此，图片服务就会有两种问题，一是存储问题，二是访问量问题。\n存储问题就是硬盘容量问题，花钱买硬盘就可以了，看似简单，但着实也是最苦的问题。按目前探索来看，最好的方式是：在任何时刻遇到硬盘空间不够时，买颗硬 盘插上，最多改改配置，就能立刻利用；另外，硬盘要能充分利用，不然图片存储量大再加上备份，很恐怖，最好是每颗硬盘都用上100%的空间。\n访问量也是个大问题，如果服务不允许防盗链，那么访问量会引起带宽、服务器压力等问题，有钱的话直接扔CDN，没钱或者有更多的钱，就自己做吧。根据垣古 不变的真理“越老的图，访问量也相对较少”这一点，分成两大部分，一边处理最新的图片，一边处理老旧的图片。最新的图片访问量大，但存储量较少；老图片访 问量低，但存储量大。\n大概分析完了，开始制定方案。\n一、拟定一个存储目录规则：\n在现有的/a/b/abcde.jpg这样的hash方式下多加一个日期的目录变成：/200810/16/a/b/abcde.jpg或者/2008 /10/16/a/b/abcde.jpg。按日期制定这个目录规则后，就可以按年月来拆机器了。\n二、 …"

"这是一个最简洁的架构。在这个架构里，负载均衡器都可以省了，用最为廉价的dns来替代，dns的优点就是廉价，不用维护，也不愁性能和稳定，还可以跨机房多用几条带宽作分流。 另外，在图片服务中，可以选择用另一个域名做dns。优点是主站中的任何cookie等header不会带到图片服务中，省了不少上传流量和服务器可能有 的处理时间；缺点是多花了点域名的钱。目前门户都喜欢用这办法，小站用的话，用另一个域名还附带有一个特别的优点：因为部分域名服务商允许添加的二级域名 有限，所以用别的域名可以节约有限的域名资源。dns这一块也可以用泛域名，不过貌似国内的泛域名支持不是特别的稳定，有些网站的泛域名，在linux下 不能解析windows就正常，比较奇怪，我也没法解释。\n在这个架构里我总共开了36个域名，但是一时没有那么多机器，所以有一些域名指向同一台机器。一般来说，一个刚上线的项目，放一台机也未尝不可，但是链接 （包括域名）一定要固定下来，不然以后调整会非常痛苦。\n域名的事情还是比较简单的，只要照着填写web表单就完成了，配置四台nginx服务器当然也是非常简单的，因为不需要什么特殊的功能，所以四台机 …"

"这几天常看到kangzj在博客里谈论代理， 上篇博文 也提到过反向代理，有同学对利用绝对路径绕过ghs起到加速作用不是很理解，那就总结一下反向代理的知 识。谈到google ghs时，说绕过ghs反向代理服务器直接使用*.appspot.com起到加速的目的，好像本文标题“利用反向代理提高网站速度”有点矛盾，其实不 然，我们域名下的资源文件绕过一个反向代理服务器，得到的appspot反向代理服务器更直接而且它有负载均衡机制。\n1. 什么是正向代理和正向代理服务器？\n正向代理就是通常所说的代理，是某台电脑通过一台服务器来上Internet网的这种 方式，其中这台电脑就叫客户机，这台服务器就叫正向代理服务器也就是通常所说的代理服务器。在这种方式中，你是主动的，网站是被动的，网站那里不能得到你 的真实ip地址。（通俗讲法）\n正向代理服务器。它只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务器（一般在 IE-Internet选项-连接-局域网设置），并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。\n2. 什么是反向代理和反向代理服务器?\n反向代理就是网 …"

"**反向代理（Reverse Proxy）**方式是指以代理服务器来接受internet上的连接请求，然后将请求转发给内部网络上的服务 器，并将从服务器上得到的结果返回给internet上请求连接的客户端，此时代理服务器对外就表现为一个服务器。\n通常的代理服务器，只用于代理内部网络对Internet的连接请求，客户机必须指定代理服务 器,并将本来要直接发送到Web服务器上的http请求发送到代理服务器中。由于外部网络上的主机并不会配置并使用这个代理服务器，普通代理服务器也被设 计为在Internet上搜寻多个不确定的服务器,而不是针对Internet上多个客户机的请求访问某一个固定的服务器，因此普通的Web代理服务器不 支持外部对内部网络的访问请求。当一个代理服务器能够代理外部网络上的主机，访问内部网络时，这种代理服务的方式称为反向代理服务。此时代理服务器对外就 表现为一个Web服务器，外部网络就可以简单把它当作一个标准的Web服务器而不需要特定的配置。不同之处在于，这个服务器没有保存任何网页的真实数据， 所有的静态网页或者CGI程序，都保存在内部的Web服务器上。因此对反向代理服务器 …"

"Google File System\n前言\n没什么好说的，传说中的文件系统，当代网络超大容量分布式文件系统设计的典范，Google的核心竞争力所在。Google的Search、GMail、 video、blog spaces等等都是用这个技术做的。Google目前的中国区总裁李开复就认为学计算机的学生都应该看看Google File System。\n很佩服Google的开放精神，将GoogleFS的详细设计写成了Paper: The Google File System, （ http://labs.google.com/papers/GoogleFS-sosp2003.pdf） 作者是Sanjay Ghemawat, Howard Gobioff, and Shun-Tak Leung。该论文长达15页，对Google FS介绍得非常详细，从设计时考虑的因素到详细的解决方案，以及测试和实际运行数据，都做了具体的说明，而不像IBM这么遮遮掩掩，从GPFS、 Storage Tank到TotalStorage SAN File System，一直都是小里小气的样子，生怕别人知道它做了啥。 …"

"Hadoop分布式文件系统：架构 和设计要点\n一、前提和设计目标\n1、硬件错误是常态，而非异常情况，HDFS可能是有成百上千的server组成，任何一个组件都有可能一直失效，因此错误检测和快速、自动的恢复是HDFS的核心架构目标。\n2、跑在HDFS上的应用与一般的应用不同，它们主要是以流式读为主，做批量处理；比之关注数据访问的低延迟问题，更关键的在于数据访问的高吞吐量。\n3、HDFS以支持大数据集合为目标，一个存储在上面的典型文件大小一般都在千兆至T字节，一个单一HDFS实例应该能支撑数以千万计的文件。\n4、HDFS应用对文件要求的是write-one-read-many访问模型。一个文 件经过创建、写，关闭之后就不需要改变。这一假设简化了数据一致性问 题，使高吞吐量的数据访问成为可能。典型的如MapReduce框架，或者一个web crawler应用都很适合这个模型。\n5、移动计算的代价比之移动数据的代价低。一个应用请求的计算，离它操作的数据越近就越高效，这在数据达到海量级别的时候更是如此。将计算移动到数据附近，比之将数据移动到应用所在显然更好，HDFS提供给应用这样的接口。\n6、在 …"

"网站文件的存储还是要讲究的，如果在网站成立初期，数据量不大就没有注意，随着时间的增长，网站的图片文件等数据肯定会越来越多，如何解决这些文件 存储也成了新的难题。如果把这些文件都完全采用大硬盘存储来解决，并不是一个好主意，因为数据量越大风险就越高，虽然文件能存得下，但是故障率相应会较 高，另外重建耗费时间也比较长。所以最好的办法是尽可能考虑分布式存储，把文件想办法利用网络分散到多个机器上。\n从我所了解的存储结构来看，分布式存储大致可以分为几种：\n1、类googlefs的分布式文件系统\n因为目前googlefs没有开源，所以网上出现的分布式文件系统都是利用google的方案自行实现的。这个方案的优点是可用性比较高，基本上基 于硬盘的应用都可以处理，可用范围就比较广泛。我看了gfs、gfs2、ocfs2、FastDFS、MogileFS的一些相关介绍，大致有一些认识。\n首先是文档比较少而出现的问题倒不少;然后是目前这些还没有一个能称得上是稳定版本，如果有的话，估计也就是其中一些收费的版本。因为磁盘存储乃是 致关重要，所以目前建议还是不要轻易把这些东西部署到重要的地方。假如非常想使用的话，最好 …"