在集群環境下，保證各個節點的資料在任一時刻訪問都是一致的
在集群環境下，保證任一時刻都能保證服務可用
在集群環境下，當部分服務不可用時，整體服務對外依舊可用，但分割槽容錯性理論來講不能達到100%的可能，因為既然是分布式，就會存在諸如網線之類的各種通訊故障問題，嚴格來講，只能說達到99.9999%。
網路分割槽容錯性：
分為兩種層面：
1、客戶端連線層面
a,b,c三個節點分割槽，由於某些原因，導致了一種現象：
客戶端1只能訪問a,b節點
客戶端2只能訪問b,c節點
這種不同客戶端分別連到了不同的「區域」的現象，但服務還可用。
2、內部集群連線
a,b,c三個節點分割槽，a,b無法連線到c，但服務可用
三個不能同時滿足，滿足兩者的同時就一定會破壞某乙個，因此出現了如下組合：
以乙個例子概述，例如集群節點有a,b集群，a,b集群存放著相同的資料，當向a寫入資料之後，勢必需要有乙個時間間隔去向b節點同步資料，而在這個時候，如果乙個客戶端請求在了b上面，要不要讓他能夠請求呢？這時候就會有不同的策略
代表：eruka
同時保證可用性和分割槽容錯性。
為了保證在任何時刻對於客戶端方面來講服務都是可用的，因此需要讓客戶端成功請求，但就會丟失
一致性
代表：zookeeper
同時保證一致性和分割槽容錯性。
為了保證各個節點的資料在任一時刻訪問都是一致的，如果客戶端請求在了b上面，勢必會因為資料在進行同步而造成不能成功得到返回，使得這次的請求的服務變得不可用
以及，另外乙個角度，當向a寫入資料之後，去同步b的時候，如果因為網路原因或者b故障，導致b不能成功寫入，為了保證資料一致性，需要將這次的寫入操作進行失敗回滾，也造成了服務的不可用，也就是丟失了可用性
同時保證一致性和可用性
實際上這兩種是互相衝突的，在保證了一致性的時候，勢必將不能保證可用性。保證了可用性，一定不能滿足一致性。
可用性越高，效能越高。
一致性越高，效能越低
關於ROS的個人見解
ros只是乙個程式開發框架而已，它主要有以下東西組成 1 ros執行環境,主要負責全域性資訊 訊息傳遞 名稱管理。2 ros專用函式庫，主要是規定ros各種規則 通訊 管理全域性資訊。3 各種能重複利用的package 4 一些方便開發的工具 ros本身執行在linux中 用ros開發框架，開發出來...
博弈 個人 見解
由於周測 做了好久的博弈題，找了好多關於博弈的相關資料，感覺自己，似乎還是動了那麼一點點。臨睡前，就小小的總結一下，希望以後看到的時候，可以有所感悟吧！接下來是正題。講到博弈，事實上也就是找規律，可是知道一般的博弈型別能夠高速便捷的解決這個問題。博弈的型別大致有下面幾種 巴什博弈，威佐夫博奕，尼姆博...
mysql個人見解
mysql基本原理 僅個人理解 mysql屬於c s架構，即客戶端和服務端互動 1.連線 例php mysqli connect 以客戶端發起請求，mysql服務端進行接收並處理，其中客戶端每發起的一次鏈結mysql均起乙個執行緒來維持乙個socket 套接字 此時會有服務端資源的開銷，因此mysq...