亚洲片一区二区三区,亚洲一区二区影院,亚洲人成图片网站

2006年11月11日

API網(wǎng)關(guān)作用、方案及如何選擇

在這篇文章中將我們一起來(lái)探討當(dāng)前的API網(wǎng)關(guān)的作用。

一、API網(wǎng)關(guān)的用處

API網(wǎng)關(guān)我的分析中會(huì)用到以下三種場(chǎng)景。

Open API。企業(yè)需要將自身數(shù)據(jù)、能力等作為開(kāi)發(fā)平臺(tái)向外開(kāi)放，通常會(huì)以rest的方式向外提供，最好的例子就是淘寶開(kāi)放平臺(tái)、騰訊公司的QQ開(kāi)放平臺(tái)、微信開(kāi)放平臺(tái)。 Open API開(kāi)放平臺(tái)必然涉及到客戶應(yīng)用的接入、API權(quán)限的管理、調(diào)用次數(shù)管理等，必然會(huì)有一個(gè)統(tǒng)一的入口進(jìn)行管理，這正是API網(wǎng)關(guān)可以發(fā)揮作用的時(shí)候。
微服務(wù)網(wǎng)關(guān)。微服務(wù)的概念最早在2012年提出，在Martin Fowler的大力推廣下，微服務(wù)在2014年后得到了大力發(fā)展。在微服務(wù)架構(gòu)中，有一個(gè)組件可以說(shuō)是必不可少的，那就是微服務(wù)網(wǎng)關(guān)，微服務(wù)網(wǎng)關(guān)處理了負(fù)載均衡，緩存，路由，訪問(wèn)控制，服務(wù)代理，監(jiān)控，日志等。API網(wǎng)關(guān)在微服務(wù)架構(gòu)中正是以微服務(wù)網(wǎng)關(guān)的身份存在。
API服務(wù)管理平臺(tái)。上述的微服務(wù)架構(gòu)對(duì)企業(yè)來(lái)說(shuō)有可能實(shí)施上是困難的，企業(yè)有很多遺留系統(tǒng)，要全部抽取為微服務(wù)器改動(dòng)太大，對(duì)企業(yè)來(lái)說(shuō)成本太高。但是由于不同系統(tǒng)間存在大量的API服務(wù)互相調(diào)用，因此需要對(duì)系統(tǒng)間服務(wù)調(diào)用進(jìn)行管理，清晰地看到各系統(tǒng)調(diào)用關(guān)系，對(duì)系統(tǒng)間調(diào)用進(jìn)行監(jiān)控等。 API網(wǎng)關(guān)可以解決這些問(wèn)題，我們可以認(rèn)為如果沒(méi)有大規(guī)模的實(shí)施微服務(wù)架構(gòu)，那么對(duì)企業(yè)來(lái)說(shuō)微服務(wù)網(wǎng)關(guān)就是企業(yè)的API服務(wù)管理平臺(tái)。

二、API網(wǎng)關(guān)在企業(yè)整體架構(gòu)中的地位

一個(gè)企業(yè)隨著信息系統(tǒng)復(fù)雜度的提高，必然出現(xiàn)外部合作伙伴應(yīng)用、企業(yè)自身的公網(wǎng)應(yīng)用、企業(yè)內(nèi)網(wǎng)應(yīng)用等，在架構(gòu)上應(yīng)該將這三種應(yīng)用區(qū)別開(kāi)，三種應(yīng)用的安排級(jí)別、訪問(wèn)方式也不一樣。因此在我的設(shè)計(jì)中將這三種應(yīng)用分別用不同的網(wǎng)關(guān)進(jìn)行API管理，分別是：API網(wǎng)關(guān)（OpenAPI合伙伙伴應(yīng)用）、API網(wǎng)關(guān)（內(nèi)部應(yīng)用）、API網(wǎng)關(guān)（內(nèi)部公網(wǎng)應(yīng)用）。

三、企業(yè)中在如何應(yīng)用API網(wǎng)關(guān)

1、對(duì)于OpenAPI使用的API網(wǎng)關(guān)來(lái)說(shuō)，一般合作伙伴要以應(yīng)用的形式接入到OpenAPI平臺(tái)，合作伙伴需要到 OpenAPI平臺(tái)申請(qǐng)應(yīng)用。因此在OpenAPI網(wǎng)關(guān)之外，需要有一個(gè)面向合作伙伴的使用的平臺(tái)用于合作伙伴，這就要求OpenAPI網(wǎng)關(guān)需要提供API給這個(gè)用戶平臺(tái)進(jìn)行訪問(wèn)。如下架構(gòu):

當(dāng)然如果是在簡(jiǎn)單的場(chǎng)景下，可能并不需要提供一個(gè)面向合作伙伴的門(mén)戶，只需要由公司的運(yùn)營(yíng)人員直接添加合作伙伴應(yīng)用id/密鑰等，這種情況下也就不需要合作伙伴門(mén)戶子系統(tǒng)。

2、對(duì)于內(nèi)網(wǎng)的API網(wǎng)關(guān)，在起到的作用上來(lái)說(shuō)可以認(rèn)為是微服務(wù)網(wǎng)關(guān)，也可以認(rèn)為是內(nèi)網(wǎng)的API服務(wù)治理平臺(tái)。當(dāng)企業(yè)將所有的應(yīng)用使用微服務(wù)的架構(gòu)管理起來(lái)，那么API網(wǎng)關(guān)就起到了微服務(wù)網(wǎng)關(guān)的作用。而當(dāng)企業(yè)只是將系統(tǒng)與系統(tǒng)之間的調(diào)用使用rest api的方式進(jìn)行訪問(wèn)時(shí)使用API網(wǎng)關(guān)對(duì)調(diào)用進(jìn)行管理，那么API網(wǎng)關(guān)起到的就是API服務(wù)治理的作用。架構(gòu)參考如下：

3、對(duì)于公司內(nèi)部公網(wǎng)應(yīng)用（如APP、公司的網(wǎng)站），如果管理上比較細(xì)致，在架構(gòu)上是可能由獨(dú)立的API網(wǎng)關(guān)來(lái)處理這部分內(nèi)部公網(wǎng)應(yīng)用，如果想比較簡(jiǎn)單的處理，也可以是使用面向合作伙伴的API網(wǎng)關(guān)。如果使用獨(dú)立的API網(wǎng)關(guān)，有以下的好處：

面向合作伙伴和面向公司主體業(yè)務(wù)的優(yōu)先級(jí)不一樣，不同的API網(wǎng)關(guān)可以做到業(yè)務(wù)影響的隔離。
內(nèi)部API使用的管理流程和面向合作伙伴的管理流程可能不一樣。
內(nèi)部的API在功能擴(kuò)展等方面的需求一般會(huì)大于OpenAPI對(duì)于功能的要求。

基于以上的分析，如果公司有能力，那么還是建議分開(kāi)使用合作伙伴OPEN API網(wǎng)關(guān)和內(nèi)部公網(wǎng)應(yīng)用網(wǎng)關(guān)。

四、API網(wǎng)關(guān)有哪些競(jìng)爭(zhēng)方案

1、對(duì)于Open API平臺(tái)的API網(wǎng)關(guān)，我分析只能選擇API網(wǎng)關(guān)作為解決方案，業(yè)界沒(méi)有發(fā)現(xiàn)比較好的可以用來(lái)作為Open API平臺(tái)的入口的其他方案。

2、對(duì)于作為微服務(wù)網(wǎng)關(guān)的API網(wǎng)關(guān)，業(yè)界的選擇可以選擇的解決方案比較多，也取決于微服務(wù)器的實(shí)現(xiàn)方案，有一些微服務(wù)架構(gòu)的實(shí)現(xiàn)方案是不需要微服務(wù)網(wǎng)關(guān)的。

Service Mesh，這是新興的基于無(wú)API網(wǎng)關(guān)的架構(gòu)，通過(guò)在客戶端上的代理完成屏蔽網(wǎng)絡(luò)層的訪問(wèn)，這樣達(dá)到對(duì)應(yīng)用層最小的改動(dòng)，當(dāng)前Service Mesh的產(chǎn)品還正在開(kāi)發(fā)中，并沒(méi)有非常成熟可直接應(yīng)用的產(chǎn)品。發(fā)展最迅速的產(chǎn)品是Istio。建議大家密切關(guān)注相關(guān)產(chǎn)品的研發(fā)、業(yè)務(wù)使用進(jìn)展。

基于duboo架構(gòu)，在這個(gè)架構(gòu)中通常是不需要網(wǎng)關(guān)的，是由客戶端直接訪問(wèn)服務(wù)提供方，由注冊(cè)中心向客戶端返回服務(wù)方的地址。

五、API網(wǎng)關(guān)解決方案

私有云開(kāi)源解決方案如下：

Kong kong是基于Nginx+Lua進(jìn)行二次開(kāi)發(fā)的方案， https://konghq.com/
Netflix Zuul，zuul是spring cloud的一個(gè)推薦組件，https://github.com/Netflix/zuul
orange,這個(gè)開(kāi)源程序是國(guó)人開(kāi)發(fā)的， http://orange.sumory.com/

公有云解決方案：

Amazon API Gateway，https://aws.amazon.com/cn/api-gateway/
阿里云API網(wǎng)關(guān)，https://www.aliyun.com/product/apigateway/
騰訊云API網(wǎng)關(guān)， https://cloud.tencent.com/product/apigateway

自開(kāi)發(fā)解決方案：

基于Nginx+Lua+ OpenResty的方案，可以看到Kong,orange都是基于這個(gè)方案
基于Netty、非阻塞IO模型。通過(guò)網(wǎng)上搜索可以看到國(guó)內(nèi)的宜人貸等一些公司是基于這種方案，是一種成熟的方案。
基于Node.js的方案。這種方案是應(yīng)用了Node.js天生的非阻塞的特性。
基于java Servlet的方案。 zuul基于的就是這種方案，這種方案的效率不高，這也是zuul總是被詬病的原因。

六、企業(yè)怎么選擇API網(wǎng)關(guān)

如果是要選擇一款已有的API網(wǎng)關(guān)，那么需要從以下幾個(gè)方面去考慮。

1、性能與可用性
如果一旦采用了API網(wǎng)關(guān)，那么API網(wǎng)關(guān)就會(huì)作為企業(yè)應(yīng)用核心，因此性能和可用性是必須要求的。

從性能上來(lái)說(shuō)，需要讓網(wǎng)關(guān)增加的時(shí)間消耗越短越好，個(gè)人覺(jué)得需要10ms以下。系統(tǒng)需要采用非阻塞的IO，如epoll，NIO等。網(wǎng)關(guān)和各種依賴的交互也需要是非阻塞的，這樣才能保證整體系統(tǒng)的高可用性，如：Node.js的響應(yīng)式編程和基于java體現(xiàn)的RxJava和Future。
網(wǎng)關(guān)必須支持集群部署，任務(wù)一臺(tái)服務(wù)器的crash都應(yīng)該不影響整體系統(tǒng)的可用性。
多套網(wǎng)關(guān)應(yīng)該支持同一管理平臺(tái)和同一監(jiān)控中心。如：一個(gè)企業(yè)的OpenAPI網(wǎng)關(guān)和內(nèi)部應(yīng)用的多個(gè)系統(tǒng)群的不同的微服務(wù)網(wǎng)關(guān)可以在同一監(jiān)控中心進(jìn)行監(jiān)控。

2、可擴(kuò)展性、可維護(hù)性
一款產(chǎn)品總有不能滿足生產(chǎn)需求的地方，因此需求思考產(chǎn)品在如何進(jìn)行二次開(kāi)發(fā)和維護(hù)，是否方便公司團(tuán)隊(duì)接手維護(hù)產(chǎn)品。
3、需求匹配度
需要評(píng)估各API網(wǎng)關(guān)在需求上是否能滿足，如：如果是OpenAPI平臺(tái)需要使用API網(wǎng)關(guān)，那么需要看API網(wǎng)關(guān)在合作伙伴應(yīng)用接入、合作伙伴門(mén)戶集成、訪問(wèn)次數(shù)限額等OpenAPI核心需求上去思考產(chǎn)品是否能滿足要求。如果是微服務(wù)網(wǎng)關(guān)，那么要從微服務(wù)的運(yùn)維、監(jiān)控、管理等方面去思考產(chǎn)品是否足夠強(qiáng)大。
4、是否開(kāi)源？公司是否有自開(kāi)發(fā)的能力？
現(xiàn)有的開(kāi)源產(chǎn)品如kong，zuul，orange都有基礎(chǔ)的API網(wǎng)關(guān)的核心功能，這些開(kāi)源產(chǎn)品大多離很好的使用有一定的距離，如：沒(méi)有提供管理功能的UI界面、監(jiān)控功能弱小，不支持OpenAPI平臺(tái)，沒(méi)有公司運(yùn)營(yíng)與運(yùn)維的功能等。當(dāng)然開(kāi)源產(chǎn)品能獲取源代碼，如果公司有比較強(qiáng)的研發(fā)能力，能hold住這些開(kāi)源產(chǎn)品，經(jīng)過(guò)二次開(kāi)發(fā)kong、zuul應(yīng)該還是適應(yīng)一些公司，不過(guò)需求注意以下一些點(diǎn)：

kong是基于ngnix+lua的，從公司的角度比較難于找到能去維護(hù)這種架構(gòu)產(chǎn)品的人。需求評(píng)估當(dāng)前公司是否有這個(gè)能力去維護(hù)這個(gè)產(chǎn)品。
zuul因?yàn)榧軜?gòu)的原因在高并發(fā)的情況下性能不高，同時(shí)需要去基于研究整合開(kāi)源的適配zuul的監(jiān)控和管理系統(tǒng)。
orange由于沒(méi)有被大量使用，同時(shí)是國(guó)內(nèi)個(gè)人在開(kāi)源，在可持續(xù)性和社區(qū)資源上不夠豐富，出了問(wèn)題后可能不容易找到人問(wèn)。

另外kong提供企業(yè)版本的API網(wǎng)關(guān)，當(dāng)然也是基于ngnix+lua的，企業(yè)版本可以購(gòu)買(mǎi)他們的技術(shù)支持、培訓(xùn)等服務(wù)、以及擁有界面的管理、監(jiān)控等功能。

