非常著名的設(shè)計模式, 把數(shù)據(jù)讀取和數(shù)據(jù)寫入過程相分離, 來拉升整個系統(tǒng)的性能. 同時也能避免多線程update時的沖突
問題
一般我們做數(shù)據(jù)統(tǒng)計, 面對的就是一個類似excel的表格, 我們從中讀取數(shù)據(jù)或者向內(nèi)寫回數(shù)據(jù).
在經(jīng)典設(shè)計模式下, 通過Database access Level讀出來一些數(shù)據(jù), 組裝成Data Transfer Object,
我們可以對這些DTO進(jìn)行修改, 然后再刷回數(shù)據(jù)庫
這種CRUD的操作的問題也很容易理解
高一致性的代價是多線程下加鎖性能不高
解決
讀寫分離了解一下, 其余的不再闡述了.基于讀寫分離的一致性問題是獲得性能的代價.
決策
- 業(yè)務(wù)是否允許幻讀, 如果不允許的話, 是否能通過一些標(biāo)志位讓業(yè)務(wù)層知道自己讀的這一條高概率幻讀了. 需要刷新(訂票網(wǎng)站通常用的模式, 實際上飛機票是超額發(fā)票等退票或者自動升艙的. 這是一個基于排隊論的業(yè)務(wù)問題而不是設(shè)計模式問題)
- 這種模式下帶來的成本能否接受. Mysql讀寫分離意味著數(shù)據(jù)可能存了兩份, 而read on snapshot的模式意味著為了讀操作按照時間窗口不斷生成snapshot
- 如果讀進(jìn)程是在客戶端的, 服務(wù)端是否在updat后主動去通知客戶端用最新的數(shù)據(jù)呈現(xiàn)給用戶以減少幻讀的影響范圍