zookpeer如何保證資料一致：
paxos演算法通過投票來對寫操作進行全域性編號，同一時刻，只有乙個寫操作被批准，同時併發的寫操作要去爭取選票，只有獲得過半數選票的寫操作才會被 批准（所以永遠只會有乙個寫操作得到批准），其他的寫操作競爭失敗只好再發起一輪投票，就這樣，在日復一日年復一年的投票中，所有寫操作都被嚴格編號排 序。編號嚴格遞增，當乙個節點接受了乙個編號為100的寫操作，之後又接受到編號為99的寫操作（因為網路延遲等很多不可預見原因），它馬上能意識到自己 資料不一致了，自動停止對外服務並重啟同步過程。任何乙個節點掛掉都不會影響整個集群的資料一致性（總2n+1臺，除非掛掉大於n臺）。
paxos的基本思路：(深入解讀zookeeper一致性原理)
假設有乙個社團，其中有團員、議員（決議小組成員）兩個角色
團員可以向議員申請提案來修改社團制度
議員坐在一起，拿出自己收到的提案，對每個提案進行投票表決，超過半數通過即可生效
為了秩序，規定每個提案都有編號id，按順序自增
每個議員都有乙個社團制度筆記本，上面記著所有社團制度，和最近處理的提案編號，初始為0
投票通過的規則：
新提案id 是否大於 議員本中的id，是議員舉手贊同
如果舉手人數大於議員人數的半數，即讓新提案生效
例如：
剛開始，每個議員本子上的id都為0，現在有乙個議員拿出乙個提案：團費降為100元，這個提案的id自增為1
每個議員都和自己id對比，一看 1>0，舉手贊同，同時修改自己本中的id為1
發出提案的議員一看超過半數同意，就宣布：1號提案生效
然後所有議員都修改自己筆記本中的團費為100元
以後任何乙個團員諮詢任何乙個議員："團費是多少？"，議員可以直接開啟筆記本檢視，並回答：團費為100元
可能會有極端的情況，就是多個議員一起發出了提案，就是併發的情況
例如
剛開始，每個議員本子上的編號都為0，現在有兩個議員（a和b）同時發出了提案，那麼根據自增規則，這兩個提案的編號都為1，但只會有乙個被先處理
假設a的提案在b的上面，議員們先處理a提案並通過了，這時，議員們的本子上的id已經變為了1，接下來處理b的提案，由於它的id是1，不大於議員本子上的id，b提案就被拒絕了，b議員需要重新發起提案
上面就是paxos的基本思路，對照zookeeper，對應關係就是：
團員 -client
議員 -server
議員的筆記本 -server中的資料
提案 -變更資料的請求
提案編號 -zxid（zookeeper transaction id）
提案生效 -執行變更資料的操作
zookeeper中還有乙個leader的概念，就是把發起提案的權利收緊了，以前是每個議員都可以發起提案，現在有了leader，大家就不要七嘴八舌了，先把提案都交給leader，由leader乙個個發起提案
paxos演算法就是通過投票、全域性編號機制，使同一時刻只有乙個寫操作被批准，同時併發的寫操作要去爭取選票，只有獲得過半數選票的寫操作才會被批准，所以永遠只會有乙個寫操作得到批准，其他的寫操作競爭失敗只好再發起一輪投票
Mysql 如何保證主從資料一致
要知道，mysql 的主從使用的是 binlog 那樣簡單的 日誌傳輸方式，來完成從庫對主庫的複製，雖然提高了效率，但是主庫和從庫之間並沒有 raft 那樣的協議來保證 主從一致。有時候主庫宕機，但是 binlog 還沒有發出去，如果直接將從庫切換為主庫，那麼將會主備不一致。並且從庫是單純告訴主庫，...
Mysql如何保證資料不會丟失
簡單來說就是依靠redo log和binlog保證持久化到磁碟後就可以保證，異常重啟資料可以正常恢復 這裡主要說下這兩個log的寫入機制。乙個事務執行的過程中，會先把日誌寫入到binlog cache中，事務提交的時候再把binlog cache中的日誌寫到binlog中。系統給binlog cac...
Kafka如何保證資料不丟失
kafka的ack機制 在kafka傳送資料的時候，每次傳送訊息都會有乙個確認反饋機制，確保訊息正常的能夠被收到，其中狀態有0,1，1。producer.type sync request.required.acks 1 producer.type async request.required.ac...