上周硅谷非常熱鬧，重大消息頻繁出現(xiàn)，其中包括了喬布斯因病休假，蘋果的恐怖財報等等。對于我們所關(guān)心的移動業(yè)界跟互聯(lián)網(wǎng)來說，Google 換帥是另外一個重量級消息。

Quora 上有一個討論串，題目是“Larry Page 上任之后，Google 的重點應(yīng)該是什么？”，討論相當活躍。我也在這里湊個熱鬧，談一談在我看來，Larry Page 應(yīng)該如何去改變 Google。

1：關(guān)注核心業(yè)務(wù)，也就是搜索

Google 前段時間在搜索結(jié)果上算是飽受攻擊，由于與日俱增的垃圾內(nèi)容，搜索結(jié)果的污染狀況越發(fā)嚴重。Stack Overflow 的創(chuàng)始人之一 Jeff Atwood 在一篇文章里這樣評價 Google 現(xiàn)在的搜索結(jié)果：

Google ，這個曾經(jīng)的必備工具，某種程度上已經(jīng)失去了它的優(yōu)勢地位。垃圾內(nèi)容制造者、以點擊率為終極目標的內(nèi)容聚合站點正在走向勝利。

在 這一點上來說，ifanr 感同身受。作為內(nèi)容提供者，我們是創(chuàng)造價值的人，是在給互聯(lián)網(wǎng)不斷添磚加瓦的一方。而之前在 Google 里搜索我們的原創(chuàng)文章，出現(xiàn)在結(jié)果最頂端的卻往往是是通過拷貝+粘貼、有時候還不注明出處進行轉(zhuǎn)載的內(nèi)容聚合站點。它們用毫無成本的方式奪取著應(yīng)該屬于原 作者的訪問量。

好在 Google 似乎已經(jīng)認識到了這一點。之前搜索質(zhì)量組的 Matt Cutts 表示他 們已經(jīng)意識到了垃圾內(nèi)容的增多，以及劣質(zhì)內(nèi)容聚合站點引發(fā)的不滿，并且會很快進行處理。從我今早的實驗來看，似乎 Google 已經(jīng)采取了措施，最近 ifanr 的原創(chuàng)文章都出現(xiàn)在首頁頭條。從根子上（點擊量帶來的經(jīng)濟利益）驅(qū)逐劣質(zhì)內(nèi)容聚合站點，對現(xiàn)代互聯(lián)網(wǎng)來說，確實是件好事

搜索，是 Google 的立身之本，從上周發(fā)布的財報來看，Google 收入的主要增長點仍然是在網(wǎng)站本身的業(yè)務(wù)。不斷改進搜索，添加新的搜索方式，才能保持和增強 Google 在這個領(lǐng)域的領(lǐng)導(dǎo)地位。后院不起火，才有在其他領(lǐng)域發(fā)展的資本。

這一條，是 Larry Page 上任以后最需要關(guān)注的。未來十年的搜索是什么樣子？如何提高內(nèi)容關(guān)聯(lián)性，改進使用體驗？怎么樣通過創(chuàng)新，把 Bing 等競爭對手遠遠甩開，對 Google 來說，至關(guān)重要。

2：在社交網(wǎng)絡(luò)方面另辟蹊徑

Google 在社交網(wǎng)絡(luò)方面的試探，到目前為止都是悲劇，坦率地說，我個人認為Google 已經(jīng)錯過了第一班社交網(wǎng)絡(luò)的列車。

作為新生事物的社交網(wǎng)絡(luò)，從一開始負載的是用戶虛擬交流的需求。

目 前的勝利者里面，F(xiàn)acebook 滿足了人們交流的愿望，利用網(wǎng)絡(luò)，表現(xiàn)了某種程度上真實的人與人關(guān)系，而大量互動元素的引入，則是模擬了現(xiàn)實生活的部分人際往來，從根底上來說，沒有理念 上的創(chuàng)新，然而它仍然足夠偉大，F(xiàn)acebook 把現(xiàn)實生活成功投影到了虛擬世界，是真正意義上的創(chuàng)造者。

另一個贏家是 Twitter，它滿足的，是人們表達自己的愿望。通過簡短的 140 個字，人與人之間形成了一種奇妙的交流關(guān)系，普通人也可以第一時間見證重大事件。可以說，Twitter 與智能手機的結(jié)合，創(chuàng)造了一種新媒體。表達自己，記錄周邊，關(guān)注別人，是 Twitter 類社交網(wǎng)絡(luò)的根本。無論是變種的 foursquare，還是 Quora，從理念上看，都是這樣的東西。

Google 之前的嘗試呢？ Wave 那個體驗一塌糊涂的東西不去說它，出生太早了；Buzz 則是無限制版本的 Twitter：Google 試圖利用現(xiàn)成的龐大用戶群，但沒有實質(zhì)性創(chuàng)新，再加上拙劣的整合方式，這個產(chǎn)品的前景樂觀不到哪兒去。

社交網(wǎng)絡(luò)走到現(xiàn)在，實際上已經(jīng)到了一個重要的關(guān)口，即：虛擬的內(nèi)容如何與現(xiàn)實社會結(jié)合起來，怎樣把線上關(guān)系與實體經(jīng)濟整合，創(chuàng)造出一個嶄新的商業(yè)模式。在我看來，這才是第二代社交網(wǎng)絡(luò)，也即成熟版本的社交網(wǎng)絡(luò)。這個方向是未來兩年的熱點，也是 Google 下一步可以突圍的角度。

Google 的最大優(yōu)勢是什么？大家應(yīng)該都非常清楚，其一是龐大的用戶群，其二就是信息了。Google 相對于 Twittter、fousquare 等來說，先天就有信息方面的優(yōu)勢。而 Google 在建設(shè)社交網(wǎng)絡(luò)的時候，卻完全忽略了這個優(yōu)勢，捆著手腳去從頭開始跟已經(jīng)成熟的對手競爭，怎么可能勝利？

舉個最簡單的例子，Google Maps 信息豐富，我經(jīng)常用它來尋找晚餐地點，最大的好處之一就是可以看到多個網(wǎng)站的用戶評價，看看截圖：

看 到了吧，有 Buzz 選項，然而搞笑的事來了。我可以看到其他網(wǎng)站的評價，可以在 Buzz 上分享這個地點，然后呢？沒了。我完全看不到 Buzz 關(guān)于這個餐館的討論，看不到我分享以后朋友的看法——一點也沒有。實體經(jīng)濟方面的內(nèi)容本身就是 Google 的長項，然而在它的任何產(chǎn)品里面，都沒有把這個長處跟自己的社交網(wǎng)絡(luò)更緊密得結(jié)合起來。

放著龐大的現(xiàn)實數(shù)據(jù)不用，幾個產(chǎn)品之間幾乎沒有交流，捧著金飯碗要飯，這就是 Google 的社交網(wǎng)絡(luò)。跟現(xiàn)實社會結(jié)合的社交網(wǎng)絡(luò)，將是 Google 在這一領(lǐng)域的最后一個機會。

3：細節(jié)，細節(jié)，還是細節(jié)

有一句老話，細節(jié)決定成敗，然而 Google 現(xiàn)在的很多做法，卻表現(xiàn)了一種對細節(jié)的漠視，極大影響了產(chǎn)品的使用體驗。還是要以 Android 為例（這玩意簡直就是反面教材）：

就從簡單的設(shè)置界面說起。Android 平鋪直敘的設(shè)置界面，完全沒有突出重點（我甚至懷疑這幫人安排順序的時候是不是拍腦門做出的決定。），跟右邊的 iOS 比，孰優(yōu)孰劣，一目了然。

還有應(yīng)用市場，每次談到 Android 的應(yīng)用市場，我都有爆粗口的沖動。緩慢的速度、時常丟失的已下載應(yīng)用列表、遲遲沒有解決的應(yīng)用無法下載問題……這是整個產(chǎn)業(yè)的核心之一，Google 就準備這么糊弄下去？

Android 不講究的地方何止這些，工程師文化并不代表著可以不拘小節(jié)，Google 的目光，應(yīng)該多放些在細節(jié)上。移動設(shè)備，用戶體驗至關(guān)重要。

4: 繼續(xù)擁抱云，下注新能源產(chǎn)業(yè)

在這個賣雜貨的、搞 B2C 的、做軟件的都在搞云應(yīng)用平臺的當口，互聯(lián)網(wǎng)界巨頭，擁抱云的先驅(qū)之一，可能擁有著世界上最好硬件以及網(wǎng)絡(luò)設(shè)施的 Google，當然也擁有自家的 App Engine。

云 計算平臺對于中小企業(yè)、個人的意義，無論如何贊揚也不會過分，它直接引領(lǐng)了當前的互聯(lián)網(wǎng)創(chuàng)業(yè)潮。低廉的平臺成本，按需付費的方式，Amazon EC2 吸引了大量的個人開發(fā)者，Google 的 App Engine 當然不錯，但我要說，還是不夠靈活，如果能提供更多語言支持，就再好不過了。

新能源很好理解，隨著碳交易市場的興起，碳排放量眼看就要變成金融市場上的一個新產(chǎn)品。在這個趨勢影響下，每個企業(yè)都應(yīng)該考慮下自己的能源來源，為將來更加嚴格的排放調(diào)控措施做好準備，規(guī)避可能的經(jīng)濟風(fēng)險。

降低所消耗能源的碳排放，對于 Google 這種能源消耗大戶來說，是經(jīng)濟跟政治上都很正確的方向，而且同樣有大量的利益存在。新能源產(chǎn)業(yè)，應(yīng)該成為 Google 下一步的重點投入方向。

5：提高決策速度與質(zhì)量，減少內(nèi)部溝通環(huán)節(jié)

大 家都知道 Google 著名的 20% 規(guī)則：員工可以把 20% 的上班時間放在其他項目上。Google 的員工無疑是優(yōu)秀的，這些業(yè)余時間做出的項目也應(yīng)該有很多不錯的點子，然而，從中孵化的成果卻并不多。其中的部分原因，恐怕與 Google 的內(nèi)部引導(dǎo)以及溝通機制存在很大的關(guān)系。由于缺乏引導(dǎo)，員工的項目往往與 Google 本身沒什么聯(lián)系，而因為溝通問題，好的項目不一定能夠獲得公司的幫助。

Google 的前員工遍布整個互聯(lián)網(wǎng)業(yè)界，大量創(chuàng)新卻往往出現(xiàn)在他們離開 Google 以后。應(yīng)該如何去引發(fā)員工的創(chuàng)造力、提高內(nèi)部效率跟執(zhí)行力度，Larry Page 需要仔細考慮，以便調(diào)整內(nèi)部架構(gòu)來適應(yīng)這個變化迅速的世界。三星這個反應(yīng)快到根本不像大公司的大公司在全世界攻城掠地，諾基亞反應(yīng)稍微遲緩一點就束手束 腳，Google，你要快一點，再快一點，才能跟 Facebook 以及數(shù)以千計的創(chuàng)業(yè)企業(yè)進行競爭。

轉(zhuǎn)自：http://www.oschina.net/news/14996/larry-page-google-five-things-todo

沒有人能說清哪種緩存算法優(yōu)于其他的緩存算法。（以下的幾種緩存算法，有的我也理解不好，如果感興趣，你可以Google一下）

Least Frequently Used（LFU）：

大家好，我是 LFU，我會計算為每個緩存對象計算他們被使用的頻率。我會把最不常用的緩存對象踢走。

Least Recently User（LRU）：

我是LRU緩存算法，我把最近最少使用的緩存對象給踢走。

我總是需要去了解在什么時候，用了哪個緩存對象。如果有人想要了解我為什么總能把最近最少使用的對象踢掉，是非常困難的。

瀏覽器就是使用了我（LRU）作為緩存算法。新的對象會被放在緩存的頂部，當緩存達到了容量極限，我會把底部的對象踢走，而技巧就是：我會把最新被訪問的緩存對象，放到緩存池的頂部。

所以，經(jīng)常被讀取的緩存對象就會一直呆在緩存池中。有兩種方法可以實現(xiàn)我，array 或者是 linked list。

我的速度很快，我也可以被數(shù)據(jù)訪問模式適配。我有一個大家庭，他們都可以完善我，甚至做的比我更好（我確實有時會嫉妒，但是沒關(guān)系）。我家庭的一些成員包括LRU2 和 2Q，他們就是為了完善 LRU 而存在的。

Least Recently Used 2（LRU2）：

我是 Least Recently Used 2，有人叫我最近最少使用twice，我更喜歡這個叫法。我會把被兩次訪問過的對象放入緩存池，當緩存池滿了之后，我會把有兩次最少使用的緩存對象踢走。 因為需要跟蹤對象2次，訪問負載就會隨著緩存池的增加而增加。如果把我用在大容量的緩存池中，就會有問題。另外，我還需要跟蹤那么不在緩存的對象，因為他 們還沒有被第二次讀取。我比LRU好，而且是 adoptive to access 模式 。

Two Queues（2Q）：

我是 Two Queues；我把被訪問的數(shù)據(jù)放到LRU的緩存中，如果這個對象再一次被訪問，我就把他轉(zhuǎn)移到第二個、更大的LRU緩存。

