楼上的几位想简单了。火车票比较特殊的地方就是:票是可变的。例如:火车从上海出发,途经南京终点武汉(为了简单,中间只经过一个停靠点南京),那么,对某个具体的座位来说,票有三种:上海-南京、上海-武汉、南京-武汉。 票:上海-武汉与上海-南京、南京-武汉不能同时出售。抽奖、秒杀等都是独立的,而票是要交叉锁定的。 可以将票放在分布式缓存中(例如redis)处理。
火车票(某日、某班次、从哪站上到哪站下)是唯一的,是单独库存的。这就好像4s店里卖汽车一样,每一台汽车都有一个单品编号。而不像商店卖袜子一样都用同一个编号。 了解这个机制,那么其它的就非常好办了。多线程、多进程机制下,充其量,只需要在保证在你从一个库存将商品转移到另一个库存时不要幻想读,这一瞬间能够加锁,就够了。剩下的所有环节都不会错,因为剩下的环节都是针对单品编号进行处理的。 逻辑上看看这个机制能不能保证,就知道你的业务逻辑有没有把概念搞错。那么剩下其它做法通常就是一些比较低级的所谓“优化”了。比如说使用内存数据库来缓存当前放出来的火车票数据,这只是简单地存储问题。 纠结到什么“线程池、异步、同步、集群、分布式、java”等等概念,都是技术问题。纠结技术问题时,最好先不要过多考虑业务问题。同样地,当你针对业务逻辑进行设计时,不要在基本技术概念还糊涂时就去过早地考虑,否则你难以看懂分布式、异步并发下的逻辑设计。
火车票和电商网站的并发处理上不太一样,和现在的秒杀有很大区别,火车票的随机性很强 他的瓶颈在于数据库乐观说的瓶颈 火车票业务的复杂特性,决定了不能用电商秒杀的技术解决方案,还要听听其他人有啥好的看法
25,980
社区成员
4,366
社区内容
加载中
试试用AI创作助手写篇文章吧