2. 程式人生 > >一文帶你重新審視CAP理論與分散式系統設計

一文帶你重新審視CAP理論與分散式系統設計

阿新 • • 發佈：2019-01-12

這是一篇來自微信公眾號的文章，如果圖片看不到，可直接跳轉到文章出處檢視：https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650765365&idx=1&sn=75c9b2050c31299960a4123c05a17e18&chksm=f3f9cda0c48e44b6a74cdc6f41456322ec6976a3867d7535a06667991f10afd8c1910a8caced&mpshare=1&scene=1&srcid=0131xZRg8CutswdEBrcEhtJX#rd

一、引言

在現代分散式系統中，節點數目是巨大的。在CAP理論的範圍內，Michael Stonebraker斷言分割槽必然會發生，並且系統內發生節點失敗的機會隨著節點數的增加而呈指數級增加：

基於這樣的事實，很多人會問：

  • 如果發生分割槽（故障），系統會犧牲什麼？一致性還是可用性？

對於這個問題，我有幾個反問：

  • 發生分割槽這個假設在多大概率上會成立？哪些因素會造成分割槽？

  • 如果發生分割槽，一致性如何定義？應用需要什麼樣的一致性？

  • 如果發生分割槽，可用性如何定義？應用需要什麼樣的可用性？

  • 如果不發生分割槽，一致性和可用性又該如何取捨？

二、全球規模分散式系統

分散式系統是指聯網的計算機通過訊息傳遞來協調行為的系統。在這樣的系統中，機器之間併發執行，獨立故障，並且沒有全域性狀態和全域性鎖。

隨著網際網路公司的全球化，為了保證服務質量和響應速度，各大網際網路公司（Google、Amzon、Facebook、Alibaba等）紛紛在全球建立資料中心，部署服務和放置資料。為了提高可用性、響應速度以及滿足容災等需求，這些系統都採用了複製技術。這就帶來了服務和資料狀態的全球範圍內的資料複製和一致性問題。

類似這樣的系統有：Dynamo、PNUTS、Cassandra、Megastore、Mesa、Walter、COPS、Spanner、Gemini等。

三、分散式系統設計的兩大原則

分散式系統設計的原則有很多，這裡介紹兩個基礎性的原則。

1、通過複製來提高可用性

通過複製來提高可用性，這是分散式系統設計的首要原則。從複製型別來看，複製可以分為主動複製和被動複製。

在主動複製中，每個客戶端請求都由所有伺服器處理。主動複製首先由Leslie Lamport以“狀態機複製”命名。這要求由伺服器託管的程序是確定性的。

確定性意味著，給定相同的初始狀態和請求序列，所有過程將產生相同的響應序列，並且最終處於相同的最終狀態。為了使所有的伺服器接收到相同的操作序列，一般都使用原子廣播協議。原子廣播協議保證所有伺服器都接收到訊息或沒有訊息，並且它們都以相同的順序接收訊息。

主動複製的主要缺點是實際上大多數真實世界的伺服器都是非確定性的。

在被動複製中，只有一個伺服器（稱為主伺服器）處理客戶機請求。處理請求後，主伺服器更新其它（備份）伺服器上的狀態，並將響應傳送回客戶端。如果主伺服器發生故障，則其中一臺備份伺服器就會接管它。被動複製可以用於非確定性過程。被動複製與主動複製相比的主要缺點是在失敗的情況下，客戶端的響應會被延遲。

從程序與系統互動角度來看，複製分為同步複製和非同步複製。

同步複製 - 通過原子寫入操作來保證“零資料丟失”，即完全寫入。在本地和遠端副本儲存的確認之前，寫入不被認為是完整的。

非同步複製 - 本地儲存確認後，寫入即被認為是完整的。遠端儲存已更新，但可能滯後很小。系統性能會因非同步複製而大大提高。但在丟失本地儲存的情況下，遠端儲存不能保證具有當前的資料副本，並且最近的資料可能會丟失。

關於複製技術，目前有三大模型：事務複製、Paxos複製和虛擬同步。事務複製、Paxos複製討論的已經比較多，虛擬同步則較少看到有產品採用。

