題目是一句golang編程箴言,對它的理解可大可小。
往小了說,golang建議使用channel來共享信息而不是使用共享內存,這是一種優雅的方式,避免了數據同步帶來的繁瑣和低效。
往大了說,本質上還是讓資源去調度請求,而不是讓請求去調度資源。
有些時候,思維的轉變,問題的視角,會帶來意想不到的收獲
資源就那么多,所有請求有序使用資源的方式就是通信的方式,反過來,為每個請求虛擬出它獨占資源的假象,那就是共享的方式。兩種截然不同的方式,差異體現在仲裁成本,這個成本決定了它們承載并發的能力。
一個一個說。
電路交換 vs 分組交換
電路交換試圖占有整條電路(其實是最后一公里),若不成功,必須等到成功。
分組交換將長信息分割成若干小數據包,小數據包統計復用鏈路。
批處理系統 vs 分時系統
批處理用戶一旦使用系統,則會獨占系統到任務完成,其它用戶等待。
分時系統將時間分片,多用戶被調度復用時間片。
CSMA/CD vs 交換式以太網
CSMA/CD主機試圖獨占總線發送數據包,若不成功便退避直到成功。
交換式以太網數據包在交換機有序排隊,復用buffer。
Apache vs Nginx
Apache為每一個請求生成一個task,該task一旦獲得CPU,其它task將等待。
Nginx采用異步模型,所有請求分時復用固定數量task的CPU時間。
共享內存 vs erlang/go channel
共享內存對寫寫以及讀寫是互斥,每次只允許一個操作,其它不得不等待,重試。
erlang/go channel將內容拆解為事務消息,依靠消息的有序傳遞共享信息。
...
我們來看上述兩兩比較的共性。
可將上述所有的二者抽象為爭搶模式和有序模式:
對于爭搶模式,本質上需要對沖突進行仲裁。
對于有序模式,本質上需要對并發進行調度。
所謂對沖突進行仲裁,意思就是發生沖突后怎么辦。無論是退避重試,還是等待,此期間均是什么都做不了,且仲裁本身需要昂貴的成本。
并發調度就會好太多,有序化便無沖突,也就沒有仲裁成本了,沒有了仲裁,也就無需重試,等待,便可以干別的了,處理完全異步化。
我們再來對比之前技術優劣:
電路交換 vs 分組交換
電路交換一旦占線,你需要自己不斷重試。
分組交換你只管發數據包,交換節點會自動調度這些數據包到達目的地后重組。
批處理系統 vs 分時系統
批處理系統一旦系統被占,你就要排隊等待或者待會兒再來。
分時系統你只需要下發任務,任務調度系統會讓所有用戶的任務分時復用時間片。
CSMA/CD vs 交換式以太網
CSMA/CD網卡需要不斷監聽沖突并重試。
交換式以太網卡只需要發包,交換機會排隊調度來不及轉發的數據包。
Apache vs Nginx
Apache線程/進程若沒被調度到CPU,就需要等待直到被調度切換至CPU。
Nginx只需將事件通知到,工作進程便會輪詢處理完所有請求。
共享內存 vs erlang/go channel
共享內存訪問需要加鎖,若持鎖失敗,要么忙等重試,要么待會兒再來。
erlang/go channel以消息傳遞通信,消息發出后就不用管了,除非它希望得到回饋,完全異步。
可見,這又是一個殊途同歸。同類的還有:
PCI vs PCIe,從總線到交換。
宏內核 vs 微內核,從共享數據結構到消息傳遞。
Spin/RW Lock vs RCU Lock,從爭搶鎖到操作副本原子更新。
RCU原理
為什么沖突仲裁的爭搶模式無法承載大并發,因為過載的沖突仲裁開銷會將資源淹沒,若要承載大并發,必然要采用調度的方式。要理解這一要素,需要換一個視角。
我們看操作的是信息的本身,還是信息的副本。
回到本文題目,“以通信方式共享內存”操作信息的副本, 而“以共享內存方式通信”則操作信息本身。
操作信息副本可以保證同時有且只有一個實體操作該副本,如果有兩個實體需要操作該副本,那就再復制一個副本,這就保證了無沖突,業務流是可控無阻塞的。
RCU可做到業務無阻塞并發,無論是spinlock還是rwlock,都做不到。spinlock/rwlock鎖臨界區,造成臨界區串行化,而RCU沒臨界區,它將本屬于臨界區的邏輯作為副本操作,擇機原子更新,這便可做到無阻塞并發。
操作副本是無阻塞并發的甘泉,如果把并發看作是時間擴展性,那么將信息共享到遠方則是空間擴展性,完成這件事的是網絡,目前它是TCP/IP網絡。TCP/IP網絡采用了“以通信方式共享內存”的方式,它無疑是正確的。
我不懂erlang,但大致知道它的意思,erlang沒有變量,只操作副本,它是通信網絡在編程語言上的映射,對于golang,大概也是如此,使用go channel可以像網絡收發一樣來處理信息。
我們看socket接口,它實屬用通信的方式共享內存的古老方式。
socket接口一開始是進程間通信機制,與之通信的進程可在本機,也可在遠處,可在世界任意地方。“以通信方式共享內存“,是最原始的編程模式,一直到現在依然正確。
共享內存是一種本地優化,僅有編程意義,卻沒有擴展性,無論是無阻塞并發的時間擴展性,還是將信息傳遞給遠方的空間擴展性。
共享內存是一種本地優化,優化的是指令操作延時,與其將信息封裝成消息并傳遞,不如直接操作信息本身,它編程更簡單,代碼指令更少,執行延時更低。但高并發并不care指令延時,高并發care同時執行的有效指令數,而spin,switch不屬于有效指令,故共享內存天生不與高并發配對。
此外,還是那個觀點,網絡編程場景,普遍毫秒級的單流通信延時,共享內存相比消息傳遞節省個微妙甚至納秒級的操作延時,并無太大意義。要怪就怪光速吧。
從云原生開始
云原生是面向微服務的架構,而消息傳遞是微服務交互的媒介,每個工人都接觸過關于消息隊列的概念,正是消息支撐了云原生微服務。
消息并不封裝狀態,消息本身無狀態,狀態通過消息之間的交互來體現。消息交互可自由組合,這是分布式的源泉,而云原生本身就是面向分布式的設計。
一個部署云原生應用的IDC機房就是縮小版的全球TCP/IP互聯網,無狀態的消息在分布式的微服務之間傳遞,狀態僅由微服務的交互定義和維護。
甚至一臺物理主機內部板卡也成了微型版的全球TCP/IP互聯網,無狀態的消息在分布式的模塊之間傳遞,狀態僅由模塊之間的交互定義和維護。
共享內存類似總線,大家擁有平等訪問權,但寫訪問時要獨占。我們可以從總線和消息交換的關系看共享內存的處境。
曾經,主機主板上很多總線,很多模塊都要先爭搶獲得總線控制權才能與CPU或別的模塊通信,但后來PCIe將總線改成了由Hub互聯的交換網絡,采用消息交換替換了總線仲裁。
以太網在此之前已經走過了同樣的軌跡。
近來年被工人們提倡的微內核思想,大致也是這么回事,將對共享數據結構的操作換成了消息傳遞。
為什么這些都和全球TCP/IP互聯網類比呢?因為TCP/IP的基礎就是異步的,無狀態的,分布式的,消息傳遞的分組交換網。
總線簡單樸素,隨著系統規模的擴大,總線爭搶帶來的時間損耗指數級上升,人們發現總線無法支持高并發及無法物理擴展時,消息傳遞便替換了總線。大規模系統,消息操作帶來的額外延時是可以忽略不計的。
無論內部板卡,局域網,PCI,操作系統都是從局域范圍開始的,它們一開始從總線開始便不足為奇。然而互聯網一開始就是連接分布式廣域端的,一開始就不適合采用總線結構,這反過來說明總線在分布式場景的不適用。
我一向贊美TCP/IP端到端原則,正是它無狀態的IP細腰讓互聯網規模得以任意擴大而不引入額外開銷,而細腰也是無狀態消息交換的核心,只在發送端和接收端之間定義和維護狀態,而不是所有端一起維護共享總線或內存的狀態。
因此,消息傳遞也遵循端到端原則,可以自由擴展規模,總線和共享內存則相反。
以上從局域擴而大之的視角,我們看到了消息傳遞替換總線的趨勢。
反過來,從廣域向內縮,規模在漸小,傳輸延時在漸短,越來越不分布式,無狀態消息傳遞帶來的可擴展優勢越發無用武之地,其額外封裝帶來的額外延時逐漸承擔了端到端延時的大頭。
除去額外的消息封裝和傳輸操作,所有不多的實體直接操作信息所在的內存,最小化端到端延時便成了可觀的收益,因此,總線和共享內存便是微縮版系統的極致了。
總結
這就兩邊都說得通了,從小規模到大規模,總線和共享內存被消息傳遞替代,從大規模到小規模,總線和共享內存則是消息傳遞的優化。
就像廣義相對論,牛頓力學,量子力學一樣,不同的規模尺度有不同的哲學。
-
以太網
+關注
關注
40文章
5419瀏覽量
171609 -
內存
+關注
關注
8文章
3019瀏覽量
74008 -
總線
+關注
關注
10文章
2878瀏覽量
88053
原文標題:深刻理解 | 以通信方式共享內存,不要以共享內存方式通信
文章出處:【微信號:LinuxHub,微信公眾號:Linux愛好者】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論