|
|
12306系统为啥难做,难做到什么地步
1、高并发。极其BT的并发量,我没有统计数据,但是想想全国上亿人同一个时间点鼠标,再加上各种抢票软件,一个软件顶上几十个人的压力应该是有的,要说查询并发能到上亿TPS我也不会太惊讶。但其实这一点并不是像马云说的那么关键。查询嘛,并发来了做负载均衡,把数据放进分布式内存缓存里,上亿的并发就是多加机器分担压力的事。阿里云做查询服务器是合适的,就跟铁道部不可能按春运规模配备火车一个道理,他也不愿意为春运这种规模的抢票配置同等规模的硬件,阿里云的好处就是忙的时候可以多买些机器用,闲的时候就不买那么多。
2、数据一致性。这个才是最要命的。读请求的分散永远是好做的,难的是写请求。其实12306的有效写请求肯定不如淘宝高,那难在哪儿呢?难的是供用户查询用的缓存数据与真实的余票数据之间的同步问题,余票数据一般而言肯定会放在物理数据库的磁盘上(或者闪存也也可能,反正是持久化),绝不可能只在内存缓存里放着,否则一掉电就啥都没了。那也就是说每卖出一张票都会修改余票数据,然后把最新的余票数据同步到各个内存缓存节点上以保证卖出去的票不会被后面的人查询到。问题来了,这个数据同步动作做的再快也要用时间的,一般情况下毫秒级是需要的,但是在每秒上亿的并发查询下会有大量的人还会查询到已经被卖出去的票,然后下单产生写请求,但是票已经被卖出去了,这个写请求注定是不成功的会返回失败,这些就是无效的写请求,无效的写请求会远远大于有效的写请求,很多时候可能会把有效的写请求堵在后面进不来,还会让数据库玩命的白忙,越忙数据同步可能就越慢,控制不好这就是一雪崩效应。这尼玛才是最难最难的啊。从这一点上我也怀疑查询放到阿里云上能起多大帮助,因为余票数据是核心数据,这些核心数据应该是不会放到阿里云上去的,只有供查询的缓存是在阿里云上的,那原来的局域网跨机器同步数据就变成了广域网跨系统同步数据,同步时延又被扩大了。当然这是我猜的,也许12306逼得把余票数据放到阿里云上了也不一定。
3、在上面两个的基础上再谈谈12306的业务复杂度。每个行当有每个行当的门道,站在门外总是觉得简单,进去了就会知道完全不是想象的那回事。我算是站在门口往里看了看,才知道真的不是这么容易。大家直觉上都觉得卖个火车票还不容易,一共就这么多张,谁抢到算谁的,卖完拉倒。但是真实情况是一列火车从北京到广州,中间停石家庄、郑州、武汉、长沙,卖出一张北京到广州的票,石家庄、郑州、武汉、长沙的票就要少一张,卖出去一张石家庄到郑州的票,北京到广州的、长沙的、武汉的、郑州的票都少了一张,北京到石家庄的没少。。。。其他车站自己去想。意味着什么呢,每卖出一张车票,系统就要重新计算一遍余票数据,计算时间还不能太长,几毫秒都嫌多了,计算完了还得同步到各个缓存节点,想想抢票高峰期每秒钟出多少张票,尼玛这得算死。12306是用国外X公司的内存缓存产品做网格并行计算解决这个问题的,阿里可能也有能力做,但至少他现在没有这方面的成功的经验(阿里不是做产品的)。上面讲的是普通的一般规则,其他不能摆在面上讲的规则就更费劲了,比如车站给各单位机关领导留票这基本上是半公开的了,所以你还得锁定不能卖,满足啥啥条件才能卖诸如此类,以我做行业应用的经验这里面BT的业务需求多了去,不脱个几层皮搞不出来。
|
|