1. 聚能聊>
  2. 话题详情

史上最难抢票年,聊聊春运背后的数据库设计难点与思考

20161124_02_pic_004

马上春节了,听说今年是史上最难抢票年,一票难求的问题依旧存在,身为程序猿的你有没有什么技术抢票的高招?

还记得10年前春节前买火车票得在放票前1天搬个小板凳去排队,对于热门路线,排一个晚上都有可能买不到票。

随着互联网的发展,几年前建设了12306网上购票系统,可以从电脑上买票,但是不要以为在电脑上就能买到票。

记得12306刚推出时,经常发生12306网站打不开,无法付款的问题。

为什么呢?

原因很简单,春节期间网上购票的人可能达到几亿的级别,而且放票日期是同一天同一个时间点,也就是说同一时刻12306要接受几亿用户的访问。

处理能力和实际的访问需求更不上,带来的结果就是网站打不开,系统不稳定的现象。

随着硬件的发展、技术的演进,12306的系统越来越趋于成熟,稳定性和响应速度也越来越好。

据说现在很多商家还开通了云抢票业务,本质上是让你不要冲击12306系统了,把需求提前收集,在放票时,这些系统会进行排队与合并购买,这种手段可以减少12306的访问并发。

抢火车票是很有意思的一个课题,对IT人的智商以及IT系统的健壮性,尤其是数据库的功能和性能都是一种挑战。

虽然很多人并不知道12306到底使用了什么技术,是如何设计的,但是并不能阻止IT人不断思考的内心。

我先帮大家揭开这神秘的技术一角 《12306的西天取经路 - 春节抢票与PostgreSQL数据库设计思考》

欢迎大家来讨论

* 回家的票你买到了么?关于春节抢票,程序猿们有什么技术高招?

* 12306背后的技术大家也来一起猜想一下,有哪些在云上的应用?

* 什么样的数据库设计,可以支撑几亿人肉DDOS的查询与售卖?

参与话题

奖品区域 活动规则 活动已结束,可继续参与讨论哦

  • 奖品一

    淘公仔 x 1

  • 奖品二

    定制笔记本 x 1

  • 奖品三

    程序员礼盒 x 2

152个回答

1

海童 已获得定制笔记本

如果12306架构设计的好,那么在高峰期(比如春节),可以通过水平扩展的方式租用服务器,空闲时期在归还,节省成本。 对于用户请求层面,通过增加机器,负载均衡是比较容易做到的。在数据库层面,当增加新机器时,可以自动将数据进行分片,降低每台机器的负载,提高响应速度。 当然,实际设计和编码起来还是有难度的。

神垕 回复

现在12306设计的应该有,这部分是靠公有云和私有云结合使用的

hzabyte 回复

动不动就提分片当万能药。能分片的12306肯定已经分了。问题是票量要归结,中途上车的要和中途下车的要对接,这个总数如何分片中实现同步?

云栖技术 回复

我感觉你的问题要被采纳。

ruanxiaojun 回复

集中与分布相结合方案: 设立一个中央数据库和若干个地区数据库,在地区数据库中存储本地区始发列车的座席数据。该方案综合了集中式和分布式两种方案的优点,避免了两者的缺点。既 便于异地购票、座席复用、信息共享,又相对减少了网络的开销;设备投资合理,升级更新容易;兼顾了技术先进和现实可能;既可适应体制改革,又能适应现状, 具有较大的弹性和适应能力。
中国铁路客票发售与预订系统由中央级、地区级和车站级三层结构组成,包括全国票务中心管理系统、地区票务中心管理系统和车站电子售票系统。系统采取集中与 分布相结合的方案,在全路票务中心内安装中央数据库,Sybase领先的数据库产品Adaptive Server Enterprise、Replication Server、Adaptive IQ,中间件产品Open Client、Open Server以及开发工具PowerBuilder和PowerDesigner在其中都有着非常重要的应用;这一系统主要用于计划与调度全系统的数据, 并接收下一系统的统计数据和财务结算数据。在地区票务中心设有地区数据库,Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner将全面支持这一数据库,它主要用于计划与调度本地区数据,并可响应异地购票请求。系 统的基础部分是由Sybase的Adaptive Server Enterprise、Replication Server、Open Client、Open Server、PowerBuilder、PowerDesigner构成的车站售票系统,它主要具有售票、预订、退票、异地售票、统计等多种功能。中国 铁路客票发售和预订系统实现了计算机联网售票,并且有出售返程、联程等异地购票的功能,实现了票额、座席、制票、计算、结算和统计等计算机管理,为铁路客 户服务提供了有效的调控手段,标志着中国铁路客户服务已走向现代化。