我踢走緩存對象是為了保持第一個緩存池是第二個緩存池的1/3。當緩存的訪問負載是固定的時候，把 LRU 換成 LRU2，就比增加緩存的容量更好。這種機制使得我比 LRU2 更好，我也是 LRU 家族中的一員，而且是 adoptive to access 模式 。

Adaptive Replacement Cache（ARC）：

我是 ARC，有人說我是介于 LRU 和 LFU 之間，為了提高效果，我是由2個 LRU 組成，第一個，也就是 L1，包含的條目是最近只被使用過一次的，而第二個 LRU，也就是 L2，包含的是最近被使用過兩次的條目。因此， L1 放的是新的對象，而 L2 放的是常用的對象。所以，別人才會認為我是介于 LRU 和 LFU 之間的，不過沒關(guān)系，我不介意。

我被認為是性能最好的緩存算法之一，能夠自調(diào)，并且是低負載的。我也保存著歷史對象，這樣，我就可以記住那些被移除的對象，同時，也讓我可以看到被移除的對象是否可以留下，取而代之的是踢走別的對象。我的記憶力很差，但是我很快，適用性也強。

Most Recently Used（MRU）：

我是 MRU，和 LRU 是對應(yīng)的。我會移除最近最多被使用的對象，你一定會問我為什么。好吧，讓我告訴你，當一次訪問過來的時候，有些事情是無法預(yù)測的，并且在緩存系統(tǒng)中找出最少最近使用的對象是一項時間復(fù)雜度非常高的運算，這就是為什么我是最好的選擇。

我是數(shù)據(jù)庫內(nèi)存緩存中是多么的常見！每當一次緩存記錄的使用，我會把它放到棧的頂端。當棧滿了的時候，你猜怎么著？我會把棧頂?shù)膶ο蠼o換成新進來的對象！

First in First out（FIFO）：

我是先進先出，我是一個低負載的算法，并且對緩存對象的管理要求不高。我通過一個隊列去跟蹤所有的緩存對象，最近最常用的緩存對象放在后面，而更早的緩存對象放在前面，當緩存容量滿時，排在前面的緩存對象會被踢走，然后把新的緩存對象加進去。我很快，但是我并不適用。

Second Chance：

大家好，我是 second chance，我是通過FIFO修改而來的，被大家叫做 second chance 緩存算法，我比 FIFO 好的地方是我改善了 FIFO 的成本。我是 FIFO 一樣也是在觀察隊列的前端，但是很FIFO的立刻踢出不同，我會檢查即將要被踢出的對象有沒有之前被使用過的標志（1一個bit表示），沒有沒有被使用 過，我就把他踢出；否則，我會把這個標志位清除，然后把這個緩存對象當做新增緩存對象加入隊列。你可以想象就這就像一個環(huán)隊列。當我再一次在隊頭碰到這個 對象時，由于他已經(jīng)沒有這個標志位了，所以我立刻就把他踢開了。我在速度上比FIFO快。

CLock

我是Clock，一個更好的FIFO，也比 second chance更好。因為我不會像second chance那樣把有標志的緩存對象放到隊列的尾部，但是也可以達到second chance的效果。

我持有一個裝有緩存對象的環(huán)形列表，頭指針指向列表中最老的緩存對象。當緩存miss發(fā)生并且沒有新的緩存空間時，我會問問指針指向的緩存對象的標 志位去決定我應(yīng)該怎么做。如果標志是0，我會直接用新的緩存對象替代這個緩存對象；如果標志位是1，我會把頭指針遞增，然后重復(fù)這個過程，知道新的緩存對 象能夠被放入。我比second chance更快。

Simple time-based：

我是 simple time-based 緩存算法，我通過絕對的時間周期去失效那些緩存對象。對于新增的對象，我會保存特定的時間。我很快，但是我并不適用。

Extended time-based expiration：

我是 extended time-based expiration 緩存算法，我是通過相對時間去失效緩存對象的；對于新增的緩存對象，我會保存特定的時間，比如是每5分鐘，每天的12點。

Sliding time-based expiration：

我是 sliding time-based expiration，與前面不同的是，被我管理的緩存對象的生命起點是在這個緩存的最后被訪問時間算起的。我很快，但是我也不太適用。

好了！聽了那么多緩存算法的自我介紹，其他的緩存算法還考慮到了下面幾點：

• 成本。如果緩存對象有不同的成本，應(yīng)該把那些難以獲得的對象保存下來。
• 容量。如果緩存對象有不同的大小，應(yīng)該把那些大的緩存對象清除，這樣就可以讓更多的小緩存對象進來了。
• 時間。一些緩存還保存著緩存的過期時間。電腦會失效他們，因為他們已經(jīng)過期了。

根據(jù)緩存對象的大小而不管其他的緩存算法可能是有必要的。

原文：http://www.zavakid.com/27

提交 B3log Solo（運行在 GAE/J 上的博客程序） 代碼后發(fā)現(xiàn) Google Code 版本控制系統(tǒng)會將提交日志同步發(fā)布到 Google Buzz 中：

但在 Buzz connected sites 里并沒有看到與 Google Code 關(guān)聯(lián)：

現(xiàn)在一提交代碼就 Buzz，還是比較無奈的....

有時我們需要隨機地獲取數(shù)據(jù)記錄（實體），比如博客程序中的“隨機文章”的實現(xiàn)。

目前 GAE 并沒有 API 可以直接獲取隨機實體，要實現(xiàn)這樣的需求我們只能自己想辦法了 :-)

在 stackoverflow 上也有人提過該問題，總結(jié)如下：

• Generate and store a random number on your entities as you create them, then pick a random number and look (via a query) for the closet record(s) to it.
• Implement some mechanism to ensure your entity ids are "densely" populated, then fetch within the known range using keys.
• Periodically generate random lists of the entities and return entities from those lists. This may take the form of a stack that entities are popped off of, or as actual lists that are returned.

目前 B3log Solo 在處理“隨機閱讀”上采用的是方法一，即在每個文章實體上添加一個屬性保存 0-1 的隨機浮點數(shù)。

在獲取隨機文章時生成一個 0-1 的隨機數(shù)（mid）作為查詢條件，以此查詢條件作為邊界（0 <= mid <=1）來過濾實體保存的隨機值屬性。

這個方法基本可以達到隨機的效果了，為了讓隨機的效果更動態(tài)一點，我們可以考慮經(jīng)常更新文章實體中的隨機浮點值：

• 訪問文章時（即在更新文章瀏覽次數(shù)時一并更新該文章的隨機浮點值）
• 后臺定時任務(wù)（獲取一定數(shù)量的隨機文章然后更新它們的隨機浮點值）
• 用戶做文章更新時

加上以上處理后，隨機的效果比較好了 :-)

作者 榮浩 發(fā)布于 2010年12月28日 上午12時0分

對jBPM來說，今年最大的事件莫過于jBPM的創(chuàng)建者Tom Baeyens離開JBoss了。Tom Baeyens離開的具體原因尚不清楚，但他的離開產(chǎn)生了兩個結(jié)果：一是jBPM的下一個版本jBPM5完全放棄了jBPM4的基礎(chǔ)代碼，基于Drools Flow重頭來過；二是Tom Baeyens加入Alfresco后很快推出了新的基于jBPM4的開源工作流系統(tǒng)Activiti。 由此不難推測Tom Baeyens離開的部分原因：JBoss內(nèi)部對jBPM未來版本的架構(gòu)實現(xiàn)產(chǎn)生了嚴重的意見分歧。更加巧合的是12月1日Activiti5剛發(fā)布，緊 接著12月2日jBPM5就發(fā)布了第一個候選發(fā)布版本，jBPM與Activiti之間的微妙關(guān)系可見一般。

在這篇文章里，我們將一起回顧jBPM從jBPM3到j(luò)BPM5以及Activiti5的發(fā)展歷程，我們可以清晰的看見jBPM（包括 Activiti）設(shè)計所遵循的一致原則：強調(diào)流程服務(wù)的可嵌入性和可擴展性。同時，從各個版本之間的變化我們也能看見產(chǎn)品設(shè)計思路的變化：更加強調(diào)面向 業(yè)務(wù)人員，增加BPMS（業(yè)務(wù)流程管理系統(tǒng)）特性。

在回顧之前，我們首先討論一下BPMS應(yīng)該嵌入還是獨立部署的問題，因為不管是jBPM還是Activiti，都強調(diào)了流程服務(wù)的可嵌入性。此外，我們還需要討論一下什么是BPMS的特性，它們所解決的問題是什么。

一、嵌入式還是獨立部署？

不管是jBPM還是Activiti，都強調(diào)了流程服務(wù)的可嵌入性。Tom Baeyens在其個人博客里稱作為獨立部署的BPMS已死，原因有兩個：一是獨立部署的BPMS需要很高的安裝使用成本，需要獨立部署、需要用戶支出大 量的培訓(xùn)成本和維護成本；二是獨立部署的BPMS與外部系統(tǒng)的交互方式是分布式，這使得很多問題變得復(fù)雜，例如分布式事務(wù)。Tom Baeyens代表了相當一部分人特別是開發(fā)人員的觀點。

Tom Baeyens沒有完全理解BPMS。什么是BPMS？BPMS最重要的目標就是需要打破各個應(yīng)用系統(tǒng)（CRM、ECM、ERP、SCM）之間的界線，將 分散在這些系統(tǒng)中的流程集中管理，這是BPMS的實質(zhì)。一如流程再造，打破各個部門之間的壁壘，減少浪費，建立流程驅(qū)動性的組織。如下圖1所示：

圖 1：BPMS打破應(yīng)用系統(tǒng)之間的界線

BPMS所要解決的問題要求其必然是獨立部署的。Tom Baeyens錯誤的根本原因在于其將BPMS與工作流系統(tǒng)的定義混為了一談，他如此定義BPMS：BPMS旨在簡化對組織核心流程進行支撐的軟件創(chuàng)建。 也就是BPMS面向的是軟件開發(fā)人員，旨在簡化他們的開發(fā)，降低他們使用流程的門檻。而這正是工作流系統(tǒng)需要解決的問題。

BPMS面向企業(yè)用戶，工作流面向開發(fā)社區(qū)和系統(tǒng)集成商。

二、BPMS特性

jBPM4、jBPM5和Activiti5都增加了其BPMS特性，那些特性能夠稱為BPMS特性呢？我們先看一看BPMS需要解決的問題，為解決這些問題所增加的特性就是BPMS特性。

1. 如何設(shè)計流程，在組織中高效地對設(shè)計出的流程進行溝通，取得共識？

   • 提供跨越組織的流程標準標記符號與術(shù)語（BPMN已經(jīng)成為標準）
   • 流程及相關(guān)文檔的可視化（流程/內(nèi)容存儲倉庫）
   • 提供在組織結(jié)構(gòu)內(nèi)進行不同層次之間的流程導(dǎo)航（流程存儲倉庫支持組織模型）
   • 流程定義在各個層次/部門間的一致性，避免業(yè)務(wù)人員的流程建模轉(zhuǎn)換到IT系統(tǒng)時受到損耗（流程引擎支持基于圖的建模，支持擴展）

2. 如何更好地執(zhí)行流程？

   • 業(yè)務(wù)活動的實時監(jiān)控，預(yù)警與控制（BAM）
   • 流程執(zhí)行的仿真
   • 流程執(zhí)行的統(tǒng)計分析與反饋（報表）
3. 如何更好地管理流程？
   • 打破各個應(yīng)用系統(tǒng)之間的界線，統(tǒng)一管理所有流程（EAI，與ESB的集成）
   • 對業(yè)務(wù)人員友好的建模工具
4. 如何在執(zhí)行流程過程中遵循業(yè)內(nèi)最佳實踐和規(guī)則？
   • 面向流程的知識管理
   • 規(guī)則引擎

三、完整的工作流實現(xiàn)jBPM3

jBPM3的最新版本是3.2.7，其包括了以下組件：基于Eclipse的流程設(shè)計器、用于監(jiān)控案例（流程實例）和處理任務(wù)的Web控制臺以及jPDL核心庫。如下圖2所示：

圖 2：jBPM3組件

1. 基于Eclipse的流程設(shè)計器

   提供給開發(fā)人員繪制jPDL流程圖，因為該設(shè)計器基于Eclipse，所以生成的流程文件可以與開發(fā)代碼一起組織管理，非常容易進行單元測試。實現(xiàn)了工作流管理系統(tǒng)參考模型里的接口1。

2. Web管理控制臺

   主要有兩個功能：一是作為工作流客戶端應(yīng)用接口，給用戶提供一種手段，以處理案例運行過程中需要人工處理的任務(wù)；二是對案例的狀態(tài)進行監(jiān)控與管理。實現(xiàn)了工作流管理系統(tǒng)參考模型里的接口2和5。

