高併發簡介

• 蔡學鏞文章
• 高併發設計重點
• 高速 : 減少I/O,尤其硬體I/O
• 大量 : 緩衝區
• 高速
• 記憶體運算技術 , 缺點即斷電後無法持久化
• Event Sourcing儲存
• 紀錄從帳戶開戶以來的所有操作，必須把操作記錄都累計起來，才會得到當前的帳戶狀態
• 直接紀錄到事件日誌的尾端，不需要搜尋、定位、調整索引等附帶的行為
• 使用快照, 存放當前用戶狀態
• 無法像RDBMS那樣做很複雜的各種關聯查詢
• 大量
• 緩衝空間可以採用經典的環狀結構
• 部署多套一樣的系統，同時接收相同的業務請求，多套系統要把請求的次序統一起來，但只有其中一套真正會進行計算
• 參考範圍
• JMM模型
• SQL優化
• JVM優化
• 分布式環境設計
• Tomcat應用水平擴充 , 設置分流增加流量處理
• 將串行鎖變成並行鎖 , 將大鎖切成小鎖 , 增加流量處理

• 架構思維順序
• 業務
• 技術
• 組織
• 架構12原則 (principles)
• 架構設計的規範、原則
• 架構原則1：不要使用Stored Procedure，因為這會讓業務邏輯難以維護
• 架構原則2：一個系統內部可以包含儲存和程式碼，但系統間不能共用資料庫。不管寫入或讀出由單一系統控制,系統之間的依賴只透過API
• 架構原則3：邏輯容易變動的程式碼必須剝離成另一個系統，容易變動者（例如應用系統）可以依賴較不容易變動者（例如平台系統）
• 架構原則4：任何系統都不能依賴容易變動的系統
• 架構原則5：被調用方必須提供清晰、文件化的API。
• 架構原則6：使用者界面要被剝離出來，且使用者界面內盡量不要有邏輯
• 架構原則7：調用外部廠商的系統時必須只依賴SPI（Service Provider Interface，服務提供者界面），不依賴具體的系統。
• 架構原則8：業務邏輯的程式碼必須區分服務（service）和物件（object），服務沒有狀態，物件有狀態，服務操作物件，物件的狀態記錄在資料庫（和外部系統）。
• 架構原則9：服務不能直接讀寫資料（和外部系統）。
• 架構原則10：物件狀態的保存方式必須做出隔離，也就是提供資料隔離層。
• 架構原則 11：充血模型才是好的物件模型。且設計模型時，要考慮是否有強一致性的要求。
• 架構原則 12：禁止循環依賴。