kungge 回复

你说的,12306肯定都有考虑,租用服务器应该是有的,毕竟现在云服务器提供商太多太多。因为票务系统是很复杂的,比单纯的淘宝买东西复杂多了,所以技术层面就某些数据分片负载均衡要看能否适用。

1561040684788441 回复
回复@hzabyte:

按车次分不就可以了。

评论
2

szm. 已获得程序员礼盒

提前30天放票当天就买到了,用了智行帮抢票,结果没加钱根本抢不到,倒是自己手动买的很容易买上。
做为买过好多次火车票的人,总结出几个经验:1. 每个车站放的票是有比例的,你搜的起点到终点没票,不代表这条线就没票了,可以试试起点向前几站,终点向后几站,说不定会有意外惊喜。2. 放票的一瞬间抢票失败率会很高,主要是抢票的人太多服务器压力大,导致出票错误率高,可以等几分钟,或者几十分钟,等峰值过去再抢。3. 迫不得已的话只能转乘,这个不用多说了。
其实得益于阿里的技术,抢票已经好多,由于火车票不像商品,被一个用户买了就没了,而是有可能一个位置被多个用户共用,并且要求同一张票只能属于一位乘客,因此复杂度很高,能达到当前的技术已经很不错了。
个人对于减轻服务器压力的几个想法:1 放票时间可以进行划分,而不是放在同一个时间点上,这样可以起到一定的分流作用。2 可以在出票时隐藏座位信息(一段时间后显示),减少乘客因为座位问题而多次退票。3 监测购票信息,发现大量囤票等行为进行干预。

kungge 回复

等个几分钟?就是等个十秒都全都没了,后面刷屏概率更低。

szm. 回复
回复@kungge:

可能是我回家的那段路人相对较少吧

szm. 回复
回复@kungge:

可能是我回家的那段路人相对较少吧

小邦 回复

并不能分流吧,但凡放了票,无论多少,都会一窝蜂上去抢。

评论
3

云栖技术 已获得淘公仔

业务
任何技术都离不开业务需求,所以,要说明性能问题,首先还是想先说说业务问题。

其一,有人可能把这个东西和QQ或是网游相比。但我觉得这两者是不一样的,网游和QQ在线或是登录时访问的更多的是用户自己的数据,而订票系统访问的是中心的票量数据,这是不一样的。不要觉得网游或是QQ能行你就以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
其二,有人说春节期间订火车的这个事好像网站的秒杀活动。的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样。火车票这个事,还有很多查询操作,查时间,查座位,查铺位,一个车次不 行,又查另一个车次,其伴随着大量的查询操作,下单的时候需要对数据库操作。而秒杀,直接杀就好了。另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需要在内存cache中放好可秒杀的数量,还可以把数据分布开来放,100商品,10台服务器一台放10个,无需在当时操作任何数据库。可以订单数够后,停止秒杀,然后批量写数据库。而且秒杀的商品不多。火车票这个不是像秒杀那么简单的,春运时间,几乎所有的票都是热门票,而且几乎是全国人民都来了。(淘宝的双十一也就3百万用户,而火车票瞬时有千万级别甚至是亿级别的)
其三,有人拿这个系统和奥运会的票务系统比较。我觉得还是不一样。虽然奥运会的票务系统当年也一上线就废了。但是奥运会用的是抽奖的方式,也就是说不存在先来先得的抢的方式,而且,是事后抽奖,事前只需要收信息,事前不需要保证数据一致性,没有锁,很容易水平扩展。
其四,订票系统应该和电子商务的订单系统很相似,都是需要对库存进行:1)占住库存,2)支付(可选),3)扣除库存的操作。这个是需要有一致性的检查的,也就是在并发时需要对数据加锁的。B2C的电商基本上都会把这个事干成异步的,也就是说,你下的订单并不是马上处理的,而是延时处理的,只有成功处理了,系统才会给你一封确认邮件说是订单成功。我相信有很多朋友都收到认单不成功的邮件。这就是说,数据一致性在并发下是一个瓶颈。
其五,铁路的票务业务很变态,其采用的是突然放票,而有的票又远远不够大家分,所以,大家才会有抢票这种有中国特色的业务的做法。于是当票放出来的时候,就会有几百万人甚至上千万人杀上去,查询,下单。几十分钟内,一个网站能接受几千万的访问量,这个是很恐怖的事情。据说12306的高峰访问是10亿PV,集中在早8点到10点,每秒PV在高峰时上千万。
多说几句:

库存是B2C的恶梦,库存管理相当的复杂。不信,你可以问问所有传统和电务零售业的企业,看看他们管理库存是多么难的一件事。不然,就不会有那么多人在问凡客的库存问题了。(你还可以看看《乔布斯传》,你就知道为什么Tim会接任Apple的CEO了,最主要的原因是他搞定了苹果的库存周期问题)
对于一个网站来说,浏览网页的高负载很容易搞定,查询的负载有一定的难度去处理,不过还是可以通过缓存查询结果来搞定,最难的就是下单的负载。因为要访问库存啊,对于下单,基本上是用异步来搞定的。去年双11节,淘宝的每小时的订单数大约在60万左右,京东一天也才能支持40万(居然比12306还差),亚马逊5年前一小时可支持70万订单量。可见,下订单的操作并没有我们相像的那么性能高。
淘宝要比B2C的网站要简单得多,因为没有仓库,所以,不存在像B2C这样有N个仓库对同一商品库存更新和查询的操作。下单的时候,B2C的 网站要去找一个仓库,又要离用户近,又要有库存,这需要很多计算。试想,你在北京买了一本书,北京的仓库没货了,就要从周边的仓库调,那就要去看看沈阳或 是西安的仓库有没有货,如果没有,又得看看江苏的仓库,等等。淘宝的就没有那么多事了,每个商户有自己的库存,库存就是一个数字,并且库存分到商户头上了,反而有利于性能扩展。
数据一致性才是真正的性能瓶颈。有 人说nginx可以搞定每秒10万的静态请求,我不怀疑。但这只是静态请求,理论值,只要带宽、I/O够强,服务器计算能力够,并支持的并发连接数顶得住10万TCP链接的建立 的话,那没有问题。但在数据一致性面前,这10万就完完全全成了一个可望不可及的理论值了。
我说那么多,我只是想从业务上告诉大家,我们需要从业务上真正了解春运铁路订票这样业务的变态之处。

前端性能优化技术
要解决性能的问题,有很多种常用的方法,我在下面列举一下,我相信12306这个网站使用下面的这些技术会让其性能有质的飞跃。

一、前端负载均衡
通过DNS的负载均衡器(一般在路由器上根据路由的负载重定向)可以把用户的访问均匀地分散在多个Web服务器上。这样可以减少Web服务器的请求负载。因为http的请求都是短作业,所以,可以通过很简单的负载均衡器来完成这一功能。最好是有CDN网络让用户连接与其最近的服务器(CDN通常伴随着分布式存储)。(关于负载均衡更为详细的说明见“后端的负载均衡”)

二、减少前端链接数
我看了一下http://12306.cn,打开主页需要建60多个HTTP连接,车票预订页面则有70多个HTTP请求,现在的浏览器都是并发请求的(当然,浏览器的一个页面的并发数是有限的,但是你挡不住用户开多个页面,而且,后端服务器TCP链接在前端断开始,还不会马上释放或重要)。所以,只要有100万个用户,就有可能会有6000万个链接(访问第一次后有了浏览器端的cache,这个数会下来,就算只有20%也是百万级的链接数),太多了。一个登录查询页面就好了。把js打成一个文件,把css也打成一个文件,把图标也打成一个文件,用css分块展示。把链接数减到最低。

