放翁（文初）的一畝三分地

@Any
http://code.google.com/p/sharedthreadpool/

@鐵木真
包括google，flickr都有自己的認(rèn)證，雖然支持OAuth，這種看起來(lái)大而全的標(biāo)準(zhǔn)，在實(shí)際使用中最多只能用于平臺(tái)互通，在初期的平臺(tái)建設(shè)上，并不一定要去趕著潮流，呵呵。而且我做開放平臺(tái)的時(shí)候,OAuth還是0.1呢。OAuth1和2差異也很大，不過明年我為了平臺(tái)間互通也會(huì)考慮支持一下。

@冰河快狼
http://www.slideshare.net/cenwenchu/ss-6142016

@愛品者
hehe，千萬(wàn)不要提補(bǔ)償，做事情一定要簡(jiǎn)單粗暴，如果一定說(shuō)要保證一致性，那么有些必定要一致性的過程就不能拆分，否則搞死自己：）

@愛品者
我還是一個(gè)前端盲：），你回答的很不錯(cuò)了，第一點(diǎn)再次請(qǐng)求帶來(lái)的消耗（雖然是304只返回消息頭）和一個(gè)域下最多2個(gè)鏈接的卻是挺大的問題（我記得有些人就壓縮合并在一起了），js重新解析我到不知道，是不是如果頁(yè)面不卸載，指向同一個(gè)js的時(shí)候也不會(huì)再解析一次。
至于緩存我覺得不論前端后端都一樣，關(guān)鍵還是更新和讀取比例的問題，不合適的話，同步反而成為累贅。
管道這塊其實(shí)和前面兩個(gè)沒啥關(guān)系，只是服務(wù)端和客戶端都可以用，將一個(gè)大事務(wù)切割成為多個(gè)小任務(wù)的時(shí)候，串行執(zhí)行可以減少每個(gè)階段自有資源的生命時(shí)常，可以提高復(fù)用效率，并行執(zhí)行可以提高多個(gè)大任務(wù)執(zhí)行中對(duì)于各個(gè)階段資源消耗的利用率。
你的回復(fù)前兩點(diǎn)，我提交到我的微薄上去，挺好的

EA@darren

@BucketLI
1.有權(quán)重的的線程池是基于concurrent上封裝的，自己嘗試過封裝，性能差不多，就沒什么意思了，現(xiàn)在配置maxpoolsize和minpoolsize是一樣大的，這樣當(dāng)線程池到了上限后就放入隊(duì)列，隊(duì)列滿了就丟棄，如果需要加入超時(shí)特性，其實(shí)就把線程池自帶的隊(duì)列中的數(shù)據(jù)封裝帶有時(shí)間戳，然后定時(shí)輪詢清理掉過期任務(wù)。或者采用時(shí)間槽的概念，比如分成6個(gè)時(shí)間槽，每隔10分鐘切換一個(gè)時(shí)間槽，那么當(dāng)你任務(wù)20分鐘是容忍極限的話，那么在每次切換時(shí)間槽的時(shí)候清除相隔2個(gè)位置的隊(duì)列。
2.這個(gè)還是看你自己的策略，簡(jiǎn)單來(lái)說(shuō)，如果一個(gè)必選步驟錯(cuò)了，就產(chǎn)生結(jié)束任務(wù)的事件，有后臺(tái)線程執(zhí)行刪除任務(wù)操作。
3.CountDownLatch你是用線程阻塞？為每一個(gè)任務(wù)都分配一個(gè)？我不是很清楚你的做法，但是個(gè)人感覺CountDownLatch用于任務(wù)的join啟動(dòng)和結(jié)束比較好，你也可以描述一下你們的做法？

今天的后續(xù)文章會(huì)談一下這點(diǎn)@BucketLI

@君楚
起初用詞的時(shí)候就是自己考慮了一下，不過你看看wikipedia的解釋，我覺得尚可 http://en.wikipedia.org/wiki/Instruction_pipeline

一般盡量不會(huì)太晚，超過12點(diǎn)太多時(shí)間，早晨6點(diǎn)多肯定起來(lái)了@xzs

線程的棧數(shù)據(jù)是jvm自己的，要不然也不會(huì)有啟動(dòng)太多線程導(dǎo)致OOM或者棧溢出的問題了@xzs

@夜露死苦
我達(dá)不到，但是如果當(dāng)時(shí)有人和我說(shuō)的話，我會(huì)少走很多彎路，呵呵，所以我和他說(shuō)了，重要的是給建議別人，而不是去挑剔。

