隨著網際網路飛速發展，資料流量和企業所需要儲存的資訊也越來越多，單一的機器已經不能滿足日常的需求，那麼分布式系統也就應運而生。而在分布式系統中，最重要的問題就是如何保證資料的一致性。為了保證資料的一致性，我們必須要找到一種共識演算法，來確保各機器之間的資料一致性。
在分布式系統中，由於機器可能宕機，網路可能短連等許多問題，paxos演算法既能解決這個問題也能保證資料的一致性。
"基於paxos一致性協議，開發乙個三節點集群kv儲存服務paxoskv。假定，該paxoskv用於儲存某遊戲中的玩家、家族或者聯盟的純英文slogan，該遊戲活躍id 10000個。slogan長度限制為32位元組。slogan中，需要包含客戶端傳送請求時刻，的毫秒級時間戳。"
以上是對本專案的簡單描述，具體來說，有以下要求
上面的三個需求中，只有第乙個是功能性需求，第二個和第三個都是非功能性需求。
本專案的主要難點在於演算法，客戶邏輯比較簡單，使用者只能執行更新資料和讀寫資料兩個操作。以下為用例圖
雖然客戶邏輯比較簡單，但是後台需要使用paxos演算法實現基於狀態機的資料同步，而這一部分需要比較多的處理，所以有如下物件：
uml圖如下
本專案實現的是kv資料庫，所以無需建立關係型資料庫的表。
這裡，客戶端可以重複地讀取和寫入資料。
在資料庫端，paxos演算法的流程如下：
階段一為準備階段
proposer 選擇乙個number n，然後向大多數acceptor傳送number 為n的prepare request。階段二為接受階段如果乙個acceptor接收到number為n的prepare request，並且n大於任何它已經回覆的prepare request的number，那麼它將承諾不再接受任何number 小於 n的proposal，並且回覆已經接受的最大number的 proposal。
如果proposer 接受了來自大多數acceptor對它的prepare request 的回 復，那麼接下來它將給這些 acceptor傳送number為n，value為v的 proposal作為accept request。其中v是收到的回覆中最大 number 的proposal的value，或者如果回覆中沒有proposal的話，就可以是它自己選的任意值。通過以上的兩個階段，我們可以保證log的完整並且順序。如果 acceptor 收到乙個number 為n的accept request，如果它沒有對number 大於n的prepare request進行過回覆，那麼就接受該accept request。
然後由於狀態機的特性，只要我們按序執行log，就能保證kv的一致性。
我的工程實踐偏向於演算法的研究，所以業務上只有很簡單的讀取和寫入kv資料兩個操作，但是通過整個分析，也能夠了解軟體工程分析在具體專案中提綱挈領的作用。
分布式系統中的共識性演算法的設計方案
基於paxos一致性協議，開發乙個三節點集群kv儲存服務paxoskv。假定，該paxoskv用於儲存某遊戲中的玩家 家族或者聯盟的純英文slogan，該遊戲活躍id 10000個。slogan長度限制為32位元組。slogan中，需要包含客戶端傳送請求時刻的毫秒級時間戳。由於我們還未正式開展具體的...
分布式系統的一致性演算法（共識演算法）
參考 分布式系統 多個節點之間的兩種通訊模型 共享記憶體 訊息傳遞。paxos演算法是基於訊息傳遞的。paxos的前提假設是不存在拜占庭將軍問題，即 通道是安全的 通道可靠 發出的訊號不會被篡改，否則該演算法就不可靠。如何保證訊息沒被篡改 數字簽名等 paxos能達成一致的原因 過半數學原理 我們稱...
分布式共識演算法 Raft詳解
拜占庭將軍問題是分布式領域最複雜 最嚴格的容錯模型。但在日 常工作中使用的分布式系統面對的問題不會那麼複雜，更多的是因 為計算機故障宕機，或者網路通訊問題而沒法傳遞資訊，這種情況 不考慮計算機之間互相傳送惡意資訊，極大簡化了系統對容錯的要 求，最主要的是達到一致性。假設將軍中沒有叛軍，信使的資訊可靠...