三、减少网页大小增加带宽
这个世界不是哪个公司都敢做图片服务的,因为图片太耗带宽了。现在宽带时代很难有人能体会到当拨号时代做个图页都不敢用图片的情形(现在在手机端浏览也是这个情形)。我查看了一下12306首页的需要下载的总文件大小大约在900KB左右,如果你访问过了,浏览器会帮你缓存很多,只需下载10K左右的文件。但是我们可以想像一个极端一点的案例,1百万用户同时访问,且都是第一次访问,每人下载量需要1M,如果需要在120秒内返回,那么就需要,1M * 1M /120 * 8 = 66Gbps的带宽。很惊人吧。所以,我估计在当天,12306的阻塞基本上应该是网络带宽,所以,你可能看到的是没有响应。后面随着浏览器的缓存帮助12306减少很多带宽占用,于是负载一下就到了后端,后端的数据处理瓶颈一下就出来。于是你会看到很多http 500之类的错误。这说明后端服务器垮了。

四、前端页面静态化
静态化一些不常变的页面和数据,并gzip一下。还有一个变态的方法是把这些静态页面放在/dev/shm下,这个目录就是内存,直接从内存中把文件读出来返回,这样可以减少昂贵的磁盘I/O。使用nginx的sendfile功能可以让这些静态文件直接在内核心态交换,可以极大增加性能。

五、优化查询
很多人查询都是在查一样的,完全可以用反向代理合并这些并发的相同的查询。这样的技术主要用查询结果缓存来实现,第一次查询走数据库获得数据,并把数据放到缓存,后面的查询统统直接访问高速缓存。为每个查询做Hash,使用NoSQL的技术可以完成这个优化。(这个技术也可以用做静态页面)

对于火车票量的查询,个人觉得不要显示数字,就显示一个“有”或“无”就好了,这样可以大大简化系统复杂度,并提升性能。把查询对数据库的负载分出去,从而让数据库可以更好地为下单的人服务。

六、缓存的问题
缓存可以用来缓存动态页面,也可以用来缓存查询的数据。缓存通常有那么几个问题:

1)缓存的更新。也叫缓存和数据库的同步。有这么几种方法,一是缓存time out,让缓存失效,重查,二是,由后端通知更新,一量后端发生变化,通知前端更新。前者实现起来比较简单,但实时性不高,后者实现起来比较复杂 ,但实时性高。

2)缓存的换页。内存可能不够,所以,需要把一些不活跃的数据换出内存,这个和操作系统的内存换页和交换内存很相似。FIFO、LRU、LFU都是比较经典的换页算法。相关内容参看Wikipeida的缓存算法。

3)缓存的重建和持久化。缓存在内存,系统总要维护,所以,缓存就会丢失,如果缓存没了,就需要重建,如果数据量很大,缓存重建的过程会很慢,这会影响生产环境,所以,缓存的持久化也是需要考虑的。

诸多强大的NoSQL都很好支持了上述三大缓存的问题。

后端性能优化技术
前面讨论了前端性能的优化技术,于是前端可能就不是瓶颈问题了。那么性能问题就会到后端数据上来了。下面说几个后端常见的性能优化技术。

一、数据冗余
关于数据冗余,也就是说,把我们的数据库的数据冗余处理,也就是减少表连接这样的开销比较大的操作,但这样会牺牲数据的一致性。风险比较大。很多人把NoSQL用做数据,快是快了,因为数据冗余了,但这对数据一致性有大的风险。这需要根据不同的业务进行分析和处理。(注意:用关系型数据库很容易移植到NoSQL上,但是反过来从NoSQL到关系型就难了)

二、数据镜像
几乎所有主流的数据库都支持镜像,也就是replication。数据库的镜像带来的好处就是可以做负载均衡。把一台数据库的负载均分到多台上,同时又保证了数据一致性(Oracle的SCN)。最重要的是,这样还可以有高可用性,一台废了,还有另一台在服务。

数据镜像的数据一致性可能是个复杂的问题,所以我们要在单条数据上进行数据分区,也就是说,把一个畅销商品的库存均分到不同的服务器上,如,一个畅销商品有1万的库存,我们可以设置10台服务器,每台服务器上有1000个库存,这就好像B2C的仓库一样。

三、数据分区
数据镜像不能解决的一个问题就是数据表里的记录太多,导致数据库操作太慢。所以,把数据分区。数据分区有很多种做法,一般来说有下面这几种:

1)把数据把某种逻辑来分类。比如火车票的订票系统可以按各铁路局来分,可按各种车型分,可以按始发站分,可以按目的地分……,反正就是把一张表拆成多张有一样的字段但是不同种类的表,这样,这些表就可以存在不同的机器上以达到分担负载的目的。

