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

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

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

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

　　3.對於基本上不會使用者查詢的多個列，可以使用json或二進位制等壓縮序列化列欄位存放資料，這樣有點兒類似於Google的Big Table，有助於提高查詢效率。

 　　以上除了第一點在本次訂單系統開發中都有使用，而且我相信你看完了上圖，你應該會感覺到這樣的資料切割：資料的存放(位置)比較清晰，比如：對於‘未付款’的訂單資料，它一定是存放於Order_OrderInfo_Temp表中，這樣：使用者在搜尋訂單狀態為“未付款”的訂單時，可以很快方便的從此表中查詢；或當用戶在進行“取消交易”的操作時，基於上面第一點所提到的，它不會影響到處於'交易中'的訂單使用者的操作。

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

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

　　1.目前的訂單系統跟支付系統的相互依賴程度比較高，以至於訂單的各個階段的操作，如：付款，買家確認收貨...，都需要呼叫支付系統的服務，以保證兩邊資料的同步。  

　　2.由於支付系統是基於第三方支付平臺相關服務方法的封裝，即支付系統對“現金”進出操作只相當於是個通道，無法控制和保證每個操作的成功。  

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

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

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

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