oldworm

實用云計算環境簡述

如今it領域沒聽說過云計算的絕對是out了，雖然大家都知道云計算，雖然很多高校很多專業都開設了云計算專業，雖然很多人都在討論云計算，雖然也有少數人走在了應用云計算的前列，然而，可悲的是，大多數人對云計算的認識僅限于amazon、google、microsoft、ibm有能力架設云計算環境，其他公司都靠邊，甚至唯他們的云計算才叫云計算，別的企業根本不可能做云計算，各級政府部門最搞笑了，動不動花多少錢引進某某云計算環境，填補某某空白，多少cpu多少機器每秒多少萬億次計算，最終是不是一堆浪費電力的擺設也沒有人知道，也沒人去過問。

略感欣慰的是，很多企業都在務實地部署自己的云計算環境，大如騰訊、淘寶、百度、小如我們這樣剛成立的小公司，其實要部署一個私有云計算環境并沒有那么難，以我個人的經驗來看，如果有一個精干的小團隊，幾個人一個月部署一個私有云計算環境是完全可能可行的。在我看來，所謂云計算就是分布式存儲+分布式計算，不局限于底下os是win還是*nix，也不局限于是局域網環境還是廣域網環境，也不管上面跑的是c++的程序還是javascript的程序，下面簡單介紹下我設計的一個即時查詢價格的云計算體系：

我一直在win下開發，win用得非常熟練，所以我把云計算環境部署在windows之上，當然也考慮到windows的機器眾多，tasknode可輕易找到非常多的目標機器，我部署的云計算環境主要分兩類節點，jobserver和tasknode，jobserver主管任務切割、任務調度，tasknode是計算節點。另外還有一些節點，jobowner可連接jobserver并提交任務，并可查詢該任務的執行情況，admin可連接jobserver查詢jobserver的狀態。

其實這些上篇博客已經寫過，我再講的詳細一點，看具體的執行情況，首先jobowner給jobserver提交package，這個package是一個zip文件，包含一組文件，jobowner提交package之后jobserver會根據約定的規則管理package，并在jobserver展開該package，如下：

Jobowner連到jobserver之后，發出如下的命令到jobserver

0x49 0x0 0x0 0x0 0x2 0x0 0xb 0x0 127.0.0.1 0x0 ppsget.dll 0x0

{type:[0,1,2,3,4],rmax:5,wb:"pc",text:"諾基亞 e63"} 0x0

上面是用我設計的一種混合顯示格式顯示的包數據，可以看到里面帶上了ppsget.dll，這就是指定包內部名，其實還可以這樣ppsget.dll:getpage，如此一個dll就可支持多個IJobTask輸出，getpage只是獲得其中一個IJobTask接口（關于IJobTask接口參考上一篇云計算實踐2的文章）。具體命令是json格式，主要是為了方便信息傳輸和解析。Jobserver接收到該命令之后，調用ppsget.dll的IJobTask接口中的split函數，將該任務分解，之后調度Tasknode執行，tasknode收到jobserver發過來的任務之后，檢查包名稱，如果缺少就會主動向jobserver要求發送相應的包，并進行部署，待部署完成之后從包獲取指定的IJobTask接口，執行該接口的map函數，將結果按照約定的格式發給jobserver，最后由jobserver調用IJobTask中的reduce函數進行打包，最后將結果發給jobowner并記錄相關Log。

上圖中還可看到一個HashCrackCloud.dll，這是另一個云計算環境下破解md5密碼的dll，這個上篇文章也寫了一下，這里就不詳述了。

為使得tasknode可適應各種機器環境，我把tasknode設計為一個dll，該dll內部自己管理消息及任務執行，該dll可被加載到各種容器進程（如gui進程、console進程、service進程）等執行，看下我的tasknode和它的容器進程：

這也算是我的得意設計吧，這樣設計的tasknode在windows系統下的確具有很高的靈活性。

這樣的tasknode甚至可直接加載在jobserver進程，也可被任意win系列機器的任意進程加載參與運算，用主動加載或被動加載都很方便，極大的方便了云計算環境的部署，反正具體執行的任務都由package完成，tasknode只要按照約定的規則部署 package即可，所以這種云計算環境是非常輕量級又非常靈活的，開發一個新的任務只要做一個新的IJobTask即可，目前我這套體系除了沒有考慮太多安全性之外，這個云計算環境的實施還是非常容易的，實際上我們這個價格查詢的后臺云計算環境只用了不到2周的時間就開發完成。

再看下jobserver記錄的每個job的log：

從log中可很容易的分析出一個job每個task的執行情況，并可根據這些數據進行相應的優化處理。

之所以把jobserver和tasknode以及package都寫出來，主要是為了表達一個看法，要實現一個簡單的云計算環境其實并不難，有經驗的團隊很容易就能做出來，參考下google的map/reduce論文，按照自己的需要簡化實現，真理在實踐中，如果只是仰望google、amazon，那就真的是在云中霧里，另一個想要表達的就是云的形式是多種多樣的，并不一定amazone、google的云計算環境才是標準的，對實用派來說，形式都是次要的，實用才是關鍵的。

