致还在喷12306的同行

标签: 数据库应用 硬件相关 业界话题 系统架构 | 发表时间:2014-01-14 07:39 | 作者:Litrin
出处:http://www.litrin.net

眼看着要过年了,又到了一家人排队买过车票的时间了。今年的排队不同于以往,这次大家都集中到了12306上面排队了。

要说前些年排队,只要你能吃苦,肯熬夜,总能买到票。可今年这个优势俨然成了会不会用网路、网速、手速的大比拼。加上天天500的网站,大量的人狂喷12306。大致上理由如下(由深至浅):

  1. 无法访问
  2. 各种各样的漏洞:退票、延期付账漏洞、身份证/姓名伪造漏洞等。
  3. 前端简陋

现在的网络,没有什么可以吐槽的状态才是值得吐槽的,本无可厚非。大家发发牢骚,发泄一下买不到票的情绪没什么问题。可有人自称自己只要数周时间就可以简单的重构12306,修补种种问题。我只能在这里“呵呵”。

先说最让人无法接受的500无法访问问题。之前作为一个 并发量问题的讨论,那时我已经说过150/s的并发,现在我觉得这个数字保守的不可救药了。150只是针对传统的电商来说的,现在的状态是每天90%以上甚至98%以上的访问集中在每天放票的半小时以内——这已经超出了13年“双十一”的峰值水平了!况且TB的购物方式仅仅是货号对唯一ID*数量=价格的简单购物系统。考虑过火车票吗?

A车站:A->B 2张,A->C 2张;B车站:B->A 1张,B->C 3张;C车站:C->A 0张,C->B1张;从A到B必经C。都是个位数一只手都不到,谁能一下子算出一共有多少张票?提示:要考虑到排列组合,只是简单加加的人直接去面壁吧!任何一张票的售出都回直接影响到整个系统中的存票量。这个模型只是在一个最简单不过的状态下的情况,想知道全国有多少火车站吗?每辆列车有多少座位吗?用户有多少种乘车/换乘可能吗?出票的系统从来不是一个“产供销”系统,更加接近于一个“路由系统”。况且每出一张票的同时都需要对几乎所有沿线的车站票务状态都要重新更新的过程。以上种种的纬度再加上时效性,有更好的数据结构和索引算法的话我愿倾听。

如果这个时候你说:只要一台强有力的机器就可以了。好吧,我只能说,你根本不了解什么叫做“原子操作”。你必须保证在同一时间全局只能由唯一一张的车票被售出,就必须在每次操作的同时对全局上锁。短期内强力的机器却是可以提升部分性能,但趋向是“无限接近于0”的双曲线。实现中,为了实现故障转移和负载均衡,这样的场景往往是多台机器铺路,但机器越多,实现原子操作的成本和难度就越大,而且同样是“趋向于正无穷”的抛物线。如果我得到的信息没错的话,当下12306用的是FireGem,中心节点17台Linux,8路Xeon E7,,1T RAM。没错,顶配的X86。

年终的时候曾经有消息称TB介入了12306的开发,甚至大家都对12306有了一点小激动。可事实上没有太大的改观——TB只是参与了12306的队列系统而已。换句话说TB可能都没有touch到核心业务。可能有人会认为有什么幕后交易阻碍了TB。事实上TB现在敢于搞个“双十一”什么的,完全是站在了自己有了10年以上的技术积累之上的,甚至为了技术上的实现重新设计过商业流程。贸然介入一个自己连自己的业务流程,甚至于管理流程都不太了解的项目中,肯定不会有太大的起色。队列系统相对简单,相信TB一开始就觉得“自己现成的解决方案,没有太多的耦合性,也相当容易有起色,绝对是油水活!”

流程上的问题,先是可以用假身份证买票。好吧,如果每个身份证都去到公安系统验证一下的话,第一订票时间至少延长一倍;第二公安身份证系统也会搞垮,这是更加让人不能接受的情况。

退票和延期付账的漏洞。关于退票漏洞,我觉得这是一个被滥用的功能。只能说退票的手续费太低,以至于还不够填补黄牛的加价费。延期付账的漏洞,其实任何一家电商都有类似的设定,只不过电商没有这么强的时效性而已。

说到前端的问题,其实我并不觉得这个有太大的槽点。UI就是一个UI,你可以说它丑,但考虑到很多用户——可能都到了爷爷辈——根本无法接受太多的图片/色彩/动态的堆嵌。大量的文字描述+简单表格反而更有可行性。就好比说每个人回家都不会看着门牌号一家一户地找,但你不能说为此门牌号就没有存在的价值。只是能在网上吐槽UI的人本身已经占据了信息高地而已。