5、公有云還是私有云
現(xiàn)在的亞馬遜、阿里、騰訊云都在提供基礎(chǔ)公有云的API網(wǎng)關(guān)，當(dāng)然這些網(wǎng)關(guān)的基礎(chǔ)功能肯定是沒(méi)有問(wèn)題，但是二次開(kāi)發(fā)，擴(kuò)展功能、監(jiān)控功能可能就不能滿足部分用戶的定制需求了。另外很多企業(yè)因?yàn)樽陨硇畔踩脑?，不能使用外網(wǎng)公有網(wǎng)的API網(wǎng)關(guān)服務(wù)，這樣就只有選擇私有云的方案了。
在需求上如果基于公有云的API網(wǎng)關(guān)只能做到由內(nèi)部人員為外網(wǎng)人員申請(qǐng)應(yīng)用，無(wú)法做到定制的合作伙伴門(mén)戶，這也不適合于部分企業(yè)的需求。
如果作為微服務(wù)網(wǎng)關(guān)，大多數(shù)情況下是希望網(wǎng)關(guān)服務(wù)器和服務(wù)提供方服務(wù)器是要在內(nèi)網(wǎng)的，在這里情況下也只有私有云的API網(wǎng)關(guān)才能滿足需求。

綜合上面的分析，基礎(chǔ)公有云的API網(wǎng)關(guān)只有滿足一部分簡(jiǎn)單客戶的需求，對(duì)于很多企業(yè)來(lái)說(shuō)私有云的API網(wǎng)關(guān)才是正確的選擇。

文章作者介紹：
來(lái)自于小豹科技的架構(gòu)師-專注于軟件研發(fā)基于平臺(tái)性軟件的研發(fā)，目前我正在研發(fā)一款基于Netty、響應(yīng)式架構(gòu)的插件式的API網(wǎng)關(guān)，希望能對(duì)行業(yè)帶來(lái)一些改變。我希望與對(duì)OpenAPI、微服務(wù)、API網(wǎng)關(guān)、Service Mesh等感興趣的朋友多交流。有興趣的朋友請(qǐng)加我的QQ群244054462。

posted @ 2018-01-05 13:42 Coolfiry 閱讀(4700) | 評(píng)論 (0) | 編輯收藏

虞美人李煜

春花秋月何時(shí)了，往事知多少？小樓昨夜又東風(fēng)，故國(guó)不堪回首月明中。雕欄玉砌應(yīng)猶在，只是朱顏改。問(wèn)君能有幾多愁，恰似一江春水向東流。

posted @ 2009-01-19 10:49 Coolfiry 閱讀(265) | 評(píng)論 (0) | 編輯收藏

雨霖鈴 ·柳永

寒蟬凄切。對(duì)長(zhǎng)亭晚，驟雨初歇。都門(mén)帳飲無(wú)緒，留戀處、蘭舟催發(fā)。執(zhí)手相看淚眼，竟無(wú)語(yǔ)凝噎。念去去、千里煙波，暮靄沉沉楚天闊。
多情自古傷離別，更那堪冷落清秋節(jié)！今宵酒醒何處？楊柳岸、曉風(fēng)殘?jiān)?。此去?jīng)年，應(yīng)是良辰好景虛設(shè)。便縱有千種風(fēng)情，更與何人說(shuō)？

posted @ 2009-01-19 10:48 Coolfiry 閱讀(260) | 評(píng)論 (0) | 編輯收藏

blog內(nèi)容預(yù)告

1、python的入門(mén)級(jí)內(nèi)容。
2、java mail的使用基本用法和注意事項(xiàng)。
3、CXF中相關(guān)BUG的解決方法。
4、UNIX 網(wǎng)絡(luò)編程步步提升系列。

posted @ 2008-12-11 15:48 Coolfiry 閱讀(1073) | 評(píng)論 (5) | 編輯收藏

snoop的用法

轉(zhuǎn)自:http://bbs.chinaunix.net/viewthread.php?tid=691982&extra=&page=1
snoop 抓包
solaris自帶snoop抓包工具,抓所有數(shù)據(jù)流

# snoop
Using device /dev/pcn0 (promiscuous mode)
192.168.8.18 -> 192.168.255.255 NBT NS Query Request for WORKGROUP[1c], Success
192.168.253.35 -> solaris    TELNET C port=1246
   solaris -> 192.168.253.35 TELNET R port=1246 Using device /dev/pc
   solaris -> 192.168.253.35 TELNET R port=1246 Using device /dev/pc
192.168.4.150 -> (broadcast)  ARP C Who is 192.168.4.200, 192.168.4.200 ?
192.168.4.200 -> (broadcast)  ARP C Who is 192.168.4.150, 192.168.4.150 ?
#

抓源地址或目的為 202.101.98.55的數(shù)據(jù)流：

# snoop 202.101.98.55
Using device /dev/pcn0 (promiscuous mode)
192.168.253.35 -> dns.fz.fj.cn DNS C www.163.com. Internet Addr ?
dns.fz.fj.cn -> 192.168.253.35 DNS R www.163.com. Internet CNAME www.cache.split.netease.com.

#

說(shuō)明：internet cname 后的為解析www.163.com的名字時(shí)，代表www.163.com回答的主機(jī)的域名。

抓 192.168.253.35和202.101.98.55之間的數(shù)據(jù)流（雙向都抓）

# snoop 192.168.253.35 202.101.98.55
Using device /dev/pcn0 (promiscuous mode)
192.168.253.35 -> dns.fz.fj.cn DNS C www.google.com. Internet Addr ?
dns.fz.fj.cn -> 192.168.253.35 DNS R www.google.com. Internet CNAME www.l.google.com.
#

抓完存在當(dāng)前目錄下的cap文件中并查看

# snoop -o cap1 -P    -P表示處在非混雜模式抓數(shù)據(jù)，只抓廣播、主播、目的為本機(jī)的數(shù)據(jù)
Using device /dev/pcn0 (non promiscuous)
15 ^C                         15的含義是：顯示目前抓了多少個(gè)數(shù)據(jù)流
#

# snoop -i cap1
  1 0.00000 192.168.253.35 -> solaris    TELNET C port=1246
  2 0.18198 192.168.253.35 -> solaris    TELNET C port=1246
  3 0.37232 192.168.4.199 -> 192.168.255.255 NBT Datagram Service Type=17 Source=WB-200[20]
  4 0.00016          ? -> (multicast)  ETHER Type=EF08 (Unknown), size = 180bytes
  5 0.62546 192.168.253.35 -> solaris    TELNET C port=1246
  6 0.13822          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
  7 0.06283 192.168.253.35 -> solaris    TELNET C port=1246
  8 0.90301 192.168.253.35 -> solaris    TELNET C port=1246
  9 0.19781 192.168.253.35 -> solaris    TELNET C port=1246
10 0.81493          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
11 0.07018 192.168.253.35 -> solaris    TELNET C port=1246
12 0.19939 192.168.253.35 -> solaris    TELNET C port=1246
13 0.90151 192.168.253.35 -> solaris    TELNET C port=1246
14 0.18904 192.168.253.35 -> solaris    TELNET C port=1246
15 0.68422          ? -> (multicast)  ETHER Type=0000 (LLC/802.3), size = 52 bytes
#snoop -i cap1 -p 10,12          只看10-12條記錄

#snoop -i cap1 -p10                只看第10條記錄

# snoop -i cap1 -v -p101          查看第10條數(shù)據(jù)流的包頭的詳細(xì)內(nèi)容

#snoop -i cap1 -v -x 0 -p101 查看第10條數(shù)據(jù)流的全部的詳細(xì)內(nèi)容

抓主機(jī)192.168.253.35和202.101.98.55之間的tcp或者udp端口53的數(shù)據(jù)

# snoop 192.168.253.35 and 202.101.98.55 and $tcp or udp$ and port 53

輸入（的時(shí)候要加轉(zhuǎn)義符號(hào)\

snoop的詳細(xì)參數(shù)
Snoop 是Solaris 系統(tǒng)中自帶的工具，是一個(gè)用于顯示網(wǎng)絡(luò)通訊的程序，它可捕獲IP 包并將其顯示或保存到指定文件. (限超級(jí)用戶使用snoop)
Snoop 可將捕獲的包以一行的形式加以總結(jié)或用多行加以詳細(xì)的描述(有調(diào)用不同的參數(shù)–v -V來(lái)實(shí)現(xiàn)). 在總結(jié)方式下(-V ) , 將僅顯示最高層的相關(guān)協(xié)議, 例如一個(gè)NFS 包將僅顯示NFS 信息, 其低層的RPC, UDP, IP, Ethernet 幀信息將不會(huì)顯示, 但是當(dāng)加上相應(yīng)的參數(shù)(-v ), 這些信息都能被顯示出來(lái).

-C

-D

-N

-P 在非混雜模式下抓包

-S 抓包的時(shí)候顯示數(shù)據(jù)包的大小

-V 半詳細(xì)的顯示抓的數(shù)據(jù)的信息

-t [ r | a | d ] 顯示時(shí)間戳，-ta顯示當(dāng)前系統(tǒng)時(shí)間，精確到毫秒

-v 最詳細(xì)的顯示數(shù)據(jù)的信息

-x offset [ , length] 以16進(jìn)制或ACSII方式顯示某數(shù)據(jù)的部分內(nèi)容，比如 -x 0,10 只顯示0-10字節(jié)

#snoop -i cap1 -v -x 0 -p101 查看被抓獲的第101個(gè)數(shù)據(jù)流的全部?jī)?nèi)容

表達(dá)式：

根據(jù)地址：

#snoop x.x.x.x       IPV4的IP

#snoop 0XX:XX:XX:XX ETHERNET的MAC地址

數(shù)據(jù)的方向：

from x.x.x.x 或者 src x.x.x.x

to x.x.x.x 或者 dst x.x.x.x

可用的數(shù)據(jù)類型的關(guān)鍵詞：

ip, ip6, arp, rarp, pppoed, pppoes，pppoe，broadcast，multicast，apple，decnet

udp, tcp, icmp, icmp6, ah, esp

greater length
   True if the packet is longer than length.

less length
   True if the packet is shorter than length.

net net

# snoop from net 192.168.1.0 抓來(lái)自192.168.1.0/24的數(shù)據(jù)

# snoop from net 192.168.0.0 抓來(lái)自192.168.0.0/16的數(shù)據(jù)

port xx XX為T(mén)CP或者UDP的端口號(hào)或者 /etc/services里定義的名字

#snoop to udp and port 53 抓到UDP53的數(shù)據(jù)

posted @ 2008-10-21 21:30 Coolfiry 閱讀(723) | 評(píng)論 (0) | 編輯收藏

CXF使用中List作為傳輸參數(shù)相關(guān)問(wèn)題的解決

在項(xiàng)目使用CXF的過(guò)程中,遇到了有關(guān)List作為傳輸參數(shù)的時(shí)候,如果WebService端沒(méi)有明確給出List的泛型類型會(huì)報(bào)錯(cuò)。
例如
CXF的WebService端口接口的一個(gè)方法為為：

1 public boolean updateMessageStatus(List batchIds);

客戶端的的調(diào)用為：

1 //預(yù)先初始化cxf對(duì)象cxfObj
2 List<String> list=new ArrayList<String>();
3 list.add("1");
4 cxfObj.updateMessageStatus(list);

在客戶端進(jìn)行調(diào)用WebService時(shí)會(huì)發(fā)生錯(cuò)誤，錯(cuò)誤為：unexpected element (uri:"", local:"arg0")等，據(jù)分析生成的wsdl，這是因?yàn)镃XF在進(jìn)行數(shù)據(jù)marshal時(shí)不知道要將要轉(zhuǎn)換的類型。

解決辦法是:在WebService端的接口必須用List的泛型類型參數(shù)，如：

1 public boolean updateMessageStatus(List<String> batchIds);

這樣就完全解決問(wèn)題了。

posted @ 2008-08-05 20:09 Coolfiry 閱讀(4956) | 評(píng)論 (1) | 編輯收藏

我的第一個(gè)和第二個(gè)unix SHELL學(xué)習(xí)程序

現(xiàn)在正在學(xué)習(xí)linux shell編程
first.sh

while read line
do
echo "$line"
done <"$1"

這是第一個(gè)shell程序小例子，就相當(dāng)于一個(gè)學(xué)習(xí)其他語(yǔ)言的hello world了吧。用法first.sh test，將test文件中的每一行輸出到stdout中。

second.sh

number=0;
while [ "$number" -lt 100 ]
do
echo "$number"
number='expr $number + 1'
done
echo

這是第二個(gè)shell程序小例子，作用是輸出0到99的數(shù)字到stdout中。其中用到的expr的作用是使expr的參數(shù)轉(zhuǎn)化為數(shù)字并相加。兩個(gè)單引號(hào)的作用是引號(hào)所包圍的命令被命令的標(biāo)準(zhǔn)輸出替換，并輸出賦值給我number，得到了如同java中number=number+1的效果。

posted @ 2008-07-20 20:34 Coolfiry 閱讀(588) | 評(píng)論 (2) | 編輯收藏

在使用CXF WebService框架時(shí)遇到的問(wèn)題與解決方案

在項(xiàng)目開(kāi)發(fā)過(guò)程中，遇到在本機(jī)和windows環(huán)境中部署用CXF框架開(kāi)發(fā)的的webService沒(méi)有任何問(wèn)題，但是當(dāng)將工程部署到solaris 的SUN ONE application上時(shí)，再用本機(jī)的cxf Web服務(wù)客戶端訪問(wèn)對(duì)應(yīng)的web服務(wù)時(shí)，如果傳輸?shù)臄?shù)據(jù)量小于大約4K不會(huì)出問(wèn)題，否則則會(huì)報(bào)一些數(shù)據(jù)綁定的異常如：
Marshalling Error: Error writing request body to server。
解決這個(gè)問(wèn)題花了我足足兩天時(shí)間，原因是有關(guān)CXF的資料太少了，而且有關(guān)于這個(gè)錯(cuò)誤的解決都必須使用google才能search到，用baidu完全search不到相關(guān)的資料。
解決方案：
在客戶端的class-path中加上cxf.xml。cxf.xml的配置如下：

<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://www.springframework.org/schema/beans"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns:http="http://cxf.apache.org/transports/http/configuration"
    xmlns:jaxws="http://cxf.apache.org/jaxws"
    xsi:schemaLocation="
http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd
http://cxf.apache.org/jaxws http://cxf.apache.org/schemas/jaxws.xsd
http://cxf.apache.org/transports/http/configuration
http://cxf.apache.org/schemas/configuration/http-conf.xsd">
    <http:conduit name="*.http-conduit">
        <http:client AutoRedirect="true" />
    </http:conduit>
</beans>

這個(gè)問(wèn)題的解決方案是我在cxf的官網(wǎng)上找了很久才找到的，雖然問(wèn)題解決了，但是我感到很迷惑。主要在windows tomcat環(huán)境下沒(méi)有問(wèn)題，而到了SUN ONE的環(huán)境就有問(wèn)題，經(jīng)過(guò)的思考和找了一資料，我認(rèn)為問(wèn)題出于solaris對(duì)于HTTP數(shù)據(jù)傳輸?shù)哪承┫拗疲绻嬉ジ闱宄脑捒赡芤⒖碿xf的source code了，但是我不想花這個(gè)時(shí)間去研究這個(gè)問(wèn)題了。