@chinablue
本來(lái)是從來(lái)不刪除別人的評(píng)論的（有點(diǎn)刪除的沖動(dòng)，保留個(gè)10天公示一下），包括你說(shuō)的某某前輩給我的意見，呵呵，我不知道你對(duì)這個(gè)前輩是不是也有你所說(shuō)的那種蔥白（既然你喜歡別字，那我也應(yīng)景一下），刪除你的評(píng)論，是因?yàn)槊總€(gè)人都有權(quán)利選擇自己的院子里面是不是需要容得下各種植物，我這篇文章沒有推到首頁(yè)（包括csdn），只是自己留下來(lái)（見諒，網(wǎng)絡(luò)硬盤也是硬盤），多說(shuō)無(wú)益，呵呵，希望你生活的精彩

@一意孤行
呵呵，大部分都同意啦，只是有句俗話說(shuō)的好：少不讀三國(guó)，老不讀紅樓，在適合的時(shí)候做適合的事情，青春就是用來(lái)燒的，這也是將來(lái)成熟的一種歷練。感謝你對(duì)我的關(guān)注，對(duì)我來(lái)說(shuō)，技術(shù)是一種愛好，但是現(xiàn)在我更在乎的是產(chǎn)品，不再會(huì)和過去一樣為了技術(shù)而技術(shù)，如何用技術(shù)來(lái)支持產(chǎn)品滿足用戶是我在乎的（當(dāng)然設(shè)計(jì)的好的架構(gòu)（不是啥開源框架，呵呵）在用戶需求不斷變化的時(shí)候可以更快的響應(yīng)，能夠前瞻到用戶的潛在需求，挖掘出用戶真正的需求）。最后貼一段我的Boss（菲青）前一陣子給我的一段評(píng)語(yǔ)：回放翁的文章。放翁和自雪應(yīng)該是阿里/淘寶開放的先行者。從08年我們開始干開放的活兒，就是大家從無(wú)到有的累積。當(dāng)然，新業(yè)務(wù)的建立需要時(shí)間，革命尚未成功。但是，看到放翁的轉(zhuǎn)變從一個(gè)技術(shù)狂愛者到一個(gè)以業(yè)務(wù)為支撐的技術(shù)專家，我很佩服他的成長(zhǎng)，也感覺TOP很幸運(yùn)有了這些人，才使得TOP能夠繼續(xù)成長(zhǎng)。我們的目標(biāo)是以技術(shù)來(lái)支撐，改變業(yè)務(wù)產(chǎn)品，但不是技術(shù)主導(dǎo)業(yè)務(wù)。當(dāng)然，因?yàn)槲覀兞髁考皹I(yè)務(wù)復(fù)雜度的關(guān)系，這中間沉淀下來(lái)的技術(shù)含量絕不亞于淘寶內(nèi)部的一些大型系統(tǒng)！

@孔夫子
這么說(shuō)我同意，呵呵，學(xué)形，學(xué)意或者悟道都是不斷進(jìn)步的，這也是我們這些老家伙為什么會(huì)比新人值錢的原因，如果僅僅關(guān)注技術(shù)外在那么做個(gè)五年還就是一個(gè)熟練工

@孔夫子
首先技術(shù)的目標(biāo)就是服務(wù)客戶，這就是最更本的要求，否則就是一個(gè)沒有畢業(yè)的大學(xué)生，因此我所涉及的內(nèi)容不會(huì)為了技術(shù)而技術(shù)，是產(chǎn)品需要而生。其次，這年頭一堆人搞忽悠，沒有人踏踏實(shí)實(shí)的寫點(diǎn)代碼，基本不靠譜，同時(shí)創(chuàng)新不是腦袋里蹦出來(lái)的，而是在使用前人已有的技術(shù)時(shí)發(fā)現(xiàn)無(wú)法滿足需求才去思索和實(shí)踐得到的結(jié)果，整天想著創(chuàng)新卻不踏踏實(shí)實(shí)的干點(diǎn)事情，那就是等著天上掉餡餅，呵呵，不多說(shuō)，仁者見仁，智者見智，少一些抱怨，多一些實(shí)干，把平凡的事情做的不平凡那就夠了

@孔夫子
如果你不了解淘寶開放的服務(wù)，請(qǐng)去看文檔；如果你覺得需要開放的沒有開放，你可以提需求；如果你有實(shí)際的工作成果，請(qǐng)展示；的卻時(shí)間可以證明很多事情，同時(shí)在評(píng)論別人的時(shí)候需要更多的拿出建議，而不僅僅是批判，這才是大家需要的氛圍，這年頭沒有不好的技術(shù)，只有生搬硬套的誤用。