3. jPDL核心庫

   jPDL核心庫是一個單獨的JAR包，可以嵌入到目標應(yīng)用中執(zhí)行，它包括了：

   • 流程倉庫：解析jPDL流程定義文件并存儲讀取；
   • 流程引擎：對流程定義進行初始化和調(diào)度執(zhí)行，節(jié)點的運行期行為與jPDL里定義的節(jié)點類型一一綁定；
   • 任務(wù)管理：生成任務(wù)節(jié)點所對應(yīng)的工作項，管理工作項的生命周期（初始化、分配執(zhí)行者、執(zhí)行、掛起、結(jié)束、終止）；
   • 事件管理：發(fā)布案例和任務(wù)的開始、結(jié)束事件，通過監(jiān)聽者模式調(diào)用相應(yīng)的事件處理器；
   • 異步執(zhí)行機制：通過線程實現(xiàn)了Job Executor，進行異步工作的處理，這些工作包括了時間處理、異步動作。
   • 身份組件模型：實現(xiàn)了一套簡單的身份組件模型，包括了組、用戶和權(quán)限。

   通過調(diào)用自定義Java代碼實現(xiàn)了對外部應(yīng)用的調(diào)用，從而實現(xiàn)工作流管理系統(tǒng)參考模型里的接口3。

jBPM3是一個輕量級的嵌入式工作流系統(tǒng)。它在Java社區(qū)的成功得益于兩個方面：一是嵌入式，這降低了使用工作流的門檻；二是對開發(fā)人 員友好，這表現(xiàn)在易讀的jPDL、流程的可測試性(Eclipse插件)以及節(jié)點行為的可擴展性，我們可以非常容易的在流程運行中加入自己定制的行為（通 過事件處理器和Action）。jBPM3面向開發(fā)人員，它解決的問題是流程的自動化，它的影響力集中在Java開發(fā)社區(qū)，是一個完整的工作流系統(tǒng)實現(xiàn)。

四、向BPMS努力的jBPM4

與jBPM3相比，jBPM4最大的變化是引入了流程虛擬機（PVM），同時增加了BPMS的特性。jBPM4不再滿足于工作流系統(tǒng)的定位，開始向BPMS努力。

1. 為什么引入流程虛擬機

   盡管jBPM3在Java社區(qū)取得了很大的成功，但是有一件事始終被人們詬病，那就是它不支持流程語言規(guī)范，從最開始的XPDL、BPEL 到后來的BPMN，它采用了自定義的jPDL。在jBPM3中，節(jié)點的運行期行為與jPDL里定義的節(jié)點類型是一一綁定的，這造成了流程引擎與特定流程語 言的綁定，要支持其他的流程語言變得困難。于是在jBPM4中，jBPM提出了流程虛擬機的概念，即流程引擎與流程語言解耦，通過一套通用的流程模型并配 以可定制的節(jié)點運行期行為實現(xiàn)了對多流程語言的支持。

   流程虛擬機帶來的好處是多方面的：第一也是最重要的是jBPM4支持了BPMN。

   第二是實現(xiàn)了基于流程組件的流程引擎，流程圖(語言)與實現(xiàn)解耦，我們使用通用編程語言實現(xiàn)節(jié)點運行期行為，稱之為流程組件，通過將流程圖 與流程組件掛接，避免了圖的損耗。在這一點上，Tom Baeyens對BPMN到BPEL的轉(zhuǎn)換提出了一針見血的批評：BPMN和jPDL以及XPDL都是基于圖的，而BPEL是基于塊的，這造成了當將業(yè)務(wù) 人員使用BPMN所建立的流程模型向BPEL執(zhí)行模型進行轉(zhuǎn)換時，出現(xiàn)許多的不匹配，最初的流程模型會扭曲變形。而扭曲的后果就是業(yè)務(wù)人員與開發(fā)人員之間 的協(xié)作困難，這影響了流程從業(yè)務(wù)到技術(shù)的實現(xiàn)。

   第三個好處是我們可以定義領(lǐng)域特定語言（DSL），在特定的應(yīng)用里，采用DSL約定并隱藏了大部分的技術(shù)細節(jié)可能做到業(yè)務(wù)人員對執(zhí)行流程的直接修改，例如企業(yè)文檔管理里的審批流程。

2. BPMS特性的加入

   這表現(xiàn)在以下三個方面：第一是支持了BPMN，BPMN已經(jīng)成為業(yè)務(wù)人員的流程建模標準；第二是引入了Signavio作為面向業(yè)務(wù)人員的Web建模器；第三是在已有的Web管理控制臺加入了對案例和任務(wù)的統(tǒng)計功能。jBPM4的組件如下圖3所示：

   

   圖3：jBPM4組件

   和jBPM3一樣，jBPM4依然是輕量級的、可嵌入的工作流系統(tǒng)。相比jBPM3，它將業(yè)務(wù)人員作為最終用戶之一，增加了部分BPMS特性，同時PVM的引入使得它的可擴展性得到了極大的增強，我們甚至可以定義自己的DSL。

   在BPMS特性里我們提到了應(yīng)該避免業(yè)務(wù)人員的流程建模轉(zhuǎn)換到IT系統(tǒng)時受到損耗，最理想的情況是業(yè)務(wù)人員與開發(fā)人員共用一個流程模型，業(yè) 務(wù)人員能夠直接對流程進行調(diào)整（在特定應(yīng)用中，通過DSL是可以做到的）；其次是通過BPMS將業(yè)務(wù)人員的模型與實際執(zhí)行的技術(shù)模型關(guān)聯(lián)起來（很多商業(yè)產(chǎn) 品已經(jīng)做到了這一點，在Activiti5中我們也會看到這一點），業(yè)務(wù)人員、開發(fā)人員以及運營團隊之間能夠做到很好的協(xié)調(diào)；最差是業(yè)務(wù)人員與開發(fā)人員各 自為政，獨立維護各自的流程模型，并且模型之間存在極大的不匹配，此時流程的迅速變化基本上是奢望。

五、鳩占鵲巢的Drools Flow與jBPM5

目前jBPM5剛剛發(fā)布了第一個候選發(fā)布版本，jBPM5基本上完全拋棄了jBPM4的代碼，所有代碼全部來自原先的Drools Flow。Drools Flow最初被用來解決規(guī)則執(zhí)行順序的問題。其實從Drools Flow開始支持BPMN時起，我們已經(jīng)預(yù)感到它與jBPM的競爭關(guān)系。

jBPM5依舊定位為輕量級的可嵌入的工作流系統(tǒng)。在jBPM5的特性里，有這么兩條引人關(guān)注：一是引入了Guvnor作為流程倉庫，這解決了流程 的可視化問題，流程定義作為資源被管理，我們可以對流程定義進行可視化管理以及全文檢索（Guvnor使用了Jackrabbit作為了其存儲實現(xiàn)，但我 們的經(jīng)驗表明Jackrabbit在大數(shù)據(jù)量情況下性能存在嚴重問題）；第二是規(guī)則引擎(Drools Expert)、事件處理引擎(Drools Fusion)與流程引擎的合三為一，這是jBPM5最讓人期待的地方。jBPM5的組件如下圖4所示：

圖 4：jBPM5組件

規(guī)則引擎在流程中的應(yīng)用已經(jīng)非常廣泛了，我們這里說說事件處理引擎。

事件處理引擎是業(yè)務(wù)活動監(jiān)控（BAM）的基礎(chǔ)，BAM的功能及執(zhí)行過程，如下：

• 捕獲：BAM捕獲各種事件（通過消息監(jiān)聽器、適配器、代理等）。這些事件來自應(yīng)用、系統(tǒng)軟件、外部交易伙伴。消息是BAM的核心——它們反應(yīng)底層業(yè)務(wù)流程的狀況。
• 過濾：BAM過濾掉沒有直接后果的事件，在很多情況下由支持事件流處理（Event Stream Processing，簡稱ESP）或復(fù)雜事件處理（Complex Event Processing，簡稱CEP）引擎來進行過濾。
• 分析：BAM根據(jù)分析模型和規(guī)則將相關(guān)事件聯(lián)系起來。
• 警告：BAM向用戶提出警告，以便用戶在必要時進行控制。

如上所示，BAM的執(zhí)行過程包含四個步驟，而前三個步驟都是對事件進行相關(guān)的處理（捕獲事件、過濾事件、分析事件、關(guān)聯(lián)事件），因此在大多數(shù)BAM的技術(shù)實現(xiàn)方案中，都基于CEP和ESP的引擎來實現(xiàn)BAM的功能。

與jBPM4相比，jBPM5對PVM的放棄也帶來了幾個不小的問題：第一是對開發(fā)人員來說只支持BPMN，不再支持jPDL（當然提供了遷移工 具）；第二是流程執(zhí)行的可擴展性回到了jBPM3的年代，僅僅支持自定義動作（相當于jBPM3里的Action）。此外，Web建模器由 Signavio替換為了Oryx Designer。

總而言之，jBPM5通過引入流程倉庫和BAM繼續(xù)向BPMS邁進（目前的進展是與流程倉庫的集成還未完成，BAM基于日志進行分析），同時，由于不再支持PVM和jPDL，帶來了流程擴展性的降低和社區(qū)開發(fā)人員的未來流失。

六、Activiti5的反擊

Activiti5是Tom Baeyens加入Alfresco后推出的新的基于jBPM4的開源工作流系統(tǒng)，1號剛剛發(fā)布第一個版本。Activiti的開發(fā)團隊相比與jBPM強 大了許多，有23位核心開發(fā)者。當然這也是由于activiti規(guī)劃的功能所致：包括核心引擎、Web的流程建模器、協(xié)作工具Activiti Cycle、Activiti Probe、Activiti Explorer、與Spring的集成、與Mule的集成等。

圖 5：Activiti5的組件

如上圖所示，Activiti5由三種類型的組件組成，分別是：專用工具（Dedicated Tools）、內(nèi)容存儲工具（Stored Content）和協(xié)作工具（Collaboration Tool）。

專用工具包括以下：

• Alfresco—Alfresco公司的企業(yè)級內(nèi)容管理產(chǎn)品

Alfresco 是一個開源的、企業(yè)級的內(nèi)容管理系統(tǒng)，功能包括：文檔管理、協(xié)作、記錄管理、知識庫管理、Web內(nèi)容管理等功能。Alfresco與Activiti的深 入集成實現(xiàn)了流程及相關(guān)文檔的可視化。更重要的是Alfresco支持組織模型，能夠提供在組織結(jié)構(gòu)內(nèi)進行不同層次之間的流程導(dǎo)航。

• Activiti Modeler—建模器

基于開源Signavio Web流程編輯器的一個定制版本，提供了對BPMN2.0圖形化規(guī)范的支持，建模后的流程以文件格式進行存儲。

• Activiti Designer—Eclipse插件形式的建模器
• Activiti probe—管理及監(jiān)控組件

對流程引擎運行期實例提供管理及監(jiān)控的Web控制臺。包含部署的管理、流程定義的管理、數(shù)據(jù)庫表的檢視、日志查看、事務(wù)的平均執(zhí)行時間、失敗多次的工作等功能。

• Activiti Explorer—任務(wù)管理組件

提供任務(wù)管理功能和對案例、任務(wù)基于歷史數(shù)據(jù)的統(tǒng)計分析（報表）功能。Web應(yīng)用程序。

內(nèi)容存儲工具：包括了文檔倉庫、模型倉庫、SVN倉庫、MVN倉庫和Activiti引擎。其中文檔倉庫、SVN倉庫和MVN倉庫三個組件為協(xié)作工具（Activiti Cycle）提供底層的支撐。Activiti引擎則是以前的PVM。

協(xié)作工具：與jBPM4相比，Activiti5最令人矚目的特性就在于它的協(xié)作工具組件。

Activiti Cycle完全是一種新類型的BPM組件。它是一個用來促進業(yè)務(wù)人員、開發(fā)人員和IT運營人員協(xié)作的Web應(yīng)用程序。 在現(xiàn)實的場景中，業(yè)務(wù)文檔有業(yè)務(wù)人員所持有，而軟件程序由開發(fā)團隊所管理，被部署的軟件應(yīng)用則被IT管理人員所管理。三者之間不能很好的協(xié)作。我們可以想 象這樣一個場景，業(yè)務(wù)經(jīng)理用文檔來維護需求和visio格式的流程圖，開發(fā)人員管理可執(zhí)行的流程和大量的Java源文件而IT維護人員則管理部署在 Tomcat中的.war文件和存儲在Activiti數(shù)據(jù)庫中的流程。

圖 6：Activiti cycle協(xié)作組件邏輯示意圖

Activiti Cycle通過BusinessLink將與流程相關(guān)的業(yè)務(wù)人員、開發(fā)團隊與IT維護人員關(guān)聯(lián)起來，實現(xiàn)他們之間的協(xié)作。

總而言之，與jBPM4相比，Activiti5目前最重要的增強就是實現(xiàn)了流程的可視化以及創(chuàng)新的Activiti Cycle協(xié)作組件，此外，通過與Mule的集成加強了其集成能力。其對PVM的保留使其繼承了jBPM4強大的可擴展能力，對jBPM的老用戶來說，這是向其遷移的重要理由。

七、總結(jié)

jBPM3是一個完整的工作流系統(tǒng)實現(xiàn)，面向開發(fā)人員，目的在于簡化對組織核心流程進行支撐的軟件創(chuàng)建，不支持標準。

jBPM4引入PVM，使其擁有更強大的擴展性，同時增加BPMS特性，這些特性包括了對BPMN的支持、面向業(yè)務(wù)人員的Web建模器和簡單統(tǒng)計分析功能的加入。