我把這個(gè)解決方案寫(xiě)出來(lái)，希望可以幫助到使用CXF的網(wǎng)友，也希望高手們能幫我解決我的迷惑。

posted @ 2008-07-18 19:11 Coolfiry 閱讀(2568) | 評(píng)論 (0) | 編輯收藏

使用負(fù)載均衡技術(shù)建設(shè)高負(fù)載的網(wǎng)絡(luò)站點(diǎn)(轉(zhuǎn))

Internet的快速增長(zhǎng)使多媒體網(wǎng)絡(luò)服務(wù)器，特別是Web服務(wù)器，面對(duì)的訪問(wèn)者數(shù)量快速增加，網(wǎng)絡(luò)服務(wù)器需要具備提供大量并發(fā)訪問(wèn)服務(wù)的能力。例如Yahoo每天會(huì)收到數(shù)百萬(wàn)次的訪問(wèn)請(qǐng)求，因此對(duì)于提供大負(fù)載Web服務(wù)的服務(wù)器來(lái)講，CPU、I/O處理能力很快會(huì)成為瓶頸。

簡(jiǎn)單的提高硬件性能并不能真正解決這個(gè)問(wèn)題，因?yàn)閱闻_(tái)服務(wù)器的性能總是有限的，一般來(lái)講，一臺(tái)PC服務(wù)器所能提供的并發(fā)訪問(wèn)處理能力大約為1000個(gè)，更為高檔的專用服務(wù)器能夠支持3000-5000個(gè)并發(fā)訪問(wèn)，這樣的能力還是無(wú)法滿足負(fù)載較大的網(wǎng)站的要求。尤其是網(wǎng)絡(luò)請(qǐng)求具有突發(fā)性，當(dāng)某些重大事件發(fā)生時(shí)，網(wǎng) 絡(luò)訪問(wèn)就會(huì)急劇上升，從而造成網(wǎng)絡(luò)瓶頸，例如在網(wǎng)上發(fā)布的克林頓彈劾書(shū)就是很明顯的例子。必須采用多臺(tái)服務(wù)器提供網(wǎng)絡(luò)服務(wù)，并將網(wǎng)絡(luò)請(qǐng)求分配給這些服務(wù)器分擔(dān)，才能提供處理大量并發(fā)服務(wù)的能力。

當(dāng)使用多臺(tái)服務(wù)器來(lái)分擔(dān)負(fù)載的時(shí)候，最簡(jiǎn)單的辦法是將不同的服務(wù)器用在不同的方面。按提供的內(nèi)容進(jìn)行分割時(shí)，可以將一臺(tái)服務(wù)器用于提供新聞頁(yè)面，而另一臺(tái)用于提供游戲頁(yè)面；或者可以按服務(wù)器的功能進(jìn)行分割，將一臺(tái)服務(wù)器用于提供靜態(tài)頁(yè)面訪問(wèn)，而另一些用于提供CGI等需要大量消耗資源的動(dòng)態(tài)頁(yè)面訪問(wèn)。然而由于網(wǎng)絡(luò)訪問(wèn)的突發(fā)性，使得很難確定那些頁(yè)面造成的負(fù)載太大，如果將服務(wù)的頁(yè)面分割的過(guò)細(xì)就會(huì)造成很大浪費(fèi)。事實(shí)上造成負(fù)載過(guò)大的頁(yè)面常常是在變化中的，如果要經(jīng)常按照負(fù)載變化來(lái)調(diào)整頁(yè)面所在的服務(wù)器，那么勢(shì)必對(duì)管理和維護(hù)造成極大的問(wèn) 題。因此這種分割方法只能是大方向的調(diào)整，對(duì)于大負(fù)載的網(wǎng)站，根本的解決辦法還需要應(yīng)用負(fù)載均衡技術(shù)。

負(fù)載均衡的思路下多臺(tái) 服務(wù)器為對(duì)稱方式，每臺(tái)服務(wù)器都具備等價(jià)的地位，都可以單獨(dú)對(duì)外提供服務(wù)而無(wú)須其他服務(wù)器的輔助。然后通過(guò)某種負(fù)載分擔(dān)技術(shù)，將外部發(fā)送來(lái)的請(qǐng)求均勻分配到對(duì)稱結(jié)構(gòu)中的某一臺(tái)服務(wù)器上，而接收到請(qǐng)求的服務(wù)器都獨(dú)立回應(yīng)客戶機(jī)的請(qǐng)求。由于建立內(nèi)容完全一致的Web服務(wù)器并不復(fù)雜，可以使用服務(wù)器同步更新或者共享存儲(chǔ)空間等方法來(lái)完成，因此負(fù)載均衡技術(shù)就成為建立一個(gè)高負(fù)載Web站點(diǎn)的關(guān)鍵性技術(shù)。

基于特定服務(wù)器軟件的負(fù)載均衡
很多網(wǎng)絡(luò)協(xié)議都支持“重定向”功能，例如在HTTP協(xié)議中支持Location指令，接收到這個(gè)指令的瀏覽器將自動(dòng)重定向到Location指明的另一個(gè) URL上。由于發(fā)送Location指令比起執(zhí)行服務(wù)請(qǐng)求，對(duì)Web服務(wù)器的負(fù)載要小的多，因此可以根據(jù)這個(gè)功能來(lái)設(shè)計(jì)一種負(fù)載均衡的服務(wù)器。任何時(shí)候 Web服務(wù)器認(rèn)為自己負(fù)載較大的時(shí)候，它就不再直接發(fā)送回瀏覽器請(qǐng)求的網(wǎng)頁(yè)，而是送回一個(gè)Locaction指令，讓瀏覽器去服務(wù)器集群中的其他服務(wù)器上獲得所需要的網(wǎng)頁(yè)。

在這種方式下，服務(wù)器本身必須支持這種功能，然而具體實(shí)現(xiàn)起來(lái)卻有很多困難，例如一臺(tái)服務(wù)器如何能保證它重定向過(guò)的服務(wù) 器是比較空閑的，并且不會(huì)再次發(fā)送Location指令？Location指令和瀏覽器都沒(méi)有這方面的支持能力，這樣很容易在瀏覽器上形成一種死循環(huán)。因此這種方式實(shí)際應(yīng)用當(dāng)中并不多見(jiàn)，使用這種方式實(shí)現(xiàn)的服務(wù)器集群軟件也較少。有些特定情況下可以使用CGI（包括使用FastCGI或mod_perl擴(kuò) 展來(lái)改善性能）來(lái)模擬這種方式去分擔(dān)負(fù)載，而Web服務(wù)器仍然保持簡(jiǎn)潔、高效的特性，此時(shí)避免Location循環(huán)的任務(wù)將由用戶的CGI程序來(lái)承擔(dān)。
基于DNS的負(fù)載均衡
由于基于服務(wù)器軟件的負(fù)載均衡需要改動(dòng)軟件，因此常常是得不償失，負(fù)載均衡最好是在服務(wù)器軟件之外來(lái)完成，這樣才能利用現(xiàn)有服務(wù)器軟件的種種優(yōu)勢(shì)。最早的負(fù) 載均衡技術(shù)是通過(guò)DNS服務(wù)中的隨機(jī)名字解析來(lái)實(shí)現(xiàn)的，在DNS服務(wù)器中，可以為多個(gè)不同的地址配置同一個(gè)名字，而最終查詢這個(gè)名字的客戶機(jī)將在解析這個(gè) 名字時(shí)得到其中的一個(gè)地址。因此，對(duì)于同一個(gè)名字，不同的客戶機(jī)會(huì)得到不同的地址，他們也就訪問(wèn)不同地址上的Web服務(wù)器，從而達(dá)到負(fù)載均衡的目的。

例如如果希望使用三個(gè)Web服務(wù)器來(lái)回應(yīng)對(duì)www.exampleorg.org.cn的HTTP請(qǐng)求，就可以設(shè)置該域的DNS服務(wù)器中關(guān)于該域的數(shù)據(jù)包括有與下面例子類似的結(jié)果：
```
www1		IN		A 		192.168.1.1
```
```
www2		IN		A 		192.168.1.2
```
```
www3		IN		A 		192.168.1.3
```
```
www		IN		CNAME		www1
```
```
www		IN		CNAME		www2
```
```
www		IN		CNAME		www3
```
此后外部的客戶機(jī)就可能隨機(jī)的得到對(duì)應(yīng)www的不同地址，那么隨后的HTTP請(qǐng)求也就發(fā)送給不同地址了。

DNS 負(fù)載均衡的優(yōu)點(diǎn)是簡(jiǎn)單、易行，并且服務(wù)器可以位于互聯(lián)網(wǎng)的任意位置上，當(dāng)前使用在包括Yahoo在內(nèi)的Web站點(diǎn)上。然而它也存在不少缺點(diǎn)，一個(gè)缺點(diǎn)是為了保證DNS數(shù)據(jù)及時(shí)更新，一般都要將DNS的刷新時(shí)間設(shè)置的較小，但太小就會(huì)造成太大的額外網(wǎng)絡(luò)流量，并且更改了DNS數(shù)據(jù)之后也不能立即生效；第二點(diǎn) 是DNS負(fù)載均衡無(wú)法得知服務(wù)器之間的差異，它不能做到為性能較好的服務(wù)器多分配請(qǐng)求，也不能了解到服務(wù)器的當(dāng)前狀態(tài)，甚至?xí)霈F(xiàn)客戶請(qǐng)求集中在某一臺(tái)服務(wù)器上的偶然情況。
反向代理負(fù)載均衡
使用代理服務(wù)器可以將請(qǐng)求轉(zhuǎn)發(fā)給內(nèi)部的Web服務(wù)器，使用這種加速模式顯然可以提升靜態(tài)網(wǎng)頁(yè)的訪問(wèn)速度。因此也可以考慮使用這種技術(shù)，讓代理服務(wù)器將請(qǐng)求均勻轉(zhuǎn)發(fā)給多臺(tái)內(nèi)部Web服務(wù)器之一上，從而達(dá)到負(fù)載均衡的目的。這種代理方式與普通的代理方式有所不同，標(biāo)準(zhǔn)代理方式是客戶使用代理訪問(wèn)多個(gè)外部Web服務(wù)器，而這種代理方式是多個(gè)客戶使用它訪問(wèn)內(nèi)部Web服務(wù)器，因此也被稱為反向代理模式。

實(shí)現(xiàn)這個(gè)反向代理能力并不能算是一個(gè)特別復(fù)雜的任務(wù)，但是在負(fù)載均衡中要求特別高的效率，這樣實(shí)現(xiàn)起來(lái)就不是十分簡(jiǎn)單的了。每針對(duì)一次代理，代理服務(wù)器就必須打開(kāi)兩個(gè)連接，一個(gè)為對(duì)外的連接，一個(gè)為對(duì)內(nèi)的連接，因此對(duì)于連接請(qǐng)求數(shù)量非常大的時(shí)候，代理服務(wù)器的負(fù)載也就非常之大了，在最后反向代理服務(wù)器會(huì)成為服務(wù)的瓶頸。例如，使用Apache的mod_rproxy模塊來(lái)實(shí)現(xiàn)負(fù)載均衡功能時(shí)，提供的并發(fā)連接數(shù)量受 Apache本身的并發(fā)連接數(shù)量的限制。一般來(lái)講，可以使用它來(lái)對(duì)連接數(shù)量不是特別大，但每次連接都需要消耗大量處理資源的站點(diǎn)進(jìn)行負(fù)載均衡，例如搜尋。

使用反向代理的好處是，可以將負(fù)載均衡和代理服務(wù)器的高速緩存技術(shù)結(jié)合在一起，提供有益的性能，具備額外的安全性，外部客戶不能直接訪問(wèn)真實(shí)的服務(wù)器。并且實(shí)現(xiàn)起來(lái)可以實(shí)現(xiàn)較好的負(fù)載均衡策略，將負(fù)載可以非常均衡的分給內(nèi)部服務(wù)器，不會(huì)出現(xiàn)負(fù)載集中到某個(gè)服務(wù)器的偶然現(xiàn)象。
基于NAT的負(fù)載均衡技術(shù)
網(wǎng) 絡(luò)地址轉(zhuǎn)換為在內(nèi)部地址和外部地址之間進(jìn)行轉(zhuǎn)換，以便具備內(nèi)部地址的計(jì)算機(jī)能訪問(wèn)外部網(wǎng)絡(luò)，而當(dāng)外部網(wǎng)絡(luò)中的計(jì)算機(jī)訪問(wèn)地址轉(zhuǎn)換網(wǎng)關(guān)擁有的某一外部地址時(shí)，地址轉(zhuǎn)換網(wǎng)關(guān)能將其轉(zhuǎn)發(fā)到一個(gè)映射的內(nèi)部地址上。因此如果地址轉(zhuǎn)換網(wǎng)關(guān)能將每個(gè)連接均勻轉(zhuǎn)換為不同的內(nèi)部服務(wù)器地址，此后外部網(wǎng)絡(luò)中的計(jì)算機(jī)就各自與自己轉(zhuǎn)換得到的地址上服務(wù)器進(jìn)行通信，從而達(dá)到負(fù)載分擔(dān)的目的。

地址轉(zhuǎn)換可以通過(guò)軟件方式來(lái)實(shí)現(xiàn)，也可以通過(guò)硬件方式來(lái)實(shí)現(xiàn)。使用硬件方式進(jìn)行操作一般稱為交換，而當(dāng)交換必須保存TCP連接信息的時(shí)候，這種針對(duì)OSI網(wǎng) 絡(luò)層的操作就被稱為第四層交換。支持負(fù)載均衡的網(wǎng)絡(luò)地址轉(zhuǎn)換為第四層交換機(jī)的一種重要功能，由于它基于定制的硬件芯片，因此其性能非常優(yōu)秀，很多交換機(jī)聲稱具備400MB-800MB的第四層交換能力，然而也有一些資料表明，在如此快的速度下，大部分交換機(jī)就不再具備第四層交換能力了，而僅僅支持第三層甚至第二層交換。

然而對(duì)于大部分站點(diǎn)來(lái)講，當(dāng)前負(fù)載均衡主要是解決Web服務(wù)器處理能力瓶頸的，而非網(wǎng)絡(luò)傳輸能力，很多站點(diǎn)的互聯(lián)網(wǎng)連接帶寬總共也不過(guò)10MB，只有極少的站點(diǎn)能夠擁有較高速的網(wǎng)絡(luò)連接，因此一般沒(méi)有必要使用這些負(fù)載均衡器這樣的昂貴設(shè)備。

