关于售票系统的疑问?
举个例子,就那火车站的售票系统,有10个售票窗口:
如果同一时间,在10个售票窗口有10个人,他们要买去同一个地方的票,也就是同意班次的票,他们都问有没有票?;
但是,现在库存数量是只有1张。
问题是:这是个窗口的售票员都能看到这一张票呢,还是只有其中一名售票员能看到这张票。
如果所有的售票员都能看到还有一张票,然后告诉给窗口乘客有,但是能出10张票吗?
如果只有一个售票员能看到还有一张票,那他告诉窗口乘客说有一张,其他人都被告知没有了,走人了,但是这个知道有票的乘客由于某种原由没有买这张票。那岂不是害的其他窗口的那些乘客没有机会买这张票呢?
这种问题从技术上、实际操作,是如何解决的。这个系统会是如何设计的呢?
------解决方案--------------------所有售票员看到这一张票告诉乘客还有一张票,谁先买就谁的
------解决方案--------------------都可以看到。
但是预订的时候最先定的加锁,其他预订失败,transaction.
------解决方案--------------------这是个业务问题,而非技术问题,根据对动车的售票了解,极可能是:
所有所有售票员看到这一张票,谁先出票就是谁。
出票不等于买票,出票是指打印出来了。买票是个付款拿票的过程。
------解决方案--------------------实际操作就是:预订要给钱,不要也行。
对于10个人都能看到只有1张票的问题,可以用查询锁定来解决。
比如剩余2张票,我就允许1号窗口,和2号窗口查询。 而后面几个窗口查询的时候:不是报查询无票,而是说查询等待中。 那1号不买了,3号查询就返回说有票。 然后2号买走了票,3号又买走了票。
4,5,6,7,8,9,10 返回说没票了。
但是觉得这样做意义不大。
------解决方案--------------------先买先得不是么,加个锁就解决了。第一个买票的把这张票锁住就不会出问题了。
如果你还不放心,可以在更新数据库之前再做一个检测就可以了。
------解决方案--------------------典型的资源抢夺问题
------解决方案--------------------
------解决方案--------------------资源抢夺,先到行得。可以同时都能看到有一张。如果有一个人选择购买就锁定票,其他人不能做购买操作,如果过一段时间没有购买,可以释放资源,其他人可以购买
------解决方案--------------------用synchronozid声明同步,if()条件充当红绿灯,问的时候谁都可以问,谁都可以看见,一旦有人预定了,红灯开启,资源除了第一个访问的线程任何线程无法干预了。
------解决方案--------------------线程锁定。
------解决方案--------------------
------解决方案--------------------
------解决方案--------------------考验思维。。。
------解决方案--------------------避免幻读呗,在买之前先加了锁,数据更新到最后再解锁,这样售票员看到的数据就是统一的,而不是全部看到的都是买前10张票,而出票就出不来的情况
------解决方案--------------------个人认为,检索时就加锁了。因为没听过售票员告诉你有票,然后再打票时突然告诉你没票了。我是没遇到过,有谁遇到过吗?
------解决方案--------------------讨论相当激烈,挺有意思的
------解决方案--------------------应该是查询时就把票锁定了吧……
------解决方案--------------------加个锁定,然后一个事务就可以啦,成功的继续走流程,失败的回滚
------解决方案--------------------
------解决方案--------------------有售票员都能看到这张票,然后会告知10个窗口的所有人,但是只有一个人能买成功
我之前做过类似的就是这样的。