2)把数据按字段分,也就是竖着分表。比如把一些不经常改的数据放在一个表里,经常改的数据放在另外多个表里。把一张表变成1对1的关系,这样,你可以减少表的字段个数,同样可以提升一定的性能。另外,字段多会造成一条记录的存储会被放到不同的页表里,这对于读写性能都有问题。但这样一来会有很多复杂的控制。

3)平均分表。因为第一种方法是并不一定平均分均,可能某个种类的数据还是很多。所以,也有采用平均分配的方式,通过主键ID的范围来分表。

4)同一数据分区。这个在上面数据镜像提过。也就是把同一商品的库存值分到不同的服务器上,比如有10000个库存,可以分到10台服务器上,一台上有1000个库存。然后负载均衡。

这三种分区都有好有坏。最常用的还是第一种。数据一旦分区,你就需要有一个或是多个调度来让你的前端程序知道去哪里找数据。把火车票的数据分区,并放在各个省市,会对12306这个系统有非常有意义的质的性能的提高。

四、后端系统负载均衡
前面说了数据分区,数据分区可以在一定程度上减轻负载,但是无法减轻热销商品的负载,对于火车票来说,可以认为是大城市的某些主干线上的车票。这就需要使用数据镜像来减轻负载。使用数据镜像,你必然要使用负载均衡,在后端,我们可能很难使用像路由器上的负载均衡器,因为那是均衡流量的,因为流量并不代表服务器的繁忙程度。因此,我们需要一个任务分配系统,其还能监控各个服务器的负载情况。

任务分配服务器有一些难点:

负载情况比较复杂。什么叫忙?是CPU高?还是磁盘I/O高?还是内存使用高?还是并发高?还是内存换页率高?你可能需要全部都要考虑。这些信息要发送给那个任务分配器上,由任务分配器挑选一台负载最轻的服务器来处理。
任务分配服务器上需要对任务队列,不能丢任务啊,所以还需要持久化。并且可以以批量的方式把任务分配给计算服务器。
任务分配服务器死了怎么办?这里需要一些如Live-Standby或是failover等高可用性的技术。我们还需要注意那些持久化了的任务的队列如何转移到别的服务器上的问题。
我看到有很多系统都用静态的方式来分配,有的用hash,有的就简单地轮流分析。这些都不够好,一个是不能完美地负载均衡,另一个静态的方法的致命缺陷是,如果有一台计算服务器死机了,或是我们需要加入新的服务器,对于我们的分配器来说,都需要知道的。另外,还要重算哈希(一致性hash可以部分解决这个问题)。

还有一种方法是使用抢占式的方式进行负载均衡,由下游的计算服务器去任务服务器上拿任务。让这些计算服务器自己决定自己是否要任务。这样的好处是可以简化系统的复杂度,而且还可以任意实时地减少或增加计算服务器。但是唯一不好的就是,如果有一些任务只能在某种服务器上处理,这可能会引入一些复杂度。不过总体来说,这种方法可能是比较好的负载均衡。

五、异步、 throttle 和 批量处理
异步、throttle(节流阀) 和批量处理都需要对并发请求数做队列处理的。

异步在业务上一般来说就是收集请求,然后延时处理。在技术上就是可以把各个处理程序做成并行的,也就可以水平扩展了。但是异步的技术问题大概有这些,a)被调用方的结果返回,会涉及进程线程间通信的问题。b)如果程序需要回滚,回滚会有点复杂。c)异步通常都会伴随多线程多进程,并发的控制也相对麻烦一些。d)很多异步系统都用消息机制,消息的丢失和乱序也会是比较复杂的问题。
throttle 技术其实并不提升性能,这个技术主要是防止系统被超过自己不能处理的流量给搞垮了,这其实是个保护机制。使用throttle技术一般来说是对于一些自己无法控制的系统,比如,和你网站对接的银行系统。
批量处理的技术,是把一堆基本相同的请求批量处理。比如,大家同时购买同一个商品,没有必要你买一个我就写一次数据库,完全可以收集到一定数量的请求,一次操作。这个技术可以用作很多方面。比如节省网络带宽,我们都知道网络上的MTU(最大传输单元),以态网是1500字节,光纤可以达到4000多个字节,如果你的一个网络包没有放满这个MTU,那就是在浪费网络带宽,因为网卡的驱动程序只有一块一块地读效率才会高。因此,网络发包时,我们需要收集到足够多的信息后再做网络I/O,这也是一种批量处理的方式。批量处理的敌人是流量低,所以,批量处理的系统一般都会设置上两个阀值,一个是作业量,另一个是timeout,只要有一个条件满足,就会开始提交处理。
所以,只要是异步,一般都会有throttle机制,一般都会有队列来排队,有队列,就会有持久化,而系统一般都会使用批量的方式来处理。