使用軟件方式來(lái)實(shí)現(xiàn)基于網(wǎng)絡(luò)地址轉(zhuǎn)換的負(fù)載均衡則要實(shí)際的多，除了一些廠商提供的解決方法之外，更有效的方法是使用免費(fèi)的自由軟件來(lái)完成這項(xiàng)任務(wù)。其中包括 Linux Virtual Server Project中的NAT實(shí)現(xiàn)方式，或者本文作者在FreeBSD下對(duì)natd的修訂版本。一般來(lái)講，使用這種軟件方式來(lái)實(shí)現(xiàn)地址轉(zhuǎn)換，中心負(fù)載均衡器存在帶寬限制，在100MB的快速以太網(wǎng)條件下，能得到最快達(dá)80MB的帶寬，然而在實(shí)際應(yīng)用中，可能只有40MB-60MB的可用帶寬。
擴(kuò)展的負(fù)載均衡技術(shù)

上面使用網(wǎng)絡(luò)地址轉(zhuǎn)換來(lái)實(shí)現(xiàn)負(fù)載分擔(dān)，毫無(wú)疑問(wèn)所有的網(wǎng)絡(luò)連接都必須通過(guò)中心負(fù)載均衡器，那么如果負(fù)載特別大，以至于后臺(tái)的服務(wù)器數(shù)量不再在是幾臺(tái)、十幾臺(tái)，而是上百臺(tái)甚至更多，即便是使用性能優(yōu)秀的硬件交換機(jī)也回遇到瓶頸。此時(shí)問(wèn)題將轉(zhuǎn)變?yōu)椋绾螌⒛敲炊嗯_(tái)服務(wù)器分布到各個(gè)互聯(lián)網(wǎng)的多個(gè)位置，分散網(wǎng)絡(luò)負(fù) 擔(dān)。當(dāng)然這可以通過(guò)綜合使用DNS和NAT兩種方法來(lái)實(shí)現(xiàn)，然而更好的方式是使用一種半中心的負(fù)載均衡方式。

在這種半中心的負(fù)載均衡方式下，即當(dāng)客戶請(qǐng)求發(fā)送給負(fù)載均衡器的時(shí)候，中心負(fù)載均衡器將請(qǐng)求打包并發(fā)送給某個(gè)服務(wù)器，而服務(wù)器的回應(yīng)請(qǐng)求不再返回給中心負(fù)載均衡器，而是直接返回給客戶，因此中心負(fù)載均衡器只負(fù)責(zé)接受并轉(zhuǎn)發(fā)請(qǐng)求，其網(wǎng)絡(luò)負(fù)擔(dān)就較小了。

上圖來(lái)自Linux Virtual Server Project，為他們使用IP隧道實(shí)現(xiàn)的這種負(fù)載分擔(dān)能力的請(qǐng)求/回應(yīng)過(guò)程，此時(shí)每個(gè)后臺(tái)服務(wù)器都需要進(jìn)行特別的地址轉(zhuǎn)換，以欺騙瀏覽器客戶，認(rèn)為它的回應(yīng)為正確的回應(yīng)。

同樣，這種方式的硬件實(shí)現(xiàn)方式也非常昂貴，但是會(huì)根據(jù)廠商的不同，具備不同的特殊功能，例如對(duì)SSL的支持等。

由于這種方式比較復(fù)雜，因此實(shí)現(xiàn)起來(lái)比較困難，它的起點(diǎn)也很高，當(dāng)前情況下網(wǎng)站并不需要這么大的處理能力。

比較上面的負(fù)載均衡方式，DNS最容易，也最常用，能夠滿足一般的需求。但如果需要進(jìn)一步的管理和控制，可以選用反向代理方式或NAT方式，這兩種之間進(jìn)行選擇主要依賴緩沖是不是很重要，最大的并發(fā)訪問(wèn)數(shù)量是多少等條件。而如果網(wǎng)站上對(duì)負(fù)載影響很厲害的CGI程序是由網(wǎng)站自己開(kāi)發(fā)的，也可以考慮在程序中自己使用Locaction來(lái)支持負(fù)載均衡。半中心化的負(fù)載分擔(dān)方式至少在國(guó)內(nèi)當(dāng)前的情況下還不需要。
http://galaxystar.javaeye.com/blog/50546

posted @ 2008-07-18 14:23 Coolfiry 閱讀(255) | 評(píng)論 (0) | 編輯收藏

垃圾收集機(jī)制(Garbage Collection)批判

在Java版發(fā)表這篇文章，似乎有點(diǎn)把矛頭指向Java了。其實(shí)不是，GC是所有新一代語(yǔ)言共有的特征，
Python, Eiffel，C#，Roby等無(wú)一例外地都使用了GC機(jī)制。但既然Java中的GC最為著名，所以天塌
下來(lái)自然應(yīng)該抗著。

這篇短文源于comp.lang.java.programmer跟comp.lang.c++上發(fā)生的一場(chǎng)大辯論，支持C++和Java
的兩派不同勢(shì)力展開(kāi)了新世紀(jì)第一場(chǎng)沖突，跟貼發(fā)言超過(guò)350，兩派都有名角壓陣。C++陣營(yíng)的擂主是
Pete Becker，ACM會(huì)員，Dinkumware Ltd. 的技術(shù)副總監(jiān)。此君精通C++和Java，開(kāi)發(fā)過(guò)兩種語(yǔ)言的
核心類庫(kù)，但是卻對(duì)C++狂熱之極，而對(duì)于Java頗不以為然。平時(shí)談到Java的時(shí)候還好，一旦有人膽
敢用Java來(lái)批判C++，立刻忍不住火爆脾氣跳將出來(lái)，以堅(jiān)韌不拔的毅力和大無(wú)畏精神與對(duì)手周旋，
舌戰(zhàn)群儒，哪怕只剩下一個(gè)人也要血戰(zhàn)到底。這等奇人當(dāng)真少見(jiàn)！我真奇怪他整天泡在usenet上，
不用工作么？他的老板P.J. Plauger如此寬宏大量？Java陣營(yíng)主角是一個(gè)網(wǎng)名Razzi的兄弟，另外有
Sun公司大名鼎鼎的Peter van der Linden助陣，妙語(yǔ)連珠，寸土必爭(zhēng)，加上人多勢(shì)眾，一度占據(jù)優(yōu)勢(shì)。
C++陣營(yíng)里大拿雖然很多，但是大多數(shù)沒(méi)有Pete那么多閑工夫，例如Greg Comeau，Comeau公司老板，
每次來(lái)個(gè)只言片語(yǔ)，實(shí)在幫不了Pete多大忙。但是自從C++陣營(yíng)中冒出一個(gè)無(wú)名小子，網(wǎng)名Courage(勇氣)，
發(fā)動(dòng)對(duì)Java GC機(jī)制的批判，形勢(shì)為之一變。C++陣營(yíng)眼下處于全攻之勢(shì)，Java陣營(yíng)疲于防守，只能
招架說(shuō)：“你們沒(méi)有證據(jù)，沒(méi)有統(tǒng)計(jì)資料”，形勢(shì)很被動(dòng)。

垃圾收集(GC)不是一直被Java fans用來(lái)炫耀，引以為傲的優(yōu)點(diǎn)么？怎么成了弱點(diǎn)了？我大惑不解，定睛
一看，才覺(jué)得此中頗有道理。

首先，Java Swing庫(kù)存在大量資源泄漏問(wèn)題，這一點(diǎn)SUN非常清楚，稱之為bugs，正在極力修正。但是看來(lái)
這里的問(wèn)題恐怕不僅是庫(kù)編寫(xiě)者的疏忽，可能根源在于深層的機(jī)制，未必能夠輕易解決，搞不好要傷筋動(dòng)骨。
不過(guò)這個(gè)問(wèn)題不是那么根本，C++陣營(yíng)覺(jué)得如果抓住對(duì)方的弱點(diǎn)攻擊，就算是占了上風(fēng)也沒(méi)什么說(shuō)服力。誰(shuí)
沒(méi)有缺點(diǎn)呢？于是反其道而行之，猛烈攻擊Java陣營(yíng)覺(jué)得最得意的東西，Java的GC機(jī)制本身。

首先來(lái)想一想，memory leak到底意味著什么。在C++中，new出來(lái)的對(duì)象沒(méi)有delete，這就導(dǎo)致了memory
leak。但是C++早就有了克服這一問(wèn)題的辦法——smart pointer。通過(guò)使用標(biāo)準(zhǔn)庫(kù)里設(shè)計(jì)精致的auto_ptr
以及各種STL容器，還有例如boost庫(kù)(差不多是個(gè)準(zhǔn)標(biāo)準(zhǔn)庫(kù)了)中的四個(gè)smart pointers，C++程序員只要
花上一個(gè)星期的時(shí)間學(xué)習(xí)最新的資料，就可以拍著胸脯說(shuō)：“我寫(xiě)的程序沒(méi)有memory leak!”。

相比之下，Java似乎更優(yōu)秀，因?yàn)閺囊婚_(kāi)始你就不用考慮什么特殊的機(jī)制，大膽地往前new，自有GC替你
收拾殘局。Java的GC實(shí)際上是JVM中的一個(gè)獨(dú)立線程，采用不同的算法策略來(lái)收集heap中那些不再有
reference指向的垃圾對(duì)象所占用的內(nèi)存。但是，通常情況下，GC線程的優(yōu)先級(jí)比較低，只有在當(dāng)前程序
空閑的時(shí)候才會(huì)被調(diào)度，收集垃圾。當(dāng)然，如果JVM感到內(nèi)存緊張了，JVM會(huì)主動(dòng)調(diào)用GC來(lái)收集垃圾，獲取
更多的內(nèi)存。請(qǐng)注意，Java的GC工作的時(shí)機(jī)是：1. 當(dāng)前程序不忙，有空閑時(shí)間。2. 空閑內(nèi)存不足。
現(xiàn)在我們考慮一種常見(jiàn)的情況，程序在緊張運(yùn)行之中，沒(méi)喲空閑時(shí)間給GC來(lái)運(yùn)行，同時(shí)機(jī)器內(nèi)存很大，
JVM也沒(méi)有感到內(nèi)存不足，結(jié)果是什么？對(duì)了，GC形同虛設(shè)，得不到調(diào)用。于是，內(nèi)存被不斷吞噬，而那些
早已經(jīng)用不著的垃圾對(duì)象仍在在寶貴的內(nèi)存里睡大覺(jué)。例如：

class BadGc {

    public void job1() {
        String garbage = "I am a garbage, and just sleeping in your precious memory, " +
                  "how do you think you can deal with me? Daydreaming! HAHA!!!";
        ....
    }

public void job2() {...}

...
...

public void job1000() {...}

    public static void main(String[] args) {
        bgc = new BadGc();
bgc.job1();
bgc.job2();
...
bgc.job1000();
    }
}

運(yùn)行中，雖然garbage對(duì)象在離開(kāi)job1()之后，就再也沒(méi)有用了。但是因?yàn)?/span>程序忙，內(nèi)存還夠用，所以GC得
不到調(diào)度，garbage始終不會(huì)被回收，直到程序運(yùn)行到bgc.job1000()時(shí)還躺在內(nèi)存里嘲笑你。沒(méi)轍吧！

好了，我承認(rèn)這段程序很傻。但是你不要以為這只是理論上的假設(shè)，恰恰相反，大多數(shù)實(shí)用中的Java程序都有
類似的效應(yīng)。這就是為什么Java程序狂耗內(nèi)存，而且好像給它多少內(nèi)存吃都不夠。你花上大筆的銀子把內(nèi)存
從128升到256，再升到512，結(jié)果是，一旦執(zhí)行復(fù)雜任務(wù)，內(nèi)存還是被輕易填滿，而且多出來(lái)的這些內(nèi)存只是
用來(lái)裝垃圾，GC還是不給面子地千呼萬(wàn)喚不出來(lái)。等到你的內(nèi)存終于心力交瘁，GC才姍姍來(lái)遲，收拾殘局。而
且GC工作的方式也很不好評(píng)價(jià)，一種方法是一旦有機(jī)會(huì)回收內(nèi)存，就把所有的垃圾都回收。你可以想象，這要
花很長(zhǎng)時(shí)間(幾百M(fèi)的垃圾啊！)，如果你這時(shí)侯正在壓下開(kāi)炮的按鈕，GC卻叫了暫定，好了，你等死吧！另一
種方法，得到機(jī)會(huì)之后，回收一些內(nèi)存，讓JVM感到內(nèi)存不那么緊張時(shí)就收手。結(jié)果呢，內(nèi)存里始終有大批垃
圾，程序始終在半死不活的蕩著。最后，GC可以每隔一段時(shí)間就運(yùn)行一次，每次只回收一部分垃圾，這是現(xiàn)在
大部分JVM的方式，結(jié)果是內(nèi)存也浪費(fèi)了，還動(dòng)不動(dòng)暫停幾百毫秒。難?。?/span>

反過(guò)來(lái)看看C++利用smart pointer達(dá)成的效果，一旦某對(duì)象不再被引用，系統(tǒng)刻不容緩，立刻回收內(nèi)存。這
通常發(fā)生在關(guān)鍵任務(wù)完成后的清理(cleanup)時(shí)期，不會(huì)影響關(guān)鍵任務(wù)的實(shí)時(shí)性，同時(shí)，內(nèi)存里所有的對(duì)象
都是有用的，絕對(duì)沒(méi)有垃圾空占內(nèi)存。怎么樣？傳統(tǒng)、樸素的C++是不是更勝一籌？

據(jù)統(tǒng)計(jì)，目前的Java程序運(yùn)行期間占用的內(nèi)存通常為對(duì)應(yīng)C++程序的4-20倍。除了其它的原因，上面所說(shuō)的是一個(gè)
非常主要的因素。我們對(duì)memory leak如此憤恨，不就是因?yàn)樗鼘?dǎo)致大量的內(nèi)存垃圾得不到清除嗎？如果有了
GC之后，垃圾比以前還來(lái)勢(shì)洶洶，那么GC又有什么好處呢？

當(dāng)然，C++的smart pointer現(xiàn)在會(huì)使用的人不多，所以現(xiàn)在的C++程序普遍存在更嚴(yán)重的memory leak問(wèn)題。
但是，如果我奶奶跟舒馬赫比賽車輸?shù)袅?，你能夠埋怨那輛車子么？
http://www.594k.com/java/html/y2007m1/12051/

posted @ 2007-10-12 10:43 Coolfiry 閱讀(643) | 評(píng)論 (1) | 編輯收藏

從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

一、LiveJournal發(fā)展歷程

LiveJournal是99年始于校園中的項(xiàng)目，幾個(gè)人出于愛(ài)好做了這樣一個(gè)應(yīng)用，以實(shí)現(xiàn)以下功能：

博客，論壇
社會(huì)性網(wǎng)絡(luò)，找到朋友
聚合，把朋友的文章聚合在一起

LiveJournal采用了大量的開(kāi)源軟件，甚至它本身也是一個(gè)開(kāi)源軟件。