jBPM5基于原先的Drools Flow，支持BPMN，通過與Drools的合并支持BAM，通過內(nèi)容倉庫增加對流程可視化的支持。由于放棄了jBPM4的PVM，引擎的可擴展性受到損害，并且不再支持jPDL。

Activiti5基于jBPM4，與Alfresco的集成增加了其流程可視化與管理能力，同時通過創(chuàng)新的Activiti Cycle協(xié)作組件支持流程相關(guān)人員之間的協(xié)調(diào)，最后，它加強了集成能力。

對于工作流應(yīng)用或者jBPM3、jBPM4的老用戶，建議轉(zhuǎn)向Activiti5。

關(guān)于作者

榮浩，ThoughtWorks咨詢師，關(guān)注敏捷和企業(yè)流程改進過程，目前正與辛鵬合著《Head First Process-深入淺出IT流程》一書。博客地址http://ronghao.javaeye.com。

轉(zhuǎn)自：http://www.infoq.com/cn/articles/rh-jbpm5-activiti5

有很多理由都能說明為什么我們應(yīng)該寫出清晰、可讀性好的程序。最重要的一點，程序你只寫一次，但以后會無數(shù)次的閱讀。當你第二天回頭來看你的代碼 時，你就要開始閱讀它了。當你把代碼拿給其他人看時，他必須閱讀你的代碼。因此，在編寫時多花一點時間，你會在閱讀它時節(jié)省大量的時間。

讓我們看一些基本的編程技巧：

1. 盡量保持方法簡短
2. 永遠永遠不要把同一個變量用于多個不同的目的
3. 使用自描述的變量名和方法名
4. 盡可能的把變量定義在靠近使用它的地方
5. 拒絕神秘數(shù)字
6. 友好的對待你的語言
7. 不要逆常規(guī)而行
8. 警惕過早優(yōu)化
9. 積極重構(gòu)測試過的程序
10. 不要過度沉迷于技巧
11. 通過習(xí)例學(xué)習(xí)新知

現(xiàn)在，讓我們把每個小點展開來詳細講一下。

1. 盡量保持方法簡短

盡管很多人都遵循這個規(guī)則，但它仍然非常的重要。你寫的方法要始終能在一個屏幕里放得下。如果你需要去滾動屏幕，這會分散你的注意力，而且你看不到 整個的上下文。最佳長度是5-20行，這根據(jù)你的情況而定。當然，getters/setters 通常是一行代碼的方法，但與其說它們是真正的方法，不如說它們只是存取工具。

2. 永遠永遠不要把同一個變量用于多個不同的目的

一個變量應(yīng)該始終只為一個目的服務(wù)。通過使變量常量化(C++里的const， Java里的final)，使得編譯器能夠優(yōu)化編譯，而且使你的代碼醒目表達這個變量是不能改變的，你的程序的可讀性會變得更好。

3. 使用自描述的變量名和方法名

你的代碼應(yīng)該，對于任何人來說，只要看一眼就能知道是干嘛的。盡量不要用簡寫方式，除非有特殊的習(xí)慣，就像下面的：

 src - source
 pos - position
 prev - previous

如果你認為描述性的名稱并不是那么有價值，請對比一下n, ns, nsisd 和 numTeamMembers, seatCount, numSeatsInStadium。

4. 盡可能的把變量定義在靠近使用它的地方

蓋房子時，你可不希望把錘子放到別人的院子里。你希望把它們放的離手頭越近越好。定義變量也是同樣的道理。

int foo = 3;
int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

baz(foo);

這段代碼可以簡單的重構(gòu)成

int bar = 5;
// 一大段使用“bar”的代碼，
// 但沒用到“foo”
// ...

int foo = 3;
baz(foo);

當你把變量的聲明和第一次用到它的地方間隔太遠時(距離超過一個屏幕)，這確實會成為一個問題。記住上下文關(guān)系會變得困難，你需要滾動屏幕去找哪來的這個變量。

5. 拒絕神秘數(shù)字

當你要把什么東西跟一個常量值做比較時，記得把這個值定義成常量。沒有什么會比去猜測你的同事寫的這樣的代碼更讓人頭疼的事了：

il < 4384

換個形式感覺如何？

inputLength < MAX_INPUT_LENGTH

6. 友好的對待你的語言

學(xué)習(xí)新語言是一種很有樂趣的事情，你能學(xué)到一種新的完成任務(wù)的途徑。當一個對一種語言已經(jīng)很專業(yè)的人去學(xué)習(xí)另一種語言時，會出現(xiàn)一種很大的負面效應(yīng)。比如說你是一個Java開發(fā)者，試圖去學(xué)習(xí)Ruby。你應(yīng)該學(xué)會用Ruby的方式解決問題，而不是沿用Java的解決問題的思想。

當你需要重復(fù)5遍”Hello world！“時，在Java里，你可能會這樣做：

for (int i = 0; i < 5; i++) {
    System.out.println("Hello world!");
}

在Ruby里，你也許會禁不住這樣寫：

for i in (0..5)
  puts "Hello world!"
end

這樣看起來沒問題，但有一個更好的方式：

5.times { puts "Hello world!" }

7. 不要逆常規(guī)而行

每種語言都有自己不同的習(xí)俗約定。一般來說，人們聽的最多的是Java的編碼規(guī)范。讓我們看看其中的一些習(xí)俗規(guī)范：

• 方法名應(yīng)該小寫字母開頭，其后用字母大寫的單詞連接(veryLongVariableName)
• 類名應(yīng)該都使用首字母大寫的單詞連接而成
• 常量名應(yīng)該全部大寫，用下劃線連接(MY_CONSTANT)
• 左大括號應(yīng)該跟 if 語句在同一行

只有在有必要的理由時才去打破這些常規(guī)，不要輕易的因為你不高興就違反它。如果你只是在團隊里改變一些這樣的習(xí)慣，那也沒問題，但當把你代碼拿出來和其他的沒有這些思想準備的程序員共享時，問題就會來了。

8. 警惕過早優(yōu)化

過早優(yōu)化是所有問題的根源，至少電視上是這么說的 … 你第一應(yīng)該關(guān)心的事情是寫出易于理解的代碼。起初寫的程序不要求快。除非你的程序很慢，否則談優(yōu)化都是為時太早。如果你想優(yōu)化什么東西，你首先需要知道問題出在哪。這就是我們需要profilers這個工具的原因。

在沒有知道問題在哪的情況下試圖對程序進行優(yōu)化，其結(jié)果必然是把程序能壞，至少你的代碼會喪失可讀性。如果你覺得有些地方很慢，不要盲目的重寫代碼，你應(yīng)先找到慢的證據(jù)。

不要傻乎乎的去解決根本不存在的問題。

9. 積極重構(gòu)測試過的程序

沒有任何東西會是完美的。即使你感覺你真正寫出了一段完美的代碼，幾個月后回頭再看看，你可能會驚訝道”怎么會這樣傻？“

改進程序的一個好方法就是重構(gòu)，但要等程序測試通過之后。你首先要確保程序是好的可運行的，你可以通過自動化測試或手工測試完成這個工作。

之初，你需要的是程序可用。不要期望在第一次就寫出完美的程序，你只需要把它寫出來，可用。然后重構(gòu)它，使之完美。對于你們當中知道測試驅(qū)動開發(fā) (TDD)的人來說，對這個會很熟悉。這里的關(guān)鍵就在于你要習(xí)慣于重構(gòu)這種事情。如果你使用的是像IntelliJ IDEA這樣強大的集成開發(fā)工具的話，重構(gòu)的工作會變得簡單的多。

重構(gòu)之后，你也許會弄出一些Bug，導(dǎo)致某些功能出問題。這就是為什么說寫自動化測試的原因。不論何時重構(gòu)后，只要運行一下所有的測試用例，你就能準確的知道什么地方出了問題。

10. 不要過度沉迷于技巧

當我第一次讀到有關(guān)設(shè)計模式的知識時，我覺得我找到了圣杯。這些精心設(shè)計的思想作用顯著，它能使你的設(shè)計易于理解，因為你可以簡單的說”我使用的是 ‘觀察器模式’“，而不用從頭到尾的解釋一遍。那么，有問題嗎？一切看起來都這么自然、簡單，你開始不論在哪都使用設(shè)計模式。為什么不把這個類做成 singleton呢？干嘛不去再創(chuàng)建一些工廠類呢？

于是一個80行就能寫完的腳本，你最終使用了10個類，15個接口，外加一大堆范式和標記符。97%的代碼不做任何事情。設(shè)計模式是一種十分有用的用來簡化你的設(shè)計的工具，但這不意味著你該在所有能用到的地方都用它。你應(yīng)該用它們，但不能濫用。

11. 通過習(xí)例學(xué)習(xí)新知

編程是一種學(xué)習(xí)新知的過程。當你學(xué)到了新的程序庫或新語言，你可能會迫不及待的丟掉舊的代碼，用你新學(xué)到的東西重新寫一遍。有很多的理由都能說明你不該這么做。

往現(xiàn)有的應(yīng)用里增加新的類庫或框架同屬于這種情況。就說你寫了一個Javascript的web應(yīng)用，期間，你發(fā)現(xiàn)了jQuery。現(xiàn)在你突然急切的想丟到你的Javascript程序，重新用jQuery寫，盡管你還從來沒用過它。

最好的方式是你先用jQuery寫一些簡單的例子，通過這種方式把你在應(yīng)用里將要用到的知識都學(xué)會。需要AJAX？在你的項目之外做一些小例子，當完全弄懂了后，丟掉例子，應(yīng)用到你的產(chǎn)品里。

如果你非常關(guān)注編程技術(shù)，我強烈的推薦你閱讀Steve McConnell寫的 《代碼大全》 一書。它會永遠的改變你對編程的認識。:)

[英文出處]：11 tips for better code

[譯文來源]：外刊IT評論

“我說我是警察，也是執(zhí)法 人員，應(yīng)該文明執(zhí)法，但還是被打斷腿！”昨天，躺在病床上，昆明市 公安局民警張俊(化名)說起事發(fā)當天的情形時，依然有些憤怒！當天他接到母親的電話，說轄區(qū)城管要強行拆除小區(qū)內(nèi)的違章建筑，讓他回家收拾東西。不料，張 俊剛到門口表明自己身份時，卻遭到拆遷執(zhí)法人員的圍毆。據(jù)小區(qū)目擊者稱，張俊被毆打時，對方揚言“打的就是警察！”。

“我還以為身上有警械，就能夠證明自己身份。”昨天下午，在解放軍昆明總醫(yī)院骨科住院部，記者見到了被打傷的張俊，他向記者講述了事發(fā)經(jīng)過。

“我是警察，也是執(zhí)法人員。”張俊說，為了阻止自己被繼續(xù)毆打，他一邊表明自己的身份，一邊準備從身上掏證件。慌忙中，張俊只摸到了自己隨身攜帶的一根伸縮警棍，這一摸不要緊，更是遭了對方一頓暴打。

當 時現(xiàn)場執(zhí)法人員叫張俊放下警棍，然后將他的警棍拿走。張俊說，第一次被打之后，自己的鼻子和嘴角已經(jīng)被打出血了。但噩運還沒有結(jié)束，之后，他被4名城管反 綁著雙手押到鄰居家的門前。他再次向執(zhí)法人員提出要回家收拾東西，但沒有人理他。聽到他的反復(fù)要求后，一名執(zhí)法人員轉(zhuǎn)頭對他說：“你拿警棍打我，怎么可能 讓你上去。”張俊表示，他拿出警棍根本沒有打到人。“我是市公安局的，也是執(zhí)法者，執(zhí)法要文明。”張俊說完時就聽到對方一句狂噴：“你敢用手指頭指我，兄 弟們，拿下。”

張俊說，他只感覺周圍的20多名城管全部圍了上來，用警棍和鐵棍將他打倒在地，還有人上前用腳踩他。當時他感覺自己的右腿很疼，他大聲懇求：“求求你們別打了，我的腿斷了。”隨后，他被打暈在地。

現(xiàn) 場很多小區(qū)業(yè)主都目睹了張俊被毆打的過程，“總共被打了兩次。”張俊的鄰居老邢說。同樣目睹事情經(jīng)過的程先生也說，張俊大概被毆打了10多分鐘，他遠遠看 著張俊滿臉都是血，倒在地上。他聽到在場的一位執(zhí)法人員對著幾乎快暈厥過去的張俊喊道：“裝死。”張俊的好友陳小姐說，現(xiàn)場就有執(zhí)法人員帶去的救護車，但 沒有對他進行救治。

而對此，當時執(zhí)法拆除違章建筑的昆明市綜合行政執(zhí)法局盤龍分局負責(zé)人稱，是張俊先揮舞警棍導(dǎo)致沖突發(fā)生。

據(jù)知情人稱，事件發(fā)生之后，已經(jīng)有一名參與沖突的執(zhí)法隊長被拘留，但此說法未得到有關(guān)部門的證實。

轉(zhuǎn)自：http://news.qq.com/a/20110103/000492.htm?qq=0&ADUIN=845765&ADSESSION=1294033435&ADTAG=CLIENT.QQ.3187_.0

