HandlerSocket的原理

HandlerSocket的應(yīng)用場景：

MySQL自身的局限性，很多站點都采用了MySQL+Memcached的經(jīng)典架構(gòu)，甚至一些網(wǎng)站放棄MySQL而采用NoSQL產(chǎn)品，比如Redis/MongoDB等。不可否認(rèn)，在做一些簡單查詢（尤其是PK查詢）的時候，很多NoSQL產(chǎn)品比MySQL要快很多，而且前臺網(wǎng)站上的80%以上查詢都是簡潔的查詢業(yè)務(wù)。

MySQL通過HandlerSocket插件提供了API訪問接口，在我們的基準(zhǔn)測試中，普通的R510服務(wù)器單實例Percona/XtraDB達(dá)到了72W+QPS（純讀），如果采用更強勁的CPU增加更多的網(wǎng)卡，理論上可以獲得更高的性能。而同等條件下Memcached僅有40W+QPS（純讀），并且在R510上Memcached單實例已經(jīng)無法提升性能，因為Memcached對內(nèi)存的一把大鎖限制了它的并發(fā)能力。

HandlerSocket原理：

MySQL的架構(gòu)是“數(shù)據(jù)庫管理”和“數(shù)據(jù)管理”分離，即MySQL Server+Storage Engine的模式。MySQL Server是直接與Client交互的一層，它負(fù)責(zé)管理連接線程，解析SQL生成執(zhí)行計劃，管理和實現(xiàn)視圖、觸發(fā)器、存儲過程等這些與具體數(shù)據(jù)操作管理無關(guān)的事情，通過調(diào)用Handler API讓存儲引擎去操作具體的數(shù)據(jù)。Storage Engine通過繼承實現(xiàn)Handler API的函數(shù)，負(fù)責(zé)直接與數(shù)據(jù)交互，數(shù)據(jù)存取實現(xiàn)（必須實現(xiàn)），事務(wù)實現(xiàn)（可選），索引實現(xiàn)（可選），數(shù)據(jù)緩存實現(xiàn)（可選）。

HandlerSocket是在MySQL的內(nèi)部組件，以MySQL Daemon Plugin的形式提供類似NoSQL的網(wǎng)絡(luò)服務(wù)，它并不直接處理數(shù)據(jù)，只是偵聽配置好的某個端口方式，接收采用NoSQL/API的通訊協(xié)議，然后通過MySQL內(nèi)部的Handler API來調(diào)用存儲引擎（例如InnoDB）處理數(shù)據(jù)。理論上，HanderSocket可以處理各種MySQL存儲引擎，但是用MyISAM時，會出現(xiàn)插入的數(shù)據(jù)查不出來，這個實際上是構(gòu)造行時第一字節(jié)沒有初始化為0xff，初始化以后就沒有問題，MyISAM也一樣可以支持，但是為了更好地利用內(nèi)存，用HandlerSocket都會搭配InnoDB存儲引擎一起使用。

圖1-2描述HandlerSocket具體做了哪些事情：

因為HandlerSocket是以MySQL Daemon Plugin形式存在，所以在應(yīng)用中，可把MySQL當(dāng)NoSQL使用。它最大的功能是實現(xiàn)了與存儲引擎交互，比如InnoDB，而這不需要任何SQL方面的初始化開銷。訪問MySQL的TABLE時，當(dāng)然也是需要open/close table的，但是它并不是每次都去open/close table，因為它會將以前訪問過的table cache保存下來以重復(fù)使用，而opening/closing tables是最耗資源的，而且很容易引起互斥量的爭奪，這樣一來，對于提高性能非常有效。在流量變小時，HandlerSocket會close tables，所以它一般不會阻塞DDL。

HandlerSocket與MySQL+Memcached的區(qū)別在哪呢？對比圖1-2和圖1-3，可從中看出其不同點，圖1-3展示了典型的MySQL+Memecached的應(yīng)用架構(gòu)。因為Memcached的get操作比MySQL的內(nèi)存中或磁盤上的主鍵查詢要快很多，所以Memcached用于緩存數(shù)據(jù)庫記錄。若是HandlerSocket的查詢速度和相應(yīng)時間能與Memcached媲美，我們就可以考慮替換Memcached緩存記錄的架構(gòu)層。

HandlerSocket的優(yōu)勢和缺陷闡述

HandlerSocket的優(yōu)勢和特點：

1) 支持多種查詢模式

HandlerSocket目前支持索引查詢（主鍵索引和非主鍵的普通索引均可），索引范圍掃描，LIMIT子句，也即支持增加、刪除、修改、查詢完整功能，但還不支持無法使用任何索引的操作。另外支持execute_multi() 一次網(wǎng)絡(luò)傳輸多個Query請求，節(jié)省網(wǎng)絡(luò)傳輸時間。

2) 處理大量并發(fā)連接

