訂單系統開發(仿淘寶和美團網) 之 項目總結(下降數據庫併發量)

　　

　　繼上一篇"訂單系統開發(仿淘寶和美團網) 之 項目總結(一)"，這篇博客重點想說下訂單系統開發的設計和有待優化改進的問題。

　　

　　

　　　　

 

　　

　　上圖是訂單系統數據庫設計比較重要的一個——其決定了訂單數據的橫向切割，而不是將全部的訂單數據都存放在一個表中。爲何要這樣設計？這樣作有什麼好處？(看下文即可知曉)  回答上面的疑問，我感受有必要引出另一個問題:對於數據庫設計，如何能下降併發量 或 提升數據的讀寫數度？我所知道和比較常見的作法以下：——  

　　1.讀寫數據庫分離，瞭解數據庫的都知道：數據庫的(讀)共享鎖S和(寫)排它鎖(X)是互斥、沒法共存的，即當一個表的數據在被修改時，會阻止其它用戶的讀取。  

　　2.數據庫表的橫向(行數據)和縱向(數據列)切割。  

　　3.對於基本上不會用戶查詢的多個列，可使用json或二進制等壓縮序列化列字段存放數據，這樣有點兒相似於Google的Big Table，有助於提升查詢效率。

 　　以上除了第一點在本次訂單系統開發中都有使用，並且我相信你看完了上圖，你應該會感受到這樣的數據切割：數據的存放(位置)比較清晰，好比：對於‘未付款’的訂單數據，它必定是存放於Order_OrderInfo_Temp表中，這樣：用戶在搜索訂單狀態爲「未付款」的訂單時，能夠很快方便的今後表中查詢；或當用戶在進行「取消交易」的操做時，基於上面第一點所提到的，它不會影響處處於'交易中'的訂單用戶的操做。

　　

　　

　　寫到這兒，感受有點兒戛然而止——不知道該寫點兒啥了；回顧這個項目的開發歷程，模糊→清晰→迷茫→糾結→釋然，這就是我在項目的各個階段的感覺，用一句話來形容就是：由最開始的感受高山仰止、舉步維艱，到如今的「神馬都是浮雲」，困難都是暫時的，等你越過去(把它踩在腳下)，你也就感受那算不上什麼。

 　　如今只想談下，有待優化和比較棘手的地方——  

　　1.目前的訂單系統跟支付系統的相互依賴程度比較高，以致於訂單的各個階段的操做，如：付款，買家確認收貨...，都須要調用支付系統的服務，以保證兩邊數據的同步。  

　　2.因爲支付系統是基於第三方支付平臺相關服務方法的封裝，即支付系統對「現金」進出操做只至關因而個通道，沒法控制和保證每一個操做的成功。  

　　3.基於以上兩點，訂單系統與之交互的操做就比較被動，讓人感受很不舒服，增大了程序的複雜度。  

　　4.訂單和退款超時數據的處理，目前沒有使用定時器或數據庫job，暫時用幾個觸發點來代替，這樣從服務到UI都增長了相應的代碼處理。

 　  怎樣讓訂單系統和支付系統儘量的'解耦'，這將是下一個版本須要重點解決的問題!  

　　就寫到這吧，但願有這方面經驗的朋友，能提些建議。