首先声明我想的不成熟，可以被挑战。
其次，只讨论技术实现。
假如车次为 G3 ，该车次为北京始发到上海，沿途经过北京南、济南西、南京南。那么，预设为各车站之间均为一个库存，那么存在北京-北京南、北京南-济南西、济南西-南京南、南京南-上海这几种库存类型，假如买了一张北京到上海的全程车票，那么会在上述区间都去掉 1 个库存。当任意一个区间库存为 0 之后，覆盖到该区间的车票将无法购买；而查询非 0 库存区间时则会提示为有票。
那么，G3 车次北京->上海为一个商品大类，二级类别中分为商务座、一等座、二等座、无座等各种座次，每个座次类型的库存相互独立。
买短乘长的逻辑为，已经购买了其中部分区间的票，超出后的部分为单独的购票逻辑。
买长乘短的逻辑为，购买了超长区间的库存，而声明提前下车后，后续区间相应库存会释放。
注意，库存数量并非为静态值。
其次，只讨论技术实现。
假如车次为 G3 ，该车次为北京始发到上海，沿途经过北京南、济南西、南京南。那么，预设为各车站之间均为一个库存，那么存在北京-北京南、北京南-济南西、济南西-南京南、南京南-上海这几种库存类型，假如买了一张北京到上海的全程车票，那么会在上述区间都去掉 1 个库存。当任意一个区间库存为 0 之后，覆盖到该区间的车票将无法购买；而查询非 0 库存区间时则会提示为有票。
那么，G3 车次北京->上海为一个商品大类，二级类别中分为商务座、一等座、二等座、无座等各种座次，每个座次类型的库存相互独立。
买短乘长的逻辑为，已经购买了其中部分区间的票，超出后的部分为单独的购票逻辑。
买长乘短的逻辑为，购买了超长区间的库存，而声明提前下车后，后续区间相应库存会释放。
注意，库存数量并非为静态值。
 |
1
uzumaki 6 天前
^ ^ ^ ^ ^ ^ 朱建生，王明哲，杨立鹏，阎志远，张志强. 12306 互联网售票系统的架构优化及演进. 铁路计算机应用，2015 ，24 （ 11 ）：1-4.
[2] ^ ^ ^ 杨立鹏，王富章，梅巧玲，朱建军. 互联网售票中的海量请求处理技术研究. 铁路计算机应用，2015 ，24 （ 7 ）：25-27. [3] ^ 王明哲，张振利，徐彦，王富章，朱建生. 铁路互联网售票系统的研究与实现. 铁路计算机应用，2012 ，21 （ 4 ）：23-25. [4] ^ 刘相坤，李 琪，徐东平，李聚宝. 虚拟化技术在 12306 双活数据中心中的应用. 铁路计算机应用，2016 ，25 （ 10 ）：27-30. [5] ^ 李天翼. 12306 互联网售票系统测试的实现. 铁路计算机应用，2016 ，25 （ 10 ）：27-30. [6] ^ Pivotal. Case Study: China Railway Corporation, Scaling Online Sales for the Largest Railway in the World. https://pivotal.io/big-data/case-study/scaling-online-sales-for-the-largest-railway-in-the-world-china-railway-corporation [7] ^ 幽云十八. 透过 12306 五大焦点看高性能高并发系统. http://storage.it168.com/a2012/0217/1313/000001313424_all.shtml |
 |
2
xinrenceshi2024 6 天前
你用 CURD BOY 的 SKU 思维，当然无法理解了。
但凡有一点算法基础，就不会用每个站点作为一个 SKU 。这就是计算机科班生跟北大青鸟培训班出来的差距。 一般应该是一个席位作为一个初始的 SKU ，如果有人买区间，就把该席位剩下的部分再生成一个或两个 SKU 。 就拿 G3 举例，最开始有 1000 个北京南 - 上海的 SKU （假设该车是 1000 个座位）。 如果有人买济南西 - 南京南的票，那就 1 、取出一个北京南 - 上海的 SKU ，分割成 北京南 - 济南西 、 济南西 - 南京南 、 南京南 - 上海三个 SKU 。 2 、将济南西 - 南京南 SKU 卖给用户出票。 3 、将 北京南 - 济南西 、 南京南 - 上海两个 SKU 入库。 |
 |