在上線后，LiveJournal實(shí)現(xiàn)了非?？焖俚脑鲩L(zhǎng)：

2004年4月份：280萬(wàn)注冊(cè)用戶。
2005年4月份：680萬(wàn)注冊(cè)用戶。
2005年8月份：790萬(wàn)注冊(cè)用戶。
達(dá)到了每秒鐘上千次的頁(yè)面請(qǐng)求及處理。
使用了大量MySQL服務(wù)器。
使用了大量通用組件。

二、LiveJournal架構(gòu)現(xiàn)狀概況

三、從LiveJournal發(fā)展中學(xué)習(xí)

LiveJournal從1臺(tái)服務(wù)器發(fā)展到100臺(tái)服務(wù)器，這其中經(jīng)歷了無(wú)數(shù)的傷痛，但同時(shí)也摸索出了解決這些問(wèn)題的方法，通過(guò)對(duì)LiveJournal的學(xué)習(xí)，可以讓我們避免LJ曾經(jīng)犯過(guò)的錯(cuò)誤，并且從一開(kāi)始就對(duì)系統(tǒng)進(jìn)行良好的設(shè)計(jì)，以避免后期的痛苦。

下面我們一步一步看LJ發(fā)展的腳步。

1、一臺(tái)服務(wù)器

一臺(tái)別人捐助的服務(wù)器，LJ最初就跑在上面，就像Google開(kāi)始時(shí)候用的破服務(wù)器一樣，值得我們尊敬。這個(gè)階段，LJ的人以驚人的速度熟悉的Unix的操作管理，服務(wù)器性能出現(xiàn)過(guò)問(wèn)題，不過(guò)還好，可以通過(guò)一些小修小改應(yīng)付過(guò)去。在這個(gè)階段里L(fēng)J把CGI升級(jí)到了FastCGI。

最終問(wèn)題出現(xiàn)了，網(wǎng)站越來(lái)越慢，已經(jīng)無(wú)法通過(guò)優(yōu)過(guò)化來(lái)解決的地步，需要更多的服務(wù)器，這時(shí)LJ開(kāi)始提供付費(fèi)服務(wù)，可能是想通過(guò)這些錢(qián)來(lái)購(gòu)買(mǎi)新的服務(wù)器，以解決當(dāng)時(shí)的困境。
毫無(wú)疑問(wèn)，當(dāng)時(shí)LJ存在巨大的單點(diǎn)問(wèn)題，所有的東西都在那臺(tái)服務(wù)器的鐵皮盒子里裝著。

2、兩臺(tái)服務(wù)器

用付費(fèi)服務(wù)賺來(lái)的錢(qián)LJ買(mǎi)了兩臺(tái)服務(wù)器：一臺(tái)叫做Kenny的Dell 6U機(jī)器用于提供Web服務(wù)，一臺(tái)叫做Cartman的Dell 6U服務(wù)器用于提供數(shù)據(jù)庫(kù)服務(wù)。

LJ有了更大的磁盤(pán)，更多的計(jì)算資源。但同時(shí)網(wǎng)絡(luò)結(jié)構(gòu)還是非常簡(jiǎn)單，每臺(tái)機(jī)器兩塊網(wǎng)卡，Cartman通過(guò)內(nèi)網(wǎng)為Kenny提供MySQL數(shù)據(jù)庫(kù)服務(wù)。

暫時(shí)解決了負(fù)載的問(wèn)題，新的問(wèn)題又出現(xiàn)了：

原來(lái)的一個(gè)單點(diǎn)變成了兩個(gè)單點(diǎn)。
沒(méi)有冷備份或熱備份。
網(wǎng)站速度慢的問(wèn)題又開(kāi)始出現(xiàn)了，沒(méi)辦法，增長(zhǎng)太快了。
Web服務(wù)器上CPU達(dá)到上限，需要更多的Web服務(wù)器。

3、四臺(tái)服務(wù)器

又買(mǎi)了兩臺(tái)，Kyle和Stan，這次都是1U的，都用于提供Web服務(wù)。目前LJ一共有3臺(tái)Web服務(wù)器和一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。這時(shí)需要在3臺(tái)Web服務(wù)器上進(jìn)行負(fù)載均橫。

LJ把Kenny用于外部的網(wǎng)關(guān)，使用mod_backhand進(jìn)行負(fù)載均橫。

然后問(wèn)題又出現(xiàn)了：

單點(diǎn)故障。數(shù)據(jù)庫(kù)和用于做網(wǎng)關(guān)的Web服務(wù)器都是單點(diǎn)，一旦任何一臺(tái)機(jī)器出現(xiàn)問(wèn)題將導(dǎo)致所有服務(wù)不可用。雖然用于做網(wǎng)關(guān)的Web服務(wù)器可以通過(guò)保持心跳同步迅速切換，但還是無(wú)法解決數(shù)據(jù)庫(kù)的單點(diǎn)，LJ當(dāng)時(shí)也沒(méi)做這個(gè)。
網(wǎng)站又變慢了，這次是因?yàn)镮O和數(shù)據(jù)庫(kù)的問(wèn)題，問(wèn)題是怎么往應(yīng)用里面添加數(shù)據(jù)庫(kù)呢？

4、五臺(tái)服務(wù)器

又買(mǎi)了一臺(tái)數(shù)據(jù)庫(kù)服務(wù)器。在兩臺(tái)數(shù)據(jù)庫(kù)服務(wù)器上使用了數(shù)據(jù)庫(kù)同步(Mysql支持的Master-Slave模式)，寫(xiě)操作全部針對(duì)主數(shù)據(jù)庫(kù)（通過(guò)Binlog，主服務(wù)器上的寫(xiě)操作可以迅速同步到從服務(wù)器上），讀操作在兩個(gè)數(shù)據(jù)庫(kù)上同時(shí)進(jìn)行(也算是負(fù)載均橫的一種吧)。

實(shí)現(xiàn)同步時(shí)要注意幾個(gè)事項(xiàng)：

讀操作數(shù)據(jù)庫(kù)選擇算法處理，要選一個(gè)當(dāng)前負(fù)載輕一點(diǎn)的數(shù)據(jù)庫(kù)。
在從數(shù)據(jù)庫(kù)服務(wù)器上只能進(jìn)行讀操作
準(zhǔn)備好應(yīng)對(duì)同步過(guò)程中的延遲，處理不好可能會(huì)導(dǎo)致數(shù)據(jù)庫(kù)同步的中斷。只需要對(duì)寫(xiě)操作進(jìn)行判斷即可，讀操作不存在同步問(wèn)題。

5、更多服務(wù)器

有錢(qián)了，當(dāng)然要多買(mǎi)些服務(wù)器。部署后快了沒(méi)多久，又開(kāi)始慢了。這次有更多的Web服務(wù)器，更多的數(shù)據(jù)庫(kù)服務(wù)器，存在 IO與CPU爭(zhēng)用。于是采用了BIG-IP作為負(fù)載均衡解決方案。

6、現(xiàn)在我們?cè)谀睦铮?/h2>

現(xiàn)在服務(wù)器基本上夠了，但性能還是有問(wèn)題，原因出在架構(gòu)上。

數(shù)據(jù)庫(kù)的架構(gòu)是最大的問(wèn)題。由于增加的數(shù)據(jù)庫(kù)都是以Slave模式添加到應(yīng)用內(nèi)，這樣唯一的好處就是將讀操作分布到了多臺(tái)機(jī)器，但這樣帶來(lái)的后果就是寫(xiě)操作被大量分發(fā)，每臺(tái)機(jī)器都要執(zhí)行，服務(wù)器越多，浪費(fèi)就越大，隨著寫(xiě)操作的增加，用于服務(wù)讀操作的資源越來(lái)越少。

由一臺(tái)分布到兩臺(tái)

最終效果

現(xiàn)在我們發(fā)現(xiàn)，我們并不需要把這些數(shù)據(jù)在如此多的服務(wù)器上都保留一份。服務(wù)器上已經(jīng)做了RAID，數(shù)據(jù)庫(kù)也進(jìn)行了備份，這么多的備份完全是對(duì)資源的浪費(fèi)，屬于冗余極端過(guò)度。那為什么不把數(shù)據(jù)分布存儲(chǔ)呢？

問(wèn)題發(fā)現(xiàn)了，開(kāi)始考慮如何解決。現(xiàn)在要做的就是把不同用戶的數(shù)據(jù)分布到不同的服務(wù)器上進(jìn)行存儲(chǔ)，以實(shí)現(xiàn)數(shù)據(jù)的分布式存儲(chǔ)，讓每臺(tái)機(jī)器只為相對(duì)固定的用戶服務(wù)，以實(shí)現(xiàn)平行的架構(gòu)和良好的可擴(kuò)展性。

為了實(shí)現(xiàn)用戶分組，我們需要為每一個(gè)用戶分配一個(gè)組標(biāo)記，用于標(biāo)記此用戶的數(shù)據(jù)存放在哪一組數(shù)據(jù)庫(kù)服務(wù)器中。每組數(shù)據(jù)庫(kù)由一個(gè)master及幾個(gè)slave 組成，并且slave的數(shù)量在2-3臺(tái)，以實(shí)現(xiàn)系統(tǒng)資源的最合理分配，既保證數(shù)據(jù)讀操作分布，又避免數(shù)據(jù)過(guò)度冗余以及同步操作對(duì)系統(tǒng)資源的過(guò)度消耗。

由一臺(tái)（一組）中心服務(wù)器提供用戶分組控制。所有用戶的分組信息都存儲(chǔ)在這臺(tái)機(jī)器上，所有針對(duì)用戶的操作需要先查詢這臺(tái)機(jī)器得到用戶的組號(hào)，然后再到相應(yīng)的數(shù)據(jù)庫(kù)組中獲取數(shù)據(jù)。

這樣的用戶架構(gòu)與目前LJ的架構(gòu)已經(jīng)很相像了。

在具體的實(shí)現(xiàn)時(shí)需要注意幾個(gè)問(wèn)題：

在數(shù)據(jù)庫(kù)組內(nèi)不要使用自增ID，以便于以后在數(shù)據(jù)庫(kù)組之間遷移用戶，以實(shí)現(xiàn)更合理的I/O，磁盤(pán)空間及負(fù)載分布。
將userid，postid存儲(chǔ)在全局服務(wù)器上，可以使用自增，數(shù)據(jù)庫(kù)組中的相應(yīng)值必須以全局服務(wù)器上的值為準(zhǔn)。全局服務(wù)器上使用事務(wù)型數(shù)據(jù)庫(kù)InnoDB。
在數(shù)據(jù)庫(kù)組之間遷移用戶時(shí)要萬(wàn)分小心，當(dāng)遷移時(shí)用戶不能有寫(xiě)操作。

7、現(xiàn)在我們?cè)谀睦?/h2>

問(wèn)題：

一個(gè)全局主服務(wù)器，掛掉的話所有用戶注冊(cè)及寫(xiě)操作就掛掉。
每個(gè)數(shù)據(jù)庫(kù)組一個(gè)主服務(wù)器，掛掉的話這組用戶的寫(xiě)操作就掛掉。
數(shù)據(jù)庫(kù)組從服務(wù)器掛掉的話會(huì)導(dǎo)致其它服務(wù)器負(fù)載過(guò)大。

對(duì)于Master-Slave模式的單點(diǎn)問(wèn)題，LJ采取了Master-Master模式來(lái)解決。所謂Master-Master實(shí)際上是人工實(shí)現(xiàn)的，并不是由MySQL直接提供的，實(shí)際上也就是兩臺(tái)機(jī)器同時(shí)是Master，也同時(shí)是Slave，互相同步。

Master-Master實(shí)現(xiàn)時(shí)需要注意：

一個(gè)Master出錯(cuò)后恢復(fù)同步，最好由服務(wù)器自動(dòng)完成。
數(shù)字分配，由于同時(shí)在兩臺(tái)機(jī)器上寫(xiě)，有些ID可能會(huì)沖突。

解決方案：

奇偶數(shù)分配ID，一臺(tái)機(jī)器上寫(xiě)奇數(shù)，一臺(tái)機(jī)器上寫(xiě)偶數(shù)
通過(guò)全局服務(wù)器進(jìn)行分配(LJ采用的做法)。

Master-Master模式還有一種用法，這種方法與前一種相比，仍然保持兩臺(tái)機(jī)器的同步，但只有一臺(tái)機(jī)器提供服務(wù)（讀和寫(xiě)），在每天晚上的時(shí)候進(jìn)行輪換，或者出現(xiàn)問(wèn)題的時(shí)候進(jìn)行切換。

8、現(xiàn)在我們?cè)谀睦?/h2>

現(xiàn)在插播一條廣告，MyISAM VS InnoDB。

使用InnoDB：

支持事務(wù)
需要做更多的配置，不過(guò)值得，可以更安全的存儲(chǔ)數(shù)據(jù)，以及得到更快的速度。

使用MyISAM：

記錄日志（LJ用它來(lái)記網(wǎng)絡(luò)訪問(wèn)日志）
存儲(chǔ)只讀靜態(tài)數(shù)據(jù)，足夠快。
并發(fā)性很差，無(wú)法同時(shí)讀寫(xiě)數(shù)據(jù)（添加數(shù)據(jù)可以）
MySQL非正常關(guān)閉或死機(jī)時(shí)會(huì)導(dǎo)致索引錯(cuò)誤，需要使用myisamchk修復(fù)，而且當(dāng)訪問(wèn)量大時(shí)出現(xiàn)非常頻繁。

9、緩存

去年我寫(xiě)過(guò)一篇文章介紹memcached，它就是由LJ的團(tuán)隊(duì)開(kāi)發(fā)的一款緩存工具，以key-value的方式將數(shù)據(jù)存儲(chǔ)到分布的內(nèi)存中。LJ緩存的數(shù)據(jù)：

12臺(tái)獨(dú)立服務(wù)器（不是捐贈(zèng)的）
28個(gè)實(shí)例
30GB總?cè)萘?
90-93%的命中率（用過(guò)squid的人可能知道，squid內(nèi)存加磁盤(pán)的命中率大概在70-80%）

如何建立緩存策略？

想緩存所有的東西？那是不可能的，我們只需要緩存已經(jīng)或者可能導(dǎo)致系統(tǒng)瓶頸的地方，最大程度的提交系統(tǒng)運(yùn)行效率。通過(guò)對(duì)MySQL的日志的分析我們可以找到緩存的對(duì)象。

緩存的缺點(diǎn)？

沒(méi)有完美的事物，緩存也有缺點(diǎn)：
增大開(kāi)發(fā)量，需要針對(duì)緩存處理編寫(xiě)特殊的代碼。
管理難度增加，需要更多人參與系統(tǒng)維護(hù)。
當(dāng)然大內(nèi)存也需要錢(qián)。

