工作一段時間會遇到一個瓶頸期，會考慮未來1到2年的發(fā)展和方向問題，之前的方式是通過不停的學習新的框架或者解決方案來調(diào)整。
比如寫服務端代碼期間會去學習TDD，DDD，CQRS代碼邏輯層的東西，學前端框架等度過第一個階段。

后來會去學習大型互聯(lián)網(wǎng)架構的解決方案，什么負載均衡，分庫分表，數(shù)據(jù)一致性的解決方案，并發(fā)的處理及解決策略，降級，靜態(tài)化，緩存一致性，異步MQ。

這些了解大部分處于填鴨式學習，比如只是去了解市面上常見的中間件及軟件的使用，并沒有涉及到底層原理或者實現(xiàn)方式上，換句話說知道的只是名詞，還未深入，如果你對外人得意的說我會這么多東西之后，人家一句：你知道他的原理嗎？為什么這樣用？為什么不用別的代替？

在了解了市面上常見的解決方案或者中間件之后，下一階段就是進入了原理了解期，這一期讓自己深層次提升的有效方式是多問自己一句：為什么？然后把這個答案深刻理解之后印在腦子里，不要滿足于我好像知道大概。

這一階段的目的主要是深入去了解一些常見或是先進的中間件的實現(xiàn)原理，當然牛X的可以看其中的源碼。

既然上面中間件主要應用場景是分布式場景。于是問一句：什么是分布式？

我印象看過wiki上的定義，具體的內(nèi)容忘記了，大意是通過將任務單元分散在多個計算機節(jié)點上，節(jié)點之間通過消息通信。

所以可以歸納起來市面上常見的分布式場景：分布式計算，分布式存儲，分布式通信。這樣我們就可以歸納出一條去學習分布式基礎的腦圖，去了解內(nèi)在原理，不滿足于知道的程度。

很簡單的道理，我通過一個禮拜學會的中間件或者框架，憑什么別人不能通過一個禮拜學會呢？反過來說也不用羨慕別人會用一些框架，如果只是在用上，他學了一個月會用，我為什么不能一個月學會呢？還是要鍛煉自己的核心價值，比如基礎算法，數(shù)據(jù)結構，設計模式，計算機組成原理，一切上層的中間件框架都是從這里開始是，同時強化自己的引申和聯(lián)想能力，有沒有更好的方式去解決。

Android培訓,安卓培訓,手機開發(fā)培訓,移動開發(fā)培訓,云培訓培訓

分布式計算，市面上較好的原理性文章可以看google的map/reduce論文，或者看一下map/reduce原理的文章去了解。然后自己去通過掌握的東西去模擬一個map/reduce的實現(xiàn)。

前幾天做了一個導數(shù)的任務，會將歷史數(shù)據(jù)導入es中，功能不難，但是數(shù)據(jù)量也是不小，把事情不是簡單的做完，爭取做好，借著這個機會可以實踐一下，決定通過map/reduce的思想去實現(xiàn)。

map/reduce的思想主要是通過namenode做數(shù)據(jù)節(jié)點狀態(tài)和分發(fā)管理，這個模塊也可以叫做"元數(shù)據(jù)"。元數(shù)據(jù)這個概念在分布式概念中很重要，每個分布式中間件都會有類似的概念，任務節(jié)點是datanode。這里其實還可以引申出兩個問題，狀態(tài)的管理或者分發(fā)是namenode做記錄好，還是datanode反饋好呢？

既然自己實現(xiàn)map/reduce，然后你會去考慮，namenode如何保證高可用，如何保證namenode和datanode之間的通信，壓縮，同時會考慮將數(shù)據(jù)清洗任務交給datanode節(jié)點之后，是不是需要定制一套算法給到datanode去。

比如datanode處理的是查詢功能，是不是可以自動轉換成查詢算法。如果datanode是排序功能，是不是可以自動切換到排序算法?；蛘呖紤]是通過IO將數(shù)據(jù)進行傳導還是將計算方式傳到，這里貌似有考慮了hadoop和spark的區(qū)別，一個通過傳導數(shù)據(jù)會有IO延遲，傳導計算單元則要快得多。同時還要考慮datanode節(jié)點崩掉的問題。

綜上這些問題解決之后，一個簡單的map/reduce的框架雛形就已經(jīng)出來了，考慮到市面上常見的分布式框架，比如hadoop，dubbo等，元數(shù)據(jù)管理大部分通過zookeeper去實現(xiàn)，于是元數(shù)據(jù)也可以考慮通過zookeeper去實現(xiàn)，namenode做任務分發(fā)和備案。

多個datanode的分發(fā)，需要引入一個負載均衡的策略，一致性hash肯定是最好的方案，如果采用權重的負載均衡策略，如何保證單一datanode節(jié)點在一段時間內(nèi)不會大量的獲取任務，我才用的比較簡單暴力的方式，就是對任務id對3求余這樣可以保證求余為0的負載到權重較高的上面，同時不會讓太多任務壓倒權重高的上面，我知道這個方法肯定不是最好的，但是也沒有花太多時間去做這個，但是說一下的目的是，我還是考慮了這個問題，炫技而已。

datanode對于消息的處理依賴，在自己維護的一個日志，日志的記錄我們可以多考慮一下，市面上常見的日志記錄方式我認為有三種：樹形，哈希+鏈表，線性記錄。

數(shù)據(jù)庫索引是樹形的，很大一部分由歷史原因決定，比如nosql就為了避免這個問題。 哈希+鏈表的方式從hashmap這種基礎的數(shù)據(jù)單元，到nosql的內(nèi)存db都可以使用。 線性記錄，這種kafka用的比較多。

通過這個數(shù)據(jù)結構可以引申出其他的問題，比如有人說我們最近用的elasticsearch，然后問他，為什么用es，為什么mysql不可以？好多人回答不上來，或者回答不在點上，要是我回答這個問題，我可能這樣說：

elasticsearch底層索引的建立是通過lucene建立的，在對非結構化數(shù)據(jù)這種情況下，luncene的倒排序方式算法遠遠優(yōu)于mysql，效率也更高，在擴容分區(qū)，備份問題上，es提供的解決方案較mysql更簡單等。

了解lucene不要簡單的了解這個庫，爭取從搜索引擎的角度去了解，推薦一本《這就是搜索引擎》，因為lucnen僅僅是建索引的一個庫，但是早期稱得上大數(shù)據(jù)，分布式的場景主要是搜索引擎，可以了解一下索引建立的算法，信息去噪，查找算法，最優(yōu)記錄的推薦，分詞方式，或者自然語言處理這些，可以更系統(tǒng)一些去鏈接這些知識。

當然這些僅僅是實現(xiàn)自己的一個分布式計算框架的思考，具體還會涉及到容錯，異常處理，線程池的拒絕策略，java的并發(fā)關鍵字等，這些有機會再講。

今天主要說了實現(xiàn)一個分布式計算框架需要考慮的問題，分布式還有另外兩大塊，分布式存儲和分布式通信，這些原理及機制以后再聊。

http://www.cnblogs.com/xiguain/p/7119758.html