[原創]HandlerSocket系列（一）：由來

新的技術，幾乎都是由需求驅動產生的。在仔細深入研究HandlerSocket之前，我覺得有必要先瞭解一下它所處的曆史背景及其它想解決什麼樣的問題。我想這應該是最關鍵的，也是做這方面研究和技術選型時第一個應該關注的要點。

 

先來說一下它的作者Yoshinori Matsunobu，現為DeNA公司的資料庫和基礎設施架構師，HandlerSocket就是Yoshinori在DeNA公司工作時開發的。DeNA是一家來自日本的社交遊戲開發商，目前在日本已經算是數一數二的社交遊戲公司，並且在全球展開過一系列的收購，收購了大量的美國遊戲廠商，屬於一個發展勢頭非常猛的公司，並且現有使用者和活躍度都算挺高的。對於這樣一個公司的應用來說，我覺得資料訪問方面最關注的應該是這幾個要點：海量資料、高並發和熱點問題。

 

對於這樣的一些典型的互連網應用在發展到一定程度了都會碰到的問題，肯定也是業界都會面臨和關注的問題。所以，大家其實可以看到，從08年開始有個詞開始頻繁的出現，它就是“NoSQL”。從08年開始，NoSQL逐漸的火熱起來，各大互連網公司都有這方面的動作，各種NoSQL產品雨後春筍般的出現。甚至於在09年年初時候，如果你關注這方面架構設計方面的人的Twitter，你可以看到很多類似下面這樣的言論，比如Tim Yang說的：這年頭，如果一個號稱有“海量資料”的互連網公司，不做一個自己的Dynamo, 出去都不好意思跟人打招呼（註： Dynamo是 Amazon開發的一個NoSQL產品，Amazon發布了Dynamo的Paper: “Dynamo: Amazon’s Highly Available Key-value Store“。由於它提出和探討了Scale Out和Failure Handling等很多NoSQL產品都會面臨的問題，使得它與BigTable的Paper差不多並稱為NoSQL 研究前必須先通讀的2個Paper，這兩個Paper在網上都可以很容易找到）。當然了，這是一個比較誇張的說法了，但是從側面也可以反映出，對於具有海量資料和高並發的互連網應用來說，NoSQL是一個不錯的選擇。在NoSQL出現之前，大部分互連網應用採用的都是MySQL+Memcached的方案。

 

NoSQL，意為”Not Only SQL”，而不是”No SQL”，並不是要來取代關係型資料庫的，而是作為關係型資料庫的補充，我相信在未來很長時間內，應該是兩者共同發展。因為從應用情境來看，兩者是互補關係，而不是替代關係。對於NoSQL產品來說，由於具有水平伸縮性、高並發讀寫效能、高可用等優勢，但是同樣的，有這些優勢也是需要付出代價的，比如絕大部分都是只支援Key-Value 操作、有限制的查詢功能、不能使用類似Join等這樣的功能、大部分為最終一致性模型、還沒有標準化等等，而且由雩都剛發布不久，穩定性方面和系統的營運也是應該謹慎考慮到的。基於NoSQL產品的這些特點，對於像類似微博、Feed等這樣的互連網應用來說，是非常合適的。因為這樣的應用一般業務複雜度都不高，不需要複雜的Join查詢等功能，可以接受最終一致性等，但是由於需要高並發讀寫和具有海量的資料，這樣的應用最適合使用NoSQL。而對於大部分應用，NoSQL可能暫時或者以後可能都不會支援，特別是對於一些公司資訊系統，關係型資料庫可能是最好的選擇。

 

DeNA和其他互連網應用都遇到的高並發讀寫、海量資料等的問題，用NoSQL是一個不錯的選擇。但是由於NoSQL發布的時間都相對比較短暫，穩定性方面還需要謹慎考慮，同時營運方面也要有所準備。在做好各種功能測試和效能測試後，最好還是需要有能力能駕馭原始碼，在出現問題的時候能更好的定位、排查和解決問題，特別是對於大型的應用來說。這一點可以從之前發生的一些事情得到驗證，Digg選擇Cassandra，但是後來出現了一些很嚴重的事故，副總甚至為此引咎辭職。Foursquare選擇了Mongodb，但是在前段時間出現了幾次宕機。對於新產品來說，在發展的過程中肯定會碰到各種各樣的問題，但是會逐步完善和穩定下來，這需要一段時間。如果我們選擇在未穩定前使用的話，最好盡量保證有能力來駕馭它們。

 

我相信肯定有一些朋友也在犯愁了，我是需要NoSQL這樣的產品，但是我真的承受不起可能由於不穩定帶來的一些問題，同時，營運同事們最熟悉的是傳統的關係型資料庫，比如MySQL、Sql Server、Oracle等，對於這些他們身經百戰，但是對於大部分NoSQL產品，則都比較陌生，需要去學習和積累經驗，需要比較大的營運成本。其實，有關注過NoSQL的朋友，可能也都看過了類似這樣的一些文章：為什麼NoSQL比傳統關係型資料庫效能高？ 這些文章都會大同小異的這樣來分析：“由於傳統的關係型資料庫在處理每個請求的時候，需要做SQL解釋、查詢最佳化、解釋執行、交易管理、鎖管理等等一系列操作，損失了很多效能。但是往往一些對效能要求非常高的應用，比如微博、Feed等，是不需要這些操作的，NoSQL就是由於去掉了這些操作效能上有了很大的提高（當然NoSQL產品在其他方面上也有做了不少最佳化）”。

 

其實有些朋友可能也想過，比如對於MySQL資料庫來說，從整體上來看，是分為兩層：SQL層和Storage層。前面說的NoSQL拋棄掉的那些SQL解釋等的操作，其實都是在SQL層的，如果把MySQL的SQL層去掉，直接跟Storage互動，效能不就能提高不少？我相信有不少人也這樣想過，但是一直都沒有人去做這事情。Yoshinori就是做了這樣的一件事情，這個產品就是HandlerSocket。通過HandlerSocket直接跟MySQL的Storage層互動，而省去了SQL層的那些操作。Yoshinori之前是Sun/Oracle的MySQL開發和諮詢顧問，所以實現這樣的一個產品還是相對比較有優勢。

 

作者：洪小軍
出處：http://www.cnblogs.com/inrie

轉載請註明出處，謝謝！