10、Web訪問(wèn)負(fù)載均衡

在數(shù)據(jù)包級(jí)別使用BIG-IP，但BIG-IP并不知道我們內(nèi)部的處理機(jī)制，無(wú)法判斷由哪臺(tái)服務(wù)器對(duì)這些請(qǐng)求進(jìn)行處理。反向代理并不能很好的起到作用，不是已經(jīng)夠快了，就是達(dá)不到我們想要的效果。

所以，LJ又開(kāi)發(fā)了Perlbal。特點(diǎn)：

快，小，可管理的http web 服務(wù)器/代理
可以在內(nèi)部進(jìn)行轉(zhuǎn)發(fā)
使用Perl開(kāi)發(fā)
單線程，異步，基于事件，使用epoll , kqueue
支持Console管理與http遠(yuǎn)程管理，支持動(dòng)態(tài)配置加載
多種模式：web服務(wù)器，反向代理，插件
支持插件：GIF/PNG互換？

11、MogileFS

LJ使用開(kāi)源的MogileFS作為分布式文件存儲(chǔ)系統(tǒng)。MogileFS使用非常簡(jiǎn)單，它的主要設(shè)計(jì)思想是：

文件屬于類（類是最小的復(fù)制單位）
跟蹤文件存儲(chǔ)位置
在不同主機(jī)上存儲(chǔ)
使用MySQL集群統(tǒng)一存儲(chǔ)分布信息
大容易廉價(jià)磁盤(pán)

到目前為止就這么多了，更多文檔可以在http://www.danga.com/words/找到。Danga.com和LiveJournal.com的同學(xué)們拿這個(gè)文檔參加了兩次MySQL Con，兩次OS Con，以及眾多的其它會(huì)議，無(wú)私的把他們的經(jīng)驗(yàn)分享出來(lái)，值得我們學(xué)習(xí)。在web2.0時(shí)代快速開(kāi)發(fā)得到大家越來(lái)越多的重視，但良好的設(shè)計(jì)仍是每一個(gè)應(yīng) 用的基礎(chǔ)，希望web2.0們?cè)诔砷L(zhǎng)為T(mén)op500網(wǎng)站的路上，不要因?yàn)榧軜?gòu)阻礙了網(wǎng)站的發(fā)展。

http://blog.csdn.net/xmr_gxcfe/archive/2007/09/14/1785292.aspx

posted @ 2007-09-29 21:26 Coolfiry 閱讀(550) | 評(píng)論 (0) | 編輯收藏

轉(zhuǎn)Windows快速創(chuàng)建大文件的三種方法

posted @ 2007-09-25 14:30 Coolfiry 閱讀(356) | 評(píng)論 (0) | 編輯收藏

UML標(biāo)識(shí)

UML類圖的各種標(biāo)識(shí)法
關(guān)鍵字: UML
·------>虛線箭頭表示依賴關(guān)系（dependency），一個(gè)類需要與另外一個(gè)類一起工作，是它一種最弱的關(guān)聯(lián)關(guān)系，常見(jiàn)于各種工具類之間的關(guān)系
·——實(shí)線表示聯(lián)合關(guān)系（association），一個(gè)類包含對(duì)另外一個(gè)類對(duì)象的引用，這個(gè)通常是使用屬性來(lái)實(shí)現(xiàn)的，為了表明之間的包含關(guān)系，有時(shí)候會(huì)在實(shí)線的一端加上箭頭（navigability arrow）來(lái)表示導(dǎo)航關(guān)系，如果關(guān)聯(lián)的雙方又都和第三個(gè)類有關(guān)聯(lián)關(guān)系，那么可以在實(shí)線的中間加一個(gè)虛線和第三個(gè)類關(guān)聯(lián)來(lái)表示這種association classes關(guān)系
·◇——空心菱形加實(shí)線表示聚合關(guān)系（aggregation），它是一種更強(qiáng)的關(guān)聯(lián)關(guān)系，表示一個(gè)類可以擁有或者享有一個(gè)類的實(shí)例對(duì)象，在java代碼表現(xiàn)上跟聯(lián)合是一樣的。
·◆——實(shí)心菱形加實(shí)線表示組合關(guān)系（composition），它的關(guān)聯(lián)性比聚合更強(qiáng)，被組合的對(duì)象是組合對(duì)象的一部分，沒(méi)法跟其他的對(duì)象共享，而且如果組合對(duì)象銷毀的話，被組合的對(duì)象也會(huì)同時(shí)被銷毀，其表現(xiàn)形式跟聯(lián)合一樣
·空心箭頭加實(shí)線，表示泛化generalization（繼承inheritance）關(guān)系，這個(gè)很簡(jiǎn)單
·在rose中要建立enumeration，只需要在建立的class中將其stereotype設(shè)置為enumeration即可。stereotype只是用來(lái)做一個(gè)標(biāo)記，并不包含別的意義

posted @ 2007-06-10 18:03 Coolfiry 閱讀(480) | 評(píng)論 (0) | 編輯收藏

要從沈陽(yáng)回成都了

明天18號(hào)，要從沈陽(yáng)回成都了

posted @ 2007-05-17 09:46 Coolfiry 閱讀(212) | 評(píng)論 (0) | 編輯收藏

轉(zhuǎn)(PO BO VO DTO POJO DAO概念及其作用)

PO BO VO DTO POJO DAO概念及其作用（附轉(zhuǎn)換圖）

J2EE開(kāi)發(fā)中大量的專業(yè)縮略語(yǔ)很是讓人迷惑，尤其是跟一些高手討論問(wèn)題的時(shí)候，三分鐘就被人家滿口的專業(yè)術(shù)語(yǔ)噴暈了，PO VO BO DTO POJO DAO，一大堆的就來(lái)了（聽(tīng)過(guò)老羅對(duì)這種現(xiàn)象的批判的朋友會(huì)會(huì)心一笑）。

首先聲明偶也不是什么高手，以下總結(jié)都是自己的體會(huì)。不對(duì)之處請(qǐng)您多指教。

PO：
persistant object持久對(duì)象

最形象的理解就是一個(gè)PO就是數(shù)據(jù)庫(kù)中的一條記錄。
好處是可以把一條記錄作為一個(gè)對(duì)象處理，可以方便的轉(zhuǎn)為其它對(duì)象。

BO：
business object業(yè)務(wù)對(duì)象

主要作用是把業(yè)務(wù)邏輯封裝為一個(gè)對(duì)象。這個(gè)對(duì)象可以包括一個(gè)或多個(gè)其它的對(duì)象。
比如一個(gè)簡(jiǎn)歷，有教育經(jīng)歷、工作經(jīng)歷、社會(huì)關(guān)系等等。
我們可以把教育經(jīng)歷對(duì)應(yīng)一個(gè)PO，工作經(jīng)歷對(duì)應(yīng)一個(gè)PO，社會(huì)關(guān)系對(duì)應(yīng)一個(gè)PO。
建立一個(gè)對(duì)應(yīng)簡(jiǎn)歷的BO對(duì)象處理簡(jiǎn)歷，每個(gè)BO包含這些PO。
這樣處理業(yè)務(wù)邏輯時(shí)，我們就可以針對(duì)BO去處理。

VO ：
value object值對(duì)象
ViewObject表現(xiàn)層對(duì)象

主要對(duì)應(yīng)界面顯示的數(shù)據(jù)對(duì)象。對(duì)于一個(gè)WEB頁(yè)面，或者SWT、SWING的一個(gè)界面，用一個(gè)VO對(duì)象對(duì)應(yīng)整個(gè)界面的值。

DTO ：
Data Transfer Object數(shù)據(jù)傳輸對(duì)象
主要用于遠(yuǎn)程調(diào)用等需要大量傳輸對(duì)象的地方。
比如我們一張表有100個(gè)字段，那么對(duì)應(yīng)的PO就有100個(gè)屬性。
但是我們界面上只要顯示10個(gè)字段，
客戶端用WEB service來(lái)獲取數(shù)據(jù)，沒(méi)有必要把整個(gè)PO對(duì)象傳遞到客戶端，
這時(shí)我們就可以用只有這10個(gè)屬性的DTO來(lái)傳遞結(jié)果到客戶端，這樣也不會(huì)暴露服務(wù)端表結(jié)構(gòu).到達(dá)客戶端以后，如果用這個(gè)對(duì)象來(lái)對(duì)應(yīng)界面顯示，那此時(shí)它的身份就轉(zhuǎn)為VO

POJO ：
plain ordinary java object 簡(jiǎn)單java對(duì)象
個(gè)人感覺(jué)POJO是最常見(jiàn)最多變的對(duì)象，是一個(gè)中間對(duì)象，也是我們最常打交道的對(duì)象。

一個(gè)POJO持久化以后就是PO
直接用它傳遞、傳遞過(guò)程中就是DTO
直接用來(lái)對(duì)應(yīng)表示層就是VO

DAO：
data access object數(shù)據(jù)訪問(wèn)對(duì)象
這個(gè)大家最熟悉，和上面幾個(gè)O區(qū)別最大，基本沒(méi)有互相轉(zhuǎn)化的可能性和必要.
主要用來(lái)封裝對(duì)數(shù)據(jù)庫(kù)的訪問(wèn)。通過(guò)它可以把POJO持久化為PO，用PO組裝出來(lái)VO、DTO

總結(jié)下我認(rèn)為一個(gè)對(duì)象究竟是什么O要看具體環(huán)境，在不同的層、不同的應(yīng)用場(chǎng)合，對(duì)象的身份也不一樣，而且對(duì)象身份的轉(zhuǎn)化也是很自然的。就像你對(duì)老婆來(lái)說(shuō)就是老公，對(duì)父母來(lái)說(shuō)就是子女。設(shè)計(jì)這些概念的初衷不是為了唬人而是為了更好的理解和處理各種邏輯，讓大家能更好的去用面向?qū)ο?/font>的方式處理問(wèn)題.

大家千萬(wàn)不要陷入過(guò)度設(shè)計(jì)，大可不必為了設(shè)計(jì)而設(shè)計(jì)一定要在代碼中區(qū)分各個(gè)對(duì)象。一句話技術(shù)是為應(yīng)用服務(wù)的。

歡迎指正。

畫(huà)了個(gè)圖，感覺(jué)沒(méi)有完全表達(dá)出自己的意思。。。。。誰(shuí)幫忙完善下，最好能體現(xiàn)各個(gè)O在MVC中的位置

轉(zhuǎn)自：http://www.tkk7.com/vip01/archive/2007/01/08/92430.html

posted @ 2007-05-17 09:44 Coolfiry 閱讀(336) | 評(píng)論 (0) | 編輯收藏

I love English from then on.I study English hard form then on.I love it.It is very lovely.

posted @ 2006-11-26 14:13 Coolfiry 閱讀(269) | 評(píng)論 (0) | 編輯收藏

Web搜索引擎設(shè)計(jì)和實(shí)現(xiàn)分析[轉(zhuǎn)載]

一、引言

　　隨著Internet的飛速發(fā)展，人們?cè)絹?lái)越依靠網(wǎng)絡(luò)來(lái) 查找他們所需要的信息，但是，由于網(wǎng)上的信息源多不勝數(shù)，也就是我們經(jīng)常所說(shuō)的"Rich Data, Poor Information"。所以如何有效的去發(fā)現(xiàn)我們所需要的信息，就成了一個(gè)很關(guān)鍵的問(wèn)題。為了解決這個(gè)問(wèn)題，搜索引擎就隨之誕生。

　　現(xiàn)在在網(wǎng)上的搜索引擎也已經(jīng)有很多，比較著名的有AltaVista, Yahoo, InfoSeek, Metacrawler, SavvySearch等等。國(guó)內(nèi)也建立了很多的搜索引擎，比如：搜狐、新浪、北極星等等,當(dāng)然由于它們建立的時(shí)間不長(zhǎng)，在信息搜索的取全率和取準(zhǔn)率上都有待于改進(jìn)和提高。

　　Alta Vista是一個(gè)速度很快的搜索引擎，由于它強(qiáng)大的硬件配置，使它能夠做及其復(fù)雜的查詢。它主要是基于關(guān)鍵字進(jìn)行查詢，它漫游的領(lǐng)域有Web和 Usenet。支持布爾查詢的"AND"，"OR"和"NOT"，同時(shí)還加上最相近定位"NEAR"，允許通配符和"向后"搜索（比如：你可以查找鏈接到某一頁(yè)的所有Web站點(diǎn)）。你可以決定是否對(duì)搜索的短語(yǔ)加上權(quán)值，在文檔的什么部位去查找它們。能夠進(jìn)行短語(yǔ)查詢而不是簡(jiǎn)單的單詞查詢的優(yōu)點(diǎn)是很明顯的，比如，我們想要查找一個(gè)短語(yǔ)"to be or not to be"，如果只是把它們分解成單詞的話，這些單詞都是屬于Stop Word，這樣這個(gè)查詢就不會(huì)有任何結(jié)果，但是把它當(dāng)作一個(gè)整體來(lái)查詢，就很容易返回一些結(jié)果，比如關(guān)于哈姆雷特或者是莎士比亞等等的信息。系統(tǒng)對(duì)查詢結(jié) 果所得到的網(wǎng)頁(yè)的打分是根據(jù)在網(wǎng)頁(yè)中所包含的你的搜索短語(yǔ)的多少，它們?cè)谖臋n的什么位置以及搜索短語(yǔ)在文檔內(nèi)部之間的距離來(lái)決定的。同時(shí)可以把得到的搜索結(jié)果翻譯成其他的語(yǔ)言。

　　Exite是稱為具有"智能"的搜索引擎，因?yàn)樗⒘艘粋€(gè)基于概念的索引。當(dāng)然，它所謂的"智能"是基于對(duì)概率統(tǒng)計(jì)的靈活應(yīng)用。它能夠同時(shí)進(jìn)行基于概念和關(guān)鍵字的索引。它能夠索引Web,Usenet和分類的廣告。支持"AND"，"OR"，"NOT"等布爾操作，同時(shí)也可以使用符號(hào)"+"和"-"。缺點(diǎn)是在返回的查詢結(jié)果中沒(méi)有指定網(wǎng)頁(yè)的尺寸和格式。

　　InfoSeek是一個(gè)簡(jiǎn)單但是功能強(qiáng)大的索引，它的一個(gè)優(yōu)點(diǎn)是有一個(gè)面向主題搜索的可擴(kuò)展的分類。你可以把你的搜索短語(yǔ)和相似的分類目錄的主題短語(yǔ)相互參照，而那些主題短語(yǔ)會(huì)自動(dòng) 加到你的查詢中去。使你的搜索有更好的主題相關(guān)性。同時(shí)它也支持對(duì)圖象的查詢。它能夠漫游Web,Usenet,Usenet FAQs等等。不支持布爾操作，但是可以使用符號(hào)"+"和"-"（相當(dāng)于"AND"和"NOT"）