3
sillydaddy 6 天前
不用这么复杂。
以不同的「起点终点对」来分配库存，会让问题大大简化，即：Map<{start, end}, store>。 假设有 1 条线路有 10 个车站，那么这 10 个车站可以组合出 45 个「起点终点对」。每个「起点终点对」都有一个预先分配的库存。 这样做，可以使得所有的库存都是预先分配的，且独立互不影响，不必依赖一个中心化的数据处理逻辑，很容易并行化。 这样做的依据也很充分。即列车的乘客流量在不同城市间，是可以统计的，而且也是符合统计规律的，容易预测。就像 v 站的帖子数量，每个月的数量都是相对固定的，甚至不同年份的在几个月的变化趋势都是相似的。 |
 |
4
RicardoY 6 天前
@xinrenceshi2024 没有理解这个方案有什么收益
|
 |
5
realpg 6 天前
别用现代化思维去想 TRS5.x 系统
他压根都不算什么网络程序 更类似一个本地程序 说实话，只要有人肯担责拍板推翻 TRS 架构 只需要现在 1/50 的成本 就能支撑全铁路高峰订票不用排队不用 单杏花还得靠这个评全国先进呢 就连电子发票都得参和一下整成他火车票的版式 |
|
6
realpg 6 天前  1
我简单给你说一下 TRS 系统基础架构
TRS 就是铁路售票系统 每个铁路局有一个集群的 SYBASE 数据库 这个叫局网 存分配给本铁路局票额 然后 每个车站的售票窗口，运行一个 TRS 程序，这个程序是 POWERBUILDER 写的，这个程序直连自己铁路局的 SYBASE 题外话 1 ---------- 因为 TRS3.0 时代，199X 年，就是几个很菜的学生加上铁科院的几个老师搞的，当时 POWERBUILDER+SYBASE 就是主流架构 那代码写的，用 2007 年时候的我的技术水平看他们 2007 年时候的代码，就是一坨屎山中的屎山 连接池变量就是全局的 sqla sqlb sqlc sqld sqle sqlf 到 sqlL 的时候 我猜是学生看错了老师给的任务书 达成了 sqlI 也不 sql1 （记不住了） --------- 题外话 1 完事 然后呢，各个铁路局只能发售本路局的票额，然后后来全国联网不行啊，就再拓展，再区域中心搞了几个集群，内部叫“路网” 就是把一部分票额扔那里面 各个窗口的 powerbuilder 程序再直连过去，本地取不到的，再去路网数据库取 数据库里面呢，就是一个又一个的存储过程，所有逻辑都在数据库里跑，还是个性能渣的突破天际的 SYBASE ，然后数据库的最主要记录，票额记录，一条几十个字段，然后得各种过滤去筛选，交给 oracle 这索引利用率都不行 因为全铁路也就几万个售票窗口，还有强烈的买票地域性，取票操作，一次三五秒都不算啥，我售票窗口，输入车次 G1 ，输入发站北京，输入到站南京南，选二等座取 3 张，按一下回车，之后窗口售票员等 1 秒 2 秒 3 秒 4 秒 5 秒，都不是啥问题，一次操作就算卡了 10 秒，外面窗口外买票的人等 10 秒钟算事儿吗？不算！ 就这么缝缝补补过来了，直到，12306 来了 12306 来了，相当于，每个人手里有一个售票窗口了。。。 你本地商业软件一个操作卡 10 秒屁事不算，你全国几千万人一起一个操作卡 2 秒，就算不考虑客户体验，这是会请求堆积数据库加锁的啊！然后就是痛苦的改造过程 ---------- 未完待续 |
 |
7
mytsing520 OP @realpg
我发现我又犯了“以结果反推过程”的错误。 |
 |
8
awanganddong 5 天前
@realpg 如果根据这种历史业务来走的话，那么 12306 就完全可以基于历史的用户购片信息，对各个站点分配不同的票量。当然这里边肯定存在不同操作对同一张票的 争抢。这个 12306 最开始用的这个技术 GemFire 。下边是链接地址： https://www.51cto.com/article/501374.html 后边用国产自研替换了。
|
 |
9
PrinceofInj 5 天前
@realpg #5 难道刚开始 12306 需要用户安装自签发的根证书也是她的杰作么？
|
 |
