招募有志青年

0 初衷

如今有不少的技術交流羣，不少的羣都是這樣的：

• 1 常常扯淡
• 2 不少伸手黨
• 3 一些道聽途說的結論都拿來做爲本身的觀點
• 4 技術交流的深度不夠

花費了不少時間在羣上，可是收穫缺並很少。而想找到一個有深度的交流羣，而不是一個問答羣。但願以下：

• 1 針對一個話題，感興趣的人都可以進行深刻研究後，而後再在一塊兒相互探討
• 2 有不少處於相同階段的志同道合的夥伴，你們都很是上進

而我就是這樣的一個處在初級階段的一我的，最近也在迷茫，該怎麼去發展，想找同齡人一塊兒交流。下面先簡單談談我最近的粗淺感覺，與君共勉

1 感覺

1.1 深度和廣度

有的人會告訴你要專注一點，不要什麼都學。有時候你本身卻是想多補充補充廣度，造成一個知識體系。

深度和廣度其實有時候很難把控，可能你所謂的深度根本就不深。

我這個小白目前的想法是：

• 廣度：初始階段，擴展擴展廣度。如中間件、數據庫、分佈式領域。

  • 基本的數據結構和算法，JDK集合源碼，多線程（鎖、線程池）

  • web:SpringMVC、Spring事務體系、mybatis或hibernate、數據庫鏈接池

  • 通訊：TCP/IP，NIO框架Netty、thrift，RPC中的dubbo

  • 消息隊列：kafka、RocketMQ等

  • 調度：

    • 中間件形式的：quartz集羣方案、elastic-job（它的Elastic-Job-Cloud也提供資源調度）
    • 大數據方向的調度：
      • oozie、zeus：把不一樣類型的調度job代碼封裝起來而後和大數據組件進行交互，用戶只需寫配置便可
      • 大數據組件內部的調度，又會細劃分爲資源調度(yarn)和任務調度(AppMaster)

  • KV存儲：redis、memcached

  • 關係型數據庫如mysql的基本原理，sql引擎、事務（隔離級別、鎖、MVCC）、binlog redo undo log、主從複製原理、高可用方案

  • 分佈式一致性：paxos、Raft、ZAB。ZooKeeper、etcd

  • 分佈式存儲：

    • NOSQL：redis的cluster、codis方案，HBase
    • NewSQL:Spanner、CockroachDB、TiDB、OceanBase等。

    上述衆多分佈式存儲的共性部分能夠簡單歸納爲2個方面：

    • 1 分片：hash分片如codis、Range分片如HBase、CockroachDB，又如消息隊列這類存儲天生具備良好的可分片特性（topic和partition）。還有分片這類meta信息的高可用存儲，分片的調度（如分片的遷移或者分片的拆分）。如kafka經過leader選舉選出一個Controller來管理meta信息（因爲meta信息少，因此經過Controller的調度使得每一個KafkaServer都存儲了一份）和分片的調度。
    • 2 分片的一致性和高可用：傾向於使用paxos、raft來實現分片的同步。如CockroachDB、TiDB使用raft，Spanner、OceanBase使用paxos。

  • 分佈式事務：

    • 中間件層面：X/Open DTP模型（不只與數據庫對接還能夠與其餘實現XA協議的RM對接）、JTA，常採用2PC來實現，如ByteTCC框架
    • 分佈式存儲層面：如google的Percolator分佈式事務方案，小米的Themis（爲HBase添加分佈式事務支持）也是基於Percolator。不少都是2PC而且進行優化的方案。

    提到了分佈式事務又不得不說分佈式時序問題：

    • google的TrueTime
    • CockroachDB的HLC
    • 授時服務

  • 分佈式計算:MapReduce、Spark等等

  幾年內把這些東西的原理以及其中存在的缺陷搞清楚（根據本身的方向，有些深刻理解，有些會用便可，有些可能涉及不到，有些漏掉，畢竟方向太多了）。可以融匯貫通，可以看到一些共性的東西，而再也不把他們當作一個個孤立的軟件來看待。不少設計都是相通的，不少問題是各個軟件都會遇到的，若是你能總結出來，那麼理解就會更加深刻了。

  這個時間因人而異，勤奮和懶惰的差距固然很大。

  這個階段還沒到深刻的地步，好比paxos論文你看懂了，可是真實落地到實際的生產系統又是一層挑戰。好比你能看懂dubbo，不必定能本身寫出來。

  這個階段同時要增強本身的代碼能力，爲下個階段作準備。

