1樓：李智慧型
不說CAP，任何軟體架構都需要在可用性、伸縮性、實時、事務等架構要素方面平衡，難以樣樣完美。
不說軟體架構，任何工作都要在時間、質量、資源方面平衡，難以樣樣完美。
不說工作，任何人都要在生活、健康、工作方面平衡，難以樣樣完美。
做架構，最怕被各種所謂的需求扯得找不到北，企圖什麼都實現，什麼都完美，最後四不像。
做軟體，最怕在老闆、客戶、團隊之間和稀泥，處處都想落個好，最後沒乙個好。
做人，最怕什麼都想得到，樣樣的都要有都要完美，最後崩潰。
回到CAP，CAP對不同的需求，意義是不一樣的，系統的CAP和區域性的CAP也不一樣。舉個栗子，某個資料的多個備份更新，可能會出現幾個備份資料在更新操作後一段時間不一致的情況，但是整個系統對資料訪問有約束，不允許對更新的資料立即訪問，那麼對系統而言就是一致的。所以，CAP是規範還是參考，因你的需求而定，因你對系統的期望而定。
2樓：harry
重視和參考本身不矛盾，CAP是種原理，指導我們根據產品模型有側重的尋求一致性，高可用，以及錯誤冗餘三方面的平衡，從這方面講，是需要被重視的。至於如果取得平衡，如何做取捨，量化標準是怎樣的，這最終取決我們的產品模型以及業務邏輯，從這點來看，CAP理論只是作為參考。
3樓：張琨
1. IT架構和傳統的現實之間是有聯絡的，比如建築軟體工程的各種模型很多的理論都可以追溯到其中。
2. 理論往往是指導實踐的乙個方向，你要說每個企業的架構設計時都CAp那不現實，所以綜上
理論需要理解和知道，但是做的時候還是因人因業務而異的。
4樓：Fenng
「2。大部分應用的資料量非常小（1GB以內），所以應該大力冗餘資料，比如每個表都關聯乙個User ID，有了冗餘，就可以把所有inner查詢給禁用掉，查詢速度提高10－100倍
」這是怎麼得出來的？什麼應用資料量比較小？大力冗餘速度就能提高10-100倍？怎麼得出來的？
5樓：李家才
任何的理論或者原則都是一些經驗，是作為參照用的，架構是以適用為原則，原則和理論可以作為架構的完備性做參考，同時避免犯一些架構常用錯誤。
6樓：iammutex
CAP理論不是乙個公式，而是防止你鑽牛角尖的理論。
在做架構設計時，首先需要考慮的就是你的架構需要滿足什麼樣的需求。這時候可以套用CAP理論來做儲存的選擇，而不會陷入無窮無盡對完美的追求中。
7樓：mysqlops
必須重視的，明白自己需要選擇啥，放棄啥，參考文章：http://www.
成熟的專案架構設計是什麼樣的
計算機或者軟體工程領域，是建立在成熟的基礎理論與廣泛實踐基礎上的。建議去廣泛系統的進行學習吧。尤其，不能限於一兩門程式語言，也不能侷限與一兩個應用框架。另外，在掌握一兩門主流語言之後，爭取進入主流的工程領域去一邊學習一邊實踐吧。另外，最簡單去GitHub看看，多一些了解開源世界的巨集大與強大。最浪費...
設計院是不是不太待見做結構設計的女生？
做結構設計的女生都很優秀！首先，能在設計院帶下來的結構女生具備了吃苦耐勞 加班加點 團隊協作強 忍耐力強 各方圍攻 等職業特徵。第二，自我學習能力強。如各種計算軟體 小外掛程式等都需要付出較多努力，畢竟女生很少玩遊戲！第三，強大的心理素質。下工地 跟甲方博弈 跟施工方溝通都需要良好的心態！ 建築集結...
為什麼企業招機械都是做結構設計的
李免銀 不然了，你如果準備好跨專業工作，自己找公司時講明。公司不是研究機構，來了就是賺錢的，管你機械專業學了什麼思維，你來了就是產出，而不是培養。 機械是出了名的氣宗專業，實踐成本高 試錯成本高 沒辦法除錯 沒辦法測試 成長難 成長慢 來錢少 來錢慢，而碼農呢？實踐成本低 試錯成本低 除錯成本低 測...