2

云栖技术

票已经抢到了,得益于飞猪,抢票很给力啊,飞猪也是使用的阿里云的服务器。阿里云的服务器已经帮我们考虑好了一切问题,重中之中使用了PGSQL,很多地方得到了优化,抢票成功率更是十拿九稳。一句话,阿里云已经帮我们做好了,不用我们操心了。

ekwz001 回复

这位兄台,你飞猪抢票成功,加钱了么?

davidfan1986 回复

我用飞猪付费都没抢到。。。。

andr0id 回复

确定不是广告贴?

hzabyte 回复

这t么的和黄牛有啥区别?

云栖技术 回复

郑重申明一下,我用飞猪没有使用花钱抢购的。一共花了2天时间,

燚蠡 回复

一样用飞猪,付费30VIP都没抢到。

云栖技术 回复

这个 嘛,。也有运气成分

merliin 回复

飞猪不是给赶火车网的订单??你确定是阿里自己用服务器给你抢的????

评论
1

mr.蜜 已获得程序员礼盒

从提前一个时间段购买火车票,这本身就是会引起高并发,何况回家过年这种年度潮汐式迁移,每年都有,为什么要让买火车票变成抢票呢?分布式数据库固然好用,读写分开也能从一定角度缓解高并发,单这种几亿的高并发量所需要的设备量,在平时就变得极其浪费资源。由于回家过年的人需求很简单,“我只想买到回去的车票”,至于买的是哪个座位,那个班次,并不是特别在意,那么为何不实用预约等机制来消耗掉这种高并发呢?让高并发的可能只存在于零时出行,那么是不是可以解决一些问题呢?

2

ljm52013

现在总体很稳定,至于抢不到票,这跟系统本身没有关系,t和运力有关系。因为票源是有限的

德哥 回复

总体已经越来越稳定了

云栖技术 回复

我们利用技术可以吧紧缺的票源,紧紧抓住。

评论
0

黄赞赞

没抢过,现在人脸识别技术挺成熟的,可不可以考略下人脸识别技术呢?

一人只能买一张票,干掉什么牛党。
但这只适合手机抢票。

聚小编 回复

刷脸抢票这个点子不错呢~

wuxiangege 回复

双胞胎,怎么办?

ichina 回复

双胞胎长的不太一样的。系统可以识别。哈哈

云栖技术 回复

那要是替别人买票么。存在很多局限性,随着科技日益进步,总有一天会实现的

ruanxiaojun 回复

根源是运力不足,跟什么技术没有多大关系,最后拼的是服务器和网速。如果票源充足,就不会出现抢票;

评论
1

风水师

说到买票,就是一个供求关系的失衡。买票人多票少。再好的网站也解决不了这个问题。只有说分散经济中心,让人口吸引在自己家庭附近,买票需求少了。怎么也不会出现买票难的这个问题。

德哥 回复

好提议,大型城市失去中心地位,也会阵痛的,要靠特色来留人了。

云栖技术 回复

这现在的社会,是一个人吃人的社会,人民素质得不到提高,无法达到发达国家的水准,还需要时间

zoup 回复

分散经济中心是不可能的,不管是从前,还是现在,年轻人和劳动力都是往大城市跑,机会更多,工资更高。不管是中国,还是美国、日本、英国,都是这样。

评论
0

anpho

买不到票的一个原因,是系统里面的预留票。比如济南到潍坊没票,但是济南到青岛却可能有几百张票。

天真丶无邪 回复

深有同感,北京到淄博的没有票,同一个车,北京到青岛就有好多

杜龙少 回复

青岛始发有很多票,而下一站高密就没票

