繼上一篇"訂單系統開發(仿淘寶和美團網) 之 項目總結(一)"，這篇博客重點想說下訂單系統開發的設計和有待優化改進的問題。
上圖是訂單系統數據庫設計比較重要的一個——其決定了訂單數據的橫向切割，而不是將所有的訂單數據都存放在一個表中。爲什麼要這樣設計？這樣做有什麼好處？(看下文便可知曉) 回答上面的疑問，我感覺有必要引出另外一個問題:對於數據庫設計，如何能降低併發量 或 提高數據的讀寫數度？我所知道和比較常見的做法如下：——
1.讀寫數據庫分離，瞭解數據庫的都知道：數據庫的(讀)共享鎖S和(寫)排它鎖(X)是互斥、無法共存的，即當一個表的數據在被修改時，會阻止其它用戶的讀取。
2.數據庫表的橫向(行數據)和縱向(數據列)切割。
3.對於基本上不會用戶查詢的多個列，可以使用json或二進制等壓縮序列化列字段存放數據，這樣有點兒類似於Google的Big Table，有助於提高查詢效率。
以上除了第一點在本次訂單系統開發中都有使用，而且我相信你看完了上圖，你應該會感覺到這樣的數據切割：數據的存放(位置)比較清晰，比如：對於‘未付款’的訂單數據，它一定是存放於Order_OrderInfo_Temp表中，這樣：用戶在搜索訂單狀態爲“未付款”的訂單時，可以很快方便的從此表中查詢；或當用戶在進行“取消交易”的操作時，基於上面第一點所提到的，它不會影響到處於'交易中'的訂單用戶的操作。
寫到這兒，感覺有點兒戛然而止——不知道該寫點兒啥了；回顧這個項目的開發歷程，模糊→清晰→迷茫→糾結→釋然，這就是我在項目的各個階段的感受，用一句話來形容就是：由最開始的感覺高山仰止、舉步維艱，到現在的“神馬都是浮雲”，困難都是暫時的，等你越過去(把它踩在腳下)，你也就感覺那算不上什麼。
現在只想談下，有待優化和比較棘手的地方——
1.目前的訂單系統跟支付系統的相互依賴程度比較高，以至於訂單的各個階段的操作，如：付款，買家確認收貨...，都需要調用支付系統的服務，以保證兩邊數據的同步。
2.由於支付系統是基於第三方支付平臺相關服務方法的封裝，即支付系統對“現金”進出操作只相當於是個通道，無法控制和保證每個操作的成功。
3.基於以上兩點，訂單系統與之交互的操作就比較被動，讓人感覺很不舒服，增大了程序的複雜度。
4.訂單和退款超時數據的處理，目前沒有使用定時器或數據庫job，暫時用幾個觸發點來代替，這樣從服務到UI都增加了相應的代碼處理。
怎樣讓訂單系統和支付系統儘可能的'解耦'，這將是下一個版本需要重點解決的問題!
就寫到這吧，希望有這方面經驗的朋友，能提些建議。