過去與今天
詞 \ 黃家駒. 曲 \ 黃家駒. 主唱 \ 黃家駒.

夜雨街中里寧與靜
霧色燈影照我身
在我的心里常會問
幻變的都市四周
可知我已放棄舊日的理想
知否我也有個夢 要我醉倒
就像 就像 就像
像那方的星光閃動 眼也會發(fā)光
仰望浮云常變不定 暗里嘆一聲
沖出他朝崎嶇道上 哪怕會退倒
試問誰人曾會考慮 過去與今天
踏破這黑暗寧與靜
誰會管失意冷風(fēng)
幻變的都市誰問過
讓暖風(fēng)緊靠我身

EverBox 是一款由盛大創(chuàng)新院推出的網(wǎng)盤產(chǎn)品，提供數(shù)據(jù)存儲和同步服務(wù)。EverBox 提供了 10GB 超大免費存儲空間，支持文件同步、文件分享、在線瀏覽照片、在線聽音樂等功能，并支持數(shù)據(jù)同步客戶端。需要邀請的朋友可以改我留言 :-)

主要功能：

支持數(shù)據(jù)同步客戶端：安裝 EverBox后，您所需的文件都將自動同步到設(shè)備上，可以隨時、隨地的使用手邊的任意一款設(shè)備訪問文件了。目前提供了 Windows 客戶端程序，支持 Windows XP，Windows Vista 和 Windows 7。在以后的版本中，EverBox 將會陸續(xù)推出其他客戶端程序，如： Android，iPhone，iPad，Mac，Linux 等。

容災(zāi)備份服務(wù)：EverBox 會自動的、實時的備份文件數(shù)據(jù)到 EverBox 安全服務(wù)器，因此，當您本地的設(shè)備壞損或丟失時，不必擔(dān)心由于數(shù)據(jù)丟失造成的損失，恢復(fù)數(shù)據(jù)易如反掌！

在線音樂播放：EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡單、便捷，無需操作即可連續(xù)播放 EverBox 當前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時使用。

在線瀏覽圖片：EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡單、便捷，并支持自動播放 EverBox 當前目錄中的圖片文件。

EverBox 功能特性

1. 10GB 超大免費空間

   成功注冊 EverBox 即可獲得 2GB 免費空間，完成指定任務(wù)可升級空間到 10GB！EverBox 在隨后的版本中將會有更多的獎勵措施，贈送活躍用戶更多空間，敬請期待！

   

2. 支持數(shù)據(jù)同步客戶端

   您是不是經(jīng)常遇到以下的情況？“我喜歡在外出時用 iPhone 聽歌，但是我需要從 PC 下載歌曲再用數(shù)據(jù)線將 MP3 導(dǎo)到 iPhone”；“我經(jīng)常出差，但是程序和文件都在笨重的 PC 上，而我只帶著筆記本”；“我到 XX 會議做演講，但是保存 PPT 的 U 盤壞掉了”。

   現(xiàn)在有了 EverBox，這些問題將迎刃而解！只需安裝 EverBox，您所需的文件都將自動同步到設(shè)備上，您就可以隨時、隨地的使用手邊的任意一款設(shè)備訪問文件了。當然，使用瀏覽器一樣可以訪問到您需要的文件。

   

3. 容災(zāi)備份服務(wù)

   硬盤損壞？數(shù)據(jù)無法訪問？筆記本電腦被盜？完了，重要的數(shù)據(jù)丟失了！

   不用擔(dān)心，有了 EverBox，這一切都不會再是問題。EverBox 會自動的、實時的備份文件數(shù)據(jù)到 EverBox 安全服務(wù)器，因此，當您本地的設(shè)備壞損或丟失時，不必擔(dān)心由于數(shù)據(jù)丟失造成的損失，恢復(fù)數(shù)據(jù)易如反掌！

   

4. 在線音樂播放

   EverBox 支持在線音樂播放功能，幾乎支持所有常用的音頻格式，使用簡單、便捷，無需操作即可連續(xù)播放 EverBox 當前目錄中的歌曲，很適于一邊使用電腦一邊聽歌時使用。

   

5. 在線瀏覽圖片

   EverBox 支持在線瀏覽圖片功能，幾乎支持所有常用的圖片格式，操作簡單、便捷，并支持自動播放 EverBox 當前目錄中的圖片文件。

   

    

GAE 博客 —— B³LOG Solo 0.2.5 Beta1 發(fā)布了。

該版本除了修復(fù) Bugs，還增加了草稿夾、多人寫作、改進了緩存，以及加入了新皮膚 community。

借此機會，祝大家圣誕節(jié)愉快，一切平安 :-)

新特性

• 多人寫作
• 鏈接排序
• 新皮膚——community（多人寫作皮膚）

Bug 修復(fù)

• 緩存多實例不一致
• 文章訪問次數(shù)統(tǒng)計失效
• IE8 下 Feed 不能顯示

改進

• 存儲對象緩存
• 自定義頁面排序方式
• 改進了頁面緩存

具體改動看這里。

升級

如果您是 0.2.1 的用戶，那么請在部署完 0.2.5 Beta1 后登錄后臺，訪問 http://${application-id}.appspot.com/upgrade/v021-v025.do 進行升級。

項目

如果在使用、測試中發(fā)現(xiàn)任何問題，如果您有任何意見或建議，請告知我們 :-)

• 項目地址：http://code.google.com/p/b3log-solo/
• 下載：http://b3log-solo.googlecode.com/files/b3log-solo-0.2.5-beta1.zip
• Bug/特性提交：http://code.google.com/p/b3log-solo/issues/list

發(fā)布計劃

• 2011 年 1 月 21 日發(fā)布 0.2.5 Beta2
• 2011 年 2 月 14 日發(fā)布 0.2.5

作者博客

• 簡約設(shè)計の藝術(shù)
• Vanessa
• 羔羊<>沉默

發(fā)布歷史

1. GAE 博客——B3log Solo 0.2.1 發(fā)布了！
2. GAE 博客——B3log Solo 0.2.0 發(fā)布了！
3. GAE 博客——B3log Solo 0.1.1 發(fā)布了！
4. B3log Solo 0.1.0 發(fā)布了！
5. B3log Solo 0.1.0-preview2 發(fā)布了！
6. Solo 0.1.0-Preview1 發(fā)布了

最近一個潛在客戶要求我們比較一下 Amazon EC2 和 Google App Engine，正好我們剛剛在 EC2 和 Google App Engine 上完成了兩個相對來說規(guī)模較大的項目，因此有必要做一下總結(jié)。

我打算從三個角度來對比這兩大云計算平臺：技術(shù)，業(yè)務(wù)和未來發(fā)展趨勢，本文是技術(shù)方面的對比，ok，準備好咖啡，我們開始吧！

如果按平臺類型來分，大家可能已經(jīng)知道Google App Engine屬于PaaS（平臺即服務(wù)），而Amazon EC2屬于IaaS（基礎(chǔ)設(shè)施即服務(wù)），Amazon EC2給你一個安裝了操作系統(tǒng)的“盒子”，你可以自己安裝應(yīng)用程序，也可以使用AMI（Amazon Machine Image），如果你想構(gòu)建一個高度復(fù)雜的定制應(yīng)用，Amazon EC2是不二之選，它允許你控制環(huán)境參數(shù)，底層操作系統(tǒng)，存儲和網(wǎng)絡(luò)需求，從技術(shù)上講，它屬于很底層的服務(wù)，你可以調(diào)整你需要的大部分東西。

Google App Engine給你一個完整的平臺，包括完整的SDK（以及Eclipse插件）和服務(wù)，你可以構(gòu)建和部署你自己的應(yīng)用程序，但你不能很好地控制操作系統(tǒng)， 硬件和存儲，諸如寫文件系統(tǒng)，使用線程等操作都有限制，這樣設(shè)計的目的是為了確保平臺不會被某個應(yīng)用程序綁架。

簡單起來就是：

IaaS：原始硬件（處理器，網(wǎng)絡(luò)和存儲）

PaaS：操作系統(tǒng)，系統(tǒng)軟件，開發(fā)框架和虛擬機。

下面從技術(shù)角度來比較一下這兩個平臺。

1、提供的服務(wù)

Google App Engine憑借豐富的服務(wù)擊敗Amazon EC2，Google App Engine提供的服務(wù)可以讓開發(fā)人員快速進入開發(fā)狀態(tài)。如 Blobstore，Images，Mail，Memcache，Multitenancy，Oauth，Task Queues，URL Fetch，Users，XMPP這些服務(wù)在Amazon EC2上是需要自己安裝的，為了便于比較，假設(shè)你已經(jīng)為Memcache，Mail和多租戶搭建好了基礎(chǔ)設(shè)施，看看在EC2上你用了多長時間安裝，我敢打 賭你會超過一個小時，使用Google App Engine時，這些服務(wù)都是現(xiàn)成的，就象果盤中插好牙簽的水果一樣，你可以隨時享用。

2、管理

Google App Engine再次勝出，因為一旦你的應(yīng)用程序部署成功后，它幾乎不需要管理，當你的應(yīng)用程序負載變大時，你不需要向服務(wù)注入新的實例，Google App Engine可以自由擴大負載能力，新實例是實時剝離的。使用Amazon EC2時，你必須時刻跟蹤通信流量（現(xiàn)在可以通過腳本自動跟蹤了），新實例是在你的配置基礎(chǔ)上剝離的，因此，如果我的峰值負載是2x+y，那么需要剝離2 個以上的應(yīng)用程序服務(wù)器。

此外，使用Google App Engine升級應(yīng)用程序服務(wù)器實例，安裝新的負載均衡器時，沒有管理開銷，這一切都是自動執(zhí)行的。

3、抽象水平

和上一條聯(lián)系緊密的是抽象水平，Google App Engine抽象得比較好，你只需要關(guān)心你的應(yīng)用程序和業(yè)務(wù)邏輯，不用擔(dān)心底層基礎(chǔ)設(shè)施的管理，正如Nick Johnson所說的那樣，抽象水平應(yīng)作為挑選云計算平臺的一個基本原則，你需要做的是駕駛，不需要研究引擎蓋以下的東西。在我看來，如果你的核心業(yè)務(wù)是 貨物運輸，那么你應(yīng)該買一輛卡車，它能高效地把你的貨物從A地運輸?shù)紹地，相反，你不應(yīng)該考慮如何購買零部件自己組裝一輛卡車。

在軟件開發(fā)領(lǐng)域，我們看到有Grails，RoR等框架，它們大受歡迎，是因為它們提供了高水平的抽象，如果你是一名泥瓦匠，它們就象是腳手架，你可以踩在它們上面干你的工作。

4、可靠性

從我個人的認識來講，兩者都很可靠，這一點從它們的用戶數(shù)量就可以知道一二，用戶可以時刻查看Google App Engine的狀態(tài)，它是透明的，但從歷史數(shù)據(jù)來看，Amazon EC2的正常運行時間比Google App Engine要好。

5、可移植性

從使用的底層操作系統(tǒng)和開發(fā)框架來看，Amazon EC2具有更好的可移植性，但也不要擔(dān)心你會被Google App Engine給鎖住，Google已經(jīng)給出了遷移指南，指導(dǎo)你如何從轉(zhuǎn)移出Google App Engine平臺，當然包含你所有的數(shù)據(jù)在內(nèi)。還有AppScale這樣的程序可以幫助你將Google App Engine上的程序轉(zhuǎn)移到Amazom EC2或其它云平臺上，AppScale已經(jīng)可以支持EC2，Eucalyptus，Xen和KVM。

6、存儲

Google App Engine目前嚴重依賴于BigTable，開發(fā)人員需要從一個完全不同的角度來認識和學(xué)習(xí)它，特別是對于那些特熟悉關(guān)系數(shù)據(jù)庫，被關(guān)系數(shù)據(jù)庫理論束縛 的人更需要洗洗腦，它提供了一個JPA&JDO訪問接口，但它不支持所有的JPA&JDO功能，特別是關(guān)系部分，Google最近也高調(diào) 宣布要讓Google App Engine支持傳統(tǒng)的SQL數(shù)據(jù)庫。Amazon EC2已經(jīng)支持SQL數(shù)據(jù)庫，你可以使用Oracle，MySQL等你所熟悉的關(guān)系數(shù)據(jù)庫。

7、應(yīng)用程序維護和升級

對Google App Engine來說，應(yīng)用程序維護和升級是件輕而易舉的事，它為各種應(yīng)用程序提供了一個詳細的管理面板，包括日志查看器和數(shù)據(jù)查看器，一個程序可以有多個版 本，當新版本經(jīng)過測試，可以用于生產(chǎn)環(huán)境時，你可以將其設(shè)為默認的版本，而Amazon EC2就麻煩多了，因為它屬于IaaS類型，所有維護和升級相關(guān)的事情你必須親力親為。

8、開發(fā)限制

使用Google App Engine時，你必須受到平臺的限制，如果你的查詢處于僵死狀態(tài)，很難將其殺掉，此外，Google App Engine沒有線程，提供的SDK也是受限的，有些類和功能被列入黑名單，因此不能被使用，也不能寫文件系統(tǒng)等等。