虛擬同步定義了一個動態的自組織程序組，這個程序組本身可以看作是一個複製變數，那麼這個變數需要特定應用中保持一致。虛擬同步常用的場景是訂閱釋出和DHT中相鄰節點的成員關係。虛擬同步和Paxos協議的區別在於不同的層次：Paxos協議可以用來保證虛擬同步的程序組檢視一致。事務複製和Paxos複製的區別在於：事務複製滿足ACID語義，有明確的BEGIN/COMMIT/ABORT介面；Paxos複製內部可能使用弱一致性的傳言協議，並可以呈現外部的一致性。Paxos複製沒有保證提供ACID語義和BEGIN/COMMIT/ABORT介面。

https://en.wikipedia.org/wiki/Virtual_synchrony

https://en.wikipedia.org/wiki/Replication_(computing)

個人認為複製的分類方式可根據節點組織關係分為以下三種：Master/Slave複製、Paxos複製和鏈式複製。這裡不贅述。

關於複製副本的數量，通常我們討論的都是3個副本，已經滿足容災和高可用的需要。但在Chubby、F1和Aurora中，為了更高的可用性，都採用了5或6個副本。結合同步複製、非同步複製以及鏈式複製，可以實現混合複製型別的系統，即5個副本中部分是實時同步，其它副本可以採用鏈式複製的方式，或者Paxos多數原則的方式，實現非同步複製。非同步複製的副本可以作為快照讀取的副本和OLAP的副本。

2、使用CAP理論指導分散式系統設計

複製技術是產生一致性問題的根源。由此帶來了分散式系統設計的第二個原則。

對於Internet這樣的全球規模的分散式系統，一直以來討論最多的是AP和CP系統。

CP系統是犧牲可用性的系統。複製同步的協議一般使用嚴格的法定數協議 (Paxos、Raft、ZAB)或者2PC協議。CP型別的系統有MongoDB、HBase、 Zookeeper等。

AP系統是犧牲一致性的系統。複製同步的協議一般使用非嚴格的法定數協議。AP型別的系統有 Couch DB、Cassandra、Amazon Dynamo等。

那麼有沒有CA系統？如何實現CA系統？本文將嘗試解答這個問題。

四、重新理解CAP

1、CAP三者並不對等：P是基礎，CA之間tradeoff

在全球廣域地理分佈環境下（全球規模的分散式系統），網路分割槽是一個自然的事實，甚至有人認為是必然的。

在這樣的情況下，有兩種聲音：

  • 因為分割槽是必然的，系統設計時只能實現AP和CP系統，CA系統是不可能的。

  • 從技術上來說，分割槽確實會出現，但從效果或者概率來說，分割槽很少出現，可以認為系統不會發生分割槽。由於分割槽很少發生，那麼在系統不存在分割槽的情況下沒什麼理由犧牲C或A。

從更廣闊的分散式計算理論背景下審視CAP理論，可以發現C，A，P三者並不對等。

CAP之父在《Spanner，真時，CAP理論》一文中寫到：

如果說Spanner真有什麼特別之處，那就是谷歌的廣域網。Google通過建立私有網路以及強大的網路工程能力來保證P，在多年運營改進的基礎上，在生產環境中可以最大程度的減少分割槽發生，從而實現高可用性。

從Google的經驗中可以得到的結論是，一直以來我們可能被CAP理論矇蔽了雙眼，CAP三者之間並不對稱，C和A不是P的原因（P不能和CA trade-off，CP和AP中不存在tradeoff，tradeoff在CA之間）。提高一個系統的抗毀能力，或者說提高P（分割槽容忍能力）是通過提高基礎設施的穩定性來獲得的，而不是通過降低C和A來獲得的。也就說犧牲C和A也不能提高P。

還有一種說法是，放棄C不是為了獲得A，而是為了低延遲（延遲不也是可用性的內涵嗎？我這裡有疑問）。PNUTS為了降低WAN上的訊息事務的延遲（幾百毫秒，對於像亞馬遜和雅虎這樣的企業需要實施的許多Web應用程式來說，成本太高），採用放棄一致性的做法。

