前言
前幾天我上班路上，和小區門口開車的師傅閑聊，發現他們雖然學歷不高，但掙錢的途徑不少，比如固定接送多位客戶，然后能通過朋友圈拓展新客戶，而且通過客戶口口相傳，也能不斷拉到生意，算下來每月也能掙1萬5出頭，好的話能有2萬，我在上海，做IT的要月入2萬，如果不是996，估計本科畢業還得干幾年。
可能有人會說了，他們第一不交金，第二未必穩定，但這批師傅學歷也就高中，對于這個學歷來說，這個收入不能算低。反觀我們，可能不少做IT的人，一心只做技術，只拿固定工資，不去拓展掙錢途徑，或者雖然到處找活干，但和路邊裝修隊相比，只是多了份固定工資，總之很難突破收入瓶頸。
所以我們IT人除了在不斷提升自己的技術能力之外，更得積極主動地拓展掙錢途徑，本文就將圍繞這點展開。
CAP原則
在分布式系統要滿足CAP原則，一個提供數據服務的存儲系統無法同時滿足：數據一致性、數據可用性、分區耐受性。
C數據一致性：所有應用程序都能訪問到相同的數據。 A數據可用性：任何時候，任何應用程序都可以讀寫訪問。 P分區耐受性：系統可以跨網絡分區線性伸縮。（通俗來說就是數據的規模可擴展） 在大型網站中通常都是犧牲C，選擇AP。為了可能減小數據不一致帶來的影響，都會采取各種手段保證數據最終一致。
-
數據強一致：各個副本的數據在物理存儲中總是一致的。
-
數據用戶一致：數據在物理存儲的各個副本可能是不一致的，但是通過糾錯和校驗機制，會確定一個一致的且正確的數據返回給用戶。
-
數據最終一致：物理存儲的數據可能不一致，終端用戶訪問也可能不一致，但是一段時間內數據會達成一致。
一致性算法
-
使一組服務器在一個值上達成一致，所以活躍的特征在于最終每個服務器都可以決定一個值。
-
通過值的一致能夠實現對同一個數據的請求會讓同一個服務器來處理。
-
Paxos和Raft都是通過選取master來實現多節點下值的一致性，從而借助一致性hash算法來分配請求。
一致性Hash算法 一致性Hash算法可以根據不同的屬性參數（通常是IP和端口號），生成一串不相同的Hash值，并將Hash值轉換成0-2^32-1的整數， 不同范圍的值由不同服務器進行處理。（B-C之間的由B處理）。
Raft算法和Paxos算法
Raft算法是在Paxos算法的基礎上的進行優化。 Raft在Paxos的基礎上主要做了兩個方向的優化： 1.將復雜的分布式共識問題拆分成領導選舉、日志復制和安全性三個問題 2.壓縮狀態空間：相對于Paxos施加了更合理的限制，減少了系統狀態過多而產生的不確定因素。
領導選舉(具體以zookeeper舉例) 其基本的特性有：
-
zookeeper在配置集群時節點數不可小于3
-
節點只有獲得半數以上的投票才能當選Leader
-
zookeeper在啟動時會通過廣播機制來把投票結果告訴其他的節點
-
zookeeper在啟動時首先會給自己投票，然后與其他已啟動的節點進行通信，通過比較id從而判斷是否能獲取其他節點的投票
zookeeper在選舉過程中的角色：領導者、跟隨者、觀察者、競選者
日志復制 在共識算法中，所有服務器節點都會包含一個有限狀態自動機，名為復制狀態機（replicated state machine）。每個節點都維護著一個復制日志（replicated logs）的隊列，復制狀態機會按序輸入并執行該隊列中的請求，執行狀態轉換并輸出結果。可見，如果能保證各個節點中日志的一致性，那么所有節點狀態機的狀態轉換和輸出也就都一致。
可見，日志由一個個按序排列的entry組成。每個entry內包含有請求的數據，還有該entry產生時的領導任期值。每個節點上的日志隊列用一個數組log[]表示。
領導節點選舉出來后，集群就可以開始處理客戶端請求了。當客戶端發來請求時，領導節點首先將其加入自己的日志隊列，再并行地發送AppendEntries RPC消息給所有跟隨節點。最終實現節點數據的一致性。
安全性 Raft安全保障機制有5種：
-
選舉安全性：節點要3個以上，避免“腦裂”的方式
-
領導者只追加：客戶端發出的請求都是插入領導者日志隊列的尾部，沒有修改或刪除的操作。
-
日志匹配：每條AppendEntries都會包含最新entry之前那個entry的下標與任期值，如果跟隨節點在對應下標找不到對應任期的日志，就會拒絕接受并告知領導節點。（避免追隨者故障，導致數據不一致）
-
領導者完全性:如果有一條日志在某個任期被提交了，那么它一定會出現在所有任期更大的領導者日志里。（master會優先獲取日志的更新）
-
狀態機安全性:如果一個節點已經向其復制狀態機應用了一條日志中的請求，那么對于其他節點的同一下標的日志，不能應用不同的請求。(避免master宕機時，重新選舉，導致部分節點數據不一致)
Raft算法和Paxos算法在分布式中的使用
Consul vs Eureka vs Zookeeper
注： CAP: 數據一致性、數據可用性、分區耐受性 AP: 犧牲強一致性，部分節點宕機，不會影響正常工作的節點。 CP: 犧牲數據可用性,為了保證數據的一致性，當一臺機器出現故障時，所有節點的數據都不能使用。
最后
一次偶然，從朋友那里得到一份“java高分面試指南”，里面涵蓋了25個分類的面試題以及詳細的解析：JavaOOP、Java集合/泛型、Java中的IO與NIO、Java反射、Java序列化、Java注解、多線程&并發、JVM、Mysql、Redis、Memcached、MongoDB、Spring、Spring Boot、Spring Cloud、RabbitMQ、Dubbo 、MyBatis 、ZooKeeper 、數據結構、算法、Elasticsearch 、Kafka 、微服務、Linux。
這不，馬上就要到招聘季了，很多朋友又開始準備“金三銀四”的春招啦，那我想這份“java高分面試指南”應該起到不小的作用，所以今天想給大家分享一下。
請注意：關于這份“java高分面試指南”，每一個方向專題（25個）的題目這里幾乎都會列舉，在不看答案的情況下，大家可以自行測試一下水平 且由于篇幅原因，這邊無法展示所有完整的答案解析
注意：關于這份“java高分面試指南”，每一個方向專題（25個）的題目這里幾乎都會列舉，在不看答案的情況下，大家可以自行測試一下水平 且由于篇幅原因，這邊無法展示所有完整的答案解析
資料領取方式：點擊【java高分面試指南-25大專題分類】