之前的文章講過，我設計的網絡框架有幾組線程，分別是io、異步、同步、定時器，各個不同應用server幾組線程組合形式不盡相同，簡單的可只有io線程，復雜一點的可io+同步，更復雜一點的也可io+同步+異步+定時器，總之我以幾組線程的自由組合方式應付各種應用，在我負責的server全是這一套框架實現的，不管是支持幾萬人連接的服務器，還是只有幾個用戶連接的內部服務器，這套框架也算是久經考驗，穩定運行多年，內部使用也非常簡單，如給sync線程組發一個消息只要PostSyncEvent，如果要給異步線程發一個消息只要發PostAsyncEvent，雖然只能開發的時候確定哪個任務在哪組線程執行，但修改還是非常方便的，執行體就是一組這樣的函數：

OnSyncEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

OnAsyncEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

一眼就知道是在哪個線程組里面執行，當然有的線程組是一個線程，有的線程組是多個，這涉及到有的資源是不是要加鎖，有經驗的開發人員很容易理解。

說了一下框架才容易理解我的問題，之前定時器是一個獨立的線程組，同步線程組、異步線程組、io組都沒有定時器功能，定時器觸發后要發送消息到相應線程組，有的要發給異步線程組，有的要發給同步線程組，這就會引起線程切換，這是問題之一，還有一個問題，之前的定時器是由windows的時鐘隊列實現的，這個定時器優點是很明顯的，定時精確，功能強大，參數眾多，獨立線程組，但也有很明顯的問題，如果要刪除一個定時器則有線程依賴，就是要在定時器線程才能刪除定時器，這個依賴約束很大，也很容易引起問題，用起來很不方便，使得一些資源的釋放不能夠即時進行。正因為有這么些問題，也為了使得時鐘模塊更容易移植，我設計了一個新時鐘模塊，為實現以下目標：

1、無線程依賴，隨便調用者在哪個線程調用都可刪除指定的定時器。

2、和事件消息集成在一個線程內，實現無需切換的定時器功能，這樣主線程、同步線程組、異步線程組都可在內部處理定時器消息，無需單獨的定時器線程輔助，方便很多。

為實現以上目標，我引入了libevent里面的minheap管理定時器，并根據之前管理事件的處理辦法，繼續使用iocp隊列管理線程消息，在每個線程組用iocp管理事件，根據最短觸發的定時器計算wait時間，這樣就在同一組線程內實現了定時器和事件合并處理，當然實現方法有很多，也可用iocp+WaitableTimer等，也可用apc，但那些實現的windows烙印都太深刻，雖然精度更高，實現更容易，我用minheap+iocp隊列方式的實現相對來說對windows的依賴較少，因為替換一個iocp隊列處理事件是很容易的，這樣也方便移植和復用代碼。經這樣修改之后，各個線程組包括主線程都可處理定時器和事件消息，也使得以前雞肋式的主線程終于可當同步線程發揮作用，以前的定時器線程組也不一定需要了，既減少了線程，也減少了切換，現在各個線程組（包括主線程）都有完全一致的消息處理和時鐘處理函數。

事件函數：

OnTimerEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

OnSyncEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

OnAsyncEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

OnServiceEvent(DWORD dwEvent, DWORD wParam, DWORD lParam);

定時器函數：

OnTimerTimer(TlsInfo *ptls, EventTimer *et);

OnSyncTimer(TlsInfo *ptls, EventTimer *et);

OnAsyncTimer(TlsInfo *ptls, EventTimer *et);

OnIoTimer(TlsInfo *ptls, EventTimer *et);

OnServiceTimer(TlsInfo *ptls, EventTimer *et);

可以給線程組增加定時器刪除定時器

AddTimer、AddSyncTimer、AddAsyncTimer、AddServiceTimer、AddIoTimer

DelTimer、DelSyncTimer、DelAsyncTimer、DelServiceTimer、DelIoTimer

可給各線程組發消息

PostTimerEvent、PostSyncEvent、PostAsyncEvent、PostServiceEvent

這套框架是我多年服務器端開發的得意之作，體現了我簡潔實用的設計思想，用起來非常方便，可任意組合，適應各種需求的應用，由于除主線程之外的io線程組、同步線程組、異步線程組、定時器線程都是可以關、開1個、開多個，所以組合非常靈活，開1個可當同步線程，開多個可當異步線程（內部搶資源），關閉就不存在該組線程，即使是io線程組也是可關的，這樣就使得這套框架不僅僅用在標準server上，就算是當作一般的消息隊列服務器也沒問題，高度的靈活性使得這套框架可適應各種規模的應用，這次對定時器的改造使得這種組合更靈活，雖然現在的實現方法定時器的精度有一些下降，但瑕不掩瑜，這樣改造之后功能無疑是更強大了。