10
234ygg 5 天前
提前声明本人非 cs 出身，也没抢过票😂
op 这种计算压力肯定是太大了，每次查询都要实时计算多个区间的库存交集，春运高峰期应该不太可能这样实现， 我们这种搞数学的会觉得是根据统计信息预先准备不同区间的库存，然后再次根据统计信息分配到不同的数据库节点，多个节点卖完多个区间后触发节点间的库存分配。。 系统设计肯定是要考虑铁总利润率，不能让某些赚不到钱的区间在高峰期坏事儿 |
|
11
realpg 5 天前
@PrinceofInj #9
不 跟他无关 12306 那个自签证书不是因为铁科院没那个钱或者自己瞎搞 是因为那个是铁路自己的 CA 在 12306 以前就已经工作了很久很久了 铁路相当多的内部应用系统都是用这个 CA 签发的 那个年代也没有 le ，所以证书还很贵 铁路内部什么单位都开发自己小系统 基于自己的 CA 签自己的证书 他们内部有证书中心处理这个 他们内部这些系统也没有几个对公众的 比如什么招标系统啊什么的 估计能签出过几千个证书 而 12306 上线时候就继承了这个 然后更换外面 CA 需要层层审批啊 还有论证啊 系统性软件工程就是这样 过了一阵子走完流程 啥都够了就花钱买外面证书了 |
|
12
realpg 5 天前
@awanganddong #8
12306 是另一回事了 现在还没说到 12306 刚说到 12306 来了 其实我不想写下去了 12306 出来以后的智障大战更是离谱中的离谱 写出来能让所有看过帖子的高级程序员血压直上 200 维持一个月 而且吧 那些公开论文什么的看看就行了 后来阿里那边参与以后 在不能动屎山的前提下 搞了挺多花活 有一些是公开的 有一些就是私下搞得 已经算是缝缝补补的 毕竟 现在高峰期允许你提交订单以后排 45 分钟的队 所以 现在只要 api entry server 不崩溃 弹性扩容到几千台 把 mq 扩大一点 反正可以排队 45 分钟 这种活 相当于 0 技术难度了 类比一下 你是京东商城的架构师 刘强东告诉你 咱抢购茅台功能 用户提交订单能接收到 45 分钟后再告诉他抢购成功没成功都行 你觉得这种系统 开发的技术难度是多少？ 再写下去 太多人知道这个 然后万一被转到小红书啥的造成舆情 还是我闹心 因为这些事儿 能全知道的 还不是铁路的人的 就那么几家 以及几个个人 早晚还是回旋镖到自己身上。。。 倒不是喝茶什么的 会给人添堵 还都是朋友 |
|
13
awanganddong 5 天前
@realpg 你还是别写了，不然我觉得你过不好年。
|
|
14
awanganddong 5 天前
@234ygg 根据 realpg 讲的业务迭代路线，就是你讲的这种技术方案。
|
|
15
realpg 5 天前
@awanganddong #13
等啥时候喝多了继续写 hhh 因为吧 因为架构原因 我这边知道很多大部内部人都不太知道的废案 以及一些内部争斗 感觉总会写出一些别的内部人不知道的东西而不自知 然后很容易定位 倒不怕他们怎么样 毕竟都是他们欠我的 我最近 20 年 干的最多的活就是帮各种人擦屁股兜底 基本都是别人欠我人情 |
|
16
awanganddong 5 天前
@realpg 你这适合出本书，讲讲国内购票系统的发展史。
|
|
17
realpg 5 天前
|
 |
18
murmur 5 天前
@realpg 那你可想少了，铁路有个其他任何互联网公司都不具备的优势，他不需要又当表子又立牌坊
对于互联网公司，黑流量也是流量，黑红也是红，灰产黑产也有价值 但是 12306 不需要，人家只要推出官方排队系统就绝杀了大部分黑产灰产，毕竟我明盘卖票规则你根本抢不到 |
|
19
realpg 5 天前
@murmur #18
你才是想多了 他们当了婊子 牌坊比互联网公司还多 周边利益链可比互联网公司大多了。互联网公司只是大手大脚，干的东西顶天因为公司体量大，多花点成本，多点内耗 只是你不懂人家体制内单位的牌坊在哪，牌坊是什么形式，你只能理解社会上普通企业的牌坊是啥样的 |
 |
20
Gilfoyle26 5 天前
不单纯的是技术方面的原因吧，更多的是各个山头的错综复杂的关系，剪不断理还乱的关系，估计才是最难的地方。
|
Select Language