@puran
一看這個(gè)名字就想起了你了，呵呵，好久沒有聯(lián)系了

@wangchangbing
我這邊是好看的么

占個(gè)坑，明天來(lái)看，哈哈哈，感謝分享

@ethan
1.對(duì)于趨勢(shì)統(tǒng)計(jì)我們現(xiàn)在是將每日數(shù)據(jù)入庫(kù)來(lái)做更加個(gè)性化的統(tǒng)計(jì)，因?yàn)榉治龊蟮臄?shù)據(jù)已經(jīng)是比較粗粒度，但是同時(shí)有能夠滿足個(gè)性化需求的，因此就不再這個(gè)系統(tǒng)中設(shè)計(jì)了。當(dāng)然趨勢(shì)告警這邊有做
2.先不說(shuō)月，我在系統(tǒng)中有max,min,average，其實(shí)就有一定的這個(gè)意思，當(dāng)著些邏輯滿足不了，可以自動(dòng)擴(kuò)展reduce的方法來(lái)實(shí)現(xiàn)。
3.對(duì)于結(jié)果的merge是master單線程做的，多線程提交只是放在合并隊(duì)列，因此不存在并發(fā)問題。而且合并結(jié)果本來(lái)就有資源競(jìng)爭(zhēng)，對(duì)于此類過程，多線程和單線程效率沒什么區(qū)別，多線程反而增加復(fù)雜度。

mapping file其實(shí)就是用java的管道和內(nèi)存文件來(lái)做的，效率應(yīng)該說(shuō)在java中比較好了，實(shí)際的測(cè)試我到?jīng)]有準(zhǔn)確的做過，也不好給出結(jié)果。

當(dāng)前正在做即時(shí)分析，數(shù)據(jù)源也可以切換到DB上去了，時(shí)間可以縮短，省掉了對(duì)大文件切割和拖拉的時(shí)間。（這塊時(shí)間的卻是在分析中最耗時(shí)的），這樣我除了每天的日?qǐng)?bào)表，也有了段時(shí)間的報(bào)表（每15分鐘，自己可以定義時(shí)間段），增量合并后就是一天的報(bào)表。

@ethan
1.condition和valuefilter就是數(shù)據(jù)清洗的環(huán)節(jié)，當(dāng)然也支持，map和reduce的自定義。
2.對(duì)于top排名只需要定義order即可，當(dāng)前流出了字段，不了解什么叫做時(shí)間窗隨意。
3.沒有這個(gè)需求，我不是做DB。
4.對(duì)于與處理來(lái)說(shuō)由于對(duì)于記錄輸入只是一次遍歷，因此沒有必要再去細(xì)分什么類型的reduce，一條記錄閱讀完成以后這些分析必須全部做，這是一個(gè)串行的過程，因此無(wú)所謂前后之分。
5.松散的設(shè)計(jì)就是讓master足夠輕，同時(shí)任務(wù)slave就是資源廉價(jià)，通過用算法來(lái)分配任務(wù)，在失效時(shí)間和分配之間找到平衡點(diǎn)，master和slave的關(guān)系。
6.還是那個(gè)設(shè)計(jì)，如果master要監(jiān)控slave，那么就不是我說(shuō)的松散設(shè)計(jì)，而是傳統(tǒng)的分布式mapreduce的思想。選擇松散就是在控制度和復(fù)雜度之間找到平衡點(diǎn)。

對(duì)于處理來(lái)說(shuō)就是需要找到關(guān)鍵路徑，然后在關(guān)鍵路徑上找各個(gè)環(huán)節(jié)可以優(yōu)化并行處理的工作，至于如何優(yōu)化，的卻需要去驗(yàn)證，就好比文件切割和任務(wù)塊執(zhí)行，最簡(jiǎn)單的設(shè)計(jì)就是根據(jù)多核來(lái)設(shè)定單機(jī)的工作線程，因?yàn)檫@是消耗cpu的工作。

對(duì)于文件切割會(huì)根據(jù)采用的方式不同而不同，我只是關(guān)心java方式，呵呵，其他我不關(guān)心了，對(duì)于java我就用map file的方式來(lái)切割，管道輸入輸出效率還是很高的，我不了解你的測(cè)試用的是什么方式。