hzabyte 回复

优先保证起点到终点的。。。这也是因为铁道部门复杂的业务逻辑引起的买票难度。

云栖技术 回复

策略不同,铁道部也是要赚钱。预留长途票。就好比程序的权限一样,哈哈。我大中国,泱泱大国,过年国家过年,安内都成大问题,如何攘外呢,应赶紧整治,贪污腐败,社会风气,求一个稳定发展。

狼窝炮神 回复
回复@hzabyte:

这倒不一定,我从洛阳(始发站)到福州(终点站)的火车第二站是郑州,买洛阳到福州没有,买郑州到福州一大堆。

评论
1

xxmocco

票已到手,还是官网靠谱

andr0id 回复

是啊,第三方付费刷的都没刷到,来回的票都是在官网顺利抢到的

jo-obj 回复

第三方Bug不比12306少

评论
0

1999483631685740

高速如此发达,为什么还是一票难求。

德哥 回复

春运高速也堵d

zoup 回复

因为一直都是一票难求,只不过互联网的存在,加速信息的流通,一票难求的问题被放大了看,自然是难以解决的。而且如果在春运这种时候都能满足运力要求的话,那铁总必然亏本,因为平常维持铁路运营的成本很高。

评论
2

神垕

能不能把第二天要出售的票,前一天晚上数据同步到缓存中,然后第二天从缓存中查询数据。

聚小编 回复

缓存风险是不是比较大

评论
1

一个人的!

看了阿里云一位工程师短视频,大概了解一点。用了一个伏羲的架构解决了这个难题。

聚小编 回复

亲一定是看过技术峰会的直播的,赞

阿灿君 回复

66

评论
3

ewingz

改变业务架构是根本,尽量推出提前预定或者集体抢购的方法。瞬间几十亿并发读写可能是目前任何硬盘数据库集群系统都无法搞定的。还有一个思路就是每天交易的售票数据使用内存存储,夜间再导入硬盘存储。这么干数据危险性大

0

51干警网

貌似抢票不难吧。春节探亲往返票已经入手。
QQ_20170105113216

聚小编 回复

赤裸裸的炫耀啊

可可口口 回复

23块钱的票,目测最多200公里吧

神垕 回复

同在郑州!

51干警网 回复

老司机。对的~

51干警网 回复
回复@神垕:

我说禹州的,搞不搞?

51干警网 回复

来啊,放纵吧。

评论
-1

1694970641463023

我买的域名无缘无故全没了,阿里云发个邮件截图如下,按照他说的去操作,一下全没了,阿里云官网客服电话还永远打不通,没人接,全是机器人。。。气死我啦
online/75e70e6eb5074ca5933875561d1fdb9d_b63344588aee4b1686925ac4e8f78985.jpg

聚小编 回复

亲,你反馈的账号中没有域名的购买记录,此账号下的手机号也一直无法打通,我们的客服MM无法联系到你。建议你用购买域名的账号提交工单反馈此问题,或是留下可以联系到你的手机号。

评论
0

wang8231690

多弄几班车,比啥都好使 ……

小北56 回复

哈喽kity 回复

车太多,管控不过来!

评论
0

undifined

一票难求的根本原因是铁路局运力问题,应该缩小各地区发展差异……

德哥 回复

好提议啊,现在流动人口太集中了,要加快城镇化发展

评论
2

hacker-dba

票资源有限,你就算数据库提交成功再快也是一千个人抢100张饼,买不到票的依旧买不到

2

1985147208754918

其实就是人肉DDoS啊^

8
24879
浏览
0
收藏
邀请他人互动
关注
61
粉丝
3188
话题
14

简介:

公益是一辈子的事, I'm digoal, just do it.
PostgreSQL被业界誉为“最先进的开源数据库”,面向企业复杂SQL处理的OLTP在线事务处理场景,支持No...

在云上签发Symantec、WoSign、CFCA证书,实现网站HTTPS化,使网站可信,防劫持、防篡改、防监听...

支持以数据库为核心的结构化存储产品之间的数据传输。 它是一种集数据迁移、数据订阅及数据实时同步于一体的数据传输服...

为您提供简单高效、处理能力可弹性伸缩的计算服务,帮助您快速构建更稳定、安全的应用,提升运维效率,降低 IT 成本...