從表面上看這些限制是不可理喻的，但如果有朝一日你也要提供PaaS類型的平臺時，你就能理解為什么Google要做這些限制了，這樣才能確保運行 在平臺上的應(yīng)用程序不會違反平臺的規(guī)則，否則平臺就可能被應(yīng)用程序綁架，從而變得不可使用，平臺上的其它應(yīng)用程序就會收到牽連。

即便有這些限制，90%的商業(yè)應(yīng)用程序仍然可以在Google App Engine上正常運行，但對于那些要使用線程，或?qū)懳募到y(tǒng)的應(yīng)用，最好還是選擇Amazon EC2，因為它提供了所有底層訪問和控制權(quán)。

9、語言支持

截至目前，Google App Engine支持Java和Python，但任何可以轉(zhuǎn)換成字節(jié)碼，可在JVM上執(zhí)行的任何編程語言都可以在Google App Engine上運行，如果你喜歡其它編程語言，最好選擇Amazon EC2，因為你可以在它的操作系統(tǒng)上面安裝語言運行時環(huán)境，你擁有幾乎完整的硬件和操作系統(tǒng)控制權(quán)，還有什么不能做的呢？在Amazon EC2上也托管了許多有趣的C#，.NET，ASP.NET MVC/Visual Studio項目，具有諷刺意味著的是，盡管還有Microsoft Azure，但許多以MS技術(shù)開發(fā)的項目卻托管在Amazon EC2上。

概括地說，Amazon EC2是進入云計算的早期嘗試者，它利用互聯(lián)網(wǎng)標準和開放平臺創(chuàng)建了一個非常靈活的云計算平臺，Google則利用了它在大型數(shù)據(jù)庫方面的研究成果和它內(nèi) 部實現(xiàn)的一些技術(shù)創(chuàng)建了一個強大，但有更多限制的云計算環(huán)境。從核心技術(shù)來講，Amazon EC2允許你擴展任何計算機實例到多個實例，因此你擁有每個虛擬盒子的完全控制權(quán)，Google App Engine從操作系統(tǒng)抽象而來，沒有計算機實例的概念，如果你的Web應(yīng)用程序不需要操作系統(tǒng)相關(guān)的功能，那么Google App Engine無疑是最好的選擇，如果需要更好地控制你的系統(tǒng)環(huán)境，特別是操作系統(tǒng)相關(guān)的控制，那么最好選擇Amazon EC2。

原文名：Comparing Google App Engine and Amazon EC2 on Technology 作者：Vikas Hazrati

不出意料地，他得到了一大堆回答。

通常情況下，你需要把所有人的發(fā)言從頭到尾讀一遍。但是，Stack Overflow有一個很貼心的設(shè)計，它允許在問題下方開設(shè)一個wiki區(qū)，讓所有人共同編輯一個最佳答案。于是，就有了下面這篇文章，一共總結(jié)出六個方面共計61條"網(wǎng)站開發(fā)須知"。

我發(fā)現(xiàn)，這種概述性的問題，最適合這種集合群智、頭腦風(fēng)暴式的回答方式了。這也是我第一次覺得，Stack Overflow做到了Wikipedia做不到的事。（難怪它最近擠進了全美前400大網(wǎng)站。）

在我的印象中，關(guān)于網(wǎng)站開發(fā)，這樣全面的概述性文章非常少見，因此也就非常有用。大家不妨看看，61件事情中你做到了多少？

（更新：剛剛發(fā)現(xiàn)，一共應(yīng)該是62條建議，我先前數(shù)錯了，這個......太窘了。）

=============================

網(wǎng)站開發(fā)人員應(yīng)該知道的61件事

原文網(wǎng)址：http://stackoverflow.com/questions/72394

譯者：阮一峰

一、界面和用戶體驗（Interface and User Experience）

1.1

知道各大瀏覽器執(zhí)行Web標準的情況，保證你的站點在主要瀏覽器上都能正常運行。你至少要測試以下引擎：Gecko（用于Firefox）、Webkit（用于Safari、Chrome和一些手機瀏覽器）、IE（你可以利用微軟發(fā)布的Application Compatibility VPC Images進行測試）和Opera。同時，不同的操作系統(tǒng)，可能也會影響瀏覽器如何呈現(xiàn)你的網(wǎng)站。

1.2

除了瀏覽器，網(wǎng)站還有其他使用方式：手機、屏幕朗讀器、搜索引擎等等。你應(yīng)該知道在這些情況下，你的網(wǎng)站的運行狀況。MobiForge提供了手機網(wǎng)站開發(fā)的一些相關(guān)知識。

1.3

知道如何在基本不影響用戶使用的情況下升級網(wǎng)站。通常來說，你必須有版本控制系統(tǒng)（CVS、Subversion、Git等等）和數(shù)據(jù)備份機制（backup）。

1.4

不要讓用戶看到那些不友好的出錯提示。

1.5

不要直接顯示用戶的Email地址，至少不要用純文本顯示。

1.6

為你的網(wǎng)站設(shè)置一些合理的使用限制，一旦超過門檻值，就自動停止服務(wù)。（這也與網(wǎng)站安全相關(guān)。）

1.7

知道如何實現(xiàn)網(wǎng)頁的漸進式增強（progressive enhancement）。

1.8

用戶發(fā)出POST請求后，總是將其重導(dǎo)向（redirect）至另外一個網(wǎng)頁。

1.9

不要忘記網(wǎng)站的可訪問性（accessibility，即殘疾人如何使用網(wǎng)站）。對于美國網(wǎng)站來說，有時這是法定要求。WAI-ARIA有一些這方面很好的參考資料。

二、安全性（Security）

2.1

閱讀《OWASP開發(fā)指南》，它提供了全面的網(wǎng)站安全指導(dǎo)。

2.2

了解SQL注入（SQL injection）及其預(yù)防方法。

2.3

永遠不要信任用戶提交的數(shù)據(jù)（cookie也是用戶端提交的！）。

2.4

不要明文（plain-text）儲存用戶的密碼，要hash處理后再儲存。

2.5

不要對你的用戶認證系統(tǒng)太自信，它可能很容易就被攻破，而你事先根本沒意識到存在相關(guān)漏洞。

2.6

了解如何處理信用卡。

2.7

在登錄頁面及其他處理敏感信息的頁面，使用SSL/HTTPS。

2.8

知道如何對付session劫持（session hijacking）。

2.9

避免"跨站點執(zhí)行"（cross site scripting，XSS）。

2.10

避免"跨域偽造請求"（cross site request forgeries，XSRF）。

2.11

及時打上補丁，讓你的系統(tǒng)始終跟上最新版本。

2.12

確認你的數(shù)據(jù)庫連接信息的安全性。

2.13

跟蹤攻擊技術(shù)的最新發(fā)展，以及你使用的平臺的最新安全漏洞。

2.14

閱讀Google的《瀏覽器安全手冊》（Browser Security Handbook）。

2.15

閱讀《網(wǎng)絡(luò)軟件的黑客手冊》（The Web Application Hackers Handbook）。

三、性能（Performance）

3.1

只要有可能，就使用緩存（caching）。正確理解和使用HTTP caching與HTML5離線儲存。

3.2

優(yōu)化圖片。不要把一個20KB的圖片文件，作為重復(fù)出現(xiàn)的網(wǎng)頁背景圖案。

3.3

學(xué)習(xí)如何用gzip/deflate壓縮內(nèi)容（deflate方式更可取）。

3.4

將多個樣式表文件或腳本文件，合為一個文件，這樣可以減少瀏覽器的http請求數(shù)，以及減小gzip壓縮后的文件總體積。

3.5

瀏覽Yahoo的Exceptional Performance網(wǎng)站，里面有大量提升前端性能的優(yōu)秀建議，還有他們的YSlow工具。Google的page speed則是另一個用來分析網(wǎng)頁性能的工具。兩者都要求安裝Firebug。

3.6

如果你的網(wǎng)頁用到大量的小體積圖片（比如工具欄），就應(yīng)該使用CSS Image Sprite，目的是減少http請求數(shù)。

3.7

大流量的網(wǎng)站應(yīng)該考慮將網(wǎng)頁對象分散在多個域名（split components across domains）。

3.8

靜態(tài)內(nèi)容（比如圖片、CSS、JavaScript、以及其他cookie無關(guān)的網(wǎng)頁內(nèi)容）都應(yīng)該放在一個不需要使用cookie的獨立域名之上。因為域名之下如果有cookie，那么客戶端向該域名發(fā)出的每次http請求，都會附上cookie內(nèi)容。這里的一個好方法就是使用"內(nèi)容分發(fā)網(wǎng)絡(luò)"（Content Delivery Network，CDN）。

3.9

將瀏覽器完成網(wǎng)頁渲染所需要的http請求數(shù)最小化。

3.10

使用Google的Closure Compiler壓縮JavaScript文件，YUI Compressor亦可。

3.11

確保網(wǎng)站根目錄下有favicon.ico文件，因為即使網(wǎng)頁中根本不包括這個文件，瀏覽器也會自動發(fā)出對它的請求。所以如果這個文件不存在，就會產(chǎn)生大量的404錯誤，消耗光你的服務(wù)器的帶寬。

四、搜索引擎優(yōu)化（Search Engine Optimization，SEO）

4.1

使用"搜索引擎友好"的URL形式，比如example.com/pages/45-article-title，而不是example.com/index.php?page=45。

4.2

不要使用"點擊這里"之類的超級鏈接，因為這樣等于浪費了一個SEO機會，而且降低了"屏幕朗讀器"（screen reader）的使用效果。

4.3

創(chuàng)建一個XML sitemap文件，它的缺省位置一般是/sitemap.xml（即放在網(wǎng)站根目錄下）。

4.4

當你有多個URL指向同一個內(nèi)容時，在網(wǎng)頁代碼中使用<link rel="canonical" ... />。

4.5

使用Google的Webmaster Tools和Yahoo的Site Explorer。

4.6

從一開始就使用Google Analytics（或者開源的訪問量分析工具Piwik）。

4.7

知道robots.txt的作用，以及搜索引擎蜘蛛的工作原理。

4.8

將www.example.com的訪問請求導(dǎo)向example.com（使用301 Moved Permanently重定向），或者采用相反的做法，目的是防止Google把它們當做兩個網(wǎng)站，分開計算排名。

4.9

知道存在著惡意或行為不正當?shù)木W(wǎng)絡(luò)蜘蛛。

4.10

如果你的網(wǎng)站有非文本的內(nèi)容（比如視頻、音頻等等），你應(yīng)該參考Google的sitemap擴展協(xié)議。

五、技術(shù)（Technology）

5.1

理解HTTP協(xié)議，以及諸如GET、POST、sessions、cookies之類的概念，包括"無狀態(tài)"（stateless）是什么意思。

5.2

確保你的XHTML/HTML和CSS符合W3C標準，使得它們能夠通過檢驗。這可以使你的網(wǎng)頁避免觸發(fā)瀏覽器的古怪行為（quirk），而且使它在"屏幕朗讀器"和手機上也能正常工作。

5.3

理解瀏覽器如何處理JavaScript腳本。

5.4

理解網(wǎng)頁上的JavaScript文件、樣式表文件和其他資源是如何裝載及運行的，考慮它們對頁面性能有何影響。在某些情況下，可能應(yīng)該將腳本文件放置在網(wǎng)頁的尾部。

5.5

理解JavaScript沙箱（Javascript sandbox）的工作原理，尤其是如果你打算使用iframe。

5.6

知道JavaScript可能無法使用或被禁用，以及Ajax并不是一定會運行。記住，"不允許腳本運行"（NoScript）正在某些用戶中變得流行，手機瀏覽器對腳本的支持千差萬別，而Google索引網(wǎng)頁時不運行大部分的腳本文件。

5.7

了解301重定向和302重定向之間的區(qū)別（這也是一個SEO相關(guān)問題）。

5.8

盡可能多得了解你的部署平臺（deployment platform）。

5.9

考慮使用樣式表重置（Reset Style Sheet）。

5.10

考慮使用JavaScript框架（比如jQuery、MooTools、Prototype），它們可以使你不用考慮瀏覽器之間的差異。

六、解決bug

6.1

理解程序員20%的時間用于編碼，80%的時間用于維護，根據(jù)這一點相應(yīng)安排時間。

6.2

建立一個有效的錯誤報告機制。

6.3

建立某些途徑或系統(tǒng)，讓用戶可以與你接觸，向你提出建議和批評。

6.4

為將來的維護和客服人員撰寫文檔，解釋清楚系統(tǒng)是怎么運行的。

6.5

經(jīng)常備份！（并且確保這些備份是有效的。）除了備份機制，你還必須有一個恢復(fù)機制。

6.6

使用某種版本控制系統(tǒng)儲存你的文件，比如Subversion或Git。

6.7

不要忘記做單元測試（Unit Testing），Selenium之類的框架會對你有用。

（完）

轉(zhuǎn)自：http://www.ruanyifeng.com/blog/2010/11/61_things_every_web_developer_should_know.html

簡介： 開源 memcached 工具是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁盤或數(shù)據(jù)庫，加載（并處理）信息了。該工具可部署在專用的情況下，也可作為用完 現(xiàn)有環(huán)境內(nèi)的多余內(nèi)存的一種方法。盡管 memcached 十分簡便，但有時它仍被不當使用，或被用在錯誤的環(huán)境類型中。在本文中，了解使用 memcached 的最佳時機。