而CA是系統的剛性強需求，但CA兩者也不對等。系統無論如何要保證一致性（無論事先還是事後，這是系統設計的最大不變性約束，後文會詳述），在這個前提下，可以談談可用性的程度。Google的Spanner就是這樣的思路。

總結：P是一個自然的事實，CA是強需求。三者並不對等。

補充：文章寫完之後，看到最新出版的文章《分散式資料庫中一致性與可用性的關係》，值得一讀。

2、保證不發生分割槽，CA也不容易兼得

在分散式系統中，安全性、活性是本質需求，並且廣泛的研究結果是分散式系統中一直存在一個廣泛意義的trade-off：在不可靠的分散式系統中無法同時實現安全性和活性。分散式系統的設計中充滿了安全性和活性的trade-off，FLA著名的論文《Impossibility of Distributed Consensus withOne Faulty process》就是說我們不可能設計一個演算法既可以絕對保證一致性（安全性）又無需時間等待的實現一致性（活性）。

CAP就是這個trade-off的的集中體現。分別對應於：

  • Safety：非正式來說，一個演算法沒有任何壞的事情發生，那麼該演算法就是安全的。CAP中的C就是典型的safety屬性：所有對客戶的響應都是正確的。

  • Liveness：相反，一個演算法最終有有一些好的事情發生，那麼該演算法就是活性的。CAP中的A就是典型的liveness屬性：所有的客戶最終都會收到迴應。

FLA中的故障是指：

  • Unreliable：有很多種方式可以讓一個系統不可靠，CAP中的P。

  • 其它故障：系統崩潰、訊息丟失、惡意攻擊、拜占庭故障等。

所以，CAP理論可以說是FLA不可能性的不同表達方式。P只是Unreliable的一種極端形式而已。在Google的Chubby文章中，指出Paxos協議維護系統的safety，引入時鐘來保證liveness，由此克服FLA的不可能性。實際上，基本的Paxos協議可以保證值一旦被選出後就一定不會改變，但不能保證一定會選出值來。換句話說，這個投票演算法不一定收斂。所以在系統設計時，Paxos演算法的使用是有條件的。

在資料庫領域，CAP也正是ACID和BASE長期博弈(trade off)的結果。ACID伴隨資料庫的誕生定義了系統基本設計思路，所謂先入為主。2000年左右，隨著網際網路的發展，高可用的話題被擺上桌面，所以提出了BASE。從此C和A的取捨消長此起彼伏，其結晶就是CAP理論。

從ACID和BASE來說，ACID是為了保證一致性而誕生，因而側重一致性；BASE是為了高可用系統的設計而誕生，因而側重可用性。在分解C和A的情況時，肯定要涉及P，所以CAP理論統一了這一切。如果非要說酸鹼，或者說酸鹼平衡，那就是平衡於CAP理論。

CAP並不與ACID中的A（原子性）衝突，值得討論的是ACID中的C（一致性）和I（隔離性）。ACID的C指的是事務不能破壞任何資料庫規則，如鍵的唯一性。與之相比，CAP的C僅指單一副本這個意義上的一致性，因此只是ACID一致性約束的一個嚴格的子集。如果系統要求ACID中的I（隔離性），那麼它在分割槽期間最多可以在分割槽一側維持操作。事務的可序列性（serializability）要求全域性的通訊，因此在分割槽的情況下不能成立。

C與A之間的取捨可以在同一系統內以非常細小的粒度反覆發生，而每一次的決策可能因為具體的操作，乃至因為牽涉到特定的資料或使用者而有所不同。我們在分散式系統設計的兩大原則中討論過保持一致性的手段：同步複製和非同步複製，結合複製協議的各種模式，請參考下表。例如簡單滿足了C，但延遲升高了，吞吐量下來了，還有什麼可用性？我覺得延遲是包含在可用性的範圍內的，不可用就是延遲的極大極限值。還有文章就只討論一致性，可用性和效能問題（比如阿里何登成的《資料一致性-分割槽可用性-效能——多副本強同步資料庫系統實現之我見》），說明在不考慮分割槽的情況下，CA問題依然是系統設計的難點。

