工作一段時間會遇到一個瓶頸期，會考慮未來1到2年的發展和方向問題，之前的方式是通過不停的學習新的框架或者解決方案來調整。
比如寫服務端代碼期間會去學習TDD，DDD，CQRS代碼邏輯層的東西，學前端框架等度過第一個階段。
后來會去學習大型互聯網架構的解決方案，什么負載均衡，分庫分表，數據一致性的解決方案，並發的處理及解決策略，降級，靜態化，緩存一致性，異步MQ。
這些了解大部分處於填鴨式學習，比如只是去了解市面上常見的中間件及軟件的使用，並沒有涉及到底層原理或者實現方式上，換句話說知道的只是名詞，還未深入，如果你對外人得意的說我會這么多東西之后，人家一句：你知道他的原理嗎？為什么這樣用？為什么不用別的代替？
在了解了市面上常見的解決方案或者中間件之后，下一階段就是進入了原理了解期，這一期讓自己深層次提升的有效方式是多問自己一句：為什么？然后把這個答案深刻理解之后印在腦子里，不要滿足於我好像知道大概。
這一階段的目的主要是深入去了解一些常見或是先進的中間件的實現原理，當然牛X的可以看其中的源碼。
既然上面中間件主要應用場景是分布式場景。於是問一句：什么是分布式？
我印象看過wiki上的定義，具體的內容忘記了，大意是通過將任務單元分散在多個計算機節點上，節點之間通過消息通信。
所以可以歸納起來市面上常見的分布式場景：分布式計算，分布式存儲，分布式通信。這樣我們就可以歸納出一條去學習分布式基礎的腦圖，去了解內在原理，不滿足於知道的程度。
很簡單的道理，我通過一個禮拜學會的中間件或者框架，憑什么別人不能通過一個禮拜學會呢？反過來說也不用羡慕別人會用一些框架，如果只是在用上，他學了一個月會用，我為什么不能一個月學會呢？還是要鍛煉自己的核心價值，比如基礎算法，數據結構，設計模式，計算機組成原理，一切上層的中間件框架都是從這里開始是，同時強化自己的引申和聯想能力，有沒有更好的方式去解決。
分布式計算，市面上較好的原理性文章可以看google的map/reduce論文，或者看一下map/reduce原理的文章去了解。然后自己去通過掌握的東西去模擬一個map/reduce的實現。
前幾天做了一個導數的任務，會將歷史數據導入es中，功能不難，但是數據量也是不小，把事情不是簡單的做完，爭取做好，借着這個機會可以實踐一下，決定通過map/reduce的思想去實現。
map/reduce的思想主要是通過namenode做數據節點狀態和分發管理，這個模塊也可以叫做"元數據"。元數據這個概念在分布式概念中很重要，每個分布式中間件都會有類似的概念，任務節點是datanode。這里其實還可以引申出兩個問題，狀態的管理或者分發是namenode做記錄好，還是datanode反饋好呢？
既然自己實現map/reduce，然后你會去考慮，namenode如何保證高可用，如何保證namenode和datanode之間的通信，壓縮，同時會考慮將數據清洗任務交給datanode節點之后，是不是需要定制一套算法給到datanode去。
比如datanode處理的是查詢功能，是不是可以自動轉換成查詢算法。如果datanode是排序功能，是不是可以自動切換到排序算法。或者考慮是通過IO將數據進行傳導還是將計算方式傳到，這里貌似有考慮了hadoop和spark的區別，一個通過傳導數據會有IO延遲，傳導計算單元則要快得多。同時還要考慮datanode節點崩掉的問題。
綜上這些問題解決之后，一個簡單的map/reduce的框架雛形就已經出來了，考慮到市面上常見的分布式框架，比如hadoop，dubbo等，元數據管理大部分通過zookeeper去實現，於是元數據也可以考慮通過zookeeper去實現，namenode做任務分發和備案。
多個datanode的分發，需要引入一個負載均衡的策略，一致性hash肯定是最好的方案，如果采用權重的負載均衡策略，如何保證單一datanode節點在一段時間內不會大量的獲取任務，我才用的比較簡單暴力的方式，就是對任務id對3求余這樣可以保證求余為0的負載到權重較高的上面，同時不會讓太多任務壓倒權重高的上面，我知道這個方法肯定不是最好的，但是也沒有花太多時間去做這個，但是說一下的目的是，我還是考慮了這個問題，炫技而已。
datanode對於消息的處理依賴，在自己維護的一個日志，日志的記錄我們可以多考慮一下，市面上常見的日志記錄方式我認為有三種：樹形，哈希+鏈表，線性記錄。
數據庫索引是樹形的，很大一部分由歷史原因決定，比如nosql就為了避免這個問題。 哈希+鏈表的方式從hashmap這種基礎的數據單元，到nosql的內存db都可以使用。 線性記錄，這種kafka用的比較多。
通過這個數據結構可以引申出其他的問題，比如有人說我們最近用的elasticsearch，然后問他，為什么用es，為什么mysql不可以？好多人回答不上來，或者回答不在點上，要是我回答這個問題，我可能這樣說：
elasticsearch底層索引的建立是通過lucene建立的，在對非結構化數據這種情況下，luncene的倒排序方式算法遠遠優於mysql，效率也更高，在擴容分區，備份問題上，es提供的解決方案較mysql更簡單等。
了解lucene不要簡單的了解這個庫，爭取從搜索引擎的角度去了解，推薦一本《這就是搜索引擎》，因為lucnen僅僅是建索引的一個庫，但是早期稱得上大數據，分布式的場景主要是搜索引擎，可以了解一下索引建立的算法，信息去噪，查找算法，最優記錄的推薦，分詞方式，或者自然語言處理這些，可以更系統一些去鏈接這些知識。
當然這些僅僅是實現自己的一個分布式計算框架的思考，具體還會涉及到容錯，異常處理，線程池的拒絕策略，java的並發關鍵字等，這些有機會再講。
今天主要說了實現一個分布式計算框架需要考慮的問題，分布式還有另外兩大塊，分布式存儲和分布式通信，這些原理及機制以后再聊。
