主题：【原创】身为码农，为12306说两句公道话 -- 代码狗
家园 好文。技术小白虽然不明觉厉，但多出主意总没坏处 其实目前技术上来说，精准营销应该可以分担12306的一些压力。每年春运流动的主体仍然是民工和学生，这两块细分市场其实完全不必通过12306走票。
学生由学校提前登记安排购票，这应该是长久以来的惯例，不知现在有没有变化。
民工稍微麻烦些，但现在实名制之后，也有解决可能。铁道部可以对数据进行整理，然后与地方政府合作，提前对本地出门打工的人群发短信征求购票意向，然后根据需求安排出票（比如根据历史记录，优先销售给那些老客户）。京沪穗等出行大站就可以把更多精力放在临时客流和客运组织上。
只是一种没有数据支撑的设想。请专业人士拍砖。
家园 其实看着有些晕 虽然每个字都认识，但是连在一起看着好复杂。
家园 高价票拍卖的方式超赞呀 抽签法我也想到了，也觉得ZF公信力是最大的挑战
家园 乃不怕铁总被口水淹死吗？ 铁路系统任重道远，一直都是中国的交通基干网络
牵一发而动全身
问问为啥北京的车牌不搞拍卖？
你就明白了，除非TG下台，墙倒了
家园 这篇技术上值得商榷 硬伤比较多了。今天实在太忙。过两天写个详细的回应吧。
12306这样的网站的确难做，但是你说的东西里面错误太多了。最明显的，从文中可以看出来对distributed transactional的东西错误理解。首先：
还有超卖，原来，某两台服务器在同一毫秒都拿到了锁，都去减了库存，15000个库存，被下了15500个订单，又得取消一部分订单。。。如果采用单线程独占锁，是可以做到同时只有一个服务器线程减库存的，但那样就对并发高峰的能力就差了好多了。SQL database如果不是设计失误，是不可能出现“同时都拿到锁”的情况的，这和单线程独占不独占关系不大。
冲着认真的写贴，先花你。
家园 这个问题不错 这个问题不错，是个懂技术的，但是基于的是对主流数据库的理解。
在商业数据库中，是有死锁的概念的，所以有回滚。但是并不会造成都把票减1。所以如果是商业数据库，你指出的是对的。
但在TAOBAO版的MYSQL中，为了使速度加快，就把这些措施都去掉了，这样在压力大的时候，就会出现LZ说的情况。这种做法在压力不大的时候也会出错，所以说TAOBAO技术如何如何，有点过头了。
可能TAOBAO也意识问题，自己写的OCEANBASE，把读写分开，专门有UPDATESERVER，都是些外行的想法。但应付TAOBAO的多读少写的场景应该有用。
家园 锁的描述确实不对 文章基本是按科普的笔法来写的（例如用绑钱的竹竿比喻抢票插件），意在帮助非技术人员理解12306的复杂。但也有一些不恰当的描述，比如超卖的问题，其实不是两个线程同时拿到了锁。
是因为淘宝的秒杀，查库存在Tair（类似memcached）里，减库存在MySQL里。下单的程序要先更新MySQL，再更新Tair里的库存数（如果Tair保证不down机，就可以先更新Tair再更新DB了，甚至全部在Tair里），这两个操作不是原子的，也不能做成DB事务（因为超出了DB的范围，再考虑分布式DB中间层，读写分离的Proxy），所以在更新数据库和Tair缓存之间那一瞬间，就有可能超卖。
如果没有MySQL，全都在Tair里操作，是不会超卖的，也可保证较好的性能。如果全在MySQL里，MySQL自己的锁会保证事务的原子性，但性能就差不少了。12306应该是全在内存DB里读写库存的，应该不存在超卖的问题。
感谢批评指正，我也只是曾经在淘宝写过几天代码，技术不行，只是比同事更善于写科普文章一些。
通宝推：敲门,- 复 锁的描述确实不对
家园 原来更外行 原本猜测是TAOBAO版本的MYSQL因为瘦身而出错，没想到是瘦身也不够，还要加内存数据库加速。
一言以蔽之，原来TAOBAO比我想的还要外行。
看网上有人说了12306的最终方案是全部都是内存数据库，这样就足够快了，比TAOBAO的方案更激进。
打个比方吧，在OS里有经典的缺页中断，利用少的内存和好的算法，可以让大多数的计算在内存中进行。内存数据库好比内存，MYSQL好比硬盘，TAOBAO就是这样提升了效率，这也是没有自己的数据库的悲哀。这样做当然就造成了内外不同步，在正常的情况下都有错误产生，如果垮掉，内存的数据就全完了。好吧，TAOBAO都是小买卖，出错也无所谓。
那么12306呢？出错就有所谓了，
可12306居然直接不用硬盘，全放内存里。如果垮掉，就是灾难性后果。估计是铁道部，被大家逼急了，先过关再说。
说到底这些问题都是因为没有掌握核心技术，而搞的外围手段。好处是见效快，坏处是风险太大了。
- 复 原来更外行
家园 ssd硬盘就相当于是内存盘了 家园 铁。。。。手！ 没想到是老大出现，失敬。
SSD有自己的优势和缺点，不考虑价格只考虑技术。
所以对SSD要有另外的算法去处理。
新的软件都支持了，所谓硬件识别算法。
但是SSD的缺点也很明显，比如容量，寿命，稳定性等等。
所以目前的主流做法，SSD也作为一种补充，是辅助用法。
从GEMFIR的描述来看，用的也不是SSD。
问题的关键是各种辅助用法或者外行做法，说白了就是打补丁，
也就是说核心的东西改不了，大家就在外围打补丁。
补丁打的多并不是好事情，不知道那块会出错。
出了错，连找谁哭都不知道。
- 复 原来更外行
家园 你错了，12306比你想象的要专业多了 12306用的是GemFire.没时间多说，你去查一下就知道。是有内存和硬盘同步的。
家园 基本概念不清 有同步和能保证事务是两个概念。
从下文可以看出12306的确是全部在内存中处理，而且是冗余内存。也就是说要坏就要冗余内存都坏才会造成数据丢失。问题在于软件就会有BUG，如果因为各种原因造成两份内存数据不一致，又怎么办呢？
所以这些都是外围的解决方案。GemFire既然叫分布式内存数据平台，而不叫内存数据库，就说明了其对事务的担忧。但是在某个具体的应用，比如12306，非通用软件，比如一个数据平台就可以使用，通过其它手段尽可能保证事务，比如排队等。这个跟淘宝把MYSQL的事务瘦身，然后承担出错风险，本质是一样的。
所以12306通过冗余内存来提高性能的办法，不叫专业，叫外行。这里并非说外行不能解决问题，而是更多风险而已。
GemFire分布式内存数据平台的原理为：
通过云计算平台虚拟化技术，将若干X86服务器的内存集中起来，组成最高可达数十TB的内存资源池，将全部数据加载到内存中，进行内存计算。计算过程本身不需要读写磁盘，只是定期将数据同步或异步方式写到磁盘。GemFire在分布式集群中保存了多份数据，任何一台机器故障，其它机器上还有备份数据，不用担心数据丢失，而且有磁盘数据作为备份。GemFire支持把内存数据持久化到各种传统的关系数据库、Hadoop库和其它文件系统中。12306之前采用Unix小型机架构，采用GemFire技术改造成Linux/X86服务器集群架构。
家园 我猜他隐含的技术背景是去IOE IBM ORACLE EMC
分别对应小型机，数据库，存储
淘宝这样规模的设施，这三个都是瓶颈，淘宝内部开源项目很多，都是为了解决这种场景的应用。
这里并非是数据库设计失误，而是在处理速度和数据精确上做了妥协，优选了速度，事后纠正，所以会出现所谓的超卖。
当然大大的投资设备，可以不必如此设计。最好的设计是适合的设计，而非教科书式的“正确”设计，他描述的问题可以在业务层面解决，你指出的瑕疵对他来说不是问题。
火车票是否有这样的业务概念，不得而知，铁路是否能接受这种，需要和客户沟通才知道。
我们只是在外面摸象，内部限于工作需要也不会在外面说。内部资料说的越多，给别人参考的就越多，比如奥巴马同学的网站，呵呵。
在真实的业务应用规模上，中国铁路，淘宝，还要....，确实是世界第一，过去的国外IT供应商，也是蛋疼。
家园 12306的宝 送花赞扬 关闭
送花成功。感谢：作者获得通宝一枚。
作者，声望:1；铢钱:16。你，乐善:1；铢钱:-1。本帖花:1
家园 其实库存可以不必那么复杂 纸板票时代还不是预先划好了票额？还是抽签最省事，刷票、排队都是做无用功，负和游戏。