云計算實踐2

上一篇《基于云計算的價格查詢實現》就算是云計算實踐1吧，所以這篇就叫《云計算實踐2》。其實今年開始研究云計算有一段時間了，約3個月前研究md5破解(http://www.shprog.com/HashCrack.aspx)，那個項目就是選來玩云計算的，當時覺得md5破解這個小項目好玩，邏輯很簡單，密碼字母組合可長可短，規模可大可小，1臺機器不嫌少，1萬臺不嫌多，所以就選中了它，沒想到第一個md5破解版本后來演變成了主要是密碼數據庫的制造，雖然第一版沒有做成標準云計算，但也算有個結果，而且存儲效率、制造速度還是令人滿意的，也就是說那個項目只是云計算研究的副產品，我的本意并不是想做一個md5破解或者qq密碼破解，但結果就產生了這么一個產品，也算是努力了一個多月的結果，期間對hash算法、存儲格式等絞盡腦汁思考了很久，也因此對云計算倒是考慮得不多，最終偏離了大目標。

好在后續研究基于云計算的價格查詢終于又回到云計算上來了，而且仿照google的map/reduce做了一個標準的jobserver + tasknode形式的實現，雖然兄弟們未必對價格查詢項目看好，但對這個基于windows實現的云計算框架還是一致看好的，價格查詢項目第一階段基本完成預定目標，所以昨天我又將以前md5破解的東西寫了一個在線版的dll，拿到云計算框架里面來試圖云破解，不過這個不是特別成功，主要是即時計算耗時有些多，平均1個task計算1億組合大約需要30秒，因此在我現在只有2個點參與運算的情況下遍歷很大區間是很耗時的，也因此我沒有做一個在線云破解md5的頁面，這個工作作為研究性探索也只在我的控制端下了幾個云計算的任務就告一段落，今后將致力于其他更實用的云計算實踐。

為了做這第二個云計算的dll，我將原來定義的jobtask接口（可參見《基于云計算的價格查詢實現》）修改了一下，不再使用原來的c風格接口，直接改成c++風格了，如下：

interface IJobTask

{

        virtual HMODULE free() = 0;

        //初始化函數，部署環境等

        virtual bool init(bool tasknode) = 0;

        //分割函數，分割輸入

        virtual size_t split(const char *input, size_t len, std::vector<CAutoBuffer *> &vbuf) = 0;

        //task執行函數

        virtual bool map(const char *cmdline, CAutoBuffer &buf, CAutoBuffer &ibuf) = 0;

        //reduce打包輸出函數

        virtual bool reduce(std::vector<CAutoBuffer *> &vbuf, CAutoBuffer &buf) = 0;

        //獲取執行錯誤

        virtual char *geterror() = 0;

};

有朋友批評我，說我的接口使用stl容器，使用自定義類CAutoBuffer等不好，我以前也是這么跟別人講的，接口不要使用這些東西，但看了google的map/reduce實現用的都是MapInput、ReduceInput之后我改變了看法，暫時就這樣定義吧，大不了各個dll都用同一版本的vc編譯就是了，也沒有什么大不了的，如果不行整體升級一下總可以吧，為了短時間盯住主要目標，也只能大刀闊斧不考慮過多細節了，這也算是一個平衡的結果吧。

這次修改除了修改了接口，簡化了實現之外，還實現了一些特性，動態卸載，上一個版本裝入之后就不卸載了，要關閉exe才能卸載這些dll，所以無法熱更新，這個版本實現動態卸載之后就支持熱更新了，關鍵就在那個free函數，

virtual HMODULE free() = 0;

該函數實例如下：

        virtual HMODULE free()

        {

                HMODULE h = m_hlib;

                delete this;

                return h;

        //     if(h) FreeLibrary(h);                這里釋放是有問題的，所以不能這樣釋放

        }

在外部調用的地方

FreeLibrary(jf->free());

這樣就實現了動態卸載dll的功能

用上云計算布局的價格查詢的這段時間，還是有一些經驗教訓的，基于這種相隔很遠，網絡條件差別很大的機器布局的云計算環境，可靠性是很差的，大多數時間可能反應還是比較快，但有的時候反應就特別慢，可能網絡延時會相差200ms，或者500ms，或者更多，我特意記錄了每個task的實際執行時間和包括網絡傳輸在內的總時間，就是從這兩個時間看出差距的，所以如果要基于這種環境做實時性很高的計算還是不適合的，如果對節點反饋實時性要求很高，那一定要布置類似局域網形式的計算環境，點點反饋時間1ms內，而且響應穩定不易受到影響。此外磁盤Log時間是不定的，我記錄最后一個task完成到job完成之間調用了兩次WriteLog，對大多數job來說，最后一個完成的task的時間和job完成的時間一致，但偶爾有少數job時間和最后一個完成的task時間差別很大，甚至有超過1s的，原先沒有這么精細的測量，這次在jobserver寫了很多log，起初是為了找錯誤，后來是為了追蹤job和task執行，倒是意外的發現了一些問題，也獲得了一些意外的收獲。

云計算好啊，早年我做過一個遠程控制的程序，當時做了一條命令broadcast，可以廣播其他任意命令，當時很得意于這個設計，也有指揮千軍萬馬的感覺，但當時各自執行，結果并不匯總，各個任務完全獨立。現在給云計算環境下達一個任務，也有同樣的感覺，可能對使用我的價格查詢(http://www.oldworm.com/pps.aspx)的用戶或者使用google查詢的用戶根本感覺不到，他這一個查詢提交下去后面有那么多機器聯動運算，但作為開發人員，真真切切的看到后面那么多機器在執行任務，真的是很爽的一件事情，一起看下我兩臺機器聯動執行任務的場面共勉吧：

圖看得不是很清楚，實際上第一個taskmanager是一臺機器，另一個taskmanager是另一臺機器，那兩個都是在遠程桌面里面運行的，下面ie是我的網頁，可以看到我在網頁里面查詢nokia的時候，上面兩臺機器的tasknodeapp里面就接收到任務并執行了任務，那個tasknodeapp是我臨時用來演示的，事實上里面都是調用tasknode.dll，tasknode的主要任務都是tasknode.dll執行的，為這個dll做了好幾個不同的容器，有service的有普通mfc的還有console的，這也是我的得意設計哦。

未來還將繼續云計算實踐，期待有相同興趣愛好的朋友一起交流。

基于云計算的價格查詢實現

上篇博客提到價格查詢功能，當時正在考慮做成云計算模式，所以當時連多線程都沒考慮，就是準備將功能都交給云計算系統的，由云計算內部管理線程和調度問題，所以當時實現就根本不用考慮多線程，現在功能基本實現，下面大致講講我的做法。

國內很多人談到全文檢索就必提lucene，提到云計算就必提google的map/reduce、開源的hadoop、amazon的ec2，似乎只有那些東西才叫云計算，咱是實戰派，沒興趣口舌之爭，在俺看來分布式存儲+分布式計算就叫云計算，俺就看了看google的map/reduce論文，照其思想在win下做了個簡單的job/task調度系統，使其能支撐俺的第一個實戰應用價格查詢，圖示如下：

①    、adminclient承擔管理功能，可查看任務及執行情況，可查看Tasknode機器情況，如果需要可管理Task，目前只支持簡單的幾條命令，adminclient主動連jobserver登錄成功后可發送管理命令。

②    、JobOwner提交一個Job之后返回一個jobid，如果意外斷開可通過下次重連的時候提交jobid和一個sessionid可提取job結果數據，job提交通過提交一個zip包即可，參數等文件都打在包里面，tasknode可直接解包執行里面的dll。Jobowner主動連jobserver，登錄成功后可發job命令。

③    TaskNode是執行具體任務的客戶端，job包用zip打包后發布給tasknode，tasknode參與計算并反饋結果。TaskNode設計成多線程模式，一個線程保持和jobserver的通信，其他線程參與運算，Tasknode可同時執行多個不同的任務，如a線程執行價格查詢，b線程執行hash破解等。Tasknode主動連jobserver，登錄后可接受jobserver分派的任務，由于tasknode是主動連jobserver的，所以即使是內網機器或者任意有閑置資源的機器都可作為Tasknode，不管它是家里的、公司的、還是網吧的，這也是該系統基于windows實現的一個重要前提，因為win的機器是如此的多，在國內win的機器無處不在。

JobServer是job調度器，管理包分發以及任務分割、調度，典型的執行流程是這樣，jobowner提交一個命名的包給jobserver，jobserver將該包部署管理，之后jobowner 可給jobserver提交任務，jobserver收到任務后根據任務指定的包配置執行，如部署包后裝載dll并執行任務分割操作，分割是將一個job分割為多個task，之后再將每個task提交給一個tasknode執行，并管理tasknode的輸出以及可能的出錯，出錯現在的處理是交給另一個tasknode執行，當剩下最后一個tasknode的時候會將該tsaknode同步叫給另一個不同的tasknode執行，不管誰最后成功執行這個tasknode，只要該task執行成功立即結束整個job，并將結果反饋給jobowner，jobowner也可在執行中提交查詢命令，jobserver會將被查詢job當前的輸出返回，這樣碰到需要長時間執行的任務也能適用。

從以上介紹可以看到，具體任務是由包執行的，這個包實際上可能是一個dll，也可能是幾個dll加上一些配置文件組成，之所以設計成這種模式，主要是考慮整個系統在win上方便部署，主dll需要支持幾個固定的接口：

//任務dll初始化函數

typedef bool (*jobtask_init_)(jobtaskfunc *jtfunc, bool tasknode);

//map分割函數

typedef size_t (*jobtask_split_)(jobtaskfunc *jtfunc,

                                   const char *input, size_t len,

                                   std::vector<CAutoBuffer *> &vbuf);

//reduce打包函數

typedef size_t (*jobtask_reduce_)(jobtaskfunc *jtfunc,

                                         std::vector<CAutoBuffer *> &vbuf,

                                         CAutoBuffer &buf);

//Task執行函數

typedef bool (*jobtask_map_)(jobtaskfunc *jtfunc, const char *cmdline, CAutoBuffer &outbuf);

//釋放函數

typedef bool (*jobtask_free_)(jobtaskfunc *jtfunc);

上面init函數主要執行線程相關的初始化，該函數典型的可能是空，或者是

CoInitialize(NULL); 等

Split函數是用來將job輸入分割為N個tasknode輸入的，該函數由jobserver調用，每個tasknode輸入就是map函數的輸入，tasknode的任務就是調用map函數，并傳遞輸入，最后將輸出返回給jobserver，jobserver在需要的時候調用reduce將各個tasknode的輸出打包返回，free函數是個輔助函數，釋放資源的。

熟悉google的map/reduce的應該知道，我的實現簡化了reduce，在我的實現里面并沒有獨立的reduce worker，該任務由jobserver自己做了，這一方面是簡化實現，另方面也是適應需求的結果，畢竟在我的需求里面輸入是很少的(一個典型任務100字節量級)，tasknode的計算是很多的，輸出也是不多的（1k量級），所以由jobserver打包整個輸出也很輕松，用不著一組獨立的reduce來管理輸出。另外可以看到上面接口用了我的自定義類CAutoBuffer，這個類主要管理不定長數據的，其實用vector<char>也可，但考慮方便，我的實現內部都用了CAutoBuffer。一個典型的分布式應用只要做一個dll，有上面幾個函數，并輸出一個

struct jobtaskfunc

{

        //初始化函數

        jobtask_init_ init;

        //釋放函數

        jobtask_free_ free;

        //以下被tasknode調用

        jobtask_map_ map;

        //以下被jobserver調用

        jobtask_split_ split;

        jobtask_reduce_ reduce;

};

typedef jobtaskfunc *(WINAPI *create_jobtask_)();

函數即可。

學習map/reduce重要的是學習其思想，并不拘泥于實現形式，我想這大概正是國內環境欠缺的，國內能說得頭頭是道的人太多，能動手干出結果來的人很少，真正坐下來做實事的不多，只喜歡抄抄概念，拿別人的東西過來架設一下，就是這樣的人也能混成大拿。我從map/reduce思想出發，學習其思想，簡化其實現，為實際應用服務，雖然這個東西很簡單，甚至可以說有些簡陋，但實際效果不錯，雖然現在只部署了兩個點，但總體上還是令人滿意的。

實現這個jobserver/tasknode系統并部署價格查詢花了不到兩周時間，實際上花在jobserver、tasknode上的時間大概只有一周多一點，ppsget.dll（具體干活的dll）用正則表達式分析網頁并提取輸出，該dll被應用到多線程環境后也出了一些問題，用boost：：reg的時候居然偶爾會出現異常，原以為boost::reg這樣的應用應該是非常明確的，要么找到，要么沒有找到，除此不應該有第三態，沒想到boost::reg這個不爭氣的東西不但不是二態的，還容易出現異常，試用了一下tr1::regex也是類似的問題，無奈只能在外面包了一層異常處理，雖然不再被異常搞死，但一旦出現異常就是很慢的，要10s左右才返回，現在也沒有特別好的辦法，只在異常的時候將頁面保存，事后分析并改寫正則表達式，盡量將正則表達式做小，將非貪婪式查找用少一點。

下面看看我們價格查詢網站 http://www.shprog.com/pps.aspx 的輸出：

那個360的價格居然是圖片，ocr模塊是俺同事搞的，現在識別率能達到99%以上，還是很不錯的。

花了四天寫了個價格查詢的web體驗版，大致結構是這樣的，前端web界面：

該web通過tcp連接后臺一個ppsserver，ppsserver調用一個ppsget.dll從一些配置好的網站現拉網頁分析產品價格等信息，說起來是很簡單的，要是畫出結構圖來也是很簡單的，看看效果：

為了寫這個東西查了比價網等很多資料，看來看去覺得現在的一些比價網都把自己當購物門戶了，上面什么信息都有，數據都是緩存的，有的還隱藏原始鏈接，用戶點進去也都是緩存的數據，不再鏈接到原始出處，看了幾個網站數據誤差較大，有個網站排在最前面價格最低的鏈接點進去之后發現根本沒有那個低價格，也不知道那個價格信息是什么時候的，或者根本就提取錯了。看了那么多比價網站，時間誤差最小的也超過10個小時，很令我失望，總之我的出發點和這些網站不同，我希望做一個界面很簡潔的、實時查詢的服務，而且速度要求很快，一次查詢速度最好小于1秒，當然我現在技術預覽版離這個目標還差得很遠。界面簡潔使得用戶即使是使用手機也能得到很好的輸出，也不占用多少帶寬，我還希望前端接上條碼掃描功能，這樣很多不會輸入的人就可直接對著條碼就能查詢網店價格，多方便啊，呵呵。不過做這個功能發現技術不是大問題，我4天除了布好了架構還做了5家網店的網頁分析，可見這些基本技術都不太難，最大的矛盾是實時查詢數據量太大，就算只查詢一個產品，分析5個網站的數據加在一起估計接近1M，這要是每秒有個幾百幾千人訪問那還得了啊，得要多大的帶寬才能撐得住啊，難怪看了那么多比價網站沒有一家提供實時查詢的，不是他們做不了實時查詢，的確是因為帶寬太大，所以我想接下來做一套分布式查詢模型，將很多無固定ip的機器接入ppscontrolserver，一起參與為用戶提供查詢服務，今天在看mapreduce，希望自己不要閉門造車，其實很多年前就想做這個功能了，只是一直沒有下手，加上那個時候也沒有一套穩定的網絡庫，現在條件都具備了，希望最近可以做一個簡單的分布式計算框架出來，那樣以后要做類似功能就容易了，可能只要加入一個簡單的dll發布一個計算命令就可以了。這個分布式計算模型做出來之后，傳統的比價網站就只能望俺項背了。

一直想測試一下json的解析速度，前些天終于花了一點時間測了一下，在我的破筆記本上，解析一個包含10個元素（各種類型都有）的object型json，1秒鐘大概只能解析不到10w次，就算把內存池用到極致也只能解析12.5w次左右，換用自己定義的一種bjson格式，速度快了一些，但也不超過20w次，想想工作量也的確很大，生成一個包含10個子元素的object，需要動態分配最少10次，還要做最少10次hash的insert，還有各種格式的轉換工作，里面有array和object還要額外分配容器并處理子對象，這可都是耗時操作，終于明白了為什么webserver為何一秒鐘只能處理幾千個請求甚至只能處理幾百個請求了，看來要將游戲協議完全用json暫時還是不大可取，從效率上看折中點的做法依然是struct+json或struct+string\0string\0…，這些我以前的blog都寫過，只是現在找到了效率上的依據，畢竟游戲服務器一秒都是要處理幾萬數據包的，要是全是json光解析json就把時間耗光了，更不用說去處理其他任務了。

HashCrack跑起來了一段時間，一直沒有寫架構方面的總結，今天在地鐵上畫了一張圖：

照此架構理論上是可以支持非常巨大的后端數據的，如果將web也弄成多個，分別連不同的SN則可支持非常巨大的用戶量。

從開始研究HashCrack兩個多月了，雖然中間忙其他項目間斷了近一個月，但總的耗在HashCrack上的時間也有一個多月，最近幾天又把web部分完善了一下，順便做了其他幾種加密算法，現在HashCrack支持MD5、SHA1、MYSQL5HASH、QQHASH四種算法，每種算法都制造了46億數據，總共占磁盤34.2 * 3G，qqhash和md5復用同一份數據。好在之前架構做得比較好，換一種加密算法只要換兩個函數即可，所以加后面三種算法只花了1天時間。為了讓界面更友好一點，臨時學了下ajax，并學習了一下.net里面調用c++ dll，順便用c++做了一個dll提供四種算法的加密供web調用。新web頁面地址是 http://www.shprog.com/hashCrack.aspx，部分界面如下：

看上去一個簡單頁面，背后2服務器程序（1web 1 hashcrackserver），103G數據，3個dll（hashencrypt.dll, page.dll, data.dll)，一個制造數據的exe，還有一個client工具，那工具好久沒升級了，client工具支持一次多條查詢。Hashcrackserver支持分布，client端工具也支持數據分布和運算，總的是一個云計算系統。

現在覺得我的這個頁面比www.cmd5.com www.md5.com.cn免費版有價值一點，他們雖然總的數據可能多一些，但開放的數據很少，特別mysql5 qqhash sha1要么沒有，要么沒開放或只開放了一點點數據，對免費用戶實際用處不大。

HashCrack程序數據及索引設計2

上個月寫了《HashCrack程序數據及索引設計》里面已經提到早期設計的幾種存儲方法，最后達到了每條記錄15個字節左右的水平，但這個存儲效果還是很差的，而且是單體文件，受制于內存限制，后來又設計了幾種復合索引格式，支持1萬億記錄一個復合索引，下面簡單講講之后的研究成果。

6、將內容區和索引區合并，索引位置不再提供指向內容區的size_t，內容區不再需要，直接在索引區，這樣索引區indexnode

Struct indexnode

{

        Size_t nextoffset;

        Char str[0];

};

經過此修改之后稍微不好的地方就是如果一個文件里面要管理不同長度的字符串那么只能取最長的字符串長度，以便indexnode保持相同大小容易索引。

這種方法雖然效果不錯，但平均下來一個字符串還是要占用11個左右的字節，而且不同長度的字符串有一些浪費的地方。

7、以上的存儲方法雖然已經比較緊湊，但還不是最緊湊的方法，如果不保存字符串只是保存字符串在序列中的位置，那么不同字符串也沒有長度不同，也可以用同樣的大小去保存，如果一個db保存42億以下的字符串，那么只要4個字節就可以了，如果一個db保存1萬億以下的數據，那么只要5個字節就可以，這真是個非常有創意的想法，其實我當初想到這個想法的時候很擔心計算效率，遲遲沒有動手代碼，但思考了幾天之后打消了我對效率的擔心，相反，只保存一個position比復制N個字符串可能還要快一點，這樣我們就只要9個字節描述indexnode了，看定義：

Struct indexnode

{

        Size_t lpos;

        Byte hpos;

        Size_t nextoffset;

};

精確到9個字節表示一條記錄，很不錯，也沒有更多的限制。事實上9字節版本的速度比方法6的確是要快一點，還沒優化的時候就比6方法要快一些了，當然查詢的時候由于要多計算一些信息，理論上是要慢一點的，但由于都是內存計算，其實影響不是很大。

8、上述9個字節的方法雖然已經很緊湊，但如果給nextoffset做一點限制，讓一個區段的數據為1667w以下，那么描述nextoffset 只需要3個字節即可，這樣indexnode總的長度就只需要8個字節，這真是很好的想法，我為這個想法驕傲，看下indexnode的8字節版本

Struct indexnode

{

        Size_t lpos;

        Size_t hpos:8;

        Size_t nextoffset:24;

};

精確的8字節indexnode，如此我們最終實現了最緊湊的md5數據庫，每條記錄8個字節，幾乎無法再減少了，期待哪天突然靈光閃現再創造出更緊湊的存儲方法吧，呵呵，這個實現其實已經超越了我最初的估計了，我以為能減少到12個字節已經到頂了，沒想到還能減少到8個字節。

8字節的版本最初寫出來的時候效率下降得很厲害，因為以前nextoffset當指針用，現在3個字節無法當指針，只能轉換，多一個轉換函數效率下降了一些，其他地方剛寫的時候也是非優化算法，所以第一個8字節版本效率比9字節降低了一半以上，但花了一個早上優化之后效率又上去了，現在制造復合索引只需要82秒就可完成1億條記錄，速度比方法6快不少，方法6需要120秒左右。

或許我講得比較簡單，如果不是深入研究這一塊的人或許看不明白，但精華我基本上講出來了，實現上其實有很多技巧，如果要做到象我一樣的速度其實是需要很深功力的，我測試用的機器是朋友的入門級服務器E5504 2.0cpu，4G內存，普通7200轉硬盤。

從需求角度看NOSQL發展

早先當640kb就足夠使用的觀點流行的時候，數據處理規模很小，需求也不多，于是簡單的文件存儲即可滿足需求，發展一段時間之后ISAM之類的簡單存儲就可滿足需求，再之后sql流行，當sql為了適應各種需求變得越來越龐大的時候，效率也止步不前，在將緩存和多線程性能榨取完了之后，sql各項性能還只停留在滿足常規應用的地步，難于處理1秒萬次以上的讀寫操作，也難于解決萬個以上的并發連接，一般的企業不可能動不動就上硬件，所以nosql發展是時代的需要是需求的推動。當然一般sql對傳統企業還是足夠滿足的，所以我們在nosql的發展上沒看到傳統企業的身影，只看到當前發展最快的SNS公司積極推動nosql不斷發展，著名的如：Facebook 推動Cassandra發展，Linkedin推動Voldemort發展，這都是最大的一類sns網站，這些網站都有幾千萬以上的用戶，巨量數據讀寫，所以這些數據庫都是極其強調分布式應用的，并不單純的強調每個點的讀寫性能。再看小一點的mixi推動的Tokyo Cabinet和Tokoy Tyrant，green.jp推動Flare的發展，這些數據庫都滿足于幾千萬條數據的高速訪問，也沒看到特別的強調并發性，只強調他們的速度，當然幾千萬條數據還是有可能全放在內存里面的，就算放不下全部數據也至少可完全放下全部索引，這樣讀寫當然快了，據說tt到億條之后寫性能急劇下降，大概就是這個原因吧。純內存式數據庫也必須要提一下，典型的如LiveJournal開發的memcached以及另一個新秀Redis等，前面提到的tt也支持memcached的協議，雖然這類數據庫有很多局限，但在某些場合的確又很適合，memcahced其實連持續存儲都不支持，為了解決持續存儲問題，又有人發展了一些，如tt其實就是一個支持存儲的memcached，國內新浪團隊也給memcached加上berkeleydb支持持續存儲。

上面說了這么多，無非想說一句話，需求推動技術進步，每一個技術進步其實都是為了滿足某種需求的結果，就如google的三大基石bigtable、gfs、map/reduce都是為了解決它的巨量數據而折騰出來的東西，google也正是靠這幾個核心技術把持了互聯網近十年的風光。同理我們可以想見，雖然百度沒有大力的宣傳他們的底層技術，但我們很容易想到，他們一定也是需要這些技術的，而且他們內部就算沒有這些技術，但一定有類似的接替代產品，否則支撐不了他們那么巨量的數據，雖然替代產品未必有google的產品那么好，但大概是略差一點或相當的水平吧。國內互聯網巨頭騰訊支持了國內最大的im應用 10億級，最大的棋牌游戲近億在線，加上他們布局網絡門戶，布局qzone等，都是巨量用戶，可以想見他們一定有類似的方案，早先聽說他們棋牌游戲是通過很多mysql + proxy來完成的，雖然這個方式現在看起來也不是很完美，但至少是一個可行的解決方案，臆測下可以這樣使用，proxy有個巨大的hash表，每個qqid計算一下就知道在哪個區段，重定向到哪個區段讀寫數據即可，說起來容易做起來難啊，就算我玩種菜都不知道遇到多少次他們數據出故障了，說明他們的系統面對巨大數據壓力的時候還是碰到了很多問題。國內還有個公司不得不提，阿里巴巴淘寶，馬云團隊發跡很快，淘寶每年不知道要成交多少筆，但他們的數據也是一個天量，看了下他們dba團隊的主頁，牛一點的dba都籠絡了不少，就是自己開發能力稍弱了一點，縱觀國內對巨量數據需求最迫切的也就這幾家公司了，雖然之后的51、開心網、盛大等也有類似需求，但數據量總歸還是沒有超過前面幾家公司。

在需求的推動下，國內的nosql、key-value應用也慢慢發展了一些，如張宴在新浪搞的memcachedb，到金山之后搞的dbcached，豆瓣開發的beansdb等，還有一些沒開源沒介紹不大為外界知道的應該也有一些，但總的來看水平還是比較低，有點不成氣候的樣子，靠的大多是1-2個牛人支撐，離開了這么幾個人就不行了，東西也沒人維護，的確，離開了巨量數據的需求一般的企業用sql就能滿足也不會去研究這些東西，少數小一點的互聯網企業有這個需求又沒有相應的人才有能力去研究，年輕一點的開發人員都在玩概念想做也做不出這些東西，畢竟做這些東西沒有很深厚的數據結構知識，沒有3-5年的深入編程磨練是不可能真正做好一個像樣東西的，矛盾啊。

最后說下我最近在做的一個東西，分布式md5計算，這個東西網上隨便查一下就知道做的人不少，提供網站服務的都不少，但搜了幾篇文章，看了幾個網站www.cmd5.com www.md5.com.cn就知道，水平之低下超出了我的想象，基本上還是停留在用sql數據庫的層次上，根據這些網站寫的時間節點感覺他們大多數時間就是在制造數據，速度大概是幾個月制造幾十億條數據，都號稱有幾萬億條數據，但事實上提供公開查詢的數據只有區區幾億條，其他都要收費才能查詢，天知道到底有沒有那幾萬億條記錄，看上很吸引人，其實用處不算很大，用我最近整的md5數據制造方法1秒制造100w條數據，1億條數據也就在2分鐘內搞定，幾億條數據也不過10分鐘左右就生成好了，1億條記錄耗費空間1.5G左右，不過10G左右空間即可，技術含量可見并不是很高。 其實我做這個項目并不是想做個類似的網站，主要是覺得這個東西玩技術很有意思，可大可小，一臺機器也可玩，1T硬盤放600億數據沒問題，1萬臺機器也不多，全字母遍歷到10位就算是上1w臺機器也不夠用，分布式存儲分布式計算典型云計算概念，client可p2p可不p2p，很多技術元素都可參與其中，很有玩性的一個程序，所以就較上勁了，也好，正好練練技術，玩玩nosql的概念。

各種新興技術出來都看到國內有深入分析，就說nosql系列的吧，深入分析memcached，深入分析tt，深入分析Cassandra的文章不計其數，到底也沒看到有幾個國人能寫類似的東西，分析得頭頭是道，做的時候白癡一樣，就算是使用都難用好，更別說自己動手做個這方面的好產品了，國情如此，略感欣慰的是國內現在也有一些公司和一些高水平的人真正參與其中，未來還是有可能有所突破的，正入本文所說，需求會推動技術發展，但短期肯定還是國外為主，國內的產品最多是一絲點綴。