挂断电话，颜浩也在琢磨：
这套系统和星纤网，牧云影票系统相比，在技术上来说最大的难点就是“库存扣减‘ 。
比如鹏城到汉口的车票。这在用户看来，只是一个a点到b点的车票，但是在系统当中的表述却是：鹏城-莞城-羊城-凤城-浈城-郴城-雁城……最后到达汉口。也就是a+b+c+d……+h 。也就是途经多少个站，就有多少个节点。
那么每卖出一张羊城到汉口的车票，那么鹏城-汉口的车票的sku也会要减少一张。这个sku是动态变化，相互影响的。
1个用户在查询车票时，系统给他传来的sku会受到其他其他用户的购票行为而产生变动的。
举个极端的例子，火车上就一个座位，车次是从 a -＞ b -＞ c。
如果卖出 b -＞ c 的车票，不去扣减 a-＞ c 库存的话，那么假设有两个用户分别买了 a-＞ c 和 b -＞ c 。那么当车行至站点b的时候，车上会有两个人，但是座位就一个。
所以不同车次之间的库存是会互相影响的。
a -＞ b -＞ c -＞ d 共 4 个车站，假如乘客买了 b -＞ c 的车票，那么同时会影响到 a-＞c，a-＞d，b-＞c，b-＞d。
这里不会影响 a -＞ b 的行程，因为乘客买的是 b -＞ c 的车票，站点 b 才上车，不占用 a -＞ b 行程的座位，我下车你上车，不冲突。
再加上用户取消订单或者支付失败导致票源返回票池这个变量。
这一套sku管理可比普通的电商那一套复杂了好几个层次。这也是让服务器需要处理的数据量成指数级上升的原因。
另外一个就是用户体验角度的问题。说简单点就是如何确保公平。
普通人很难跟那些有专业服务器不停刷票的大黄牛竞争。尤其是那些返回票池的余票。普通人抢到的概率微乎其微。
打击黄牛，既可以减少那些黄牛不断刷新查询请求给服务器带来的负担，也可以保证票务系统对普通用户公平。
针对以上两个问题。颜浩打算采用nosql服务