- 程序有所改变。发帖如还有问题请报告
- 【征集】西西河的经济学，及清流措施，需要主动参与者，『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】身为码农，为12306说两句公道话 -- 代码狗
家园 写的很好 虽然不懂技术，但楼主这么一分析，明白了许多
家园 数据模型设计 关于库存数据存储设计，我再提一个方案，不用16个商品也不用136个，只用1个，但是不存储“库存数量”，而是用一个bit vector代表整个路线的存货，查询和购买都只用一次操作。
北京西到深圳北就是一个16位的bit vector，初始状态全部是1。
查询1号站到5号站就是查询:
1111 1111 1111 1111 AND 1111 0000 0000 0000 == 1111 0000 0000 0000
查询只用一次操作，得TRUE
如果这张票卖出去了，那写入也只是一次操作:
1111 1111 1111 1111 - 1111 0000 0000 0000， 得新值0000 1111 1111 1111，写入。
下一次查询比如2号站到6号站：
0000 1111 1111 1111 AND 0111 1000 0000 0000 == 0111 1000 0000 0000 得 FALSE.
读写兼顾，而且数据库维护很容易，没有任何多余重复信息。
- 复 数据模型设计
家园 我同意你的算法，而且这个算法可以硬件加速 余票查询，分配，前面有人提到了硬件加速，这是可行的，算法其实更简单。
核心，还是位表。
其样子大概如下：
0 表示空闲，1 表示占用
座位号 | A 区间 | B 区间 | C 区间 | D 区间 | E 区间 | F 区间 | G 区间 | H 区间
-------+----------+----------+----------+----------+----------+----------+----------+----------
1 | 0 0 0 0 0 0 0 0
2 | 0 0 0 0 0 0 0 0
3 | 0 0 0 0 1 1 1 1
4 | 0 1 0 0 0 0 0 0
5 | 0 0 0 0 0 0 0 0
6 | 1 1 1 1 0 0 0 0
7 | 0 0 0 0 0 0 0 0
8 | 1 1 1 1 1 1 1 1
9 | 0 0 0 0 0 0 0 0
...................
求区间余票，比如 B 到 G，只要把这个位表的相关区间按列取出，进行 “或” 操作就行了，最后得出的位表，就是查询结果。
考虑到一个车次的总车位在数百到数千，那么这个位表的总数据量大小不会超过数百 KB。
这个算法完全可以用 FPGA 或者专用的 ASIC ，位表操作和结果判定可以用硬件并行进行。
基本上来说，查询速度有多快，只取决于芯片能跑多快的频率。如果芯片工作在 1G 的频率，10个Cycle 处理一次查询或者订票请求，做到每秒一亿次是没什么问题的。
世界级难题？ 我就笑笑 ...................
如果真如某篇不要脸的吹牛B 文章所说的。
12306 曾扬言 “钱管够”。
那无论是华为或者是思科，都能把订票功能内置到骨干网的路由器里面去。
唯一就看中国电信的骨干网有多快了。
- 复 数据模型设计
家园 这个设计只适合1个座位吧 一个车次上千个座位，你要匹配上千次，效率不高啊~~
家园 感觉在文中，以G71为例这个简化的的408个商品的模型， 还是有很大的不足，没有考虑每张车票它的座位属性。这个是很要命的，不然大家好不容易挤上车，就开扁了--抢座哈。当然，开扁这是我编的。甚至考虑这样一个方案：设G71总共有M个座，16个站段，那就是16*M个商品，也避免不了座位属性。主要是因为卖出2个站段及2个站段以上的车票，在方案中也就是2个商品，这2个商品的座位属性必须是一个座位。
家园 16 种商品的方案明显优于 136 种商品的方案 主要针对楼主的这段话：
如果出一张01号站到17号站的票，就把SKU01/SKU02....SKU16这16个SKU的库存都减一。这种做法是可以运行的。我原来参与设计的一个ERP系统就是这样的做的。
16个商品方案的优点是商品数会比较少，缺点在于查询性能较低，要查询16次才能知道【北京西到深圳北】还有没有余票。而136个商品的设计，穷举了所有出发和到达站点的组合，出票前只需要查询1次库存就知道还有没有余票。
大部分面向公众的网站，其业务特点都是读多写少。电商系统的库存查询次数更是远远多于库存修改次数的。在秒杀系统中，可能会出现99%的请求查库存1%请求改库存的情况。 像12306春运抢票这种场景，在秒杀工具（抢票软件）的推波助澜下，查询1万次库存才成功出一张票也不是没有可能。
查询性能在这里不是问题，因为查询本来就不应该直接去访问余票数据库，而是应该为余票数据库建多个定时更新的只读副本，把所有的查询流量分散到这些副本上，余票数据库只服务最终下单的请求。这样做的缺点是查询结果和实际余票情况在一定时间内会存在不一致，可能查得到票却买不着。但这在很多人同时下单买票的情况下本来就无可避免。
从服务最终下单操作的请求来看，16 种商品的方案明显优于楼主提出的 136 种商品的方案 —— 这点楼主是否同意？
家园 但是有些问题铁道部也是不可推卸的 就是对于身份证号码没有任何验证信息，比如你随便输入一个自己编定的身份证号码，010195846320454142，也是可以买票的，这个总不能说是技术问题吧。
家园 本来这样做是有道理的 定票时12306如果做这个校验，可能会拖垮公安的网络系统；另外对正常的乘客其实也不需要做这个。这个信息的正确性应该是由乘客自己保证的。如果检票把关严，票、证不符不许过，乱填的人就傻眼了。
现在的问题是这个做法被黄牛钻了空子，乱填一串符合身份证号生成规则的数字就可定票了。
家园 12306将联网身份认证系统 虚假身份无法购票 http://news.qq.com/a/20140115/004909.htm?ADUIN=534733126&ADSESSION=1389702743&ADTAG=CLIENT.QQ.5281_.0&ADPUBNO=26292
好像铁路部门不认为联网认证会拖垮相关系统