不過很感謝你的留言，起碼看到有人還是看了，呵呵。

@叮當(dāng)
赫赫,技術(shù)是學(xué)習(xí)入門,然后靠實(shí)踐再去推翻或者改進(jìn)已有的知識(shí)體系,作出來(lái)的是實(shí)踐積累,反過來(lái)影響知識(shí).

@HiMagic!
其實(shí)我是要說(shuō)明，對(duì)于流程中的工作需要細(xì)分，監(jiān)聽消息到來(lái)和分發(fā)消息是很單薄的工作（可能在高并發(fā)下還有合并消息），而具體的工作執(zhí)行應(yīng)該是另一個(gè)繁重而不穩(wěn)定的階段，需要區(qū)分對(duì)待，來(lái)提高前面隊(duì)列的穩(wěn)定性，當(dāng)然worker比較慢同樣會(huì)導(dǎo)致worker線程耗盡，這就需要考慮用什么策略來(lái)應(yīng)對(duì)，可以用超時(shí)設(shè)置，丟棄排隊(duì)等方式來(lái)實(shí)現(xiàn)。

寫錯(cuò)了，真是的啊。

觀察過,1.5肯定是不回收的,它的一個(gè)鎖信號(hào)量,1.6回收比較慢,要到一定的內(nèi)存占用比例才會(huì)去Gc。SIP最早時(shí)候的內(nèi)存泄露就是這個(gè)問題。

像牛一樣干活的人

@躺著讀書
樓上說(shuō)的很對(duì),我的比喻不恰當(dāng),改一下.赫赫,不過就中西醫(yī)來(lái)說(shuō),我的想法是當(dāng)你的手段越豐富,可能讓人變得浮躁,其實(shí)不管是中西醫(yī),關(guān)鍵還是那個(gè)人,要能夠沉的下心去做事.

如果使用內(nèi)存數(shù)據(jù)庫(kù),的卻寫出的頻度可以比普通的數(shù)據(jù)庫(kù)要快,但是就算是內(nèi)存數(shù)據(jù)庫(kù),它的連接資源還是有限的,就算使用連接池,其實(shí)在每天幾十億的數(shù)據(jù)量下還是撐不住的.這里雖然用了線程,但是采用的是比較單一的使用方式,線程切換代價(jià)不大.不過這個(gè)可以測(cè)試一下看看,采用mysql內(nèi)存數(shù)據(jù)庫(kù)，然后每來(lái)一條數(shù)據(jù)就寫，與批量異步寫看看對(duì)于系統(tǒng)壓力以及性能來(lái)說(shuō)是否有變化。

Google的Gdata，豆瓣的Open API，Amazon的S3等等都是REST的，當(dāng)然并沒有說(shuō)REST一定是好的，技術(shù)沒有所謂的優(yōu)劣，只有用的人是否在合適的場(chǎng)景充分的利用了它的優(yōu)勢(shì)特點(diǎn)。

對(duì)了，最近修復(fù)了幾個(gè)邊界問題，最新版本為2.4

^_^,不錯(cuò)

@Always BaNg.
不是淘寶，是阿里軟件

沒有,如果可以，你可以用這兩個(gè)包在同樣的環(huán)境試試看。

不錯(cuò)

動(dòng)作很快么,呵呵.昨天我才在theserverside看到，你今天就出中文版了。

改造Spring的組件，支持import

Enterprise Architect

寫的不錯(cuò)哦：），不過有一點(diǎn)要糾正的就是socket不是協(xié)議，是對(duì)網(wǎng)絡(luò)通信協(xié)議抽象實(shí)現(xiàn)的一種方式，tcp和udp是兩種傳輸協(xié)議，而http是標(biāo)準(zhǔn)的應(yīng)用協(xié)議（設(shè)計(jì)初衷），只是有人將http誤用為傳輸協(xié)議（這也就是REST的理念），他們?nèi)吆蛃ocket完全沒有什么必然的聯(lián)系。

看了三篇文章，也受益不少：），不過對(duì)于OSGI和SCA以及服務(wù)框架有自己一點(diǎn)想法，這兒寫不下：），回blog寫。不過以后有了你和我交流和學(xué)習(xí)，對(duì)將來(lái)完善動(dòng)態(tài)載入的服務(wù)框架更加有信心了^_^

@vagrant
先謝謝你的支持啦：），不過我是沒看過你說(shuō)的那電視，至于我的名字，呵呵，我爺爺取的，應(yīng)該沒什么太大關(guān)系。