l*****9
发帖数: 9501 | 1 铁路订票系统怎么强耦合了？12306绝对架构错了
对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
可分。这个数据量，大概只好用nonsql了
具体到12306设计：查票订票购票网站分开
查票网站
1。不实时，结果正确性不保证。
2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
客户登记网站：接受客户实名信息和支付办法
订票网站：只有已登记的客户可以使用
1。 直接接订单，用户可以选择订票成功自动购买。
2。 用户自己组合联票，比如（昆明到北京101次；天津到哈尔滨），组合逻辑由用户
提出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用
后台订票服务器：50台，每台处理限定车次
订票综合服务器：200台，每个用户的同一个订单去同一个服务器，订票结果电邮用户
。订票限时作废。
购票退票网站：用户接受订票成功结果的话，一键购票。不接受的话，一键取消定票。
一键退票。
客票实名制，上车时票证一起检查，不怕黄牛。退票不全额退款。 |
l*****t
发帖数: 2019 | 2 我认为任何有ActiveX的都是加错了，吼吼
所以，国内跟钱有关的网站都驾错了
【在 l*****9 的大作中提到】
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
: 可分。这个数据量，大概只好用nonsql了
: 具体到12306设计：查票订票购票网站分开
: 查票网站
: 1。不实时，结果正确性不保证。
: 2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
: 3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
: 出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
: 客户登记网站：接受客户实名信息和支付办法
|
T*****e
发帖数: 361 | 3 你这个架构跟goodbug说的感觉差不多，特别是非实时订票买票以及订票服务器按车次
横向分布两个方面。
对于余票查询，这个好像跟goodbug的方案有差别。goodbug的方案应该是实时的。其实
可以根据数据量的不同，可以把余票查询分为两类。
一类是来自车票查询网站的用户余票查询。这个可以从余票服务器（或订票服务器）汇
总后的snapshot服务器来查询，这个应该非常快，可以做到结果正确但非实时，也就是
说余票查询的结果是过去不久前的结果，而非此时此刻。估计你说的也是这个意思吧。
个人感觉这样做没啥大问题，毕竟余票查询只是订票的参考。
你的订票服务器可能叫单票服务器更清楚些。单票服务器除了余票外可能还需要维护单
票请求队列，通过队列来确定下一个获得暂时订票的订单。未被确认的暂时订票在一定
时间后可以转给下一个订单，防止死锁。
另外一类余票查询来自订票系统（订票综合服务器）。这个可以直接从单票服务器及其
replicas上查询。订票则走主单票服务器。这个其实是真正的用户订票处理服务器，用
来接收、处理和维护从订票网站传来的各种订单。所有订单都分解为单票请求发给单票
服务器，在获得暂时订票后确认，在获得所有单票暂时订票后联系用户购票；为避免长
期锁定暂时订票，一定时限后应该取消未完成订票的单票暂时订票，或取消超出购票期
限的暂时订票并取消订单。这个有点复杂了，真正实现可能更加复杂些。
用户订票处理服务器的数量应该可以根据实际需求增减。单票服务器也可以根据实际负
载来增减、切分、合并，极端情况应该是单日单车次一台服务器，不过应该不至于。这
些应该都可以做到快速调整而无需暂停系统运行。
联票查询也有可能在（通过snapshot服务器的）余票查询的基础上做到，当然也不保证
时效性。这个可能需要单独的服务器，因为涉及到车次网络。联票查询应该可以给用户
提供更好的线路选择。 |
l*****9
发帖数: 9501 | 4 嗯，其实就是尽量decoupling，服务器可以随便增加，从而得到更好的performance。
12306加服务器没用，说明架构有问题
【在 T*****e 的大作中提到】
: 你这个架构跟goodbug说的感觉差不多，特别是非实时订票买票以及订票服务器按车次
: 横向分布两个方面。
: 对于余票查询，这个好像跟goodbug的方案有差别。goodbug的方案应该是实时的。其实
: 可以根据数据量的不同，可以把余票查询分为两类。
: 一类是来自车票查询网站的用户余票查询。这个可以从余票服务器（或订票服务器）汇
: 总后的snapshot服务器来查询，这个应该非常快，可以做到结果正确但非实时，也就是
: 说余票查询的结果是过去不久前的结果，而非此时此刻。估计你说的也是这个意思吧。
: 个人感觉这样做没啥大问题，毕竟余票查询只是订票的参考。
: 你的订票服务器可能叫单票服务器更清楚些。单票服务器除了余票外可能还需要维护单
: 票请求队列，通过队列来确定下一个获得暂时订票的订单。未被确认的暂时订票在一定
|
h*******u
发帖数: 15326 | 5 你这个不能查联票，用户骂死你。
UA,DELTA购票都可自动查联票，你怎么不行？
【在 l*****9 的大作中提到】
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
: 可分。这个数据量，大概只好用nonsql了
: 具体到12306设计：查票订票购票网站分开
: 查票网站
: 1。不实时，结果正确性不保证。
: 2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
: 3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
: 出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
: 客户登记网站：接受客户实名信息和支付办法
|
l*****9
发帖数: 9501 | 6 2.0
【在 h*******u 的大作中提到】
: 你这个不能查联票，用户骂死你。
: UA,DELTA购票都可自动查联票，你怎么不行？
|
B********a
发帖数: 132 | 7 你out了， 现在查票直接用一个无线的 手持终端读取含有电子芯片的二代身份证，
上车查票都不用看票， 扫一下你的身份证就知道了。 |
d********u
发帖数: 5383 | 8 几百万APP一起刷票，你这个系统一样死得硬邦邦的。
生搬硬套是不行的。
【在 l*****9 的大作中提到】
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
: 可分。这个数据量，大概只好用nonsql了
: 具体到12306设计：查票订票购票网站分开
: 查票网站
: 1。不实时，结果正确性不保证。
: 2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
: 3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
: 出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
: 客户登记网站：接受客户实名信息和支付办法
|
z****e
发帖数: 54598 | 9 人家12306才用了17个nodes
你用了50个
3倍了
【在 l*****9 的大作中提到】
: 铁路订票系统怎么强耦合了？12306绝对架构错了
: 对于超多用户超大工作量的应用，界面一定要简单，尽量用后台批量处理，工作量线性
: 可分。这个数据量，大概只好用nonsql了
: 具体到12306设计：查票订票购票网站分开
: 查票网站
: 1。不实时，结果正确性不保证。
: 2。不回答联票查询。比如昆明到哈尔滨是否有票？没有直达车就说没有。
: 3。回答组合查询，比如（昆明到北京；北京到哈尔滨）是否有票。组合逻辑由用户提
: 出，每部分之间客户给出时间间隔，比如尽快或48小时，简化了应用。
: 客户登记网站：接受客户实名信息和支付办法
|
m**u
发帖数: 541 | 10 问题根本不在订票系统，你们真让人发愁…
现在俺明白为啥让三哥痛扁了… |
|
|
n****1
发帖数: 1136 | 11 问题是铁道部所有的窗口都是能卖联程票的, 结果堂堂国有的最牛IT系统, 连卖票窗口
都比不过, 媒体会怎么写? 群众会怎么骂?
铁路出票系统一直以来都是强耦合的, 宕机年年有, 大家习惯了. 但为了技术方便而随
便更改游戏规则是要担政治风险的.
我感觉12306并不是老魏的方案, 而是两者的折中. 其实阿里巴巴也参与设计了, 能做
到现在这个样子, 已经是能平衡各方利益了.
【在 l*****9 的大作中提到】
: 2.0
|
g*****g
发帖数: 34805 | 12 怎么不能买联程票，可以买，我提到过分库的一种办法就是分票，所有票都分10份，到
票库存低于某个值再合票，是完全可以做到的。
【在 n****1 的大作中提到】
: 问题是铁道部所有的窗口都是能卖联程票的, 结果堂堂国有的最牛IT系统, 连卖票窗口
: 都比不过, 媒体会怎么写? 群众会怎么骂?
: 铁路出票系统一直以来都是强耦合的, 宕机年年有, 大家习惯了. 但为了技术方便而随
: 便更改游戏规则是要担政治风险的.
: 我感觉12306并不是老魏的方案, 而是两者的折中. 其实阿里巴巴也参与设计了, 能做
: 到现在这个样子, 已经是能平衡各方利益了.
|
n****1
发帖数: 1136 | 13 联程票是一篮子组合, 要么都买下来, 要么都不要. 这个其实是个distributed
transaction, 应该会加强各节点间的依赖性吧.
比如昆明到沈阳, 经过北京转车, 那这个订单要排至少两个队. 你越分得细队列就越多
吧.
还是说你把这两张票合成一种商品, 用同一个队列? 那样的话商品种类就得是原来的2
次方了.而且像北京这种枢纽, 去个方向的都有, 昆明到北京票只分10份, 是不是只能
满足最多10种不同目的地联程需求?
可能是我没理解, 能否把你的想法说得再详细一点?
【在 g*****g 的大作中提到】
: 怎么不能买联程票，可以买，我提到过分库的一种办法就是分票，所有票都分10份，到
: 票库存低于某个值再合票，是完全可以做到的。
|
b**********g
发帖数: 460 | 14 为啥不考虑z/tpf呢？成功先例在那摆着呢。 全球的gds全用，visa 和 amex 这种处理
大交易量的也都用。 |
z****e
发帖数: 54598 | 15 ibm的东西贵啊
铁道部抠门，不舍得
要真舍得，当初竞标时候就选ibm了
【在 b**********g 的大作中提到】
: 为啥不考虑z/tpf呢？成功先例在那摆着呢。 全球的gds全用，visa 和 amex 这种处理
: 大交易量的也都用。
|
s*****r
发帖数: 43070 | 16 资源有限，不是设备牛X，系统先进能解决的
1月4日，央视曾直播上海-成都K696次车的网络售票现场，数千张车票在2分钟内被一抢
而空，速度之快令人咋舌。
两分钟之内抢不到，game over
【在 z****e 的大作中提到】
: ibm的东西贵啊
: 铁道部抠门，不舍得
: 要真舍得，当初竞标时候就选ibm了
|
s*****r
发帖数: 43070 | 17 订单处理不需要太多机器，完全可以在后台处理，和客户界面没有直接关系。车票查询
应该不是实时的，也没有必要，可以多上一些机器来满足春运期间的大量查询。
下订单这步有点难搞，如果要保证下单就有票，必须事先锁定车票资源，checkout分好
几步，选择支付种类，输入支付信息，确认，正常输入要一分钟时间。春运期间把车票
锁住一分钟是不现实的，还不能保证支付能最终完成。
热门车票一上线就卖光，说明客户下单的时候没有锁定车票，不能保证下单就一定能买
到，假设支付信息是有效的。由订单处理的机器来决定订单能否被完成，或者失败。用
户下单后，就看到一个spinner在等待，这期间订单处理器完成一系列的步骤，最后通
知用户订单成功或者失败。
【在 T*****e 的大作中提到】
: 你这个架构跟goodbug说的感觉差不多，特别是非实时订票买票以及订票服务器按车次
: 横向分布两个方面。
: 对于余票查询，这个好像跟goodbug的方案有差别。goodbug的方案应该是实时的。其实
: 可以根据数据量的不同，可以把余票查询分为两类。
: 一类是来自车票查询网站的用户余票查询。这个可以从余票服务器（或订票服务器）汇
: 总后的snapshot服务器来查询，这个应该非常快，可以做到结果正确但非实时，也就是
: 说余票查询的结果是过去不久前的结果，而非此时此刻。估计你说的也是这个意思吧。
: 个人感觉这样做没啥大问题，毕竟余票查询只是订票的参考。
: 你的订票服务器可能叫单票服务器更清楚些。单票服务器除了余票外可能还需要维护单
: 票请求队列，通过队列来确定下一个获得暂时订票的订单。未被确认的暂时订票在一定
|
g*****g
发帖数: 34805 | 18 你把所有票分10份，什么联程不能卖？卖得差不多再调度呗。再说了，每天票不过几千
万张，还分时发，好点机器单机数据库也能撑下来。难点就在于收订单。订单能多100
倍。所以前后要分离。前端要上 Cassandra. 订单可以很复杂，比如100次没有就买200
次，这样可以减少的订单数目。
2
【在 n****1 的大作中提到】
: 联程票是一篮子组合, 要么都买下来, 要么都不要. 这个其实是个distributed
: transaction, 应该会加强各节点间的依赖性吧.
: 比如昆明到沈阳, 经过北京转车, 那这个订单要排至少两个队. 你越分得细队列就越多
: 吧.
: 还是说你把这两张票合成一种商品, 用同一个队列? 那样的话商品种类就得是原来的2
: 次方了.而且像北京这种枢纽, 去个方向的都有, 昆明到北京票只分10份, 是不是只能
: 满足最多10种不同目的地联程需求?
: 可能是我没理解, 能否把你的想法说得再详细一点?
|
g*****g
发帖数: 34805 | 19 一分钟几千个交易罢了，离不是什么很高要求。
【在 s*****r 的大作中提到】
: 资源有限，不是设备牛X，系统先进能解决的
: 1月4日，央视曾直播上海-成都K696次车的网络售票现场，数千张车票在2分钟内被一抢
: 而空，速度之快令人咋舌。
: 两分钟之内抢不到，game over
|
n****1
发帖数: 1136 | 20 你从来不谈细节, 有瓶颈就加机器. 如果做系统能用"stateless & partition"一句口
号就完工, 这个初中生也能, 那还要架构师做什么.
首先要保证你的架构下,人家能够买到联程票. 我已经说了, 两张票同时出的话牵涉到
不同节点通信. 我不管你怎么分票,如果通信是同步的, 牵涉到联程的票库都得受性能
影响.如果通信是异步, 没准通信还没完成票都卖光了, 那样系统就等价于卖不了联程
票.
100
200
【在 g*****g 的大作中提到】
: 你把所有票分10份，什么联程不能卖？卖得差不多再调度呗。再说了，每天票不过几千
: 万张，还分时发，好点机器单机数据库也能撑下来。难点就在于收订单。订单能多100
: 倍。所以前后要分离。前端要上 Cassandra. 订单可以很复杂，比如100次没有就买200
: 次，这样可以减少的订单数目。
:
: 2
|
|
|
n****1
发帖数: 1136 | 21 为啥是10份, 不是两份或100份? 是随便来还是有讲究? |
g*****g
发帖数: 34805 | 22 我讨论细节的时候你哪去了？当初争论了一周哪个细节不是被拷问了3遍？出票是后端
，加上分时出，transaction保证联票，你单机 rdbms 就完了。
【在 n****1 的大作中提到】
: 你从来不谈细节, 有瓶颈就加机器. 如果做系统能用"stateless & partition"一句口
: 号就完工, 这个初中生也能, 那还要架构师做什么.
: 首先要保证你的架构下,人家能够买到联程票. 我已经说了, 两张票同时出的话牵涉到
: 不同节点通信. 我不管你怎么分票,如果通信是同步的, 牵涉到联程的票库都得受性能
: 影响.如果通信是异步, 没准通信还没完成票都卖光了, 那样系统就等价于卖不了联程
: 票.
:
: 100
: 200
|
l*****9
发帖数: 9501 | 23 系统自动出联票，计算量会大很多。查询量，订单量，任何其他系统和12306相比都要
小几个量级
【在 h*******u 的大作中提到】
: 你这个不能查联票，用户骂死你。
: UA,DELTA购票都可自动查联票，你怎么不行？
|
z****e
发帖数: 54598 | 24 其实铁道资源紧张主要集中在进川和出川
不知道为什么这部分不加大投入
倒是东南沿岸比如上海到深圳，这条不堵的线弄了高铁
当然我个人不反对，我回家更方便了
但是从我以前春节回家，不管是从广州深圳还是上海回福州
从来没有堵过，因为高速公路解决了绝大部分问题
都不需要坐火车，主要堵的就是广州到成都这条线
年前看广州，年后看成都么
【在 s*****r 的大作中提到】
: 资源有限，不是设备牛X，系统先进能解决的
: 1月4日，央视曾直播上海-成都K696次车的网络售票现场，数千张车票在2分钟内被一抢
: 而空，速度之快令人咋舌。
: 两分钟之内抢不到，game over
|
b**********g
发帖数: 460 | 25 这个流量不算什么吧。 有的gds的设计上线是30ktps, 处理这点票没什么。
国内也不是没有处理大流量的先例，体育彩票就要处理100万个交易／7秒， 只是背后
计算部分没有订票那么复杂了。
【在 s*****r 的大作中提到】
: 资源有限，不是设备牛X，系统先进能解决的
: 1月4日，央视曾直播上海-成都K696次车的网络售票现场，数千张车票在2分钟内被一抢
: 而空，速度之快令人咋舌。
: 两分钟之内抢不到，game over
|