HandlerSocket的連接是輕量級的，因為HandlerSocket采用epoll() 和worker-thread/thread-pooling架構(gòu)，而MySQL內(nèi)部線程的數(shù)量是有限的（可以由my.cnf中的handlersocket_threads/handlersocket_threads_wr參數(shù)控制），所以即使建立上千萬的網(wǎng)絡(luò)連接到HandlerSocket，也不會消耗很多內(nèi)存，它的穩(wěn)定性不會受到任何影響（消耗太多的內(nèi)存，會造成巨大的互斥競爭等其他問題，如bug#26590，bug#33948，bug#49169）。

3) 優(yōu)秀的性能

HandlerSocket的性能見文章HandlerSocket的性能測試報告描述，相對于其它NoSQL產(chǎn)品，性能表現(xiàn)一點也不遜色，它不僅沒有調(diào)用與SQL相關(guān)的函數(shù)，還優(yōu)化了網(wǎng)絡(luò)/并發(fā)相關(guān)的問題：

(1). 更小的網(wǎng)絡(luò)數(shù)據(jù)包：和傳統(tǒng) MySQL 協(xié)議相比，HandlerSocket 協(xié)議更簡短，因此整個網(wǎng)絡(luò)的流量更小。

(2). 運行有限的MySQL內(nèi)部線程數(shù)：參考上面的內(nèi)容。

(3). 將客戶端請求分組：當(dāng)大量的并發(fā)請求到達(dá)HandlerSocket時，每個工作線程盡可能多地聚集請求，然后同時執(zhí)行聚集起來的請求和返回結(jié)果。這樣，通過犧牲一點響應(yīng)時間，而大大地提高性能。例如，可以減少fsync()調(diào)用的次數(shù)，減少復(fù)制延遲。

4) 無重復(fù)緩存

當(dāng)使用Memcached緩存MySQL/InnoDB記錄時，在Memcached和InnoDB Buffer Pool中均緩存了這些記錄，因此效率非常低（實際上有兩份數(shù)據(jù)，Memcached本身可能還需要做HA支持），而采用 HandlerSocket插件, 它直接訪問 InnoDB 存儲引擎，記錄緩存在InnoDB Buffer Pool，于是其它SQL語句還可以重復(fù)使用緩存的數(shù)據(jù)。

5) 無數(shù)據(jù)不一致的現(xiàn)象

由于數(shù)據(jù)只存儲在一個地方（InnoDB存儲引擎緩存區(qū)內(nèi))，不像使用Memcached時，需要在Memcached和MySQL之間維護數(shù)據(jù)一致性。

6) 崩潰安全

后端存儲是InnoDB引擎，支持事務(wù)的ACID特性，能確保事務(wù)的安全性，即使設(shè)置innodb_flush_log_at_trx_commit=2，若數(shù)據(jù)庫服務(wù)器崩潰時，也只會丟掉<= 1s的數(shù)據(jù)。

7) SQL/NOSQL并存

在許多情況下，我們?nèi)匀幌Ｍ褂肧QL（例如復(fù)雜的報表查詢），而大多數(shù)NoSQL產(chǎn)品都不支持SQL接口，HandlerSocket僅僅是一個 MySQL 插件，我們依然可以通過MySQL客戶端發(fā)送SQL語句，但當(dāng)需要高吞吐量和快速響應(yīng)時，則使用 HandlerSocket。

8) 繼承MySQL的功能

因為HandlerSocket運行于MySQL，因此所有MySQL的功能依然被支持，例如：SQL、在線備份、復(fù)制、HA、監(jiān)控等等。

9) 不需要修改/重建MySQL

因為HandlerSocket是一個插件并且開源，所以它支持從任何MySQL源碼、甚至是第三方版本（例如Percona）構(gòu)建，而無需對MySQL做出任何修改。

10) 獨立于存儲引擎

雖然我們只測試了MySQL-EnterpriseInnoDB和Percona XtraDB插件，但HandlerSocket理論上可以和任何存儲引擎交互。MyISAM通過簡單的修改也是可以被支持的，但是從數(shù)據(jù)緩存而利用內(nèi)存的角度看這個意義不大。

HandlerSocket的缺陷和注意事項

1) 協(xié)議不兼容

HandlerSocket API與Memcached API并不兼容，盡管它很容易使用，但仍然需要一點學(xué)習(xí)來學(xué)會如何與HandlerSocket交互。不過我們可以通過重載Memecached函數(shù)來翻譯到HandlerSocket API。

2) 沒有安全功能

與其它NoSQL數(shù)據(jù)庫類似，HandlerSocket不支持安全功能，HandlerSocket的工作線程以系統(tǒng)用戶權(quán)限運行，因此應(yīng)用程序可以通過HandlerSocket協(xié)議訪問所有的表對象，但是可以通過簡單的修改協(xié)議，在my.cnf中增加一個配置項為密碼，連接時通過這個配置的密碼驗證，當(dāng)然也可以通過網(wǎng)絡(luò)防火墻來過濾數(shù)據(jù)包。