• 深度：深刻階段，找到本身的感興趣的方向，深刻作下去，去面臨現實中的各類挑戰，去作出創新，如

  • 消息隊列，加入大廠的消息隊列團隊，真正去作出一個開源產品來
  • NOSQL：如深刻搞HBase，成爲committer啥的
  • 分佈式KV、分佈式數據庫

  這個階段固然須要專一在某個領域內，須要必定時間的積澱（固然我也沒啥話語權，還沒到這個階段，只能這麼粗略的認爲）。

1.2 眼界

特別是咱們這種普通程序員，若是侷限在本身狹窄的範圍，你可能放鬆對本身的要求。

好比學習ZooKeeper：

• 有些人就會用用
• 有些人看些文章瞭解其中的原理，本身咀嚼別人的知識
• 有些人看看源碼，本身主動獲取知識，但處於只知其一;不知其二的狀態
• 有些人源碼看的更加深刻一些，真正理解背後的設計，背後所面臨的一致性問題
• 有些人不只僅侷限於ZooKeeper，開始擴展到其餘系統，也能解決其中的不足，有條件的話本身也能造輪子

因此提升本身對知識的要求，你作的還遠遠不足。

1.3 打好基礎

• 學好英語

  須要看國外大師的一些博客文章、各類paper。因此學好英語是必須過的一關。

• 學好數據結構和算法

  不少時候都會提出咱們作web開發的須要學這些嗎？正是由於你不會，才只能作這個。

1.4 多總結

舉例以下：

• 當你面對redis的全量和增量同步中存在的問題時，你是否曾想其餘軟件是否也存在這個問題，他們又是怎麼解決的？多去了解了解，作到融匯貫通

• 看文章：如今的文章真的太多太多了，這就致使了咱們不少時候僅僅是粗淺的瀏覽了下，並無去深刻其中的細節（可能做者對於每一處都很認真的推敲，可能做者也是不負責任的寫一寫，這個須要你本身去辨別）。如今不少文章都沒有高質量的評論交流能夠從側面看出，如今你們的閱讀通常都很粗淺。

2 想作的事

2.1 願景

想籠絡想奮進的人進羣，羣人數保持在30到50人。

• 每週至少開展1個話題，由話題提出者主導研究，其餘人感興趣的參與研究，而後在某個固定時間你們一塊兒交流。多個話題能夠同時展開，各自參加各自的話題小分隊
• 基本不容許提簡單的問題，這種通常自行解決，最好提一些有質量的話題。這裏是一個交流的平臺，而不是一個問答平臺。
• 長時間不參與各類話題只能勸退出羣了，等你有空研究再參與進來
• 各類弄虛做假者來蹭的也會勸退

2.2 要求條件

• 想成大牛的潛力股，具備自我驅動力，能自主去研究一些東西
• 讀源碼是最最最基本的要求
• 對技術有本身獨到的看法和認識
• 樂於分享技術（有本身的技術博客最好，而且要求博客內容質量高）
• 大牛也能夠進來指導指導（哈哈）

知足條件的能夠先看下下面的測試題，挑選其中3個回答，而後私信留言，覈對後拉進羣，一塊兒討論學習。

不知足條件的不要怪別人不給機會，只有本身先變得上進起來，別人天然會去主動找你。

