订单系统开发(仿淘宝和美团网) 之 项目总结(下降数据库并发量)

　　

　　继上一篇"订单系统开发(仿淘宝和美团网) 之 项目总结(一)"，这篇博客重点想说下订单系统开发的设计和有待优化改进的问题。

　　

　　

　　　　

 

　　

　　上图是订单系统数据库设计比较重要的一个——其决定了订单数据的横向切割，而不是将全部的订单数据都存放在一个表中。为何要这样设计？这样作有什么好处？(看下文即可知晓)  回答上面的疑问，我感受有必要引出另一个问题:对于数据库设计，如何能下降并发量 或 提升数据的读写数度？我所知道和比较常见的作法以下：——  

　　1.读写数据库分离，了解数据库的都知道：数据库的(读)共享锁S和(写)排它锁(X)是互斥、没法共存的，即当一个表的数据在被修改时，会阻止其它用户的读取。  

　　2.数据库表的横向(行数据)和纵向(数据列)切割。  

　　3.对于基本上不会用户查询的多个列，可使用json或二进制等压缩序列化列字段存放数据，这样有点儿相似于Google的Big Table，有助于提升查询效率。

 　　以上除了第一点在本次订单系统开发中都有使用，并且我相信你看完了上图，你应该会感受到这样的数据切割：数据的存放(位置)比较清晰，好比：对于‘未付款’的订单数据，它必定是存放于Order_OrderInfo_Temp表中，这样：用户在搜索订单状态为“未付款”的订单时，能够很快方便的今后表中查询；或当用户在进行“取消交易”的操做时，基于上面第一点所提到的，它不会影响处处于'交易中'的订单用户的操做。

　　

　　

　　写到这儿，感受有点儿戛然而止——不知道该写点儿啥了；回顾这个项目的开发历程，模糊→清晰→迷茫→纠结→释然，这就是我在项目的各个阶段的感觉，用一句话来形容就是：由最开始的感受高山仰止、举步维艰，到如今的“神马都是浮云”，困难都是暂时的，等你越过去(把它踩在脚下)，你也就感受那算不上什么。

 　　如今只想谈下，有待优化和比较棘手的地方——  

　　1.目前的订单系统跟支付系统的相互依赖程度比较高，以致于订单的各个阶段的操做，如：付款，买家确认收货...，都须要调用支付系统的服务，以保证两边数据的同步。  

　　2.因为支付系统是基于第三方支付平台相关服务方法的封装，即支付系统对“现金”进出操做只至关因而个通道，没法控制和保证每一个操做的成功。  

　　3.基于以上两点，订单系统与之交互的操做就比较被动，让人感受很不舒服，增大了程序的复杂度。  

　　4.订单和退款超时数据的处理，目前没有使用定时器或数据库job，暂时用几个触发点来代替，这样从服务到UI都增长了相应的代码处理。

 　  怎样让订单系统和支付系统尽量的'解耦'，这将是下一个版本须要重点解决的问题!  

　　就写到这吧，但愿有这方面经验的朋友，能提些建议。