重新審視本文時，恰好看到一個新的理論PACELC：even when the system is running normally in theabsence of partitions, one has to choose between latency (L) and consistency(C). 可謂和我的想法不謀而合。

PACELC：In case of network partitioning (P) in a distributed computersystem, one has to choose between availability (A) and consistency (C) (as perthe CAP theorem), but else (E), even when the system is running normally in theabsence of partitions, one has to choose between latency (L) and consistency(C).（https://en.wikipedia.org/wiki/PACELC_theorem）

可用性並不是簡單的網路連通，服務可以訪問，資料可以讀取就是可用性，對於網際網路業務，可用性是完整的使用者體驗，甚至會延伸到使用者現實生活中（補償）。有的系統必須容忍大規模可靠分散式系統中的資料不一致，其中原因就是為了在高併發條件下提高讀寫效能。

必須容忍大規模可靠分散式系統中的資料不一致，有兩個原因：在高併發條件下提高讀寫效能， 並要區分物理上導致的不一致和協議規定的不一致。

  • 節點已經宕機，副本無法訪問（物理）

  • 法定數模型會使部分系統不可用的分割槽情況，即使節點已啟動並執行（paxos協議）

  • 網路斷開，節點孤立（物理）

所以，保證不發生分割槽，CA也不是免費午餐：儘管保證了網路可靠性，儘量不發生分割槽，同時獲得CA也不是一件簡單的事情。

CA系統才是真正的難點。

宣稱是CA系統的，目前有兩家：一家是Google的Spanner，一家是Alibaba的OceanBase。

3、發生分割槽時，也不要隨意犧牲CA

雖然架構師仍然需要在分割槽的前提下對資料一致性和可用性做取捨，但具體如何處理分割槽和恢復一致性，這裡面有不計其數的變通方案和靈活度。

當發生分割槽時，系統設計人員不應該盲目地犧牲一致性或可用性。當分割槽存在或可感知其影響的情況下，就要預備一種策略去探知分割槽並顯式處理其影響。這樣的策略應分為三個步驟：探知分割槽發生，進入顯式的分割槽模式以限制某些操作，啟動恢復過程以恢復資料一致性並補償分割槽期間發生的錯誤。

這一切都需要在系統設計之初考慮到，並在測試時模擬各種故障保證覆蓋到你的測試點。

構建高度穩健的基礎設施永遠是第一要務，所以我不認為網路分割槽與CA屬性是對等的。

五、分解，分解，分解

分解CAP：“三選二”的公式一直存在著誤導性，它會過分簡單化各性質之間的相互關係。現在我們有必要辨析其中的細節。

CAP三種性質都可以在程度上衡量，並不是非黑即白的有或無。可用性顯然是在0%到100%之間連續變化的，一致性分很多級別，連分割槽也可以細分為不同含義，如系統內的不同部分對於是否存在分割槽可以有不一樣的認知。

1、P分解：延遲？故障？分割槽？

if you're working with distributed systems,you should always be thinking about failure.

如果你正在使用分散式系統，你應該永遠考慮失敗。

故障，延遲，分割槽，是一組非常相關的概念。

在通訊網路中，最重要的兩個屬性是頻寬和延遲。延遲也往往取決於鏈路轉發節點的效率。由於延遲的存在，系統很難就全域性狀態達成一致。當鏈路發生故障，就會導致網路分割槽。由於延遲的特性，就算鏈路沒有發生故障，系統也可能判斷髮生了分割槽。

對P的分解需要從網路開始。網路包含了基礎設施，光速限制以及軟體配置與升級等。Google通過建設自己廣域網獲得高可靠的基礎設施支撐，對於Google Spanner的CA系統，CAP之父曾總結說網路才是根本。

