Home > Back-end >  Why 12306 so slow
Why 12306 so slow

Time:12-10

Is it the technical framework of use right?
Is the network hardware architecture problem?
Is high concurrency technical issues?

CodePudding user response:

Visits you now visit wouldn't slow

CodePudding user response:

Large is one of the traffic, and the algorithm is more complex, real-time data, how many cattle in the brush ticket software, etc

CodePudding user response:

Don't slow how to assure safety

CodePudding user response:

The
refer to the original poster weixin_41664930 response:
is its technical framework with wrong?
Is the network hardware architecture problem?
Is high concurrency technical issues?
why are you think there is something wrong with the 12306 technology? Because the peak rob performance issue tickets?
Any technology is inseparable from the needs of the business, so, to explain the performance problems, first is about business issues,

First, one might compare this thing and QQ or online, but I think the two are not the same, online games and QQ online, or login access is more of the user's own data, and the amount of is the center of the ticket reservation system to access data, this is not the same, don't feel like online games or QQ can do you think this is the same, online games and QQ back-end load relative to the electronic commerce system is simple,

其二,有人说春节期间订火车的这个事好像网站的秒杀活动,的确很相似,但是如果你的思考不在表面的话,你会发现这也有些不一样,火车票这个事,一方面会伴随着大量的查询操作,更BT的是下单的时候需要对数据库很多的一致性的操作,一方面是从起点到终点各个分段票的一致性,另一方面,买的人路线,车次,时间选择有很多,会不停地改变下单方式,而秒杀,直接杀就好了,没有那么多查询和一致性的问题,另外,关于秒杀,完全可以做成只接受前N个用户的请求(完全不操作后端的任何数据, 仅仅只是对用户的下单操作log),这种业务,只需要在内存cache中放好可秒杀的数量,还可以把数据分布开来放,100商品,10台服务器一台放10个,无需在当时操作任何数据库,可以订单数够后,停止秒杀,然后批量写数据库,而且秒杀的商品不多,火车票这个不是像秒杀那么简单的,春运时间,几乎所有的票都是热门票,而且几乎是全国人民都来了,而且还有转车业务,多条线的库存都要做事务操作,你想想吧,这有多难,(淘宝的双十一也就3百万用户,而火车票瞬时有千万级别甚至是亿级别的)(更新:2014年1月11日:来了淘宝后,对淘宝的系统有了解,淘宝的秒杀活动,本质上是用输验证码并在CDN上把用户直接过滤掉了,比如:1千万个用户过滤了只剩2万个用户,这样数据库就顶得住了)

Thirdly, some comparisons between the system and Olympic ticketing system, I think it's not the same, although the Olympic Games online ticketing system was also a waste, but the Olympic Games is a lottery, that is to say there is no first come, first serve rob way, moreover, is after the lottery, only need to collect information in advance, do not need to guarantee the data consistency, no lock, easily scale-out,

Fourthly, reservation system should and e-commerce order systems are similar, are the need for inventory: 1) engaged in stock, 2) pay (optional), 3) to deduct inventory operation, this is the need to have consistency check, also is the need to lock data when concurrent, B2C electrical contractor will basically to do the work as asynchronous, that is to say, your order is not handled immediately, but the delay treatment, only have successfully processed, system will give you a confirmation email orders successful, I believe that there are a lot of friends have received recognition is not successful email, that is, data consistency under the concurrent is a bottleneck,

Fifthly, railway ticketing business is very abnormal condition, its use is suddenly let tickets, and some tickets not enough points, so everyone will have robbed the practice of this kind of business with Chinese characteristics, so the pawn ticket out of time, there will be millions or even tens of millions of people killed, inquiry, order, a few minutes, a web site can receive tens of millions of visitors, this is a horrible thing, it is said that 12306 peak access is 1 billion PV, focused on 8 PM and 10 PM, PV at the peak of millions per second,

12306 actually have done a lot of optimization, the verification code from the front end animation, tickets to the period of time, to the back-end to minicomputer, virtualization, the use of an in-memory database, it can be said that the 12306 is the most powerful Chinese government agencies do website (electricity), if the 12306 open source code, estimate and you chew for a period of time enough

CodePudding user response:

Who don't let it have a API interface,
Every day there are a large number of reptiles, creep test

CodePudding user response:

reference 5 floor savage beast reply:
who don't let it have a API interface,
Every day there are a large number of reptiles, creep test ticket


Spoke these words, the API does not need to be calculated background seems like, before 12306, page display is a very simple thing, API throw the results with the page display is there a difference?

CodePudding user response:

refer to 6th floor also want to lazy enough to reply:
Quote: savage beast reference 5 floor response:
who don't let it have a API interface,
Every day there are a large number of reptiles, creep test ticket


Spoke these words, the API does not need to be calculated background seems like, before 12306, page display is a very simple thing, API throw the results with the page display is there a difference?


Don't have to have the API creeper crawled unnecessary resource, page data don't have to climb so many load so much,

You don't give the API crawler finish loading a page will have 100 k,

A API can have 100 k

CodePudding user response:

Every day there are a large number of reptiles, creep test

CodePudding user response:

Let them spend some money, please Mr. Ma's team to do it

CodePudding user response:

Safety security safety

CodePudding user response:

66666666

CodePudding user response:

https://blog.csdn.net/csdnnews/article/details/103942676
This article quite detailed

CodePudding user response:

In many cases, especially the slowest in the evening, the first is to users to access the truth too much, the second is to brush ticket software in access to,

CodePudding user response:

Traffic is too large, double tenth and 12306 is not a level

CodePudding user response:

7.17 12306 APP or website, endorsed to all problems. Only have more than one hour endorsed to succeed, want to refund also during the retreat
  • Related