　　Yahoo實(shí)際上不能稱為是一個(gè)搜索引擎站點(diǎn)，但是它提供了一個(gè)分層的主題索引，使你能夠從一個(gè)通常的主題進(jìn)入到一個(gè)特定的主題，Yahoo對(duì)Web進(jìn)行了有效的組織和分類。比如你想要建立一個(gè)網(wǎng)頁(yè)，但是你不知道如何操作，為了在Yahoo上找到關(guān)于建立網(wǎng)頁(yè)的信息，你可以先在Yahoo上選擇一個(gè)主題：計(jì)算機(jī)和Internet，然后在這個(gè)主題下，你可以發(fā)現(xiàn)一些子主題，比如：Web網(wǎng)頁(yè)制作，CGI編程，JAVA，HTML，網(wǎng)頁(yè)設(shè)計(jì)等，選擇一個(gè)和你要找的相關(guān)的子主題，最終你就可以得到和該子主題相關(guān)的所有的網(wǎng)頁(yè)的鏈接。也就是說(shuō)，如果你對(duì)要查找的內(nèi)容屬于哪個(gè)主題十分清楚的話，通過(guò)目錄查詢的方法要比一般的使用搜索引擎有更好的準(zhǔn)確率。你可以搜索Yahoo的索引，但是事實(shí)上，你并沒(méi)有在搜索整個(gè)Web。但是Yahoo提供了選項(xiàng)使你可以同時(shí)搜索其他的搜索引擎，比如： Alta Vista。但是要注意的是Yahoo實(shí)際上只是對(duì)Web的一小部分進(jìn)行了分類和組織，而且它的實(shí)效性也不是很好。

　　搜索引擎的基本原理是通過(guò)網(wǎng)絡(luò)機(jī)器人定期在web網(wǎng)頁(yè)上爬行，然后發(fā)現(xiàn)新的網(wǎng)頁(yè)，把它們?nèi)』貋?lái)放到本地的數(shù)據(jù)庫(kù)中，用戶的查詢請(qǐng)求可以通過(guò)查詢本地的數(shù)據(jù)庫(kù)來(lái)得到。如yahoo每天會(huì)找到大約500萬(wàn)個(gè)新的網(wǎng)頁(yè)。

　　搜索引擎的實(shí)現(xiàn)機(jī)制一般有兩種，一種是通過(guò)手工方式對(duì)網(wǎng)頁(yè)進(jìn)行索引，比如yahoo的網(wǎng)頁(yè)是通過(guò)手工分類的方式實(shí)現(xiàn)的，它的缺點(diǎn)是Web的覆蓋率比較低，同時(shí)不能保證最新的信息。查詢匹配是通過(guò)用戶寫(xiě)入的關(guān)鍵字和網(wǎng)頁(yè)的描述和標(biāo)題來(lái)進(jìn)行匹配，而不是通過(guò)全文的匹配進(jìn)行的。第二種是對(duì)網(wǎng)頁(yè)進(jìn)行自動(dòng)的索引，象AltaVista則是完全通過(guò)自動(dòng)索引實(shí)現(xiàn)的。這種能實(shí)現(xiàn)自動(dòng)的文檔分類，實(shí)際上采用了信息提取的技術(shù)。但是在分類準(zhǔn)確性上可能不如手工分類。

　　搜索引擎一般都有一個(gè)Robot定期的訪問(wèn)一些站點(diǎn)，來(lái)檢查這些站點(diǎn)的變化，同時(shí)查找新的站點(diǎn)。一般站點(diǎn)有一個(gè)robot.txt文件用來(lái)說(shuō)明服務(wù)器不希望Robot訪問(wèn)的區(qū)域，Robot 都必須遵守這個(gè)規(guī)定。如果是自動(dòng)索引的話，Robot在得到頁(yè)面以后，需要對(duì)該頁(yè)面根據(jù)其內(nèi)容進(jìn)行索引，根據(jù)它的關(guān)鍵字的情況把它歸到某一類中。頁(yè)面的信息是通過(guò)元數(shù)據(jù)的形式保存的，典型的元數(shù)據(jù)包括標(biāo)題、IP地址、一個(gè)該頁(yè)面的簡(jiǎn)要的介紹，關(guān)鍵字或者是索引短語(yǔ)、文件的大小和最后的更新的日期。盡管元數(shù) 據(jù)有一定的標(biāo)準(zhǔn)，但是很多站點(diǎn)都采用自己的模板。文檔提取機(jī)制和索引策略對(duì)Web搜索引擎的有效性有很大的關(guān)系。高級(jí)的搜索選項(xiàng)一般包括：布爾方法或者是短語(yǔ)匹配和自然語(yǔ)言處理。一個(gè)查詢所產(chǎn)生的結(jié)果按照提取機(jī)制被分成不同的等級(jí)提交給用戶。最相關(guān)的放在最前面。每一個(gè)提取出來(lái)的文檔的元數(shù)據(jù)被顯示給用戶。同時(shí)包括該文檔所在的URL地址。

　　另外有一些關(guān)于某一個(gè)主題的專門(mén)的引擎，它們只對(duì)某一個(gè)主題的內(nèi)容進(jìn)行搜索和處理，這樣信息的取全率和精度相對(duì)就比較高。

　　同時(shí)，有一類搜索引擎，它本身不用Robot去定期的采集網(wǎng)頁(yè)。象SavvySearch 和 MetaCrawler是通過(guò)向多個(gè)搜索引擎同時(shí)發(fā)出詢問(wèn)并對(duì)結(jié)果進(jìn)行綜合返回給用戶實(shí)現(xiàn)搜索功能。當(dāng)然實(shí)際上象SavvySearch能夠?qū)Ω鱾€(gè)搜索引擎的功能進(jìn)行分析和比較，根據(jù)不同的用戶查詢提交給不同的搜索引擎進(jìn)行處理，當(dāng)然用戶自己也可以指定利用哪一個(gè)搜索引擎。

　　一個(gè)優(yōu)秀的搜索引擎必須處理以下幾個(gè)問(wèn)題：1 網(wǎng)頁(yè)的分類2 自然語(yǔ)言的處理3 搜索策略的調(diào)度和協(xié)作 4 面向特定用戶的搜索。所以很多搜索引擎不同程度的使用了一些人工智能的技術(shù)來(lái)解決這些方面的問(wèn)題。

　　二、網(wǎng)絡(luò)Spider的實(shí)現(xiàn)描述

　　現(xiàn)在有很多文章對(duì)Web引擎做了大量的介紹和分析，但是很少有對(duì)它們的實(shí)現(xiàn)做一個(gè)詳細(xì)的描述，這里我們主要來(lái)介紹一個(gè)具有基本功能的Web引擎的實(shí)現(xiàn)。本文，我們以類C++語(yǔ)言的形式來(lái)描述Web引擎如何采集網(wǎng)頁(yè)并存放到數(shù)據(jù)庫(kù)中的過(guò)程。同時(shí)描述了如何根據(jù)用戶輸入的關(guān)鍵字查詢數(shù)據(jù)庫(kù)并得到相關(guān)網(wǎng)頁(yè)的過(guò) 程。

　　2.1數(shù)據(jù)庫(kù)結(jié)構(gòu)

　　首先，我們要建立一個(gè)數(shù)據(jù)庫(kù)表用來(lái)存放我們得到的網(wǎng)頁(yè)。這里一般需要建立如下的表：

　　1.字典表的建立，事實(shí)上這里是用文檔中有意義的單詞和它們的出現(xiàn)頻率來(lái)代表一個(gè)文檔。

　　該表（WordDictionaryTbl）主要要包括三個(gè)字段，主要是用來(lái)存放和一個(gè)網(wǎng)頁(yè)相關(guān)的單詞的情況

????url_id? ? 對(duì)每一個(gè)URL的唯一的ID號(hào)
? ? word? ? ? 該URL中的經(jīng)過(guò)stem的單詞
? ? intag? ? 該單詞在該網(wǎng)頁(yè)中的出現(xiàn)的次數(shù)

　　2.存儲(chǔ)每一個(gè)URL信息的表

　　該表(URLTbl)中主要的關(guān)鍵字段有：

? rec_id? ? ? ? 每一條記錄的唯一的ID號(hào)
? status? ? 得到該URL內(nèi)容的狀態(tài)，比如HTTP_STATUS_TIMEOUT表示
? ? ? ? ? ? 下載網(wǎng)頁(yè)的最大允許超時(shí)
? url? ? ? ? URL的字符串名稱
? content_type? ? ? 內(nèi)容的類型
? last_modified? ? 最新的更改時(shí)間
? title? ? ? ? ? ? 該URL的標(biāo)題
? docsize? ? ? ? ? 該URL的文件的尺寸
? last_index_time? 最近一次索引的時(shí)間
? next_index_time? 下一次索引的時(shí)間
? tag? ? 對(duì)于網(wǎng)頁(yè)，用來(lái)表示它的類型，比如：是text，或者是html，
? ? ? ? ? ? ? ? ? ? 或者是圖片等等
? hops? ? ? ? ? ? ? 得到文件時(shí)候的曾經(jīng)失敗的次數(shù)
? keywords? ? ? ? ? 對(duì)于網(wǎng)頁(yè)，和該網(wǎng)頁(yè)相關(guān)的關(guān)鍵字
? description? ? ? 對(duì)于網(wǎng)頁(yè)，指網(wǎng)頁(yè)的內(nèi)容的描述
? lang? ? ? ? ? ? ? 文檔所使用的語(yǔ)言

　　3.因?yàn)榫W(wǎng)頁(yè)中有很多單詞是一些介詞和語(yǔ)氣助詞或者是非常常用的常用詞，它們本身沒(méi)有多少意義。比如：英語(yǔ)中的about,in,at,we,this 等等。中文中的如"和"，"一起"，"關(guān)于"等等。我們統(tǒng)一的把它們稱為停止詞（stop word）。所以我們要建立一個(gè)表，來(lái)包括所有這些停止詞。該表(StopWordTbl)主要有兩個(gè)字段。
word char(32)? ? 表示那些停止詞
lang char(2)? ? ? 表示所使用的語(yǔ)言

　　4.我們要建立一個(gè)關(guān)于robot的表，我們?cè)谇懊嬲f(shuō)過(guò)，所有的網(wǎng)站一般都有一個(gè)robot.txt文件用來(lái)表示網(wǎng)絡(luò)上的robot可以訪問(wèn)的權(quán)限。該表(RobotTbl)主要有以下字段。
? ? hostinfo? ? ? ? ? Web站點(diǎn)主機(jī)的信息
? ? path? ? ? ? ? ? ? 不允許robot訪問(wèn)的目錄

　　5.建立我們需要屏蔽的那些網(wǎng)頁(yè)(比如一些內(nèi)容不健康的或者沒(méi)有必要去搜索的站點(diǎn))的一張表(ForbiddenWWWTbl)，主要的字段就是網(wǎng)頁(yè)的URL。

　　6.另外我們需要建立一個(gè)我們所要得到的文件類型的表(FileTypeTbl)，比如，對(duì)于一個(gè)簡(jiǎn)單的Web搜索引擎，我們可能只需要得到后綴為. html，htm，.shtml和txt的類型文件。其他的我們只是簡(jiǎn)單的忽略它們。主要的字段就是文件的類型和說(shuō)明。

　　其中關(guān)于停止詞的表的內(nèi)容是我們要實(shí)現(xiàn)要根據(jù)各種語(yǔ)言的統(tǒng)計(jì)結(jié)果，把那些意義不大的單詞放進(jìn)去。關(guān)于文檔單詞、URL和Robot的表的內(nèi)容都是在獲取Web網(wǎng)頁(yè)的時(shí)候動(dòng)態(tài)增加記錄的。

　　2.2 具體網(wǎng)頁(yè)獲取算法描述

　　具體的網(wǎng)頁(yè)的獲取步驟是這樣的：

　　我們可以設(shè)定我們的搜索程序最大可以開(kāi)的線程的數(shù)目，然后這些線程可以同時(shí)在網(wǎng)上進(jìn)行搜索，它們根據(jù)數(shù)據(jù)庫(kù)中已有的關(guān)于網(wǎng)頁(yè)的信息，找出那些需要更新的網(wǎng)頁(yè)（如何判斷哪些網(wǎng)頁(yè)需要更新是一個(gè)值得研究的過(guò)程，現(xiàn)在有很多啟發(fā)式和智能的算法，基本上是基于統(tǒng)計(jì)規(guī)律進(jìn)行建模。最簡(jiǎn)單的當(dāng)然是設(shè)定一個(gè)時(shí)間范圍，在某個(gè)時(shí)間范圍以前的網(wǎng)頁(yè)被重新去搜索一遍），然后判斷那些網(wǎng)頁(yè)是否在屏蔽表中，如果是的話，就從關(guān)于URL的表中刪除該條記錄。否則，我們就到相應(yīng)的 WWW站點(diǎn)去得到URL指定的文件(這里需要注意的是根據(jù)不同的URL的特點(diǎn)，需要使用不同的協(xié)議，比如對(duì)于FTP站點(diǎn)要采用FTP協(xié)議，對(duì)于HTTP站點(diǎn)要采用HTTP協(xié)議，新聞?wù)军c(diǎn)要采用NNTP協(xié)議等等)事實(shí)上，我們先得到關(guān)于該網(wǎng)頁(yè)的頭信息，如果該網(wǎng)頁(yè)的最新修改時(shí)間和我們最近提取的時(shí)間是一樣的話，表示該網(wǎng)頁(yè)內(nèi)容沒(méi)有任何更新，則我們就不必去得到它的內(nèi)容，只需要修改最近一次更新它的時(shí)間為當(dāng)前的時(shí)間就可以了。如果該網(wǎng)頁(yè)最近做了修改，我們就要得到該網(wǎng)頁(yè)，并對(duì)它的內(nèi)容進(jìn)行分析，主要要包括和它相關(guān)的鏈接，把它們加到相應(yīng)的數(shù)據(jù)庫(kù)中，同時(shí)判斷網(wǎng)頁(yè)所包含的各種其他的文件，如文本文件、圖形文件、聲音文件和其他多媒體文件是否是我們所需要的文件，如果是的話，就把它加到我們響應(yīng)的數(shù)據(jù)庫(kù)中。同時(shí)要根據(jù)網(wǎng)頁(yè)的內(nèi)容提取所有的有意義的單詞和它們的出現(xiàn) 的次數(shù)，放到相應(yīng)的數(shù)據(jù)庫(kù)中。為了更好的描述這個(gè)過(guò)程，我們來(lái)看跟這個(gè)過(guò)程相關(guān)的主要的幾個(gè)對(duì)象和數(shù)據(jù)結(jié)構(gòu)。對(duì)象主要是針對(duì)三個(gè)層次來(lái)講的。第一層是針對(duì) WWW服務(wù)器，第二層是針對(duì)每一個(gè)頁(yè)面，第三層是針對(duì)每一個(gè)頁(yè)面的全文的索引。