簡介

memcached 常被用來加速應(yīng)用程序的處理，在這里，我們將著重于介紹將它部署于應(yīng)用程序和環(huán)境中的最佳實踐。這包括應(yīng)該存儲或不應(yīng)存儲哪些、如何處理數(shù)據(jù)的靈活分布以 及如何調(diào)節(jié)用來更新 memcached 和所存儲數(shù)據(jù)的方法。我們還將介紹對高可用性的解決方案的支持，比如 IBM WebSphere® eXtreme Scale。

所有的應(yīng)用程序，特別是很多 web 應(yīng)用程序都需要優(yōu)化它們訪問客戶機和將信息返回至客戶機的速度。可是，通常，返回的都是相同的信息。從數(shù)據(jù)源（數(shù)據(jù)庫或文件系統(tǒng)）加載數(shù)據(jù)十分低效，若是每次想要訪問該信息時都運行相同的查詢，就尤顯低效。

雖然很多 web 服務(wù)器都可被配置成使用緩存發(fā)回信息，但那與大多數(shù)應(yīng)用程序的動態(tài)特性無法相適。而這正是 memcached 的用武之地。它提供了一個通用的內(nèi)存存儲器，可保存任何東西，包括本地語言的對象，這就讓您可以存儲各種各樣的信息并可以從諸多的應(yīng)用程序和環(huán)境訪問這些信息。

基礎(chǔ)知識

memcached 是一個開源項目，旨在利用多個服務(wù)器內(nèi)的多余 RAM 來充當一個可存放經(jīng)常被訪問信息的內(nèi)存緩存。這里的關(guān)鍵是使用了術(shù)語緩存：memcached 為加載自他處的信息提供的是內(nèi)存中的暫時存儲。

比如，考慮這樣一個典型的基于 web 的應(yīng)用程序。即便是一個動態(tài)網(wǎng)站可能也會有一些組件或信息常量是貫穿頁面整個生命周期的。在一個博客站點內(nèi)，針對單個 blog post 的類別列表不大可能在頁面查看間經(jīng)常性地變更。每次都通過一個對數(shù)據(jù)庫的查詢加載此信息相對比較昂貴，特別是在數(shù)據(jù)沒有更改的情況下，就更是如此。從圖 1 可以看到一個博客站點內(nèi)可被緩存的頁面分區(qū)。

圖 1. 一個典型的博客頁面內(nèi)的可緩存元素

將這種結(jié)構(gòu)放在 blog 站點的其他元素，poster 信息、注釋 — 設(shè)置 blog post 本身 — 進行推斷，可以看出為了顯示主頁的內(nèi)容很可能需要發(fā)生 10-20 次數(shù)據(jù)庫查詢和格式化。 每天對數(shù)百甚至數(shù)千的的頁面查看重復(fù)此過程，那么您的服務(wù)器和應(yīng)用程序執(zhí)行的查詢要遠遠多于為了顯示頁面內(nèi)容所需執(zhí)行的查詢。

通過使用 memcached，可以將加載自數(shù)據(jù)庫的格式化信息存儲為一種可直接用在 Web 頁面上的格式。并且由于信息是從 RAM 而不是通過數(shù)據(jù)庫和其他處理從磁盤加載的，所以對信息的訪問幾乎是瞬時的。

再強調(diào)一下，memcached 是一個用來存儲常用信息的緩存，有了它，您便無需從緩慢的資源，比如磁盤或數(shù)據(jù)庫，加載并處理信息了。

對 memcached 的接口是通過網(wǎng)絡(luò)連接提供的。這意味著您可以在多個客戶機間共享單個的 memcached 服務(wù)器（或多個服務(wù)器，如本文稍后所示的）。這個網(wǎng)絡(luò)接口非常迅速，并且為了改善性能，服務(wù)器會故意不支持身份驗證或安全性通信。但這不應(yīng)限制部署選項。 memcached 服務(wù)器應(yīng)該存在于您網(wǎng)絡(luò)的內(nèi)部。網(wǎng)絡(luò)接口的實用性以及可以部署多個 memcached 實例的簡便性讓您可以使用多個機器上的多余 RAM 來提高您緩存的整體大小。

memcached 的存儲方法是一個簡單的鍵/值對，類似于很多語言內(nèi)的散列或關(guān)聯(lián)數(shù)組。通過提供鍵和值來將信息存儲到 memcached 內(nèi)，通過按特定的鍵請求信息來恢復(fù)信息。

信息會無限期地保留在緩存內(nèi)，除非發(fā)生如下的情況：

1. 為緩存分配的內(nèi)存耗盡 — 在這種情況下，memcached 使用 LRU（最近最少使用）方法從此緩存刪除條目。最近未曾使用的條目會從此緩存中先刪除，最舊的最先訪問。
2. 條目被明確刪除 — 總是可以從此緩存內(nèi)刪除條目。
3. 條目過期失效 — 各條目均有一個有效的期限以便針對此鍵存儲的信息在過于陳舊時可從緩存中清除這些條目。

上述這些情況可以與您應(yīng)用程序的邏輯綜合使用以便確保緩存內(nèi)的信息是最新的。有了這些基礎(chǔ)知識后，讓我們來看看在應(yīng)用程序內(nèi)如何能最好地利用 memcached。

何時使用 memcached

在使用 memcached 改進應(yīng)用程序性能時，可以對一些關(guān)鍵的過程和步驟進行修改。

在加載信息時，典型的場景如圖 2 所示。

圖 2. 加載要顯示的信息的典型順序

一般而言，這些步驟是：

1. 執(zhí)行一個或多個查詢來從數(shù)據(jù)庫加載信息
2. 格式化適合于顯示（或進一步處理）的信息
3. 使用或顯示格式化了的數(shù)據(jù)

在使用 memcached 時，為配合這個緩存，可對應(yīng)用程序的邏輯進行稍許修改：

• 盡量從緩存加載信息
• 如果存在，使用信息的被緩存版本
• 如果它不存在：
  1. 執(zhí)行一個或多個查詢來從數(shù)據(jù)庫加載信息
  2. 格式化適合于顯示或進一步處理的信息
  3. 將信息存儲到緩存內(nèi)
  4. 使用格式化了的數(shù)據(jù)

圖 3 是對這些步驟的總結(jié)。

圖 3. 在使用 memcached 時加載適合于顯示的信息

數(shù)據(jù)加載成為了至多三個步驟的一個過程，從緩存加載數(shù)據(jù)或從數(shù)據(jù)庫（視情況而定）加載數(shù)據(jù)并存儲在緩存內(nèi)。

當這個過程首次發(fā)生時，數(shù)據(jù)將正常地從數(shù)據(jù)庫或其他數(shù)據(jù)源加載，然后再存儲到 memcached 內(nèi)。當下一次訪問此信息時，它就會從 memcached 拉出，而不是從數(shù)據(jù)庫加載，節(jié)省了時間和 CPU 循環(huán)。

問題的另一個方面是要確保如果更改了要存儲在 memcached 內(nèi)的信息，在更新后端信息的同時還要更新 memcached 的版本。這會讓圖 4 內(nèi)所示的這個典型順序發(fā)生稍許變化，如 圖 5 所示。

圖 4. 在一個典型的應(yīng)用程序內(nèi)更新或存儲數(shù)據(jù)

圖 5 顯示了使用 memcached 后發(fā)生了變化的流程。

圖 5. 在使用 memcached 時更新或存儲數(shù)據(jù)

比如，仍以博客站點為例，在博客系統(tǒng)更新數(shù)據(jù)庫內(nèi)的類別列表時，更新應(yīng)該遵循如下順序：

1. 更新數(shù)據(jù)庫內(nèi)的類別列表
2. 格式化信息
3. 將信息存儲到 memcached 內(nèi)
4. 將信息返回至客戶機

memcached 內(nèi)的存儲操作是原子的，所以信息的更新不會讓客戶機只獲得部分數(shù)據(jù)；它們獲得的或者是老版本，或者是新版本。

對于大多數(shù)應(yīng)用程序，這兩個操作是您惟一需要注意的。在訪問他人使用的數(shù)據(jù)時，它會自動被添加到這個緩存內(nèi)，而且如果對該數(shù)據(jù)進行了更改，此緩存內(nèi)也會自動進行更新。

鍵、名稱空間和值

memcached 另一個需要重點考慮的因素是如何組織和命名存儲在緩存內(nèi)的這些數(shù)據(jù)。從之前博客站點的例子中，不難看出需要使用一種一致的命名結(jié)構(gòu)以便您能加載博客類別、歷史和其他信息，然后再在加載信息（并更新緩存）時或者在更新數(shù)據(jù)（同樣也要更新緩存）時使用。

使用的何種具體的命名系統(tǒng)特定于應(yīng)用程序，但通常可以使用一種與現(xiàn)有應(yīng)用程序類似的結(jié)構(gòu)，并且這種結(jié)構(gòu)很可能基于某種惟一識別符。當從數(shù)據(jù)庫拉出信息或在整理信息集時，就會發(fā)生這種情況。

以 blog post 為例，可以在一個具有鍵 category-list 的項中存儲類別列表。與此 post ID 對應(yīng)的單個 post，比如 blogpost-29 相關(guān)的值都可以使用，而該項的注釋則可以存儲在 blogcomments-29 內(nèi)，其中 29 就是這個 blog post 的 ID。這樣一來， 您就可以將各種各樣的信息存儲在緩存內(nèi)，使用不同的前綴來標識這些信息。

memcached 鍵/值存儲的簡便性（以及安全性的缺乏）意味著如果您想要在使用同一個 memcached 服務(wù)器的同時支持多個應(yīng)用程序，那么就可以考慮使用其他格式的量詞來標識數(shù)據(jù)屬于某種特定的應(yīng)用程序。比如，可以添加像 blogapp:blogpost-29 這樣的應(yīng)用程序前綴。這些鍵是沒有格式的，所以可以使用任何字符串作為鍵的名稱。

在存儲值的方面，應(yīng)該確保存儲在緩存內(nèi)的信息適合于您的應(yīng)用程序。比如，對于這個博客系統(tǒng)，您可能想要存儲被博客應(yīng)用程序使用的對象以便格式化博客信息，而不是原始的 HTML。如果同一個基礎(chǔ)結(jié)構(gòu)用在應(yīng)用程序內(nèi)的多個地方，這一點更具實用性。

大多數(shù)語言的接口，包括 Java™、Perl、PHP 等，都能串行化語言對象以便存儲在 memcached 內(nèi)。這就讓您可以存儲并隨后從內(nèi)存存儲恢復(fù)全部對象，而不是在您的應(yīng)用程序內(nèi)手動重構(gòu)它們。 很多對象，或它們使用的結(jié)構(gòu)，都基于某種散列或數(shù)組結(jié)構(gòu)。對于跨語言的環(huán)境，比如在 JSP 環(huán)境和 JavaScript 環(huán)境間共享相同信息，可以使用一種架構(gòu)中立的格式，比如 JavaScript Object Notation (JSON) 甚或 XML。

填充并使用 memcached

作為一種開源產(chǎn)品以及一種最初開發(fā)用來工作于現(xiàn)有開源環(huán)境內(nèi)的產(chǎn)品，memcached 受大量環(huán)境和平臺支持。與 memcached 服務(wù)器通信的接口有很多，并常常具有針對所有語言的多個實現(xiàn)。參見 參考資料 以獲得常用的庫和工具箱。

要列出所有受支持的接口和環(huán)境不太可能，但它們均支持 memcached 協(xié)議提供的基礎(chǔ) API。這些描述已經(jīng)被簡化并應(yīng)用在不同語言的上下文內(nèi)，在這些語言中，使用不同的值可指示錯誤。主要的函數(shù)有：

• get(key) — 從存儲了特定鍵的 memcached 獲得信息。 如果鍵不存在，就返回錯誤。
• set(key, value [, expiry]) — 使用緩存內(nèi)的標識符鍵存儲這個特定的值。如果鍵已經(jīng)存在，那么它就會被更新。期滿時間的單位為秒，并且如果值小于 30 天 (30*24*60*60)，那么就用作相對時間，如果值大于 30 天，那么就用作絕對時間 (epoch)。
• add(key, value [, expiry]) — 如果鍵不存在就將這個鍵添加到緩存內(nèi)，如果鍵已經(jīng)存在就返回錯誤。如果您想要顯式地添加一個新鍵而又不會因它已經(jīng)存在而更新它，那么這個函數(shù)將十分有用。
• replace(key, value [, expiry]) — 更新此特定鍵的值，如果鍵不存在就返回一個錯誤。
• delete(key [, time]) — 從緩存中刪除此鍵/值對。如果您提供一個時間，那么添加具有此鍵的一個新值就會被阻塞這個特定的時期。超時讓您可以確保此值總是可以重新讀取自您的數(shù)據(jù)中心。
• incr(key [, value]) — 為特定的鍵增 1 或特定的值。只適用于數(shù)值。
• decr(key [, value]) — 為特定的鍵減 1 或特定的值，只適用于數(shù)值。
• flush_all — 讓緩存內(nèi)的所有當前條目無效（或到期失效）。

