solr官網：
我在學校專案實踐時使用過solandra，它是乙個基於solr和nosql資料庫cassandra的分布式搜尋引擎。cassandra是由facebook開源的nosql數
據庫，facebook的信箱搜尋就是基於它實現的，它是基於列結構的，不同與關聯式資料庫。它的數學模型基於google的bigtable和amazon的dynamo，
它的乙個重要特性是沒有對外沒有中心節點，所以不會存在單點故障的問題，如果當前豬節點掛了，那麼它餘下的節點會進行自動投票，選舉出新的
節點，這種特性未來必定是所有分布式系統的特性之一。它是當前熱門的nosql資料庫之一。
我看了下它的原始碼，它從底層上重新實現了solr索引的
儲存，把索引資料儲存到cassandra中。它的這種實現方式給了我乙個思路，就是lucene和nosql資料庫結合的可行性。由於solandra的零配置和自
動發現的特性，很容易就部署起來，基本上一啟動服務就行了。我把原先用於測試的200萬資料導浸solandra中，它完全是黑盒模式的，你根本不知
道你的資料分布到了那台機器，你可以設定副本數來冗餘資料，增加可用性和容錯性。
導完資料就對它進行效能測試，發現它的第一次查詢效率非常
低，平均查詢時間4秒，比原生的solr低了很多，我猜測這裡效能的差距主要是因為它把索引儲存cassandra中，原本的是直接儲存到檔案系統中的
，現在是先從資料庫讀取到檔案系統，多了一步，所以查詢效率有所差異，不過這樣的好處是真正實現了索引的分布式儲存。想到如果執行當中有台
機器掛了怎麼辦？於是就開始測試它的容災性，結果發現，如果是乙個3台機的solandra機器，掛了其中一台機還是可以查的，但是如果掛了兩台機
就搜尋不出東西。這是因為我把索引的副本定義為2即集群中有兩份完整的索引。由於它索引不可見的黑盒特性我們並不知道它實際上索引的分布情
況，這樣的話對後期索引的維護並不好。加上它查詢效率的問題，最終放棄該方案。
solandra專案主頁：
逛solr官網時無意發現了solrcloud這個開源專案，即solr雲或叫分布式solr。它是基於solr的，使用zookeeper作為節點之間通訊管理，它具有
solr的所有特徵，並提供索引分片的功能，不過這是要自己在配置檔案中配置分片資訊的。它好的地方是它是個實時的搜尋引擎，即將推出的
lucene4.0將實現實時搜尋，而solrcloud就是基於開發中的lucene4.0的，目前solrcloud也是個本成品，本著試試的心態根據官方配置文件搭建了
乙個三颱機器，三個分片的分布式環境並對其進行測試。查詢效率與三颱機的solr集群差不多，都比較快。不過它的搜尋介面很不好，你要在請求的
。還有乙個不好的地方是和solr一
樣，建立索引時它沒有自動給你做負載均衡，如果你一直往分片1中插資料它也不管你的，你要自己程式設計去完成索引的均衡分配，這樣的話工作量就
很大了。於是放棄solrcloud。
solrcloud專案主頁：
乙個叫katta的開源專案進入我的視線，它是乙個分布式索引建立和管理工具，底層是hadoop的hdfs分布式檔案系統，hadoop是當今雲計算的熱門使
用專案，由apatch開源是乙個海量資料的處理和儲存方案，它的主要核心就是它的hdfs分布式檔案儲存系統和mapreduce演算法，它們分別是google論
文中的gfs和mapreduce的開源實現。目前大公司的雲計算平台基本上都是基於它來搭建的。因為我之前在學校做的乙個搜尋引擎專案也是基於它的，
所以我對它還是比較熟悉的，通過之前寫過的自動化部署指令碼，我很快就搭起了乙個由4臺機器組成的hadoop集群，每台機160g的硬碟，乘於4的話就
是640g了，而且這640g還是乙個整體來的哦，以後如果空間不夠了，或者運算能力不夠了的話就直接加機器就行了，使用hadoop可以非常容易的提高
整個系統的運算能力，google的核心技術之一就它了。而katta這個專案只是個lucene的索引管理工具，通過hadoop的mapreduce演算法來批量建立索
引，它的很大部分特性都是參考了nutch（乙個基於hadoop的開源爬蟲專案），它提供的搜尋功能很弱，只有最基本的查詢方法，一些高階的如：分
組，統計，範圍查詢都沒有的，於是試試看看能否把它和solr進行整合，因為solr提供了很強大的搜尋功能，網上搜尋發現有人已經研究實現它了，
就是這個帖子
，不過配置過程極其複雜，而且還要該很多的原始碼，我看那帖子是從10年就開始
了的，他們的討論已經持續一年多了，貌似還沒有什麼結果，可見難度還是比較大的。就沒有深入去了解。
katta官網：
最後發現了elasticsearch這個分布式搜尋框架，我一看它的介紹就覺得，就是它了。它基本上所有我想要的特性都包含了，分布式搜尋，分布式索
引，零配置，自動分片，索引自動負載，自動發現，restful風格介面。於是就開始使用，部署了四台機器，並把索引導了進去，我設定的分片為3，
即把索引分成三片，副本為2，即有兩份完整的索引。
通過它的管理工具可以很清晰的看到它索引分布的情況：哪塊分布在那裡，占用空間多少都可
以看到，並且可以管理索引。還發現當一台機掛了時，整個系統會對掛機裡的內容重新分配到其它機器上，當掛掉的機重新加入集群時，又會重新把
索引分配給它。當然，這些規則都是可以根據引數進行設定的，非常靈活。對它的搜尋效率進行測試，查詢時間基本上維持在200毫秒左右，第二次
搜尋的話因為有快取，所以和solr差不多。但經過詳細對比測試後發現，solr在建索引時的查詢效能非常之差，因為solr在建索引時會產生io的阻塞
，造成搜尋效能的下降，但elasticsearch不會，因為它是先把索引的內容儲存到記憶體之中，當記憶體不夠時再把索引持久化到硬碟中，同時它還有一
個佇列，是在系統空閒時自動把索引寫到硬碟中。
它的儲存方式有四種，1.像普通的lucene索引，儲存在本地檔案系統中。2.儲存在分布式檔案系統
中，如freeds。3.儲存在hadoop的hdfs中。4.儲存在亞馬遜的s3雲平台中。它支援外掛程式機制，有豐富的外掛程式。比如和mongodb couchdb同步的river外掛程式，分詞外掛程式，hadoop外掛程式，指令碼支援外掛程式等。它有個第三方的solr介面模擬外掛程式，使用這個外掛程式可以使你原本基於 solr的系統無須改**直接切換到elasticsearch中，它還是個準實時的搜尋引擎，所謂實時搜尋引擎就是當你索引乙個文件後你搜尋這個文件立即就能搜尋到。於是就決定使用這套分布式搜尋框架。
後記：之前還簡單了解過linkedin的zoie，它也是個準實時搜尋框架，不過它是不支援分布式的，現在linkedin開源出了基於zoie的分布式搜尋框架sensei，這個沒研究過，有空可以試下。
elasticsearch solr對比評測：
elasticsearch官網：
分布式鎖的技術選型
一，基於資料庫實現分布式鎖 悲觀鎖 利用select where for update 排他鎖 注意 其他附加功能與實現一基本一致，這裡需要注意的是 where name lock name欄位必須要走索引，否則會鎖表。有些情況下，比如表不大，mysql優化器會不走這個索引，導致鎖表問題。樂觀鎖 所...
zookeeper分布式部署方案
版本 環境 debian 7 8 說明 最低配置3臺 步驟 2.配置zookeeper 3.4.8 2.1單機偽分布式部署 注意 部署在同一臺電腦時，特別注意不能共用相同的埠號，包括clientport，server.1 3的埠號 1 zookeeper 3.4.8 1 位置 var local z...
分布式快取布置方案
有時我們僅布置一台快取機器 如mencached，redis 是不夠的，因此需要分布式快取。那麼問題來了，當我們布置了多台機器，我們如何確定乙個資料應該儲存在哪一台機器上？或者說，我們怎麼知道我們要查詢的資料分布在哪一台機器上？通常有以下兩種方式 普通hash分布 一致性hash分布 下面以php為...