高手問答
從數據到大模型應用，11 月 25 日，杭州源創會，共享開發小技巧
云計算時代下，云廠商幫我們解決了計算和存儲資源的維護與拓展問題，但用戶也面臨被廠商綁定的問題。
2021年UCBerkeley 提出了Sky Computing（“天空計算”）的概念，其目標是允許應用跨多個云廠商運行，實現多云之間的互操作性。 算力和數據在多云之間的遷移是天空計算需要解決的兩個基本問題。隨著虛擬化技術的發展，算力遷移正在逐漸得到解決，無狀態計算密集型任務可以在各個云廠商無差別運行。但安全快速地進行跨云數據遷移和同步仍存在較大挑戰。
云計算背景下的分布式系統大多運行在同一數據中心的多臺服務器上，其間網絡延遲低，可靠性高?？缭苿t意味著服務器間物理距離的增加，導致網絡延遲增加和可靠性降低，服務器間的一致性維護，共識的建立都更加困難。 Xline是使用Rust開發的跨云KV數據庫，兼容Etcd的metadata存儲接口。Xline基于CURP協議實現，在跨云部署情況下相較基于Raft的Etcd有更好的性能，實驗表明理想情況下延遲低一倍。使用Xline可實現數據跨數據中心共享訪問，并且保證數據的一致性，方便業務系統實現多地多活部署。
OSCHINA 本期高手問答 (2 月 1 日 - 2 月 7 日) 我們請來了施繼成老師和大家一起探討關于“天空計算”相關的問題。
可討論的問題包括但不限于：
- 天空計算相較于云計算的優勢
- 跨云存儲面臨的技術挑戰
- Xline如何做到低時延跨云數據交互
- 分布式一致性協議原理與選型
- 如何打造低耦合可復用的協議框架
- Rust開發的優勢與劣勢
有其他相關問題，也歡迎大家積極提問！
嘉賓介紹
施繼成，DatenLord 聯合創始人兼 CTO，曾就職于谷歌、微軟、阿里巴巴等互聯網公司，多年操作系統和分布式系統研究和開發經驗。
為了鼓勵踴躍提問，我們會在問答結束后從提問者中抽取幸運會員贈予《Rust 實戰》書籍一本。
OSChina 高手問答一貫的風格，不歡迎任何與主題無關的討論和噴子。
下面歡迎大家就編程語言設計與開發相關的問題向施繼成老師提問，直接回帖提問既可。
高手問答第 296 期 —— 天空計算到底是不是云計算的未來？
@某人gmgn3 @osc_32324621 @pyboy58 @屮殖 @zerolemon
恭喜以上5位網友分別獲得《Rust 實戰》書籍一本。
請于02月16日12：00前登陸賬號， 私信@OSC噠噠 告知快遞信息（格式：姓名+電話+地址），逾期視為自動放棄哦~
@達坦科技DatenLord Rust 和 天空計算 都是我關注的內容。沒想到今天可以放到一起。不過我有點可能杞人憂天的擔心：就是國內“分聯網”，國外“給你斷網”的這種操作下，是否會帶來跨運營商實際操作的難度？各個廠商對天空計算的支持態度如何？以及，我層設想的，將發布后臺數據量少但是要求算力大的計算放在自建的廉價本地機房以避免干線機房的大額費用的思路，是否還有多少必要性？或者有沒有其它更好的解決方案？
@達坦科技DatenLord 請問云原生是什么意思嗎？
@達坦科技DatenLord 1.Rust語言如何入門開發?
2.天空計算相較于云計算的優勢, 這種混合云的開發, 例如華為云,騰訊云,或者私有云的類的自己不是也可以開發嗎?
3.Xline 如何做到低時延跨云數據交互? Rust的Xline 相當于JAVA的什么??
@達坦科技DatenLord 你好，請問你們在選擇分布式協議的時候，比如我們知道有Paxos算法，Raft算法以及其他實現像zookeeper的zab這么多實現，你們最后選用的是哪個，還是自研的，又是怎樣的考慮呢？
如果你們選用了raft，又是怎么克服它自身的缺點的呢？比如性能問題
謝謝
@達坦科技DatenLord 我們一直有做云平臺的設備數據存儲和計算功能，但是面對海量設備數據狀態信息時，經?？紤]的是使用數據庫優化的方案，以及簡化接口傳輸內容，進行優化。
在程序運行方面，rust或者云計算，能否提供對應的類似微服務的功能業務
@達坦科技DatenLord
1. 請問前面的回答中提到了“在無沖突情況下(fast path)，Curp 協議能比 Raft 協議或者 Paxos 協議節省 1 個 RTT。在有沖突的情況下（slow path），Xline 中的 Curp 能夠退化為 Raft 協議，恢復到 2 個 RTT”。怎么理解這里提到的沖突？
2. 軟件行業沒有銀彈。fast path 能夠比 slow path 節省 1 個 RTT，那它是怎么做取舍的？
@達坦科技DatenLord
1. 請問前面的回答中提到了
怎么理解這里提到的沖突？
2. 軟件行業沒有銀彈。fast path 能夠比 slow path 節省 1 個 RTT，那它是怎么做取舍的？
@達坦科技DatenLord 我想問一下使用 Rust 開發的跨云 KV 數據庫的優勢是什么？
引用來自“osc_32324621”的評論
@達坦科技DatenLord
1. 請問前面的回答中提到了
怎么理解這里提到的沖突？
2. 軟件行業沒有銀彈。fast path 能夠比 slow path 節省 1 個 RTT，那它是怎么做取舍的？
1. 以 Xline 的 KV 操作為例，如果 client 并發地讀寫不同的 key，那么這兩個操作是可以相互交換的，例如 client A 發起了 PUT X = 1 的請求，而 Client B 發起了 PUT Y = 2 的請求，那么這兩個請求在 CURP 看來誰先執行誰后執行都不影響狀態機的最終狀態，我們稱這兩個操作為 commutative(可交換的)。如果兩個 client 操作同一個 key，那么則需要看情況，如果兩個請求都是只讀請求，則依然滿足 commutative 原則。而這兩個請求如果其中包含了至少一個寫請求，則不滿足 commutative，因為對于讀寫操作，先讀后寫會讀到舊值，而先寫后讀會讀到新值，而對于寫寫操作，后寫會覆蓋先寫的結果。如果在 fast path 中，接收到的所有操作都滿足 commutative 原則，則成為無沖突；反之，在 fast path 中，接收到的若干個請求中，包含了至少一個不滿足 commutative 原則的操作，則認為有沖突，fast path 會 fallback 到 slow path，需要 2 個 RTT 來達成共識。
2. Raft 算法之所以需要 2 個 RTT，主要是因為它必須同時滿足持久化存儲（過半數的副本）和有序這兩個前提。client 只能和 master 通信，master 接收到請求后要執行 AppendEntries 操作，此時滿足有序前提，請求會以 log index 的形式確定好唯一的順序，再由 master 將這個順序和命令一同復制到集群中的過半數節點，這就導致 2 個 RTT。CURP 弱化了假設，將有序和持久化存儲分開到兩個角色中，即 master 和 witness 中，其中 master 來確定命令的唯一執行順序，而 witness 負責持久化（witness 中持久化的請求的執行順序是無保證的）。它帶來了一些取舍（架構設計上的復雜度，包括集群角色的增加，client 的請求發送方式，master retire 的復雜度等）：