归根结底,作为一个票务系统,我敢说在全世界范围内不会再有哪个系统敢说能出其右。买不到票的原因不见得是因为12306烂,而是根本上车票的稀缺性。如果你自诩为有过硬的技术,充沛的带宽,一系列的工具尚买不到票而牢骚满腹牢骚,我只能说,比你牛的人早就满大街了。如果不了解IT的人吐槽我一笑了之,如果哪位同行还有不懈我只能说:You can you up!

相关 [数据库应用 硬件相关 业界话题 系统架构 ] 推荐:

Redis的主从复制

- - 开源小站
作为MySQL对于Web应用的优化之一,主从复制(Master-slaver)是普遍被接受的,Redis作为当下一个no-sql的解决方案,很自然的将这个特性引入. 同时将“操作便捷”作为一大目标,Redis的主从复制更为简单,甚至不需要额外的操作,完全可以在两台热机之间进行. 首先,准备2套Redis主机,本例192.168.0.1为主,192.168.0.2为从.

从Redis的数据丢失说起

- - 开源小站
碰到一个悲催的事情:一台Redis服务器,4核,16G内存且没有任何硬件上的问题. 持续高压运行了大约3个月,保存了大约14G的数据,设置了比较完备的Save参数. 而就是这台主机,在一次重起之后,丢失了大量的数据,14G的数据最终只恢复了几百兆而已. 正常情况下,像Redis这样定期回写磁盘的内存数据库,丢失几个数据也是在情理之中,可超过80%数据丢失率实在太离谱.

MongoDB Shareding部署

- - 开源小站
几年前写过 MongoDB的Sharding和replication. 其实现在看起来Replication还是可以,Sharding的部分有点过于简单了. 于是现在重新补充一下,至少也更新下,毕竟现在的MongoDB已经到了2.6,于当时的2.2还是有所差异的. 正常的情况下,应该是有6台主机实现一个比较像样的MongoDB Sharding集群,它们分别是mongos /router1台,config 3台,shard 2台.

致还在喷12306的同行

- - 开源小站
眼看着要过年了,又到了一家人排队买过车票的时间了. 今年的排队不同于以往,这次大家都集中到了12306上面排队了. 要说前些年排队,只要你能吃苦,肯熬夜,总能买到票. 可今年这个优势俨然成了会不会用网路、网速、手速的大比拼. 加上天天500的网站,大量的人狂喷12306. 各种各样的漏洞:退票、延期付账漏洞、身份证/姓名伪造漏洞等.

HBase 系统架构

- - 博客园_首页
HBase是Apache Hadoop的数据库,能够对大型数据提供随机、实时的读写访问. HBase的目标是存储并处理大型的数据. HBase是一个开源的,分布式的,多版本的,面向列的存储模型. 5 可在廉价PC Server搭建大规模结构化存储集群. HBase是Google BigTable的开源实现,其相互对应如下:.

Facebook 的系统架构

- Ivan - 博客园新闻频道
  来源:http://www.quora.com/What-is-Facebooks-architecture (由Micha?l Figuière回答).   根据我现有的阅读和谈话,我所理解的今天Facebook的架构如下:. Web 前端是由 PHP 写的. Facebook 的 HipHop [1] 会把PHP转成 C++并用 g++编译,这样就可以为模板和Web逻贺业务层提供高的性能.

Digg.com 的系统架构

- - 标点符
在过去的几年间,我们一直致力于重构Digg的架构,现在我们称之为“Digg V4”.本文我们将全面介绍Digg的使用的系统和技术. 首先,我们来看下Digg给大众用户提供的服务吧:. 人们通过浏览器或者其他应用来访问这些Digg服务. 一些有Digg账户的用户,可以得到“我的新闻”. 每位用户可以得到的我们称之为“热门新闻”.

系统架构师JD

- - CSDN博客架构设计推荐文章
国内大型的物流企业,专业从事国内公路运输和航空运输代理. Foss项目的架构设计,包括需求分析,模块设计,系统结构设计,关键功能的开发,技术难题的解决,对团队质量输出的把控等等. 1、熟悉WebLogic/Websphere/JBoss等一个以上大型应用服务器,熟悉Linux及应用服务器集群. 2、 具有丰富J2EE架构设计经验,具有大型基于J2EE体系结构的项目规划、系统架构设计、开发经验.

Android 系统架构分析

- - CSDN博客移动开发推荐文章
Android:开源的 Linux + Google 的封闭软件 + 私有的基带 + 运营商锁定 = 开放的 Android 手机. iPhone:开源的 BSD + 苹果的闭源软件 + 私有的基带 + 运营商锁定 = 封闭的苹果 iPhone. 一个平庸的应用商店,开发者依靠广告赚钱,商店并非独此一家,用户找不到好软件.