就目前接触 UCMA的经验来看，太多的UCMA细节迷乱研发人员的视线，需要释放一下UCMA激情。我想到的方案是这样子，将UCMA的细节屏蔽掉，让研发人员无需关心UCMA的通信机制，直接完成业务，所谓以不变应万变。以一个普通的Text Robot为例，启动机器人、接收信息、解析信息、回复，这个过程中，启动机器人、接收信息、解析信息并处理、回复无论在何种场景中都可以抽出一些不变的因子。
启动机器人、接收信息相对固定，做成通用的，类似于一个IIS，只是承载对象不一定，IIS承载的是Web Page，而这里承载的是Robot App
解析信息设计并处理，设计标准接口，将接收到的信息进行解析并转发给具体实现
回复，将回复动作与回复内容分离，屏蔽UCMA操作细节，研发工程师调用封装好的回复操作
进一步，将UCMA做为一个信息通道，做为一个信息通道的具体实现。即，其他信息通道，如Email、Gtalk、电话等等，可以做为通道选择。一个Robot Server浮现出来ing
我想通过此种方式，能较好的释放UCMA激情。包装成Robot Server，真正化繁为简
证书服务商：https://www.startssl.com/
选择理由：Free
Demo 1:
安装效果:https://www.jishudao.com
变绿色滴啦
Deomo 2:
安装效果:https://www.zhongdaiqi.com
经验与心得：
1.StartSSL不是使用普通的帐号、密码登陆，而是使用证书，所以注册帐户的过程是一个证书安装的过程。不用太担心，按照提示操作即可。
2.生成证书需要先认证域名所有权，StartSSL会向域名注册人邮箱、或@domain的特定帐号发送认证码。
3.生成证书涉及多个密钥的生成，按照提示操作即可。
如有不明白之处，欢迎加入技术岛QQ群：193939203
1.原来在公司内网用Live Writer，走代理，配置的时候出问题，网上搜索了一堆解决办法，说是将某个文件的代码微调一下。当时这么操作了，可以写。
2.现在不在内网写了。又提示配置问题。把文件恢复，还是有问题。最后看到网上有提示说，某些插件会引起此问题。尝试性的将新浪微博插件禁用。保真，能用了~~
嘿嘿，终于可以用Live Writer啦，好久没有更新自己的博客。
这次想把博客丰富成UCMA方面的优质博客~~
接触UCMA3.0着实是个很大的意外。对UCMA一点概念都没有，对UC也只是听过这么个名词，连全名都不知道。接触UCMA，只能说是为了五斗米再一次折腰呗。做UCMA开发就像一个开卷考试，参考资料都丢到眼皮底下，考试的人却百般煎熬，看着文档束手无措。在此我不得不提及一位微软员工在博客里写的一句话：文档太过跳跃，又缺少上下文，摸索许多次才把环境搭好。
若是你也踏入UCMA3.0，正在困惑中，可以向我求助哈~
围观地址：http://product.dangdang.com/product.aspx?product_id=60255737
截图：
26岁的我，北漂，不暗熟村里的来来往往、人情冷暖。每逢过年，老爸会给自己找一个响当当的借口待在家里，绝不出去拜访左邻右社的旁系亲友。对老爸来说，这是一件多么困难的事情，他宁愿待着，宁愿在厨房忙着，也不愿意走动一下。我骨子里也有这种基因，但是过年总是逃不出叔叔的魔爪，我也没有什么理由可以拒绝如此有亲情意义的活动，这着实给我一些尴尬。
第一站，来到一位老奶奶家，我却不能称呼“老奶奶”，论家族字辈，只能称之为“伯母”，我们方言直译为“母母”。她，正在一个瓦房的小屋里烤火，给人很村里人感觉。W与小火坑可谓浑然一体，翻遍童年的记忆都找不到W与小火坑靠得如此近的情形，着实有些惊异，很惊奇，也很意味。此地不宜久留啊，叔叔急忙推辞不老奶奶的就坐邀请，我也乐得叔叔立即结束第一站拜年。水没喝，果子没吃，即刻奔往下一家。
第二站，直奔到了“小叔公”—我们家族健在的最具权威资历最深的男性人物。我想论权威论资历，略逊于我婆婆，但是小叔公家里到是很热闹，到感觉我婆婆过年在拜年环节的冷清。小叔公问及我在北京的工作，有扯出位在北京的某某怎么挣钱，尴尬啊。过年的常见问答我也记不住，只能附和一两句。在小叔公的小火坑周围，有10多号人，很有年味。我们的到来让小火坑拥挤不少，挤走了先来的几位。正当我们聊着，有来了一波，我和叔叔只好起身去下一家了。
第三站，又是一位老奶奶，这回是一位名正言顺的奶奶。没有火坑的奶奶伤不起啊，家里显示好冷清，再辅以老奶奶蹒跚的步伐，简直让人心酸。老奶奶见人来拜年甚是高兴，老奶奶让我们坐下来，叔叔和我却没有坐意。大厅里就一张饭桌，凳子是长长，用来吃饭的凳子。老奶奶让吃这吃那的，还抓把糖过来。可我已经不是小时的我，对果子没有兴趣啊，又不能伤到老奶奶，勉强吃了点。老奶奶像是有好多话要说，叔叔又要告辞了，我也紧紧的跟上。身后传来一句：“你们都不理我这个老太婆了”。
第四站，从西屋出来到东屋，这显然是两兄弟分家了。穿过客厅，来到厨房，厨房的角落有个小火坑，老爷爷守着小火坑。记得去年来过这里，老爷爷一个劲的讲自己的往事，没人理老爷爷在说什么，我叔叔此刻都会找到他的一个侄子，跟他一般大，他们聊自己的，老爷爷说自己的，我在旁边听着。他总是试图让大家听听他的故事，可是有故事也是徒劳，大家各自聊着。
离开小火坑时，我霎时发现,西屋的老奶奶与东屋的老爷爷不就是一对夫妻么，他们共同的渡过了多少年风风雨雨，步入往年却在分隔在东西屋，一墙之隔，一东一西，一个无火坑，一个有火坑，爱情的往年就是这样子么？
意义：
通过转换，将不同技术熟悉度不同难度不同规模的任务转化成任务指数。一方面可用于比较不同团队成员完成任务的效率。另一方面通过积累历史数据，使今后估算任务时间可以更精确。
名词
任务指数=技术熟悉度*难度*规模系数
时间=任务指数*系数
转载请注明出处
http://www.ibm.com/developerworks/cn/java/joy-down/index.html
其实断点续传的原理很简单，就是在 Http 的请求上和一般的下载有所不同而已。
打个比方，浏览器请求服务器上的一个文时，所发出的请求如下：
假设服务器域名为 wwww.sjtu.edu.cn，文件名为 down.zip。
GET /down.zip HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, application/vnd.ms-
excel, application/msword, application/vnd.ms-powerpoint, */*
Accept-Language: zh-cn
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
Connection: Keep-Alive
服务器收到请求后，按要求寻找请求的文件，提取文件的信息，然后返回给浏览器，返回信息如下：
200
Content-Length=106786028
Accept-Ranges=bytes
Date=Mon, 30 Apr 2001 12:56:11 GMT
ETag=W/"02ca57e173c11:95b"
Content-Type=application/octet-stream
Server=Microsoft-IIS/5.0
Last-Modified=Mon, 30 Apr 2001 12:56:11 GMT
所谓断点续传，也就是要从文件已经下载的地方开始继续下载。所以在客户端浏览器传给 Web 服务器的时候要多加一条信息 — 从哪里开始。
下面是用自己编的一个"浏览器"来传递请求信息给 Web 服务器，要求从 2000070 字节开始。
GET /down.zip HTTP/1.0
User-Agent: NetFox
RANGE: bytes=2000070-
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
仔细看一下就会发现多了一行 RANGE: bytes=2000070-
这一行的意思就是告诉服务器 down.zip 这个文件从 2000070 字节开始传，前面的字节不用传了。
服务器收到这个请求以后，返回的信息如下：
206
Content-Length=106786028
Content-Range=bytes 2000070-106786027/106786028
Date=Mon, 30 Apr 2001 12:55:20 GMT
ETag=W/"02ca57e173c11:95b"
Content-Type=application/octet-stream
Server=Microsoft-IIS/5.0
Last-Modified=Mon, 30 Apr 2001 12:55:20 GMT
和前面服务器返回的信息比较一下，就会发现增加了一行：
Content-Range=bytes 2000070-106786027/106786028
返回的代码也改为 206 了，而不再是 200 了。
知道了以上原理，就可以进行断点续传的编程了。
- (1) 用什么方法实现提交 RANGE: bytes=2000070-。
当然用最原始的 Socket 是肯定能完成的，不过那样太费事了，其实 Java 的 net 包中提供了这种功能。代码如下：
URL url = new URL("http://www.sjtu.edu.cn/down.zip");
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection();
// 设置 User-Agent
httpConnection.setRequestProperty("User-Agent","NetFox");
// 设置断点续传的开始位置
httpConnection.setRequestProperty("RANGE","bytes=2000070");
// 获得输入流
InputStream input = httpConnection.getInputStream();从输入流中取出的字节流就是 down.zip 文件从 2000070 开始的字节流。大家看，其实断点续传用 Java 实现起来还是很简单的吧。接下来要做的事就是怎么保存获得的流到文件中去了。
- 保存文件采用的方法。
我采用的是 IO 包中的 RandAccessFile 类。
操作相当简单，假设从 2000070 处开始保存文件，代码如下：
RandomAccess oSavedFile = new RandomAccessFile("down.zip","rw");
long nPos = 2000070;
// 定位文件指针到 nPos 位置
oSavedFile.seek(nPos);
byte[] b = new byte[1024];
int nRead;
// 从输入流中读入字节流，然后写到文件中
while((nRead=input.read(b,0,1024)) > 0)
{
oSavedFile.write(b,0,nRead);
}
怎么样，也很简单吧。接下来要做的就是整合成一个完整的程序了。包括一系列的线程控制等等。
主要用了 6 个类，包括一个测试类。
SiteFileFetch.java 负责整个文件的抓取，控制内部线程 (FileSplitterFetch 类 )。
FileSplitterFetch.java 负责部分文件的抓取。
FileAccess.java 负责文件的存储。
SiteInfoBean.java 要抓取的文件的信息，如文件保存的目录，名字，抓取文件的 URL 等。
Utility.java 工具类，放一些简单的方法。
TestMethod.java 测试类。
下面是源程序：
/*
/*
* SiteFileFetch.java
*/
package NetFox;
import java.io.*;
import java.net.*;
public class SiteFileFetch extends Thread {
SiteInfoBean siteInfoBean = null; // 文件信息 Bean
long[] nStartPos; // 开始位置
long[] nEndPos; // 结束位置
FileSplitterFetch[] fileSplitterFetch; // 子线程对象
long nFileLength; // 文件长度
boolean bFirst = true; // 是否第一次取文件
boolean bStop = false; // 停止标志
File tmpFile; // 文件下载的临时信息
DataOutputStream output; // 输出到文件的输出流
public SiteFileFetch(SiteInfoBean bean) throws IOException
{
siteInfoBean = bean;
//tmpFile = File.createTempFile ("zhong","1111",new File(bean.getSFilePath()));
tmpFile = new File(bean.getSFilePath()+File.separator + bean.getSFileName()+".info");
if(tmpFile.exists ())
{
bFirst = false;
read_nPos();
}
else
{
nStartPos = new long[bean.getNSplitter()];
nEndPos = new long[bean.getNSplitter()];
}
}
public void run()
{
// 获得文件长度
// 分割文件
// 实例 FileSplitterFetch
// 启动 FileSplitterFetch 线程
// 等待子线程返回
try{
if(bFirst)
{
nFileLength = getFileSize();
if(nFileLength == -1)
{
System.err.println("File Length is not known!");
}
else if(nFileLength == -2)
{
System.err.println("File is not access!");
}
else
{
for(int i=0;i<nStartPos.length;i++)
{
nStartPos[i] = (long)(i*(nFileLength/nStartPos.length));
}
for(int i=0;i<nEndPos.length-1;i++)
{
nEndPos[i] = nStartPos[i+1];
}
nEndPos[nEndPos.length-1] = nFileLength;
}
}
// 启动子线程
fileSplitterFetch = new FileSplitterFetch[nStartPos.length];
for(int i=0;i<nStartPos.length;i++)
{
fileSplitterFetch[i] = new FileSplitterFetch(siteInfoBean.getSSiteURL(),
siteInfoBean.getSFilePath() + File.separator + siteInfoBean.getSFileName(),
nStartPos[i],nEndPos[i],i);
Utility.log("Thread " + i + " , nStartPos = " + nStartPos[i] + ", nEndPos = "
+ nEndPos[i]);
fileSplitterFetch[i].start();
}
// fileSplitterFetch[nPos.length-1] = new FileSplitterFetch(siteInfoBean.getSSiteURL(),
siteInfoBean.getSFilePath() + File.separator
+ siteInfoBean.getSFileName(),nPos[nPos.length-1],nFileLength,nPos.length-1);
// Utility.log("Thread " +(nPos.length-1) + ",nStartPos = "+nPos[nPos.length-1]+",
nEndPos = " + nFileLength);
// fileSplitterFetch[nPos.length-1].start();
// 等待子线程结束
//int count = 0;
// 是否结束 while 循环
boolean breakWhile = false;
while(!bStop)
{
write_nPos();
Utility.sleep(500);
breakWhile = true;
for(int i=0;i<nStartPos.length;i++)
{
if(!fileSplitterFetch[i].bDownOver)
{
breakWhile = false;
break;
}
}
if(breakWhile)
break;
//count++;
//if(count>4)
// siteStop();
}
System.err.println("文件下载结束！");
}
catch(Exception e){e.printStackTrace ();}
}
// 获得文件长度
public long getFileSize()
{
int nFileLength = -1;
try{
URL url = new URL(siteInfoBean.getSSiteURL());
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection ();
httpConnection.setRequestProperty("User-Agent","NetFox");
int responseCode=httpConnection.getResponseCode();
if(responseCode>=400)
{
processErrorCode(responseCode);
return -2; //-2 represent access is error
}
String sHeader;
for(int i=1;;i++)
{
//DataInputStream in = new DataInputStream(httpConnection.getInputStream ());
//Utility.log(in.readLine());
sHeader=httpConnection.getHeaderFieldKey(i);
if(sHeader!=null)
{
if(sHeader.equals("Content-Length"))
{
nFileLength = Integer.parseInt(httpConnection.getHeaderField(sHeader));
break;
}
}
else
break;
}
}
catch(IOException e){e.printStackTrace ();}
catch(Exception e){e.printStackTrace ();}
Utility.log(nFileLength);
return nFileLength;
}
// 保存下载信息（文件指针位置）
private void write_nPos()
{
try{
output = new DataOutputStream(new FileOutputStream(tmpFile));
output.writeInt(nStartPos.length);
for(int i=0;i<nStartPos.length;i++)
{
// output.writeLong(nPos[i]);
output.writeLong(fileSplitterFetch[i].nStartPos);
output.writeLong(fileSplitterFetch[i].nEndPos);
}
output.close();
}
catch(IOException e){e.printStackTrace ();}
catch(Exception e){e.printStackTrace ();}
}
// 读取保存的下载信息（文件指针位置）
private void read_nPos()
{
try{
DataInputStream input = new DataInputStream(new FileInputStream(tmpFile));
int nCount = input.readInt();
nStartPos = new long[nCount];
nEndPos = new long[nCount];
for(int i=0;i<nStartPos.length;i++)
{
nStartPos[i] = input.readLong();
nEndPos[i] = input.readLong();
}
input.close();
}
catch(IOException e){e.printStackTrace ();}
catch(Exception e){e.printStackTrace ();}
}
private void processErrorCode(int nErrorCode)
{
System.err.println("Error Code : " + nErrorCode);
}
// 停止文件下载
public void siteStop()
{
bStop = true;
for(int i=0;i<nStartPos.length;i++)
fileSplitterFetch[i].splitterStop();
}
}
/*
**FileSplitterFetch.java
*/
package NetFox;
import java.io.*;
import java.net.*;
public class FileSplitterFetch extends Thread {
String sURL; //File URL
long nStartPos; //File Snippet Start Position
long nEndPos; //File Snippet End Position
int nThreadID; //Thread's ID
boolean bDownOver = false; //Downing is over
boolean bStop = false; //Stop identical
FileAccessI fileAccessI = null; //File Access interface
public FileSplitterFetch(String sURL,String sName,long nStart,long nEnd,int id)
throws IOException
{
this.sURL = sURL;
this.nStartPos = nStart;
this.nEndPos = nEnd;
nThreadID = id;
fileAccessI = new FileAccessI(sName,nStartPos);
}
public void run()
{
while(nStartPos < nEndPos && !bStop)
{
try{
URL url = new URL(sURL);
HttpURLConnection httpConnection = (HttpURLConnection)url.openConnection ();
httpConnection.setRequestProperty("User-Agent","NetFox");
String sProperty = "bytes="+nStartPos+"-";
httpConnection.setRequestProperty("RANGE",sProperty);
Utility.log(sProperty);
InputStream input = httpConnection.getInputStream();
//logResponseHead(httpConnection);
byte[] b = new byte[1024];
int nRead;
while((nRead=input.read(b,0,1024)) > 0 && nStartPos < nEndPos
&& !bStop)
{
nStartPos += fileAccessI.write(b,0,nRead);
//if(nThreadID == 1)
// Utility.log("nStartPos = " + nStartPos + ", nEndPos = " + nEndPos);
}
Utility.log("Thread " + nThreadID + " is over!");
bDownOver = true;
//nPos = fileAccessI.write (b,0,nRead);
}
catch(Exception e){e.printStackTrace ();}
}
}
// 打印回应的头信息
public void logResponseHead(HttpURLConnection con)
{
for(int i=1;;i++)
{
String header=con.getHeaderFieldKey(i);
if(header!=null)
//responseHeaders.put(header,httpConnection.getHeaderField(header));
Utility.log(header+" : "+con.getHeaderField(header));
else
break;
}
}
public void splitterStop()
{
bStop = true;
}
}
/*
**FileAccess.java
*/
package NetFox;
import java.io.*;
public class FileAccessI implements Serializable{
RandomAccessFile oSavedFile;
long nPos;
public FileAccessI() throws IOException
{
this("",0);
}
public FileAccessI(String sName,long nPos) throws IOException
{
oSavedFile = new RandomAccessFile(sName,"rw");
this.nPos = nPos;
oSavedFile.seek(nPos);
}
public synchronized int write(byte[] b,int nStart,int nLen)
{
int n = -1;
try{
oSavedFile.write(b,nStart,nLen);
n = nLen;
}
catch(IOException e)
{
e.printStackTrace ();
}
return n;
}
}
/*
**SiteInfoBean.java
*/
package NetFox;
public class SiteInfoBean {
private String sSiteURL; //Site's URL
private String sFilePath; //Saved File's Path
private String sFileName; //Saved File's Name
private int nSplitter; //Count of Splited Downloading File
public SiteInfoBean()
{
//default value of nSplitter is 5
this("","","",5);
}
public SiteInfoBean(String sURL,String sPath,String sName,int nSpiltter)
{
sSiteURL= sURL;
sFilePath = sPath;
sFileName = sName;
this.nSplitter = nSpiltter;
}
public String getSSiteURL()
{
return sSiteURL;
}
public void setSSiteURL(String value)
{
sSiteURL = value;
}
public String getSFilePath()
{
return sFilePath;
}
public void setSFilePath(String value)
{
sFilePath = value;
}
public String getSFileName()
{
return sFileName;
}
public void setSFileName(String value)
{
sFileName = value;
}
public int getNSplitter()
{
return nSplitter;
}
public void setNSplitter(int nCount)
{
nSplitter = nCount;
}
}
/*
**Utility.java
*/
package NetFox;
public class Utility {
public Utility()
{
}
public static void sleep(int nSecond)
{
try{
Thread.sleep(nSecond);
}
catch(Exception e)
{
e.printStackTrace ();
}
}
public static void log(String sMsg)
{
System.err.println(sMsg);
}
public static void log(int sMsg)
{
System.err.println(sMsg);
}
}
/*
**TestMethod.java
*/
package NetFox;
public class TestMethod {
public TestMethod()
{ ///xx/weblogic60b2_win.exe
try{
SiteInfoBean bean = new SiteInfoBean("http://localhost/xx/weblogic60b2_win.exe",
"L:\\temp","weblogic60b2_win.exe",5);
//SiteInfoBean bean = new SiteInfoBean("http://localhost:8080/down.zip","L:\\temp",
"weblogic60b2_win.exe",5);
SiteFileFetch fileFetch = new SiteFileFetch(bean);
fileFetch.start();
}
catch(Exception e){e.printStackTrace ();}
}
public static void main(String[] args)
{
new TestMethod();
}
}
钟华，您可以通过电子邮件 zhong_hua@263.net 跟他联系。
浅谈千万级PV/IP规模高性能高并发网站架构
作者：老男孩 QQ：31333741
原文地址：http://blog.chinaunix.net/space.php?uid=26131888&do=blog&id=3034987
BLOG:http://oldboy.blog.chinaunix.net
高并发访问的核心原则其实就一句话“把所有的用户访问请求都尽量往前推”。
如果把来访用户比作来犯的"敌人"，我们一定要把他们挡在800里地以外，即不能让他们的请求一下打到我们的指挥部（指挥部就是数据库及分布式存储）。
如：能缓存在用户电脑本地的，就不要让他去访问CDN。 能缓存CDN服务器上的，就不要让CDN去访问源（静态服务器）了。能访问静态服务器的，就不要去访问动态服务器。以此类推：能不访问数据库和存储就一定不要去访问数据库和存储。
说起来很轻松，实际做起来却不容易，但只要稍加努力是可以做到的，Google的日独立IP过亿不也做到了么？我们这几千万的PV站比起Google不是小屋见大屋了。我们还是先从我们的小屋搭起吧！哈哈！下面内容的介绍起点是千万级别的PV站，也可以支持亿级PV的网站架构。
高性能高并发高可扩展网站架构访问的几个层次：
有人会问，我们老是说把用户对业务的访问往前推，到底怎么推啊？推到哪呢？下面，老男孩就为大家一一道来。
第一层：首先在用户浏览器端，使用Apache的mod_deflate压缩传输，再比如：expires功能、deflate和expires功能利用的好，就会大大提升用户体验效果及减少网站带宽，减少后端服务器的压力。当然，方法还有很多，这里不一一细谈了。
提示：有关压缩传输及expires功能nginx/lighttpd等软件同样也有。
第二层：页面元素，如图片/js/css等或静态数据html，这个层面是网页缓存层,比如CDN（效果比公司自己部署squid/nginx要好，他们更专业，价格低廉，比如快网/CC等（价格80元/M/月甚至更低）而且覆盖的城市节点更多），自己架设squid/nginx cache来做小型CDN是次选(超大规模的公司可能会考虑风险问题实行自建加购买服务结合)，除非是为前端的CDN提供数据源服务，以减轻后端我们的服务器数据及存储压力，而不是直接提供cache服务给最终用户。taobao的CDN曾经因为一部分图片的次寸大而导致CDN压力大的情况，甚至对图片尺寸大的来改小，以达到降低流量及带宽的作用。
提示：我们也可以自己架设一层cache层，对我们购买的CDN提供数据源服务，可用的软件有varnish/nginx/squid 等cache，以减轻第三层静态数据层的压力。在这层的前端我们也可以架设DNS服务器，来达到跨机房业务拓展及智能解析的目的。
第三层：静态服务器层一般为图片服务器，视频服务器，静态HTML服务器。这一层是前面缓存层和后面动态服务器层的连接纽带，大公司发布新闻等内容直接由发布人员分发到各cache节点（sina,163等都是如此），这和一般公司的业务可能不一样。所以，没法直接的参考模仿，比如人人的SNS。
我们可以使用Q队列方式实现异步的分发访问，同时把动态发布数据（数据库中的数据）静态化存储。即放到本层访问，或通过其他办法发布到各cache节点，而不是直接让所有用户去访问数据库，不知道大家发现了没有，qq.com门户的新闻评论多的有几十万条，如果所有用户一看新闻就加载所有评论，那数据库不挂才怪。他们的评论需要审核（美其名约，实际是异步的方式，而且，评论可能都是静态化的或类似的静态化或内存cache的方式），这点可能就是需要51cto.com这样站点学习的，你们打开51CTO的一篇博文，就会发现下面的评论一直都显示出来了，也可能是分页的。不过，应该都是直接读库的，一旦访问量大，数据库压力大是必然。这里不是说51cto网站不好，所有的网站都是从类似的程序架构开始发展的。CU也可能是如此。
提示：我们可以在静态数据层的前端自己架设一层cache层，对我们购买的CDN提供数据源服务，可用的软件有varnish/nginx/squid 等cache。在这层的前端我们也可以架设DNS服务器，来达到跨机房业务拓展及智能解析的目的。
第四层：动态服务器层：php,java等，只有透过了前面3层后的访问请求才会到这个层，才可能会访问数据库及存储设备。经过前三层的访问过滤能到这层访问请求一般来说已非常少了，一般都是新发布的内容和新发布内容第一次浏览如；博文（包括微博等），BBS帖子。
特别提示：此层可以在程序上多做文章，比如向下访问cache层，memcache,memcachedb,tc,mysql,oracle，在程序级别实现分布式访问，分布式读写分离，而程序级别分布式访问的每个db cache节点，又可以是一组业务或者一组业务拆分开来的多台服务器的负载均衡。这样的架构会为后面的数据库和存储层大大的减少压力，那么这里呢，相当于指挥部的外层了。
第五层：数据库cache层，比如：memcache,memcachedb,tc等等。
根据不同的业务需求，选择适合具体业务的数据库。对于memcache、memcachedb ttserver及相关nosql数据库，可以在第四层通过程序来实现对本层实现分布式访问，每个分布式访问的节点都可能是一组负载均衡（数十台机器）。
第六层：数据库层，一般的不是超大站点都会用mysql主从结构，如：163,sina,kaixin都是如此，程序层做分布式数据库读写分离，一主（或双主）多从的方式，访问大了，可以做级连的主从及环状的多主多从，然后，实现多组负载均衡，供前端的分布式程序调用，如果访问量在大，就需要拆业务了，比如：我再给某企业做兼职时，发现类似的51cto的一个站点，把www服务,blog服务，bbs服务都放一个服务器上，然后做主从。这种情况，当业务访问量大了，可以简单的把www,blog,bbs服务分别各用一组服务器拆分开，这种方式运维都会的没啥难度。当然访问量在大了，可以继续针对某一个服务拆分如：www库拆分，每个库做一组负载均衡，还可以对库里的表拆分。需要高可用可以通过drbd等工具做成高可用方式。对于写大的，可以做主主或多主的MYSQL REP方式，对于ORACLE来说，来几组oracle DG（1master多salve方式）就够了，11G的DG可以象mysql rep一样，支持读写分离了。当然可选的方案还有，mysql cluster 和oracle 的RAC，玩mysql cluster和oracle RAC要需要更好更多的硬件及部署后的大量维护成本，因此，要综合考虑，到这里访问量还很大，那就恭喜了，起码是几千万以上甚至上亿的PV了。
象百度等巨型公司除了会采用常规的mysql及oracle数据库库外，会在性能要求更高的领域，大量的使用nosql数据库，然后前端在加DNS，负载均衡，分布式的读写分离，最后依然是拆业务，拆库，。。。逐步细化，然后每个点又可以是一组或多组机器。
特别提示：数据库层的硬件好坏也会决定访问量的多少，尤其是要考虑磁盘IO的问题，大公司往往在性价比上做文章，比如核心业务采用硬件netapp/emc及san光纤架构，对于资源数据存储，如图片视频，会采用sas或固态ssd盘，如果数据超大，可以采取热点分取分存的方法：如：最常访问的10-20%使用ssd存储，中间的20-30%采用sas盘，最后的40-50%可以采用廉价的sata。
第七层：千万级PV的站如果设计的合理一些，1，2个NFS SERVER就足够了。我所维护（兼职）或经历过的上千万PV的用NFS及普通服务器做存储的还有大把，多一些磁盘，如SAS 15K*6的，或者用dell6850，搞几组 NFS存储，中小网站足够了。当然可以做成drbd+heartbeat+nfs+a/a的方式。
如果能达到本文设计要求的，中等规模网站，后端的数据库及存储压力会非常小了。 象门户网站级别，如sina等， 会采用硬件netapp/emc等等硬件存储设备或是san光纤同道，甚至在性价比上做文章，比如核心业务采用硬件netapp/emc及san光纤架构，对于资源数据存储，如图片视频，会采用sas或固态ssd盘，如果数据超到，可以采取热点分取分存的方法：如：最常访问的10-20%使用ssd存储，中间的20-30%采用sas盘，最后的40-50%可以采用廉价的sata。
象百度等巨型公司会采用hadoop等分布式的存储架构，前端在加上多层CACHE及多及的负载均衡，同样会根据业务进行拆分，比如爬虫层存储，索引层存储，服务层存储。。。可以更细更细。。。为了应付压力，什么手段都用上了。
特殊业务，如人人，开心网，包括门户网站的评论，微博，大多都是异步的写入方式，即无论读写，并发访问数据库都是非常少量的。
以上1-7层，如果都搭好了，这样漏网到第四层动态服务器层的访问，就不多了。一般的中等站点，绝对不会对数据库造成太大的压力。程序层的分布式访问是从千万及PV向亿级PV的发展，当然特殊的业务 还需要特殊架构，来合理利用数据库和存储。
老男孩个人资料介绍：
资深Linux运维架构专家、高级运维总监，从事一线运维及系统架构10年+，曾维护千万级/亿级PV的几个行业门户网站，并将多年的运维经验成功应用到教育领域教育教学工作多年。
老男孩从事多年的IT教育领域一线工作，对IT教育有着非同寻常的认识，研习过教育心理学，并于2008年创办了老男孩linux运维培训机构，培训中心以其独特的先进的教育教学理念及创新的科学学习方法。累计培养了数百名linux运维行业精英人才。
个人blog:http://oldboy.blog.chinaunix.net
======================================================
欢迎广到运维兄弟一起交流linux/unix网站运维技术!
老男孩 QQ:31333741
mail:31333741@qq.com
======================================================