2.3 預先的測試題

• 1 Guava RateLimter中預熱是怎麼一回事
• 2 你以爲RedLock有沒有問題？若是有指出來
• 3 分佈式一致性算法中，選舉出新的leader後，Raft和ZAB是如何處理上一個leader殘留的還未提交的事務的
• 4 如何改進kafka的日誌丟失問題

3 話題內容

這裏準備把一些話題列出來，僅供參考，大牛就不要拍磚了。

3.1 分佈式鎖話題

• 有哪些方案？
• 方案都有哪些缺陷，你對RedLock怎麼看？
• 從各類方案中你能總結出如何來設計分佈式鎖？有哪些要點？

3.2 紅黑樹

• 如何看待算法導論中紅黑樹的相關操做的解法
• 你是否能直接描述出如何插入刪除數據的過程

3.3 恢復技術以及副本同步（增量和全量同步）

• redis的rgb和aof
• ZooKeeper的快照和事務日誌
• hdfs的image和editLog
• kafka？
• mysql？

上述幾種都會面臨如何恢復，以及如何進行副本同步。

這些過程當中有哪些技術難點？他們分別是怎麼應對的？

你能總結出來什麼東西？

3.4 paxos

• 1 paxos的針對場景的誤解：

  • 達成一個建議的場景
  • 日誌複製場景

• 2 paxos的運行過程

• 3 paxos的證實過程

• 4 base paxos與ZAB和Raft的區別

  如多寫入仍是單寫入

• 5 base paxos和multi-paxos

• 6 使用多輪的base paxos來進行日誌同步，見使用Basic-Paxos協議的日誌同步與恢復

• 7 使用Multi-Paxos協議的日誌同步使用Multi-Paxos協議的日誌同步與恢復

• 8 對於上述7文章中的幽靈復現問題的討論

3.5 undo redo binlog

• 1 undo redo 均可以實現持久化，他們的流程是什麼？爲何選用redo來作持久化？
• 2 undo、redo結合起來實現原子性和持久化，爲何undo log要先於redo log持久化？
• 3 undo爲何要依賴redo？
• 4 日誌內容能夠是物理日誌，也能夠是邏輯日誌？他們各自的優勢和缺點是？
• 5 redo log最終採用的是物理日誌加邏輯日誌，物理到page，page內邏輯。還存在什麼問題？怎麼解決？Double Write
• 6 undo log爲何不採用物理日誌而採用邏輯日誌？
• 7 爲何要引入Checkpoint？
• 8 引入Checkpoint後爲了保證一致性須要阻塞用戶操做一段時間，怎麼解決這個問題？（這個問題仍是頗有廣泛性的，redis、ZooKeeper都有相似的狀況以及不一樣的應對策略）又有了同步Checkpoint和異步Checkpoint
• 9 開啓binlog的狀況下，事務內部2PC的通常過程（含有2次持久化，redo log和binlog的持久化）
• 10 解釋上述過程，爲何binlog的持久化要在redo log以後，在存儲引擎commit以前？
• 11 爲何要保持事務之間寫入binlog和執行存儲引擎commit操做的順序性？（即先寫入binlog日誌的事務必定先commit）
• 12 爲了保證上述順序性，以前的辦法是加鎖prepare_commit_mutex，可是這極大的下降了事務的效率，怎麼來實現binlog的group commit？
• 13 怎麼將redo log的持久化也實現group commit？至此事務內部2PC的過程，2次持久化的操做均可以group commit了，極大提升了效率

3.6 AQS

• 1 AQS中一旦某個線程1獲取到了鎖正在執行同步代碼塊，這時候其餘線程再來獲取鎖，他們會不斷的CAS嘗試獲取鎖一段時間以後再被阻塞仍是立馬被阻塞呢？

  這個問題要綜合的考慮，既有AQS的問題又有AQS對外留出的tryAcquire方法的問題