　　2.3 和實(shí)現(xiàn)相關(guān)的主要類對(duì)象和功能描述下面的結(jié)構(gòu)是針對(duì)一個(gè)站點(diǎn)來(lái)說(shuō)的。

? ? Class? CServer {
? ? 主要的屬性有：
????char *url;? ? ? ? ? ? //WWW站點(diǎn)的URL名稱
????char *proxy;? ? ? ? ? //使用的代理的名稱
????char *basic_auth;? ? ? //進(jìn)行基本的HTTP認(rèn)證
????int? proxy_port;? ? ? //代理的端口號(hào)
????int? period;? ? ? ? ? //再次索引的周期
????int? net_errors;? ? ? //網(wǎng)絡(luò)連接不通的次數(shù)
????int? max_net_errors;? //可以允許的最大的網(wǎng)絡(luò)錯(cuò)誤
????int? read_timeout;? ? //下載文件允許的最大的延遲
????int? maxhops;? ? ? ? ? //表示URL可以最大跳轉(zhuǎn)的深度
????int? userobots;? ? ? ? //是否遵守robot.txt中的約定
????int? bodyweight;? // 在< body >....< /body >之間的單詞的權(quán)重
????int? titleweight; // 在< title >....< /title >之間的單詞的權(quán)重
????int? urlweight;? // 在文檔的URL中的單詞的權(quán)重
????int descweight;//在? ? < META
NAME="Description"? ? ? ? Content="..." >之間單詞的權(quán)重
????int? keywordweight; //在< META NAME="Keywords" Content="..." >
? 之間的單詞的權(quán)重

　　主要方法有：
FindServer();//用來(lái)查找該服務(wù)器是否存在并可以連接
FillDefaultAttribute() //用來(lái)針對(duì)所有的WWW服務(wù)器填寫(xiě)默認(rèn)的屬}；

以上的對(duì)象中的成員變量是和一個(gè)站點(diǎn)相關(guān)的參數(shù)的設(shè)置，我們對(duì)所有的站點(diǎn)有一個(gè)默認(rèn)的設(shè)置，但是可以對(duì)某些站點(diǎn)做一些特殊的設(shè)置。這些設(shè)置可以在配置文件中設(shè)定。
　　下面是關(guān)于文檔的結(jié)構(gòu)的主要的數(shù)據(jù)成員：

Class CNetDocument
? ? 主要屬性有：
? ? int????url_id; //該URL的ID號(hào)
? ? int????status;? //獲取該文檔時(shí)候的狀態(tài)
? ? int????size;? //文檔的尺寸
int????tag;? //和該文檔相關(guān)的標(biāo)簽，表示該文檔是
HTML，TEXT或者是其他類型
? ? int????hops;? ? //URL跳轉(zhuǎn)的次數(shù)
? ? char????*url; //和該文檔相關(guān)的URL的名稱
? ? char????*content_type;? ? ? //該內(nèi)容的類型
? ? char????*last_modified;? ? //最近一次的更新時(shí)間
? ? char????*title;? ? ? ? ? ? //該文檔的標(biāo)題
? ? char????*last_index_time;? //上次索引的時(shí)間
? ? char????*next_index_time;? //下次索引的時(shí)間
? ? char????*keywords;? ? ? ? ? //該文檔中的關(guān)鍵字
? ? char????*description;? ? ? //該文檔的描述

? 主要方法有：
? FillDocInfo(…) //根據(jù)數(shù)據(jù)庫(kù)，得到該文檔相關(guān)信息
? AddHerf(…)? ? //加入網(wǎng)頁(yè)中存在的新的鏈接的網(wǎng)址
? DeleteURL(…)? //刪除一個(gè)存在的網(wǎng)址
? CanGetThisURL(…) //根據(jù)配置決定是否去得到該網(wǎng)頁(yè)
? //下面三個(gè)方法是根據(jù)不同的URL，用不同的協(xié)議去獲得文檔
? NNTPGet(…)? ? ?
? FTPGet(….)
? HTTPGet(….)
? ParseHead(…)? //如果是HTTP協(xié)議得到的話，分析頭信息
? ParseMainBody(…)? ? //對(duì)獲得的文檔的主體進(jìn)行分析
? ServerResponseType (….)? //得到服務(wù)器端的響應(yīng)消息
? UpdateURLDB(….)? //更新的數(shù)據(jù)入庫(kù)
} ；

　　事實(shí)上，我們?cè)谝崛∫粋€(gè)網(wǎng)頁(yè)的時(shí)候，都要建立一個(gè)CNetDocument對(duì)象，然后再對(duì)這個(gè)網(wǎng)頁(yè)進(jìn)行分析的時(shí)候，把相關(guān)的內(nèi)容放到這個(gè)CNetDocument的成員變量里面。下面是關(guān)于頁(yè)面全文索引的結(jié)構(gòu)的主要數(shù)據(jù)成員：
Class CIndexer {
主要屬性有：
? char????*url;? ? ? //我們要處理的文檔相關(guān)的URL的名稱
? int mwords;????? //? 我們事先設(shè)定的一個(gè)網(wǎng)頁(yè)的最大的單詞數(shù)目
????int nwords;????????? // 實(shí)際的得到的單詞的數(shù)目
????int swords;????????? // 我們已經(jīng)排序的單詞的數(shù)目
????WORD *Word;????? //所有單詞的內(nèi)容
????char *buf;? ? ? //我們?yōu)槲臋n所分配的空間
主要方法有：
? InitIndexer(…)? ? //進(jìn)行初始設(shè)置和分配
? ParseGetFile(…)? //對(duì)得到的網(wǎng)頁(yè)進(jìn)行全文索引
? AddWord(…)? ? //把網(wǎng)頁(yè)的可以索引的單詞加到Word數(shù)組中去
? InToDB(….)? ? //關(guān)于網(wǎng)頁(yè)全文索引的信息入庫(kù)
}；

　　進(jìn)行網(wǎng)頁(yè)提取前，我們要建立一個(gè)CIndexer對(duì)象，它主要是用來(lái)對(duì)網(wǎng)頁(yè)進(jìn)行全文的索引。一般來(lái)說(shuō)我們只對(duì)兩種類型的URL進(jìn)行全文索引，一個(gè)是text/html，另外一個(gè)是text/plain。其中WORD的數(shù)據(jù)結(jié)構(gòu)如下：
? ? ? ? typedef struct word_struct {
????int count;? //該單詞出現(xiàn)的次數(shù)
????int code;? //該單詞的正常的形式，
比如單詞可能為 encouraging,它的正常的形式應(yīng)該為
encourage,這其實(shí)是一種對(duì)單詞的stem。
即我們只取單詞的主干部分。
????char *word;? //該單詞的內(nèi)容
} WORD;

　　以下的結(jié)構(gòu)是和網(wǎng)頁(yè)中的一些鏈接的對(duì)象相關(guān)的一個(gè)數(shù)據(jù)結(jié)構(gòu)
? ? typedef struct href_struct {
????char *href;? ? //該鏈接的名稱
????int hops;? ? ? //發(fā)生的跳轉(zhuǎn)次數(shù)
????int stored;? ? //是否已經(jīng)存儲(chǔ)到數(shù)據(jù)庫(kù)中
} HREF;
?

　　所有需要更新的和新產(chǎn)生的URL都被放到這個(gè)結(jié)構(gòu)中，當(dāng)它的數(shù)量超過(guò)一定的范圍以后，被一次性的存入數(shù)據(jù)庫(kù)。
　　關(guān)于URL的一個(gè)數(shù)據(jù)結(jié)構(gòu)如下：

typedef struct url {
char *schema; //表示該URL是通過(guò)什么協(xié)議得到的，比如HTTP，
? ? ? ? ? ? ? FTP，NNTP等。
char *specific;? ? //主機(jī)的名稱加上路徑
char *hostinfo;? ? //主機(jī)的名稱加上相關(guān)的協(xié)議端口
char *hostname;? ? //主機(jī)的名稱
char *path;? ? ? ? //在主機(jī)的具體的路徑
char *filename;? ? //文件的名稱
char *anchor;? ? ? //相關(guān)的anchor
int? port;? ? ? ? //協(xié)議相關(guān)的端口
} URL;

　　這是針對(duì)URL的一些相關(guān)的屬性的描述的一個(gè)數(shù)據(jù)結(jié)構(gòu)。事實(shí)上在數(shù)據(jù)庫(kù)中，我們存儲(chǔ)的只是對(duì)網(wǎng)頁(yè)的描述和對(duì)一些文本和HTML頁(yè)面的關(guān)鍵詞的索引信息。我們并不存儲(chǔ)網(wǎng)頁(yè)的實(shí)際的內(nèi)容。

　　三、用戶查詢實(shí)現(xiàn)描述

　　關(guān)于對(duì)用戶提交的查詢請(qǐng)求的實(shí)現(xiàn)分析：

　　用戶想要查詢某一方面的信息一般都是通過(guò)提供和該領(lǐng)域相關(guān)的幾個(gè)關(guān)鍵字來(lái)進(jìn)行的。

　　我們來(lái)看一下關(guān)于用戶查詢的相關(guān)的數(shù)據(jù)結(jié)構(gòu)和類：

　　下面是一個(gè)關(guān)于單詞和它的權(quán)值的基本結(jié)構(gòu)：

? typedef struct word_weight_pair
? ? {
? ? ? char word[WORD_LEN];
? ? ? int weight;
? ? }word_weight_pair;
? ?

　　下面的類主要是用來(lái)對(duì)用戶的查詢進(jìn)行處理和分析：
? ? Class CUserQuery
? ? {
char m_UserQuery[MAX_QUERYLEN];? //用戶的查詢表達(dá)式
CPtrArray word_weight_col;
//是關(guān)于結(jié)構(gòu)word_weight_pair的動(dòng)態(tài)數(shù)組
int m_maxReturnSum;? //用戶希望返回的最多的網(wǎng)頁(yè)數(shù)
int search_mode;
CObArray m_returnDoc;? //是關(guān)于CNetDocument對(duì)象的一個(gè)動(dòng)態(tài)數(shù)組
NormalizeWord（char* OneWord）;? //對(duì)單詞進(jìn)行歸整化，即Stem.
Find(char* odbcName);? //進(jìn)行數(shù)據(jù)庫(kù)查找和匹配
}；

　　系統(tǒng)實(shí)現(xiàn)的基本的步驟如下：

　　1.對(duì)用戶輸入的查詢表達(dá)式進(jìn)行分析。事實(shí)上，我們?cè)谇懊娴腟pider搜索過(guò)程中對(duì)文檔的表示是通過(guò)關(guān)鍵字形式描述的，每一個(gè)文檔可以表示為這樣的一個(gè)集合

? ? 其中 ::=< 單詞或短語(yǔ)名稱 >< 單詞或短語(yǔ)的權(quán)值 >

　　實(shí)際上就是采用矢量空間的表示方法來(lái)表示的文檔。

　　我們對(duì)用戶輸入的查詢表達(dá)式也采用矢量空間的表示方法。我們認(rèn)為用戶輸入的關(guān)鍵字的順序代表了它的重要性的程度，所以對(duì)于位置靠前的單詞有相對(duì)比較高的優(yōu)先級(jí)，同時(shí)我們對(duì)所有的內(nèi)容以短語(yǔ)或者是單詞為最小原子，進(jìn)行Stem操作，即象前面所提到的：比如單詞Encouraging就轉(zhuǎn)化成 Encourage的格式。然后去掉那些Stop Word，比如is ,as等等的單詞，這些單詞存放在StopWordTbl表中。然后把所有歸整化后的內(nèi)容放入動(dòng)態(tài)數(shù)組word_weight_col中去。

　　2.對(duì)于動(dòng)態(tài)數(shù)組word_weight_col中的每一個(gè)元素，即結(jié)構(gòu)word_weight_pair（包括單詞和該單詞的權(quán)重），我們從表WordDictionaryTbl中可以找到和這些單詞相關(guān)的記錄，這些記錄應(yīng)該是包括了所有的在word_weight_col中的單詞。

　　進(jìn)行網(wǎng)頁(yè)是否和查詢相匹配的計(jì)算。匹配計(jì)算的過(guò)程如下：首先我們對(duì)所有的記錄按URL地址進(jìn)行排序。因?yàn)榭赡芎脦讞l記錄對(duì)應(yīng)的是一個(gè)URL，然后對(duì)每一個(gè)網(wǎng)頁(yè)進(jìn)行打分，每一條記錄的單詞權(quán)值為 INITSCORE*WEIGHT+（TOTALTIMES-1）*WEIGHT* INCREMENT。其中INITSCORE為每一個(gè)單詞的基準(zhǔn)分?jǐn)?shù)，TOTALTIMES為該單詞在網(wǎng)頁(yè)中的出現(xiàn)的次數(shù)，WEIGHT是該單詞在不同的內(nèi)容段出現(xiàn)有不同的權(quán)值（比如在KEYWORD段，或者是標(biāo)題段，或者是內(nèi)容段等等）。INCREMENT是該單詞每多出現(xiàn)一次所增加的分?jǐn)?shù)。

　　3.根據(jù)用戶指定的m_maxReturnSum，顯示匹配程度最高的前m_maxReturnSum頁(yè)。

　　四、結(jié)束語(yǔ)

　　我們利用上面所討論的機(jī)制，在WINDOWS NT操作系統(tǒng)下，用VC++和SQL SERVER實(shí)現(xiàn)了一個(gè)Web搜索引擎的網(wǎng)頁(yè)搜集過(guò)程。在建立了一個(gè)基本的搜索引擎的框架以后，我們可以基于這個(gè)框架，實(shí)現(xiàn)一些我們自己設(shè)計(jì)的算法，比如如何更好的進(jìn)行Spider的調(diào)度，如何更好的進(jìn)行文檔的歸類，如何更好的理解用戶的查詢，用來(lái)使Web搜索引擎具有更好的智能性和個(gè)性化的特點(diǎn)。

posted @ 2006-11-11 21:37 Coolfiry 閱讀(471) | 評(píng)論 (0) | 編輯收藏

導(dǎo)航

常用鏈接

留言簿(4)

隨筆分類

隨筆檔案

Firend

Programing

搜索

最新評(píng)論

閱讀排行榜

評(píng)論排行榜

從LiveJournal后臺(tái)發(fā)展看大規(guī)模網(wǎng)站性能優(yōu)化方法

一、LiveJournal發(fā)展歷程

二、LiveJournal架構(gòu)現(xiàn)狀概況

三、從LiveJournal發(fā)展中學(xué)習(xí)