快取在我們系統內部也廣泛使用，基本分本地快取和分布式快取。本地快取由自定義寫的快取元件，分靜態快取與動態快取，所謂靜態就是資料存入就不會被應用清除，動態快取採用lru淘汰策略。本地快取自不多說。但就使用的分布式快取redis說明下。
說到快取的使用場景，1、需要經常訪問；2、是很少發生改動；（如果使用快取並且資料發生頻繁改動，同步開銷需要注意控制。）
多個子系統都需要使用快取，比如上篇寫到的使用者許可權資料，還有基礎資料，比如（機構，品牌、品類，商品等等），還有一些商品**資訊。設計使用上，沒有使用redis持久化，只是單單記憶體快取，比如，key設計，每種api時的時間複雜度的考量，快取更新策略等，這點大家基本達成共識。那麼我們的部署架構應該怎麼來做呢？
另一種聲音是b：最好是每個子系統同一套快取集群。（前期可以是同乙個例項）。
我們還是使用目標場景決策，來選型我們的部署方案。
使用過redis的同學都很清楚，redis單執行緒結構，所以，設計快取介面方案時，都注意控制每個api的請求處理時間。那不相關的系統快取，放在一起的原因，只有乙個解釋，就是成本考慮。
a b
成本 低 高
效能 低 高
操作耦合性 高 低
維護複雜性 低 相對高
當然，後續對子系統快取設計，也需要考量快取資料量，訪問壓力，進而採用不同的快取策略。
綜上：前期可以將不同系統快取使用多redis例項隔離。
零售系統軟體架構 資料架構之資料分片
對於乙個由多個子系統組成的乙個完整的系統而言。系統之間的互動，也在很大程度上反映了資料分布的情況。每個業務系統都具有自己本系 特的業務資料。所以，目前每個業務系統乙個業務庫的形式。這種就是類似大家常說的垂直分庫。然而隨著業務單據的劇增，單一業務庫的壓力自然上公升，特別是對企業應用而言，業務操作的重要...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...
軟體架構設計 二 系統總體架構設計
系統總體架構非常重要，但在表達上都不盡相同，下面介紹幾種常用的系統架構模式，供參考 assf access service biz standard fundation 模式 訪問 服務 業務功能 標準 基礎，對系統架構各個層次均有表達，但部署應用模式需要有單獨說明，如下圖方式組織系統總體架構 lo...