比如，在 Perl 內(nèi)，基本 set 操作可以如清單 1 所示的那樣處理。

清單 1. Perl 內(nèi)的基本 set 操作

				
use Cache::Memcached;

my $cache = new Cache::Memcached {
    'servers' => [
                   'localhost:11211',
                   ],
    };

$cache->set('mykey', 'myvalue');

Ruby 內(nèi)的相同的基本操作如清單 2 所示。

清單 2. Ruby 內(nèi)的基本 set 操作

				
require 'memcache'
memc = MemCache::new '192.168.0.100:11211'

memc["mykey"] = "myvalue"

在兩個例子中可以看到相同的基本結(jié)構(gòu)：設(shè)置 memcached 服務(wù)器，然后分配或設(shè)置值。其他的接口也可用，包括適合于 Java 技術(shù)的那些接口，讓您可以在 WebSphere 應(yīng)用程序內(nèi)使用 memcached。memcached 接口類允許將 Java 對象直接序列化到 memcached 以便于存儲和加載復(fù)雜的結(jié)構(gòu)。當在像 WebSphere 這樣的環(huán)境內(nèi)進行部署時，有兩個事情非常重要：服務(wù)的彈性（在 memcached 不可用時如何做）以及如何提高緩存存儲量來改進在使用多個應(yīng)用程序服務(wù)器或在使用像 WebSphere eXtreme Scale 這樣的環(huán)境時的性能。我們接下來就來看看這兩個問題。

彈性和可用性

有關(guān) memcached 最常見的一個問題是：“若緩存不可用了，會發(fā)生什么情況呢？”正如之前章節(jié)中明示的，緩存內(nèi)的信息不應(yīng)該成為信息的的惟一資源。必須要能夠從其他位置加載存儲在緩存內(nèi)的數(shù)據(jù)。

雖然，無法從緩存訪問信息將會減緩應(yīng)用程序的性能，但它不應(yīng)該阻止應(yīng)用程序的運轉(zhuǎn)。可能會發(fā)生這樣幾個場景：

1. 如果 memcached 服務(wù)宕掉，應(yīng)用程序應(yīng)該回退到從原始數(shù)據(jù)源加載信息并對信息進行顯示所需的格式化。此應(yīng)用程序還應(yīng)繼續(xù)嘗試在 memcached 內(nèi)加載和存儲信息。
2. 一旦 memcached 服務(wù)器恢復(fù)可用，應(yīng)用程序就應(yīng)該自動嘗試存儲數(shù)據(jù)。沒有必要強制重載已緩存了的數(shù)據(jù)，可以使用標準的訪問來用信息加載和填充緩存。最終，緩存將會被最常用的數(shù)據(jù)重新填充。

再次重申，memcached 是信息的緩存但并非惟一的數(shù)據(jù)源。memcached 服務(wù)器不可用不應(yīng)該是應(yīng)用程序的終結(jié)，雖然這意味著在 memcached 服務(wù)器恢復(fù)正常之前性能會有所降低。實際上，memcached 服務(wù)器相對簡單，并且雖然不是絕對無故障的，但它的簡單性的結(jié)果就是它很少會出錯。

分配緩存

memcached 服務(wù)器只是網(wǎng)絡(luò)上針對一些鍵存儲值的一個緩存。如果有多臺機器，那么很自然地會想要在所有多余機器上設(shè)置一個 memcached 的實例來提供一個超大的聯(lián)網(wǎng) RAM 緩存存儲。

有了這個想法后，還有一種想當然是需要使用某種分配或復(fù)制機制來在機器之間復(fù)制鍵/值對。這種方式的問題是如果這么做反而會減少可用的 RAM 緩存，而不是增加。如圖 6 所示，可以看出這里有三個應(yīng)用程序服務(wù)器，每個服務(wù)器都可以訪問一個 memcached 實例。

圖 6. 多重 memcached 實例的不正確使用

盡管每個 memcached 實例都是 1 GB 的大小（產(chǎn)生 3 GB 的 RAM 緩存），但如果每個應(yīng)用程序服務(wù)器只有其自己的緩存（或者在 memcached 之間存在著數(shù)據(jù)的復(fù)制），那么整個安裝也仍只能有 1 GB 的緩存在每個實例間復(fù)制。

由于 memcached 通過一個網(wǎng)絡(luò)接口提供信息，因此單個的客戶機可以從它所能訪問的任何一個 memcached 實例訪問數(shù)據(jù)。如果數(shù)據(jù)沒有跨每個實例被復(fù)制，那么最終在每個應(yīng)用程序服務(wù)器上，就可以有 3 GB 的 RAM 緩存可用，如圖 7 所示。

圖 7. 多重 memcached 實例的正確使用

這個方法的問題是選擇哪個服務(wù)器來儲存鍵/值對，以及當想要重新獲得一個值時，如何決定要與哪個 memcached 服務(wù)器對話。問題的解決方案就是忽略復(fù)雜的東西，比如查找表，或是寄望 memcached 服務(wù)器來為您處理這個過程。而 memcached 客戶機則必須要力求簡單。

memcached 客戶機不必決定此信息，它只需對在存儲信息時指定的鍵使用一個簡單的散列算法。當想要從一列 memcached 服務(wù)器存儲或獲取信息時，memcached 客戶機就會用一個一致的散列算法從這個鍵獲取一個數(shù)值。舉個例子，鍵 mykey 被轉(zhuǎn)換成數(shù)值 23875 。是保存還是獲取信息無關(guān)緊要，這個鍵將總是被用作惟一標識符來從 memcached 服務(wù)器加載，因此在本例中，“mykey” 散列轉(zhuǎn)化后對應(yīng)的值總是 23875。

如果有兩個服務(wù)器，那么 memcached 客戶機將對這個數(shù)值進行一個簡單的運算（例如，系數(shù)）來決定它應(yīng)將此值存儲在第一個還是第二個配置了的 memcached 實例上。

當存儲一個值時，客戶機會從這個鍵確定出散列值以及它原來存儲在哪個服務(wù)器上。當獲取一個值時，客戶機會從這個鍵確定出相同的散列值并會選擇相同的服務(wù)器來獲取信息。

如果在每個應(yīng)用程序服務(wù)器上使用的是相同的服務(wù)器列表（并且順序相同），那么當需要保存或檢索同一個鍵時，每個應(yīng)用程序服務(wù)器都將選擇同一個 服務(wù)器。現(xiàn)在，在這個例子中，有 3GB 的 memcached 空間可以共享，而不是同一個 1 GB 的空間的復(fù)制，這就帶來了更多的可用緩存，并很有可能會提高有多個用戶情況下的應(yīng)用程序的性能。

這個過程也有其復(fù)雜性（比如當一個服務(wù)器不可用時會怎樣），更多信息，請參見相關(guān)文檔（參見 參考資料）。

如何能不使用 memcached

盡管 memcached 很簡單，但 memcached 實例有時候還是會被不正確地使用。

memcached 不是一個數(shù)據(jù)庫

最常見的 memcached 誤用就是把它用作一個數(shù)據(jù)存儲，而不是一個緩存。memcached 的首要目的就是加快數(shù)據(jù)的響應(yīng)時間，否則數(shù)據(jù)從其他數(shù)據(jù)源構(gòu)建或恢復(fù)需要很長時間。一個典型的例子就是從一個數(shù)據(jù)庫中恢復(fù)信息，特別是在信息顯示給用戶前 需要對信息進行格式化或處理的時候。Memcached 被設(shè)計用來將信息存儲在內(nèi)存中以避免每次在數(shù)據(jù)需要恢復(fù)時重復(fù)執(zhí)行相同的任務(wù)。

切不可將 memcached 用作運行應(yīng)用程序所需信息的惟一信息源；數(shù)據(jù)應(yīng)總是可以從其他信息源獲取。此外，要記住 memcached 只是一個鍵/值的存儲。不能在數(shù)據(jù)上執(zhí)行查詢，或者對內(nèi)容進行迭代來提取信息。應(yīng)該使用它來存儲數(shù)據(jù)塊或?qū)ο笠詡渑渴褂谩?/p>

不要緩存數(shù)據(jù)庫行或文件

雖然可以使用 memcached 存儲加載自數(shù)據(jù)庫的數(shù)據(jù)行，但這實際上是查詢緩存，并且大多數(shù)數(shù)據(jù)庫都提供各自的查詢緩存的機制。其他的對象，比如文件系統(tǒng)的圖像或文件的情況與此相同。很多應(yīng)用程序和 web 服務(wù)器針對此類工作已經(jīng)有了一些很好的解決方案。

如果在加載和格式化后，使用它來存儲全部信息塊，就可以從 memcached 獲得更多的實用工具和性能上的改善。仍以我們的博客站點為例，存儲信息的最佳點是在將博客類別格式化為對象，甚至是在格式化成 HTML 后。博客頁面的構(gòu)造可通過從 memcached 加載各個組件（比如 blog post、category list、post history 等）并將完成的 HTML 寫回至客戶機實現(xiàn)。

memcached 并不安全

為了確保最佳性能，memcached 并未提供任何形式的安全性，沒有身份驗證，也沒有加密。這意味著對 memcached 服務(wù)器的訪問應(yīng)該這么處理：一是通過將它們放到應(yīng)用程序部署環(huán)境相同的私有側(cè)，二是如果安全性是必須的，那么就使用 UNIX® socket 并只允許當前主機上的應(yīng)用程序訪問此 memcached 服務(wù)器。

這多少犧牲了一些靈活性和彈性，以及跨網(wǎng)絡(luò)上的多臺機器共享 RAM 緩存的能力，但這是在目前的情況下確保 memcached 數(shù)據(jù)安全性的惟一一種解決方案。

不要限制自己

除了不應(yīng)該使用 memcached 實例的情況外，memcached 的靈活性不應(yīng)忽視。由于 memcached 與應(yīng)用程序處于相同的架構(gòu)水平，所以很容易集成并連接到它。并且更改應(yīng)用程序以便利用 memcached 也并不復(fù)雜。此外，由于 memcached 只是一個緩存，所以在出現(xiàn)問題時它不會停止應(yīng)用程序的執(zhí)行。如果使用正確的話，它所做的是減輕其余服務(wù)器基礎(chǔ)設(shè)施的負載（減少對數(shù)據(jù)庫和數(shù)據(jù)源的讀操 作），這意味著無需更多的硬件就可以支持更多的客戶機。

但請記住，它僅僅是個緩存！

結(jié)束語

在本文中，我們了解了 memcached 以及如何最佳地使用它。我們看到了信息如何存儲、如何選擇合理的鍵以及如何選擇要存儲的信息。我們還討論了所有 memcached 用戶都要遇到的一些關(guān)鍵的部署問題，包括多服務(wù)器的使用、當 memcached 實例消亡時該怎么做，以及（也許最為重要的）在哪些情況下不能使用 memcached。

作為一種開源的應(yīng)用程序并且是目的簡單而直白的應(yīng)用程序，memcached 的功能和實用性均來自于這種簡單性。通過為信息提供巨大的 RAM 存儲空間、讓它在網(wǎng)絡(luò)上可用，然后再讓它可通過各種不同的接口和語言訪問到，memcached 可被集成到多種多樣的安裝和環(huán)境中。

參考資料

學(xué)習(xí)

• MySQL memcached 文檔 提供了很多有關(guān)如何在一個典型的數(shù)據(jù)庫部署環(huán)境內(nèi)使用 memcached 的信息。
• 通過體驗 IBM solidDB 產(chǎn)品家族，了解 IBM 的商業(yè)緩存解決方案 solidDB®。
• 隨時關(guān)注 developerWorks 技術(shù)活動和網(wǎng)絡(luò)廣播。
• 查閱最近將在全球舉辦的面向 IBM 開放源碼開發(fā)人員的研討會、交易展覽、網(wǎng)絡(luò)廣播和其他 活動。
• 訪問 developerWorks Open source 專區(qū)獲得豐富的 how-to 信息、工具和項目更新以及最受歡迎的文章和教程，幫助您用開放源碼技術(shù)進行開發(fā)，并將它們與 IBM 產(chǎn)品結(jié)合使用。
• 查看免費的 developerWorks On demand 演示，觀看并了解 IBM 及開源技術(shù)和產(chǎn)品功能。
  
  

獲得產(chǎn)品和技術(shù)

• memcached.org 提供了有關(guān) memcached 以及如何下載并安裝它的信息。
• Cache::Memcached interface for Perl 提供了一個廣泛的接口。
• 對于 Java 技術(shù)，可使用 com.danga.MemCached 類，它會提供一些額外的故障轉(zhuǎn)換及多實例擴展。
• 使用 IBM 產(chǎn)品評估試用版軟件 改進您的下一個開發(fā)項目，這些軟件可以通過下載獲得。
• 下載 IBM 產(chǎn)品評估試用版軟件 或 IBM SOA Sandbox for People，并開始使用來自 DB2®、Lotus®、Rational®、Tivoli® 和 WebSphere® 的應(yīng)用程序開發(fā)工具和中間件產(chǎn)品。

討論

• 參與 developerWorks 博客 加入 developerWorks 社區(qū)。
• 歡迎加入 My developerWorks 中文社區(qū)。
  
  

關(guān)于作者