而光速限制則告誡我們：一致性是一個結果，不是實時的狀態。由於光速無法超越，則延遲必然存在（下圖顯示從加拿大到荷蘭的網路延遲在150毫秒左右）。延遲的存在讓一個節點無法獲得對方節點的實時狀態。

https://people.eecs.berkeley.edu/~rcs/research/interactive_latency.html

由於延遲的存在，有人說即時性和全球性的一致性是不可能的，宇宙根本不允許它。我以前從事分散式系統研發時，帶我的博士總是告誡說，系統設計不要超越時空的限制。

軟體配置與升級則體現基礎設施搭建工程能力和運維能力。Google調查了Spanner事故的內部原因分類顯示，網路類別的事故是由網路分割槽和網路配置問題造成的。

Michael Stonebraker在《Errors in Database Systems, Eventual Consistency, and the CAP Theorem》一文中通過對故障進行分解，給出進入CAP討論範圍的部分故障列表：

  • 應用程式錯誤。應用程式執行一個或多個不正確的更新。一般來說，這不是幾分鐘到幾個小時之後才發現的。必須將資料庫備份到違規事務之前的一個時間點，然後重做後續活動。

  • 可重複的DBMS錯誤。DBMS在處理節點上崩潰。在具有副本的處理節點上執行相同的事務將導致備份崩潰。這些錯誤被稱為Bohr錯誤。

  • 不可重複的DBMS錯誤。資料庫崩潰了，但是一個副本很可能沒問題。這些通常是由處理非同步操作的奇怪角落造成的，並且被稱為Heisenbugs。

  • 作業系統錯誤。作業系統崩潰在一個節點，產生“藍屏死亡”。

  • 本地叢集中的硬體故障。這些包括記憶體故障，磁碟故障等。通常，這些會導致作業系統或DBMS的“緊急停止”。但是，有些時候這些失敗就像Heisenbugs一樣。

  • 本地叢集中的網路分割槽。LAN失敗，節點不能再相互通訊。

  • 災難。地方資料中心被洪水，地震等等所消滅。群集不再存在。

  • WAN中的網路故障將叢集連線在一起。WAN失敗，群集不能再相互通訊。

Michael Stonebraker總結認為錯誤1、2和7是CAP定理根本不適用的情況的示例，3、4、5和6是本地故障，錯誤8是WAN網路中的一個分割槽，但這是非常罕見的。所以不要盲目的follow CAP理論，輕易的放棄一致性。分解故障，進行鍼對性的設計。

PACELC理論本質就是對分割槽進行分解：發生分割槽時，在CA之間取捨；沒有發生分割槽時，在C和延遲之間取捨。（我們系統設計的大多數情況就是在沒有發生分割槽的時候）

如何探知分割槽？這涉及到分散式系統中常見且重要的話題：故障檢測。故障檢測需要從從分散式系統的定義談起：節點和連線的模型。在分散式系統中，通過訊息通訊建立的連線，連線兩端的節點在任意時刻以及節點中執行的程序，隨時都可能發生故障。

在分散式系統中，節點故障判斷必然依賴超時（時限設定），在一定的超時時間內，訊息可能延遲，也可能鏈路故障造成的節點不可達，在這樣的情況下，如何判斷節點故障？常見的策略是間隔一段時間重新嘗試連線，降低誤判的風險，這樣就增加了系統的延遲時間，也就是降低了可用性。遠端節點無法準確的判斷存活還是故障，就無法準確的判斷分割槽是否真的發生。所以CAP之父在其著名的文章《CAP Twelve Years Later: How the "Rules" Have Changed》中提出了分散式設計的核心問題：分割槽兩側是否能夠在無通訊的情況下繼續其操作？

下面舉一個複雜的例子。在分散式事務這樣的場景中，涉及的訊息和操作很多。每一條訊息和操作都有可能故障，如下圖所示。這就要求我們在程式的設計和實現過程中，針對大量的異常和故障編寫程式碼。這就是故障檢測之後的故障處理。

