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

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

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

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

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

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

EA@darren

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

今天的后續文章會談一下這點@BucketLI

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

一般盡量不會太晚，超過12點太多時間，早晨6點多肯定起來了@xzs

線程的棧數據是jvm自己的，要不然也不會有啟動太多線程導致OOM或者棧溢出的問題了@xzs

@夜露死苦
我達不到，但是如果當時有人和我說的話，我會少走很多彎路，呵呵，所以我和他說了，重要的是給建議別人，而不是去挑剔。

@chinablue
本來是從來不刪除別人的評論的（有點刪除的沖動，保留個10天公示一下），包括你說的某某前輩給我的意見，呵呵，我不知道你對這個前輩是不是也有你所說的那種蔥白（既然你喜歡別字，那我也應景一下），刪除你的評論，是因為每個人都有權利選擇自己的院子里面是不是需要容得下各種植物，我這篇文章沒有推到首頁（包括csdn），只是自己留下來（見諒，網絡硬盤也是硬盤），多說無益，呵呵，希望你生活的精彩

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

@孔夫子
這么說我同意，呵呵，學形，學意或者悟道都是不斷進步的，這也是我們這些老家伙為什么會比新人值錢的原因，如果僅僅關注技術外在那么做個五年還就是一個熟練工

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

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

@puran
一看這個名字就想起了你了，呵呵，好久沒有聯系了

@wangchangbing
我這邊是好看的么

占個坑，明天來看，哈哈哈，感謝分享

@ethan
1.對于趨勢統計我們現在是將每日數據入庫來做更加個性化的統計，因為分析后的數據已經是比較粗粒度，但是同時有能夠滿足個性化需求的，因此就不再這個系統中設計了。當然趨勢告警這邊有做
2.先不說月，我在系統中有max,min,average，其實就有一定的這個意思，當著些邏輯滿足不了，可以自動擴展reduce的方法來實現。
3.對于結果的merge是master單線程做的，多線程提交只是放在合并隊列，因此不存在并發問題。而且合并結果本來就有資源競爭，對于此類過程，多線程和單線程效率沒什么區別，多線程反而增加復雜度。

mapping file其實就是用java的管道和內存文件來做的，效率應該說在java中比較好了，實際的測試我到沒有準確的做過，也不好給出結果。

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

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

對于處理來說就是需要找到關鍵路徑，然后在關鍵路徑上找各個環節可以優化并行處理的工作，至于如何優化，的卻需要去驗證，就好比文件切割和任務塊執行，最簡單的設計就是根據多核來設定單機的工作線程，因為這是消耗cpu的工作。

對于文件切割會根據采用的方式不同而不同，我只是關心java方式，呵呵，其他我不關心了，對于java我就用map file的方式來切割，管道輸入輸出效率還是很高的，我不了解你的測試用的是什么方式。

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

@叮當
赫赫,技術是學習入門,然后靠實踐再去推翻或者改進已有的知識體系,作出來的是實踐積累,反過來影響知識.

@HiMagic!
其實我是要說明，對于流程中的工作需要細分，監聽消息到來和分發消息是很單薄的工作（可能在高并發下還有合并消息），而具體的工作執行應該是另一個繁重而不穩定的階段，需要區分對待，來提高前面隊列的穩定性，當然worker比較慢同樣會導致worker線程耗盡，這就需要考慮用什么策略來應對，可以用超時設置，丟棄排隊等方式來實現。

寫錯了，真是的啊。

觀察過,1.5肯定是不回收的,它的一個鎖信號量,1.6回收比較慢,要到一定的內存占用比例才會去Gc。SIP最早時候的內存泄露就是這個問題。

像牛一樣干活的人

@躺著讀書
樓上說的很對,我的比喻不恰當,改一下.赫赫,不過就中西醫來說,我的想法是當你的手段越豐富,可能讓人變得浮躁,其實不管是中西醫,關鍵還是那個人,要能夠沉的下心去做事.

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

Google的Gdata，豆瓣的Open API，Amazon的S3等等都是REST的，當然并沒有說REST一定是好的，技術沒有所謂的優劣，只有用的人是否在合適的場景充分的利用了它的優勢特點。

對了，最近修復了幾個邊界問題，最新版本為2.4

^_^,不錯

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

沒有,如果可以，你可以用這兩個包在同樣的環境試試看。

不錯

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

改造Spring的組件，支持import

Enterprise Architect

寫的不錯哦：），不過有一點要糾正的就是socket不是協議，是對網絡通信協議抽象實現的一種方式，tcp和udp是兩種傳輸協議，而http是標準的應用協議（設計初衷），只是有人將http誤用為傳輸協議（這也就是REST的理念），他們三者和socket完全沒有什么必然的聯系。

看了三篇文章，也受益不少：），不過對于OSGI和SCA以及服務框架有自己一點想法，這兒寫不下：），回blog寫。不過以后有了你和我交流和學習，對將來完善動態載入的服務框架更加有信心了^_^

@vagrant
先謝謝你的支持啦：），不過我是沒看過你說的那電視，至于我的名字，呵呵，我爺爺取的，應該沒什么太大關系。