zookeeper學習
為什麼需要zookeeper，zookeeper作用是什麼
zookeeper主要用於分布式系統中，為了提供高可用的服務，作用主要包括兩點：1)在主備節點之間選舉主節點
2)在發生宕機重啟等意外情況時，使某個值達成一致，保證不論發生以上任何異常，都不會破壞決議一致性。
在kafaka集群中，通過zookeeper管理集群配置，選舉leader，以及在consumer group發生變化時進行rebalance hadoop,使用zookeeper的事件處理確保整個集群只有乙個namenode,儲存配置資訊等.
3)hbase,使用zookeeper的事件處理確保整個集群只有乙個hmaster,察覺hregionserver聯機和宕機,儲存訪問控制列表等.
zookeeper原理
zookeeper中的角色：
leader：領導者，負責進行投票的發起和決議，更新系統狀態
learner：
follower：追隨者接收客戶請求並向客戶端返回結果，在選主過程中進行投票
observer：觀察者不參與投票，僅同步leader的狀態。目的是為了擴充套件系統，提高讀取速度。
client：請求發起方
zookeeper中節點在工作過程中有三種狀態：
looking：當前server不知道leader是誰，正在搜尋
leading：當前server即為選舉出來的leader
following：leader已經選舉出來，當前server與之同步
zookeeper與客戶端
zookeeper節點資料操作流程
整體流程如下：
1.在client向follwer發出乙個寫的請求
2.follwer把請求傳送給leader
3.leader接收到以後開始發起投票並通知follwer進行投票
4.follwer把投票結果傳送給leader
5.leader將結果彙總後如果需要寫入，則開始寫入同時把寫入操作通知給leader，然後commit;
6.follwer把請求結果返回給client
paxos演算法
基於訊息傳遞通訊模型的分布式系統，不可避免的會發生以下錯誤：程序可能會 慢、被殺死或者重啟，訊息可能會延遲、丟失、重複，在基礎 paxos 場景中，先不考慮可能 出現訊息篡改即拜占庭錯誤(byzantine failure，即雖然有可能乙個訊息被傳遞了兩次，但是 絕對不會出現錯誤的訊息)的情況。paxos 演算法解決的問題是在乙個可能發生上述異常的分 布式系統中如何就某個值達成一致，保證不論發生以上任何異常，都不會破壞決議一致性。
paxos 演算法使用乙個希臘故事來描述，在 paxos 中，存在三種角色，分別為
proposer(提議者，用來發出提案 proposal)
acceptor(接受者，可以接受或拒絕提案)
learner(學習者，學習被選定的提案，當提案被超過半數的 acceptor 接受後為被批准)
下面更精確的定義 paxos 要解決的問題：
1、決議(value)只有在被 proposer 提出後才能被批准
2、在一次 paxos 演算法的執行例項中，只批准(chose)乙個 value
3、learner 只能獲得被批准(chosen)的 value
zookeeper 的選舉演算法有兩種：一種是基於 basic paxos(google chubby 採用)實現的，另外 一種是基於 fast paxos(zookeeper 採用)演算法實現的。系統預設的選舉演算法為 fast paxos。 並且 zookeeper 在 3.4.0 版本後只保留了 fastleaderelection 演算法。
zookeeper 的核心是原子廣播，這個機制保證了各個 server 之間的同步。實現這個機制的協 議叫做 zab 協議(zookeeper atomic brodcast)。 zab 協議有兩種模式，它們分別是崩潰恢復模式(選主)和原子廣播模式(同步)。
1、當服務啟動或者在領導者崩潰後，zab 就進入了恢復模式，當領導者被選舉出來，且大 多數 server 完成了和 leader 的狀態同步以後，恢復模式就結束了。狀態同步保證了 leader 和 follower 之間具有相同的系統狀態。
2、當 zookeeper 集群選舉出 leader 同步完狀態退出恢復模式之後，便進入了原子廣播模式。 所有的寫請求都被**給 leader，再由 leader 將更新 proposal 廣播給 follower
為了保證事務的順序一致性，zookeeper 採用了遞增的事務 id 號(zxid)來標識事務。所有 的提議(proposal)都在被提出的時候加上了 zxid。實現中 zxid 是乙個 64 位的數字，它高 32 位是 epoch 用來標識 leader 關係是否改變，每次乙個 leader 被選出來，它都會有乙個新 的 epoch，標識當前屬於那個 leader 的統治時期。低 32 位用於遞增計數。
zookeeper 的集群選主例項
以乙個簡單的例子來說明整個選舉的過程：假設有五颱伺服器組成的 zookeeper 集群，它們 的 serverid 從 1-5，同時它們都是最新啟動的，也就是沒有歷史資料，在存放資料量這一點 上，都是一樣的。假設這些伺服器依序啟動，來看看會發生什麼
1、伺服器 1 啟動，此時只有它一台伺服器啟動了，它發出去的報沒有任何響應，所以它的 選舉狀態一直是 looking 狀態
2、伺服器 2 啟動，它與最開始啟動的伺服器 1 進行通訊，互相交換自己的選舉結果，由於 兩者都沒有歷史資料，所以 id 值較大的伺服器 2 勝出，但是由於沒有達到超過半數以上的伺服器都同意選舉它(這個例子中的半數以上是 3)，所以伺服器 1、2 還是繼續保持 looking 狀態
3、伺服器 3 啟動，根據前面的理論分析，伺服器 3 成為伺服器 1,2,3 中的老大，而與上面不 同的是，此時有三颱伺服器(超過半數)選舉了它，所以它成為了這次選舉的 leader
4、伺服器 4 啟動，根據前面的分析，理論上伺服器 4 應該是伺服器 1,2,3,4 中最大的，但是 由於前面已經有半數以上的伺服器選舉了伺服器 3，所以它只能接收當小弟的命了
5、伺服器 5 啟動，同 4 一樣，當小弟
zookeeper 的非全新集群選主
那麼，初始化的時候，是按照上述的說明進行選舉的，但是當 zookeeper 執行了一段時間之 後，有機器 down 掉，重新選舉時，選舉過程就相對複雜了。
需要加入資料 version、serverid 和邏輯時鐘。
資料 version：資料新的 version 就大，資料每次更新都會更新 version
server id：就是我們配置的 myid 中的值，每個機器乙個
邏輯時鐘：這個值從 0 開始遞增，每次選舉對應乙個值，也就是說：如果在同一次選舉中， 那麼這個值應該是一致的;邏輯時鐘值越大，說明這一次選舉 leader 的程序更新，也就是 每次選舉擁有乙個 zxid，投票結果只取 zxid 最新的
選舉的標準就變成：
1、邏輯時鐘小的選舉結果被忽略，重新投票
2、統一邏輯時鐘後，資料 version 大的勝出
3、資料 version 相同的情況下，server id 大的勝出
根據這個規則選出 leader。
raft演算法
和paxos類似，區別如下兩點：
raft 是基於對multi paxos 的兩個限制形成的：
傳送的請求的是連續的, 也就是說raft 的append 操作必須是連續的. 而paxos 可以併發的. (其實這裡併發只是append log 的併發提高, 應用的state machine 還是必須是有序的) 選主是有限制的, 必須有最新, 最全的日誌節點才可以當選. 而multi-paxos 是隨意的 所以raft 可以看成是簡化版本的multi paxos(這裡multi-paxos 因為允許併發的寫log, 因此不存在乙個最新, 最全的日誌節點, 因此只能這麼做. 這樣帶來的麻煩就是選主以後, 需要將主裡面沒有的log 給補全, 並執行commit 過程)
思考個問題：
zookeeper為什麼需要2n+1個server，發生了宕機，什麼情況下會不能使用
只有乙個不穩定，宕機系統就癱了，2或偶數個的話，會出現一半選舉這個另一半選舉那個，此時無法決斷
2n+1臺server，只要有n+1臺就可以使用。也就是你說的少於一半集群就無效了
LCD原理解析
硬體體系 3個部分 lcd液晶 屏 lcd驅動晶元 lcd控制器 整合在arm晶元內部 控制器 通過驅動晶元 控制液晶屏 液晶屏種類 stn gf tft tft 在嵌入式中較為常用 lcd控制器結構與模組 由17個可程式設計的暫存器組和一塊 256 16的調色盤內 存組成，通過這些暫存器，可以配置...
session原理解析
首先session跟cookies都是會會話進行跟蹤，session通過在伺服器端記錄資訊來記錄，cookies通過在客戶端記錄資訊來記錄。在此只對session進行分析 session是記錄在伺服器記憶體中的，每當乙個使用者通過瀏覽器第一次進行訪問時進行建立 需要注意只有訪問jsp，servlet...
Kerberos原理解析
kerberos這一名詞 於希臘神話 三個頭的狗 地獄之門守護者 系統設計上採用客戶端 伺服器結構與des加密技術，並且能夠進行相互認證，即客戶端和伺服器端均可對對方進行身份認證。可以用於防止竊聽 防止replay攻擊 保護資料完整性等場合，是一種應用對稱金鑰體制進行金鑰管理的系統。支援sso si...