故障處理如何做？有以下模型可以考慮。

  • 相關推薦

    一文帶你重新審視CAP理論與分散式系統設計

    這是一篇來自微信公眾號的文章，如果圖片看不到，可直接跳轉到文章出處檢視：https://mp.weixin.qq.com/s?__biz=MzI4NTA1MDEwNg==&mid=2650765365&idx=1&sn=75c9b2050c31

    一文帶你深度解析騰訊雲直播答題方案

    exc com erp 同學 col 測試 的確 影響 cep 歡迎大家前往雲+社區，獲取更多騰訊海量技術實踐幹貨哦~ 作者：騰訊視頻雲 進入2018年最火的新鮮事物無疑就是“直播答題”了，動輒上百萬的獎金更是吸引了大量用戶的參與。一場直播動輒幾百萬的獎金，每人可以分到

    一文帶你了解激光雷達重要指標及參數

    因此 一個 https 速度 .com p s 展示 jpg left 博客轉載自：https://www.leiphone.com/news/201801/oySuWNzftbNrWwpv.html 雷鋒網(公眾號：雷鋒網)按：本文作者SLAMTEC（思嵐科技公號slam

    一文帶你吃透執行緒池

    微信公眾號：[Amos部落格] 內容目錄 TreadPoolexecutor原始碼解析 類關係圖 Executor介面 ExecutorService介面 AbstractExecutorService 成員變數

    一文帶你快速瞭解最火的數字經濟（大資料、人工智慧等都有）

    人工智慧行業應用加速（暴富機會由“網際網路+”轉向AI+） “網際網路+”紅利已開發將盡，未來，新的暴富紅利將由“人工智慧”接棒。從產業演進看，科技巨頭正加速全球化併購，打造AI生態閉環，開源化也將成為全球性趨勢。開源化使得人工智慧的行業運用門檻急遽降低，未來幾年將迎來人工智慧行業應用浪潮。 2

    某高校計算機程式設計教授教你如何快速入門python，一文帶你進入程式設計

    如何快速入門Python 學習任何一門語言都是從入門(1年左右)，通過不間斷練習達到熟練水準(3到5年)，少數人最終能精通語言，成為執牛耳者，他們是金字塔的最頂層。雖然萬事開頭難，但好的開始是成功的一半，今天這篇文章就來談談如何開始入門 Python。只要方向對了，就不怕路遠。 設定目標

    一文帶你學會使用YOLO及Opencv完成影象及視訊流目標檢測（上）|附原始碼

    計算機視覺領域中，目標檢測一直是工業應用上比較熱門且成熟的應用領域，比如人臉識別、行人檢測等，國內的曠視科技、商湯科技等公司在該領域佔據行業領先地位。相對於影象分類任務而言，目標檢測會更加複雜一些，不僅需要知道這是哪一類影象，而且要知道影象中所包含的內容有什麼及其在影象中的位置，因此，其工業應用比較廣泛。那麼

    一文帶你學會使用YOLO及Opencv完成圖像及視頻流目標檢測（上）|附源碼

    目錄 aliyun sele 分數 connected 出了 man 領域 turn 計算機視覺領域中，目標檢測一直是工業應用上比較熱門且成熟的應用領域，比如人臉識別、行人檢測等，國內的曠視科技、商湯科技等公司在該領域占據行業領先地位。相對於圖像分類任務而言，目標檢測會更加

    一文帶你瞭解求職面試那些名詞（乾貨）

    喬兄剛剛經歷了19秋招，收穫了百度offer，馬上要迎來了19春招，有很多公眾號的粉絲經常會問今年不是2018年嗎，你咋就已經完成了2018校招了？由於被很多人經常問起，下面喬兄給大家普及一下跟校招相關的名詞。 現在時間是北京時間 2018.11.15，請務必根據現在的時間去推測你的情況。 201

    還沒寫過爬蟲的小白點進來，一文帶你入門python爬蟲（小白福利）

    入門 準備工作 需要準備的東西： Python、scrapy、一個IDE或者隨便什麼文字編輯工具。 隨便建一個工作目錄，然後用命令列建立一個工程，工程名為miao，可以替換為你喜歡的名字。 scrapy startproject miao 隨後你會得到如下的一個由scrapy建立

    一文帶你瞭解 Raft 一致性協議的關鍵點

    此文已由作者孫建良授權網易雲社群釋出。 歡迎訪問網易雲社群，瞭解更多網易技術產品運營經驗。 Raft 協議的釋出，對分散式行業是一大福音，雖然在核心協議上基本都是師繼 Paxos 祖師爺（lamport） 的精髓，基於多數派的協議。但是 Raft 一致性協議的貢獻在於，定義了可易於實現的一致性協議

    一文帶你看懂卷積神經網路(CNN)讓你意想不到的10創新idea

        全文摘要 卷積神經網路(CNN)可以說是深度學習發展的一個縮影，特別是現在在計算機視覺方面已經得到了非常成熟的應用，在目標檢測、目標追蹤等方面也是獨領風騷，本文將講述卷積神經網路近些年來的發展歷程，以及它到底創新在什麼地方。本文略長，看完大約3

    slam是什麼意思？一文帶你讀懂SLAM

      SLAM是Simultaneous localization and mapping縮寫，意為“同步定位與建圖”，主要用於解決機器人在未知環境運動時的定位與地圖構建問題，為了讓大家更多的瞭解SLAM，以下將從SLAM的應用領域、SLAM框架、SLAM分類（基於感測器的SLAM分類）

    訓練的神經網路不工作？一文帶你跨過這37個坑

    近日，Slav Ivanov 在 Medium 上發表了一篇題為《37 Reasons why your Neural Network is not working》的文章，從四個方面（資料集、資料歸一化／增強、實現、訓練），對自己長久以來的神經網路除錯經驗做了 37 條總結，並穿插了不少出色

    從能做什麽到如何去做，一文帶你快速掌握Python編程基礎與實戰

    選擇結構 好處 過濾 類和對象 最重要的 既然 項目 能力提升 for語句 摘要：Python語言的教程雖然隨處可見，但是忙於日常業務/學習的你或許：一直想要“找個時間學一點”，但是又不知道該從何下手？本文將從Python能做什麽，如何學習Python以及Python的基

    從原始碼入手，一文帶你讀懂Spring AOP面向切面程式設計

    基於這兩者的實現上，這次來探索下Spring的AOP原理。雖然AOP是基於Spring容器和動態代理，但不瞭解這兩者原理也絲毫不影響理解AOP的原理實現，因為大家起碼都會用。 AOP，Aspect Oriented Programming，面向切面程式設計。在很多

    一文帶你看懂cookie，面試前端不用愁

    本文由雲+社群發表 在前端面試中，有一個必問的問題：請你談談cookie和localStorage有什麼區別啊？ localStorage是H5中的一種瀏覽器本地儲存方式，而實際上，cookie本身並不是用來做伺服器儲存的。但在 localStorage 出現之前，cookie被濫用當做了儲存工具，什麼資

    一文帶你瞭解程序

    現代計算機體系結構 馮·諾依曼結構 要了解程序的概念得先從計算機的體系結構說起，首先了解一些世界上用得最多的計算機體系結構：馮·諾依曼結構(還有其他的計算機體系結構：如哈佛結構) 馮·諾曼結構處理器具有以下幾個特點：必須有一個儲存器；必須有一個控制器；必須有一

    實用 | 一文帶你菠菜合買平臺出租零基礎入行深度學習

    深度菠菜合買平臺出租聯絡方式：QQ：2747044651【征途原始碼論壇http://t.cn/Eyb4XkK】學習存在一定的門檻，這是必然的，並不是網上說的僅僅成為一個“調包狹”。你可能是結合一些實際的業務場景，需要復現一些模型，甚至自己設計一些模型，所以需要具備一定的數學、英語、程式設計等等能力。 &n

    一文帶你理解Java中Lock的實現原理

    當多個執行緒需要訪問某個公共資源的時候，我們知道需要通過加鎖來保證資源的訪問不會出問題。java提供了兩種方式來加鎖，一種是關鍵字：synchronized，一種是concurrent包下的lock鎖。synchronized是java底層支援的，而concurrent包