3) 對于磁盤IO密集的場景沒有優(yōu)勢

對于IO密集的應(yīng)用場景，數(shù)據(jù)庫每秒無法執(zhí)行數(shù)千次查詢，通常只有1-10%的CPU利用率，在這種情況下，SQL解析不會成為性能瓶頸，因此使用HandlerSocket沒有什么優(yōu)勢，應(yīng)當(dāng)只在數(shù)據(jù)完全裝載到內(nèi)存的服務(wù)器上使用 HandlerSocket。但是對于PCI-E SSD（例如Fusion-IO）設(shè)備，每秒可以提供4w+ IOPS，并且IO設(shè)備本身消耗CPU比較大，使用HandlerSocket依然具有優(yōu)勢。

HandlerSocket的性能測試

HandlerSocket Oprofile測試報告

 

 

MySQL執(zhí)行SQL語句，首先要經(jīng)過SQL解析階段，調(diào)用MYSQLparse() 和MYSQLlex() 進行語法和詞法解析；然后進入查詢優(yōu)化階段，調(diào)用make_join_statistics() 和JOIN::optimize() 獲得統(tǒng)計信息和生成執(zhí)行計劃，可以清洗第發(fā)現(xiàn)，主要耗資源的是SQL解析和優(yōu)化層，而不是InnoDB存儲層，row_search_for_mysql只消耗了很少的時間。

因此我們對比Memcached/NoSQL，知道MySQL除了數(shù)據(jù)操作，還要很多額外的步驟需要完成：

1 Parsing SQL statements【解析SQL】

2 Opening, locking tables【打開并鎖定表】

3 Making SQL execution plans SQL【解析SQL并生成執(zhí)行計劃】

4 Unlocking, closing tables【解鎖并關(guān)閉表】

另外，MySQL 還必須要做大量的并發(fā)控制，比如在發(fā)送/接收網(wǎng)絡(luò)數(shù)據(jù)包的時候，fcntl() 就要被調(diào)用很多次；Global mutexes比如LOCK_open，LOCK_thread_count也被頻繁地取得/釋放。所以在Oprofile的輸出中，排在第二位的是my_pthread_fastmutex_lock()。并且Mutex的競爭帶來的上下文切換，導(dǎo)致%system占用CPU使用比例相當(dāng)高（>20%）。

其實， MySQL 開發(fā)團隊和外圍的開發(fā)團體早已意識到大量并發(fā)控制對性能的影響，MySQL 5.5中已經(jīng)解決了一些問題，Percona也對Mutex做了一些拆分處理，未來的MySQL版本中，也應(yīng)該會越來越好。

在完全內(nèi)存操作的情況時，CPU的效率非常重要。如果只有一小部分?jǐn)?shù)據(jù)進入內(nèi)存，那么SQL語句帶來的消耗可以忽略不計。很簡單，因為機械磁盤IO操作的時間消耗遠(yuǎn)比CPU解析SQL語句的時間消耗多，這種情況下，就不需要過分考慮SQL語句所帶來的消耗。但是對于SSD盤，尤其是PCI-E SSD盤，響應(yīng)時間在微秒級（Fusion I/O為30us左右），就必須考慮SQL帶來的消耗了。

在大多數(shù)的MySQL 服務(wù)器中，大部分的熱點數(shù)據(jù)都緩存在內(nèi)存中，因而訪問變得只受CPU的限制。Profiling 的結(jié)果就類似上所述的情況：SQL 層消耗了大量的資源。假設(shè)需要做大量的PK查詢（例如：SELECT x FROM t WHERE id=?）或者是做LIMIT的范圍查詢，即使有70-80%都是在同一張表中做PK查詢（僅僅只是查詢條件中給定的值不同，即value不同而已）， MySQL 還是每次需要去做 parse/open/lock/unlock/close， 這對我們來說是非常影響效率的事情。

HandlerSocket性能測試報告：

【測試主機】

機型：R510

CPU：Intel(R) Xeon(R) CPU E5520 @ 2.27GHz

內(nèi)存：4G*6

磁盤：146G*2(OS) + 300G*12 RAID10(data)

 1) 完全隨機測試

測試場景描述：

單實例MySQL 5.1.48 InnoDB Plugin

測試SQL：INSERT INTO table (key, value) VALUES(#key#, #value#) / SELECT value FROM table WHERE key=#key#

HS API：execute_single

2) 重復(fù)獲取同一條數(shù)據(jù)

測試場景描述：

1 單實例Percona 5.1.57-12.8 XtraDB

2 測試SQL：SELECT value FROM table WHERE key=#key#

3 HS API：execute_single

4 MC API：get

 在《php核心技術(shù)與最佳實踐》第11章第2節(jié)介紹了handlersocket的使用方法，可以參考一下。