悟空-简单就好
.net企业级应用研究

考虑最复杂的情况
开发出最简单的实现


Word文档-资料管理系统!

总结大家的发言,期望中的火车新订票系统

1)铁付通:允许允值到帐户

2)预订方式:预订不成功退钱回帐户

3)加入分配规则:解决像春节特殊节日下,优先满足回家的人们

(去年有回去的优先级下降一档、不是回家的优先最低。

 什么流量,根本就是最最基本的技术问题,谈流量者SB)

4)加入用户信用评价体系,并和分配优先级挂钩

5)支持PC、智能手机的订票方式,逐渐减少人工售票点(不会在线订票的人群)

6)目标是:用户可以10分钟内完成预订单(不需要也不提供查余票功能)

              在抢票期内5分钟~24小时给出是否预订成功;

         非抢票期在运输资源出来后1小时内给出是否预订成功。

         节约没有意义的排队、刷屏的国民时间;照顾到需要照顾的人群

              让最基层的老百姓多些满意。

 

(架构图就不画了,估计铁道部相关的人员也不会理睬这个)

***********************************************************

 

 前言:

  最近经常看到买票难,作为搞技术的我TMD的骂一次:

      票会增加吗?总是有人能买到,有人不能买到;

      就不能换个思路设计订票系统。

      要是我是什么什么的来着,早已经实现通过手机短信、网站就能轻松买票了;

      还顺便将手机实名制给实现了。

 

 摘要:

  现有的订票方案问题在哪,

  1)是即时的,需要很多很多计算资源;搞得订票过程耗时

  2)技术难度大:如余票查询、数量扣除锁等,都有很大的架构难度。

  即并行访问根本就不是问题,问题在于单个用户的处理时间过长,

  造成用户在网站“同一资源过程”停留的过长造成的雪崩效应问题。

     最终是:200个用户在A服务器上卡死了,会话时间为20分钟的话,A服务器基本上是挂了。要等监控进程清理,所以才会出现付钱不给票的情况(强制清除进程造成)

  

  我想解决的是:避免浪费国民的时间,老是作那些没有意义的查询,

  直接根据旅客的要求要给有没有票就好了。

  而且,能实现很多很多其它的功能,又没有什么技术难度。

 

 

 

 正文:

 

  不知是我想简单了,还是专家们想复杂了。

 铁道部的专家还停留在线下售票方案中拨不出来;

 线上售票系统简单得多了。
 骂完铁道部后,提供一简单又可行的解决方案。

  查询余票、防止超售、防止黄牛,一般的设计思路是有难度,

  换个思路,TMD太简单的就能搞定。


一、总体方案

 1、正常情况:预订交钱-->后台自动验证规则-->不符合购买限制的钱原路退回-->
-->提醒用户预订成功(但不一定有票)-->运输资源出来,根据先到可先得+优化级的原则分配
-->短信通知用户取票

 2、用户不取票:没有关系,因为铁道部已经收到钱,所以你开车前两小时取即可。
      多方便啊,就不用为了票多走一次车站。

 3、用户退票:春运有人退吗? 平时要是退了,就退吧


二、前台网站设计

 只需要预订,根本不需要查余票什么的。所以很简单的架构就能搞定,甚至不用CDN

 

三、后台设计

 

 预订后,后台慢慢处理,看资源情况增加服务器。即使后台的服务器挂了,前台用户也感觉不出来。
 运输资源出来,看有多少是分配给网上订票的,依规则分配即可。

 这样后台的架构要有多灵活,就可以设计成多灵活。
 后台由验证服务器+分配服务器+取票及跟踪服务器组成。
 具有分配资格的,满足了身份证唯一、已付款、优先级等等要求了;
 而且是一票一票分配的,根本就没有什么复杂的逻辑处理,也没有什么数据库表锁;
 因为能分配的已经满足了锁的要求了,用单线程分配就好了。
 2核的一秒就可以处理1000张票以上。

 

四、可能的问题

 

  1、有存在海量的处理的情况吗? 没有,预订对数据只是增加操作,不需要扣除数量锁表
  2、有峰值压力吗? 没有,预订时要处理的事情很少很少
  3、能不能订到票,心里没底? 预订和抢票,没有区别啊,
  关键一点的是,预订可以有复杂的预计,比如允许自动安排下一趟什么的;
  多灵活啊。也不要做哪些没有意义的重复提交。
  4、如果铁道部的内部人员想作弊,采用什么方式都可能存在作弊

 

 五、优点

 1、能提前10年预订都没有问题,只要铁道部和旅客愿意。将来的目标发展为:个人旅行管理系统
 2、前台轻量,爱怎样扩展就怎样扩展
   3、后台爱怎样处理都行,而且可以很容易监控,有异常还可以人工偷偷处理一下,用户根本感觉不到
 4、实际上这样一套系统上线,在家中买票,要坐车再去取票就可以了。不够铁道部的关系人少了点代理收入。

 

六、@诺贝尔的启发,完善系统如下:


 1、前台部分:
     PC端:由前台预订系统、身证验证子系统、网银子系统、防止入侵子系统、业务监控系统
   智能手机:修改适合手机特点的预订系统
    (前台预计系统很简单,就一般的小公司都没做再来的那一种,就是往数据库里增加记录,不验证不看余票等规则)
 2、后台部分

  订票确权服务器(是否有预计资格)、车票分配服务器、取票通知服务器、业务监控系统、资源管理和分配规则管理系统等组成

 3、结算部分

   另开发结算管理系统,处理帐务、退钱、退票等

 

   经以上分析,结论:用Asp.net+SQL2008 就可以轻松实现。特别是后台,用C#.net 开发绝对是优势。

 

 

posted on 2012-01-12 03:47 新悟空 阅读(5081) 评论(102) 编辑 收藏
Comments
  • #3楼[楼主]
    新悟空      
    Posted @ 2012-01-12 11:02
    有时思路不正确,软件做死了也搞不好真的。 所以做软件架构师,思维导图和个人知识管理是必须的。此文放在主页,让大家讨论一下:软件开发中的“思路决定出路”的重要性  回复 引用 查看   
  • 自由用户      
    Posted @ 2012-01-12 11:13
    这个您是做完了还是这么想想?  回复 引用 查看   
  • kiler      
    Posted @ 2012-01-12 11:13
    2核的一秒就可以处理1000张票以上。

    这牛皮吹的,国人的做软件的态度决定了了质量肯定好不了。
     回复 引用 查看   
  • 上不了岸的鱼      
    Posted @ 2012-01-12 11:17
    没有经过实践,还是不要这么轻易下结论为好  回复 引用 查看   
  • lindping      
    Posted @ 2012-01-12 11:25
    但是 预订仅限于购买一种票的情况,实际的情况是很多人买票都不会限于只买某一个车次一个时间点的票,通常是择优选择,比如先挑硬卧,没有的话硬座也凑合,如果是站票呢,就比较犹豫了。车次呢,优先是高铁,然后是特快,普快。。等等。所以,如果要实现先预订,再取票,前提可能需要用户预先录入这些购买的优先规则,铁路网站按照该用户定义的规则给他排票。
    再有一个是预订的期限,如果没有日期限制,什么时候预订都有可以的话,那么很多人都会上去先预订一个座位了,到年底真正需要回家的人估计就不好买票了,如果设置一个时间段开放订票,那么大家伙都在这个时间一拥而上,网站该崩溃还是会崩溃,跟现在买票也没有什么区别。
     回复 引用 查看   
  • #8楼[楼主]
    新悟空      
    Posted @ 2012-01-12 11:26
    @assiwe
    晕,例你在12月1日预计12月20日的票,12月10日的运输资源和分配规则出来后,你就可以知道有没有票了。
     回复 引用 查看   
  • #9楼[楼主]
    新悟空      
    Posted @ 2012-01-12 11:27
    @kiler
    请大家注意,是预订;分配票是由后台多台的服务器在哪慢慢处理的,不是即时交易的那一种
    引用kiler:
    2核的一秒就可以处理1000张票以上。

    这牛皮吹的,国人的做软件的态度决定了了质量肯定好不了。
     回复 引用 查看   
  • #10楼[楼主]
    新悟空      
    Posted @ 2012-01-12 11:29
    采用预订就付费的原则。
    如果退订,不好意思,你的信用,你的优先级就会下降。

    大家看的,新的玩法,多有意思。至少比抢票有意思、有创新吧。
    【那么很多人都会上去先预订一个座位了,到年底真正需要回家的人估计就不好买票了】
     回复 引用 查看   
  • #11楼[楼主]
    新悟空      
    Posted @ 2012-01-12 11:32
    再说明一下,票的数量是一定的,总有人订不到。
    说明采用预订+分配的原则,就可以方便照顾到学生、民工兄弟等
    【那么很多人都会上去先预订一个座位了,到年底真正需要回家的人估计就不好买票了】
     回复 引用 查看   
  • doun      
    Posted @ 2012-01-12 11:52
    思路很不错啊,只是业务可能要好好想想  回复 引用 查看   
  • #13楼[楼主]
    新悟空      
    Posted @ 2012-01-12 12:01
    本文就大概一个思路,让大家骂铁道部时,也提出自己好的建议。
    现有的订票方案,1)是即时的,需要很多很多计算资源;搞得订票过程耗时2)技术难度大:如余票查询、数量扣除锁等,都有很大的架构难度。而新的火车新订票系统,将计算资源分离,没有大的技术难度问题。
     回复 引用 查看   
  • pulihe      
    Posted @ 2012-01-12 12:03
    博主这个思维太简单了
    连硬件选型和网络流量计算都没谈就直接说能搞定
    大型架构时硬件和软件是要同时考虑的
    细节太多了
    io满载、队列满载、dns如何处理、是轮询还是集群、数据库集群处理方式,带宽如何并行拓展。。。
    你知道当流量峰值连续超过150MB时瓶颈在哪里么?
    真做过了印象才深刻,绝不是1+1+1这样搞下去的。
     回复 引用 查看   
  • Goodspeed      
    Posted @ 2012-01-12 12:10
    先不说你什么架构,你这个产品思路更有问题。

    钱付了还不一定有票。你真更坑爹。
     回复 引用 查看   
  • sweethome      
    Posted @ 2012-01-12 12:24
    业务就设计得有问题, 真是没资格跟人说技术细节实现了.  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-12 12:28
    先弄明白现有的订票方案问题在哪,1)是即时的,需要很多很多计算资源;搞得订票过程耗时2)技术难度大:如余票查询、数量扣除锁等,都有很大的架构难度。

    不是带宽、不是硬件、是人、是人的思想问题
    引用pulihe:
    博主这个思维太简单了
    连硬件选型和网络流量计算都没谈就直接说能搞定
    大型架构时硬件和软件是要同时考虑的
    细节太多了
    io满载、队列满载、dns如何处理、是轮询还是集群、数据库集群处理方式,带宽如何并行拓展。。。
    你知道当流量峰值连续超过150MB时瓶颈在哪里么?
    真做过了印象才深刻,绝不是1+1+1这样搞下去的。
     回复 引用 查看   
  • arg      
    Posted @ 2012-01-12 12:29
    根本就没看到这烂系统的烂处。烂系统就烂在访问量和并发处理上。
    你这种等啊等的到时候还不知道有票没。同样大家会各种手段争取预订名额。最终还是要处理访问量和并发的问题,逃不掉的。人类已经有很多成熟的解决方案,人家不愿意用,你有什么办法。
     回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-12 12:31
    没有票时会退给你!
    预订系统会自动根据你预订设定的参数,
    这一真趟不行,下一趟。真没满足要求的,退钱。

    我就明白了,要是没票了,你有钱有什么用啊。
    还要白白浪费很多时间在哪查询查询查询啊。
    国民时间真不值钱啊!
    引用Goodspeed:
    先不说你什么架构,你这个产品思路更有问题。

    钱付了还不一定有票。你真更坑爹。
     回复 引用 查看   
  • 阳光沙滩海岸线      
    Posted @ 2012-01-12 12:38
    如果那么简单,架构师就不值钱了。  回复 引用 查看   
  • #21楼[楼主]
    新悟空      
    Posted @ 2012-01-12 12:41
    ×××××
    并行访问根本就不是问题,问题在于单个用户的处理时间过长,造成用户在网站“同一资源过程”停留的过长造成的雪崩效应问题。
    ×××××
    先弄明白现有的订票方案问题在哪,1)是即时的,需要很多很多计算资源;搞得订票过程耗时2)技术难度大:如余票查询、数量扣除锁等,都有很大的架构难度。
    引用arg:
    根本就没看到这烂系统的烂处。烂系统就烂在访问量和并发处理上。
    你这种等啊等的到时候还不知道有票没。同样大家会各种手段争取预订名额。最终还是要处理访问量和并发的问题,逃不掉的。人类已经有很多成熟的解决方案,人家不愿意用,你有什么办法。
     回复 引用 查看   
  • 诺贝尔      
    Posted @ 2012-01-12 12:42
    我认为改进的方法可以这样:
    1.建立手机等端系统
    2.建立身份验证系统
    3.一个身份一张票,一张票一份钱,如果有上面两个其实已经是水到渠成的事情了。
    4.登录预订
    5.通知付款(网站通知你,不是你在不停刷啊刷)
    6.成功交易

    瓶颈在那里?第一个是客户登录,一下子数千万人登录,服务器会垮掉?实际不会,现在的技术应对这个问题很轻松的。
    问题在于不能保证流程的逐步通过,不断的循环流程,结果1000万人,就1两个人处理完毕,大部分人都在刷新。
    所以解决瓶颈的方法就是尽快把用户赶走,减少服务的人数,保证当前服务对象可以不被系统稳定等问题干扰。

    设想如下:
    数千万人同时登录,服务器遇到流量瓶颈,服务器开启保护功能,直接断开新用户的链接尝试。这个和百度的原理差不多,你老是刷新百度,他就直接把你屏蔽几分钟,这样保证他系统正常负荷。
    假设有一百万人顺利进入系统,并且是很稳定的状态,客户登录系统,记录身份信息,电话号码,什么车次,等等细节。
    之后就退出系统。
    网站可以接待其他客人。
    假设用一天时间记录了5000千万个预订信息,实际座位只有一千万,那么当前系统已经是0人访问,因为大家预订了,不需要访问,这时候根据预订情况系统通知客户来登录,进行付款等耗时操作。
    系统的负荷,都在可控范围。

    只要由网站控制负荷,别说几千万,就算是几十亿人预订我觉得都没有什么问题,就是时间问题罢了。
     回复 引用 查看   
  • 农村的芬芳      
    Posted @ 2012-01-12 12:47
    是一种新思路

    当然肯定有很多没考虑周到地方

    但不能说不是一新思路

    肯定
     回复 引用 查看   
  • #24楼[楼主]
    新悟空      
    Posted @ 2012-01-12 12:52
    @诺贝尔
    赞成!经你的启发,完善系统如下:
    1、前台部分:
     PC端:由前台预订系统、身证验证子系统、网银子系统、防止入侵子系统、业务监控系统
     智能手机:修改适合手机特点的预订系统

    2、后台部分

     订票确权服务器(是否有预计资格)、车票分配服务器、取票通知服务器、业务监控系统、资源管理和分配规则管理系统等组成

    3、结算部分

     另开发结算管理系统,处理帐务、退钱、退票等
     回复 引用 查看   
  • Sinitic      
    Posted @ 2012-01-12 13:09
    关键我是消费者,你不能剥夺我选择产品的权利。  回复 引用 查看   
  • 诺贝尔      
    Posted @ 2012-01-12 13:12
    1.如果网站一登录就崩溃,那么怎么解决都没戏。这个只能提升硬件,让硬件可以过滤掉当前不能处理掉的客户。
    2.那么剩下来的都是有效客户(虽然大部分客户会显示网站忙,但是有效客户是可以正常访问的),如何缩短他们的停留时间就是关键。如果他们停留一个小时,那么一天就只能处理24趟客户流,这个效率是无法保证售出几千万的车票的。
    因此,首先分发好客户端(包括有异步能力的网页),内容包括什么用户资料输入,订票情况,这些都是离线操作,登录提交只需要一键提交,也就是1秒钟。如果提交失败,客户端自动延长不等长时间段(非用户控制),防止提交集中化。
    不管有票没票,都是后面的事情,用户只需要等待通知。
    如果车票只有1000万,但是访客5000万,1000万后面提交的信息都是没有什么用处的,可以返回预订完毕等信息,让客户端不再提交。
    系统可以专心致志处理自己能处理的1000万客户,当然这个也要有相应的硬件支持,你不可能用100万处理能力的硬件,通过流程优化变得能处理1000万。流程优化只是屏蔽掉无效的和进行时刻优化分配而已。
     回复 引用 查看   
  • 诺贝尔      
    Posted @ 2012-01-12 13:18
    不知道现在12306一天能出多少张票。  回复 引用 查看   
  • #28楼[楼主]
    新悟空      
    Posted @ 2012-01-12 13:23
    @诺贝尔

    1.如果网站一登录就崩溃,那么怎么解决都没戏。
     ==前台轻量化,就不存在用户登录问题;即单台服务器可处理的用户数增加一个数量级
     ==用户很快处理完就不会操作,等通知就好了
     或搞个长连接的Ajax有通知,就告诉用户了
    2、如果车票只有1000万,但是访客5000万
     ==使用预订参数,例我要从福州--》宁波东
      日期:2012-02-12
      时间:9:00 ~ 13:00
    满足这些规则的,都可以成功预订,
      而且,越宽松,得票的概率越大。
      就不用重复提交、查询了,浪费了多少国民生产力啊。
      只能说:国民的时间,还真的不值钱,
      所以那些有钱人除了有钱坐得起飞机外,
       一个原因就是不想浪费时间在各个环节

     ××××
     一个国家,啥时开始考虑为国民节省时间,
     那才真的是进步啊!
     回复 引用 查看   
  • zsea      
    Posted @ 2012-01-12 13:36
    这个方案简直是胡闹,  回复 引用 查看   
  • 火星大能猫      
    Posted @ 2012-01-12 13:37
    订了没底的事情,谁敢定??还是找黄牛买票放心店.  回复 引用 查看   
  • 易元      
    Posted @ 2012-01-12 13:41
    看不懂,不过楼主很嚣张,估计技术很NB?  回复 引用 查看   
  • #32楼[楼主]
    新悟空      
    Posted @ 2012-01-12 13:43
    @火星大能猫
    是提前预订,不是提前10天那一种,可以提前30天以上。
    如果运输资源一再来,过几分钟再通知你结果,不用即时告诉你结果。

    不要停留在“抢票”的心态来考虑问题。
     回复 引用 查看   
  • ★金★      
    Posted @ 2012-01-12 13:54
    这个思路很好,其实一些视频网站也是这样做的,先上传视频,然后系统生成flash。预订后,服务器处理要快很多。  回复 引用 查看   
  • ★金★      
    Posted @ 2012-01-12 13:56
    淘宝的技术实力应该不错吧,可是在光棍节一样挂机。
    思路决定一切。
     回复 引用 查看   
  • 烤地瓜      
    Posted @ 2012-01-12 13:57
    这几天我也在关注这个事,正好上来说两句,我比较认同楼主的设计方向。但具体实施的确没有楼主想的那么容易。
    3亿旅客往返,6亿张火车票。但这只是小头,大头是哪每日10亿次的访问率。现在的网站是每日10亿次主动操作做为整个网站的驱动。而我比较赞同楼主的观点,采用预定的方式,既以6亿份订单作为驱动远胜于现在的每日10亿次。
    顾客提交购买意向,条件区间,交定金,火车站取票。这是最理想化的流程,但是需要一系列非常严谨的游戏规则,同时对算法的要求是很高的。算法必须保证每一个参与者,在一个最大周期内,比如十天内一定能拿到票。否则,就不会有人和你玩。所以还需要必要的预测分析程序,用他来决定全国各条线路,那一条需要追加临时列车。
    我想现在的12306也一定层考虑过这样做,只是时间上来不及。网站如果按这个思路建设,项目时间是很难保障的。所以我们还是期待明年吧。

    我在补充一点,以6六亿张订单作为驱动,此时对用户最有价值的就不在是车票,而是“机会”。从这个角度讲,预订的意向可以提前几个月便提交,即使没有票,也可以告知你目前的名次,估算拿到票的时间点。铁道部则可以根据这些数据调整年末的运力安排。换句话说,先将老百姓想去的地方搜集全,画一个地图,然后再根据这个地图去安排运力。
     回复 引用 查看   
  • iRead      
    Posted @ 2012-01-12 14:03
    说的好简单!!!
    建议你搞一个网站,然后来个几百万的并发量。看你的服务器能承受得了不!!
     回复 引用 查看   
  • 烤地瓜      
    Posted @ 2012-01-12 14:09
    @阳光沙滩海岸线
    架构师解决不了全国人民买票难的问题。这个问题是产品经理负责的。不过中国很多程序员,眼里的极限就是架构师了。
     回复 引用 查看   
  • ksmy      
    Posted @ 2012-01-12 14:27
    我只想说说的简单。  回复 引用 查看   
  • 注册表      
    Posted @ 2012-01-12 14:35
    难道大家不是普遍认为,预定就有票?
    中国有句古话说的好:
    1、长痛不如短痛。2、有多大希望就有多大失望
    这种订票方式绝对坑爹,不透明,谁知道你后台怎么处理的
    谁知道是不是偷偷卖给黄牛了。作为一名消费者,预定10天都没有
    票,谁会接受?还不是直接没票,我还可以作别的打算。
    总之,程序开发的目标是简化人们的生活,而不是让人更加麻烦。
    程序制作应回归于与人类生活的紧密结合,而不是打乱
     回复 引用 查看   
  • 海蓓娜楽      
    Posted @ 2012-01-12 14:35
    TMD12306是必须要骂的...,还要狠狠的骂......

    但LZ只停留在理论上,具体的没有这么简单吧
     回复 引用 查看   
  • #41楼[楼主]
    新悟空      
    Posted @ 2012-01-12 14:39
      再说一次,不是访问量的问题,是用户停留在网站的同一资源过程过长造成的,如查余票、抢票等。
     国内应该有很多很多的公司,可以搞上千万访问的系统,关键是前台架构要轻,加一台服务器就能一下子解决很多人访问。

     而不是200个在A服务器上卡死了。
     
     想像一下网站的问题是CPU、内存、I/O资源还有数据库的锁!!!
     (数据库事务、业务的ACID等归结为锁的问题)

    引用iRead:
    说的好简单!!!
    建议你搞一个网站,然后来个几百万的并发量。看你的服务器能承受得了不!!
     回复 引用 查看   
  • Muse      
    Posted @ 2012-01-12 14:48
    搞那么复杂!
    一个车次一台双路8核128G内存的服务器,一条100M光纤,我就不信能崩溃!

    这东西软硬结合,连带宽都不够,还谈什么性能不性能的呢?
     回复 引用 查看   
  • 陈梓瀚(vczh)      
    Posted @ 2012-01-12 14:52
    其实所有的问题,只要12306有“充值”功能就好办了。先把钱冲进去,然后选择购票,然后就可以离开了。如果两个小时或者多久的时间内票没有了导致你失败,那就发短信告知。买到了也可以发短信告知。如果实在没票,反正钱还在12306里面,还能用来下次买。这样每个人只需要登陆一次就可以知道结果,不需要在那里不停地刷啊刷啊,根本不会造成一天10亿的局面——尼玛一天怎么会有10亿个人去买票呢?  回复 引用 查看   
  • 风中独火      
    Posted @ 2012-01-12 14:55
    果然是没有什么实际经验的建议啊.
    用ASP.NET还是JAVA根本不是问题的关键.
    问题的关键是如何应付海量实时访问和查询,以及相关的锁定关系.

    这里最大的问题就是锁定关系.因为车票是所有数据的核心,所有的请求都在争抢这个资源.只有把这个资源处理好了.才可能谈其他的问题.

    不知道铁道部这个方面是怎么解决的,各种选择都是有难度的.用数据库,一定是有更新的锁定和互斥的问题.
    用cache又要考虑系统崩溃的问题.
     回复 引用 查看   
  • #45楼[楼主]
    新悟空      
    Posted @ 2012-01-12 14:56
    前台架构要轻,将更多的计算资源放在后台“迟后”进行。
    用这种思路重新改造一下系统,也能解决现在的问题。
    思路不一样,很多东西就会变得不一样的。

    有时候,我们真的是想复杂了。
     回复 引用 查看   
  • iGrfx      
    Posted @ 2012-01-12 15:01
    根本问题就是只有一张票,但是现在要10个人去抢,你怎么设计都没法解决这个问题.  回复 引用 查看   
  • #47楼[楼主]
    新悟空      
    Posted @ 2012-01-12 15:03
    @风中独火
    已经说过了,预订方案不存在海量数据问题,不检查余票、不作其它规则验证。就一件事:Add 一条记录。
    这会有海量数据问题??
    --多数人为何老停留在既有的海量数据,
    是不是那样才能体现技术能力。

    将更多的数据处理,放在后台迟后处理。
     回复 引用 查看   
  • #48楼[楼主]
    新悟空      
    Posted @ 2012-01-12 15:06
    就是这个意思,更进一步的是可以提前N天预订,作为出行管理。这样后台有足够的时间来处理订单,对就是”接订单后处理“的思路,不是什么淘宝商量抢购的思路。

    引用陈梓瀚(vczh):其实所有的问题,只要12306有“充值”功能就好办了。先把钱冲进去,然后选择购票,然后就可以离开了。如果两个小时或者多久的时间内票没有了导致你失败,那就发短信告知。买到了也可以发短信告知。如果实在没票,反正钱还在12306里面,还能用来下次买。这样每个人只需要登陆一次就可以知道结果,不需要在那里不停地刷啊刷啊,根本不会造成一天10亿的局面——尼玛一天怎么会有10亿个人去买票呢?
     回复 引用 查看   
  • 陈梓瀚(vczh)      
    Posted @ 2012-01-12 15:08
    @风中独火
    您觉得这世界上资源紧缺人人都要但是却运行的井然有序的商品是什么——摇号买车牌啊!多好的机制啊(从系统稳定性角度上来说)……
     回复 引用 查看   
  • #50楼[楼主]
    新悟空      
    Posted @ 2012-01-12 15:12
    所以要加入分配的优先级规则,照顾学生、民工兄弟等
    身份认证方式还是可以从职业、个税、工商系统等获取的。

    然后再加上出行目的限制(可以从人的户口信息、历史出行记录中分析),就能更大程度上实现公平。如春节期间,优先满足回家,商务次之,旅游其次等

    引用iGrfx:根本问题就是只有一张票,但是现在要10个人去抢,你怎么设计都没法解决这个问题.
     回复 引用 查看   
  • 調皮↙不搗蛋      
    Posted @ 2012-01-12 15:28
    与其找楼主这个方法给别人操控生死,还不如自己去刷可信.你这方法明显存在很大的制度漏洞,谁tm知道铁道部那帮人把票都给谁了啊!  回复 引用 查看   
  • Dai.Hanzhang      
    Posted @ 2012-01-12 15:36
    成不成先不行,想法的确不错。  回复 引用 查看   
  • Brush      
    Posted @ 2012-01-12 16:15
    楼主提供的方案,从技术角度上没有问题,确实能避免“海量并发”情况,最关键的是“游戏规则”定制和实施问题,如何分配票源?

    如果继续是先订先得的话,一样会导致大家一窝蜂地集中订票,业务上处理这样的并发并无太大问题,但这样做无疑是另外一种“秒杀”模式。

    如果在上面规则上加上某类人优先的话,规则的定制就会比较复杂,而且最重要的是人们不大会买帐,还不如先订先得的规则。

    另外,个人觉得是否分配到票的结果,可以在12小时内给出答案(比如符合提前10天内买票的约定)
     回复 引用 查看   
  • 张志敏      
    Posted @ 2012-01-12 16:26
    按照楼主说的, 架构设计好了, 用户体验增加了, 车票瞬间被抢光了, 那不是要骂的人更多?
    人多票少才是根本问题。
     回复 引用 查看   
  • doun      
    Posted @ 2012-01-12 16:39
    还有一些人没法上网订票,怎么办?  回复 引用 查看   
  • ulee      
    Posted @ 2012-01-12 16:42
    真这样的话,代购火车票的中介机构将会增加很多,黄牛也合法化了  回复 引用 查看   
  • 陈梓瀚(vczh)      
    Posted @ 2012-01-12 16:45
    @ulee
    现在的火车票都有身份证号码了,不一样的。
     回复 引用 查看   
  • ulee      
    Posted @ 2012-01-12 16:54
    中介就说,你给身份证,我保证能订到票,这样的话很多人还是会"被"选择的,毕竟人多票少的情况下,大家都会想办法去"抢"那个名额.这样间接造福了黄牛...  回复 引用 查看   
  • wanax      
    Posted @ 2012-01-12 17:08
    中国很多公司不是号称都是先进的云公司的吗?怎么不说话了这时候。  回复 引用 查看   
  • 发奋图强II      
    Posted @ 2012-01-12 17:11
    楼主的思路大大降低了服务器负载,提高用户体验。
    以前有个很不错的订票网站“华铁在线”就是这么做的,后来被和谐了。
     回复 引用 查看   
  • pulihe      
    Posted @ 2012-01-12 17:39
    @风中独火
    引用风中独火:
    果然是没有什么实际经验的建议啊.
    用ASP.NET还是JAVA根本不是问题的关键.
    问题的关键是如何应付海量实时访问和查询,以及相关的锁定关系.

    这里最大的问题就是锁定关系.因为车票是所有数据的核心,所有的请求都在争抢这个资源.只有把这个资源处理好了.才可能谈其他的问题.

    不知道铁道部这个方面是怎么解决的,各种选择都是有难度的.用数据库,一定是有更新的锁定和互斥的问题.
    用cache又要考虑系统崩溃的问题.

    说得对,而且铁路票务的锁机制逻辑还比较曲折。
    不过铁道部称1/3票务投入网络购票,所以这个票锁还是要轻很多的。
    就我自己的服务器而言,每月总有几天要跑到150mb/s;至少用上面大部分人的建议都是不适合。
    谈海量访问我认为单单谈软件架构是不行的。
     回复 引用 查看   
  • 程序诗人      
    Posted @ 2012-01-12 17:49
    流量都放在那里 技术纯属扯淡 硬件配置或者分布式才好解决  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-12 17:57
    没有谈技术啊,只谈改为预订的解决方案,而不是目前的抢票方案。

    引用程序诗人:流量都放在那里 技术纯属扯淡 硬件配置或者分布式才好解决
     回复 引用 查看   
  • 深邃的狮子座      
    Posted @ 2012-01-12 18:01
    其实我觉得,最好铁道部把权利下放,比如:腾讯,网易啊,等等,让他们去搞。肯定没问题。  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-12 18:10
    @深邃的狮子座

    不好! 术有专攻的原则。
    如果腾讯,网易 接单下来,那就只能是创业公司。
    不可能选择和自己主营无关的东西,
    阶段铁道部开放销售提成,有长期收入模式,倒还有可能。
    不能还是让给专业公司长久做好。
     回复 引用 查看   
  • 北斗清合      
    Posted @ 2012-01-12 18:26
    在下不敢苟同,你没有从根本上解决问题。  回复 引用 查看   
  • ocean      
    Posted @ 2012-01-12 18:50
    这个实际上是解决并发业务大的一种思路,即并行化改为串行化。也即服务器只接受最基本的请求,然后将这个请求直接压到队列中,而后台服务器则从队列中一个一个的读取来处理,当处理完毕后主动通知用户。

    我们有一个系统是客户查询报表,对于复杂报表来说,很多要十多分钟,有的报表甚至要1个小时才能计算完毕,这时我们就是使用MSMQ,先将用户的请求压到MSMQ队列里面,然后后面服务器慢慢处理,处理完毕后邮件通知客户报表已经生成,可以查看了。如果并行处理,多一些用户提交报表请求,同时几个报表一起计算,那么每个报表的生成时间将大大加长,如果用户因为没有生成出来而不断重复提交大报表生成请求,则会直接加重服务器压力导致服务器挂掉。

    这实际上是个很常规的思路。

    只是具体的处理上不是这么简单,也不仅仅是这么一个并行化转串行化处理就能解决的。还需要考虑其他因素。但是对于大规模的并发来说,并行化转串行化处理是有效的一种方式。再配合强悍的硬件、负载均衡等,完全可以承受当前的票,实际上大家真的想想,每天一共发送多少人次?实际上真正的交易票数一天也就几百万张,几百万笔交易真的不算很大,问题就在于这种同步处理方式导致服务器卡死,进而大家疯狂刷新页面而造成的,那10亿次访问都是虚的,真正的用户能有1000万就不错了,每个人都贡献了 几百次甚至上千次点击。
     回复 引用 查看   
  • 狼Robot      
    Posted @ 2012-01-12 19:06
    给了钱不见票、车次选择权被剥夺、还商务次之旅游其次,都同样是给钱买票坐车,凭什么就要分三六九等?提升了用户体验吗,不觉得!真要按这个方案做,估计骂的人会更多吧。  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-12 19:13
    @ocean
    又学习了一个知识点了。
    太好了,博客园就是需要这个更多的有益讨论,让每个说出自己的想法来,就可以不断完善自己的认识,从而提高架构、设计水平等。
    @dudu (这个@功能,老大能收到吗?)
     回复 引用 查看   
  • 铃兰草      
    Posted @ 2012-01-12 19:26
    在供需缺口大量存在的社会现实之下,你何以能判断客户怎么安排行程?
    给了钱还未必能订到票,你就这么信任政府部门?
    大量资金存放铁道部门,谁来监管?实质上已经是第三方支付性质,银监会能pass吗?
    考虑解决方案要基于社会现实
     回复 引用 查看   
  • #71楼[楼主]
    新悟空      
    Posted @ 2012-01-12 19:38
    @铃兰草
    铁付通有限公司,估计已经成立了吧。

    反正我是非常非常铁道部成立这样的公司,
    每次为买票浪费不少时间。
    虽然不值钱,也可以做不少事
     回复 引用 查看   
  • 无色      
    Posted @ 2012-01-12 20:19
    Asp.net+SQL2008?

    我想你的买票系统,一定是在现在有窗口买票系统的数据库上开发的,而不是你想用什么数据库就用什么数据库。

    基本上排除了sql2008,估计用的是db2或oracle。
    Asp.net运行的windows 2008用在商业系统上很难保证不被黑客利用漏洞,基本上排除了

    这个系统一定要保证不能影响窗口买票系统,所以不能满负何的跑。

    另外学过数据库的都知道,卖火车票系统都采用严格的数据库锁,可以不卖,但绝对不能把一张票卖给两个人,这个比普通web程序要求高得多。

    首先第一条就是保证程序在多并发下事务处理完全正确,如何出现错误售票,后果很严重。

    第 二条就是保证程序正确,可以让用户等待。

    第三条必需使用现有的数据库系统,并保证窗口卖票的速度和安全。
     回复 引用 查看   
  • 用情      
    Posted @ 2012-01-12 20:58
    我觉得这至少是一个思路。
    如果能有一个公开透明的排队算法,让每个人都能清楚的知道自己现在的位置,什么时候能轮到我大家心里有数。如果还怕有问题,可以过后公布分配明细。

    这样做的另一个问题是大家要能尽早的确定自己的行程,以后可能要提前通知放假时间了。
     回复 引用 查看   
  • 深海沉      
    Posted @ 2012-01-12 21:28
    首先 LZ这种异步的处理思路是不错的,但是有必要让用户知道或者是提醒他:他前面有多少人已经预订了,如果他排队的号数已经超出了运力,则提醒他订其它车次。  回复 引用 查看   
  • Caspar Jiong      
    Posted @ 2012-01-12 21:31
    在LZ的思路上提两点:
    1. 有人提到黄牛的问题,我觉得可以通过完全电子化来解决,进站直接刷身份证,车上配一个车位查询的显示屏,如果车票需要报销,出站时可以通过智能终端或窗口获取票据凭证
    2. 建议加入团体票预订功能,不然假如我陪女朋友回她家,我订到票了她没订到,你那不坑爹嘛

    关于并发的问题,国内云计算不是吹得天花乱坠的嘛,这不正是大显身手的时候!
     回复 引用 查看   
  • xiaowy      
    Posted @ 2012-01-12 23:01
    不错,LZ在码农之上很久了!  回复 引用 查看   
  • #77楼[楼主]
    新悟空      
    Posted @ 2012-01-12 23:29
    是为了解决票有限的情况下,如春节时,如何更公平一些的做法啊。
    春节是一特殊的节日,优先满足回家的人们,应该没错吧。

    不够,有说话权的都是有钱人、商人等,估计这个和他们个人利益不符合的事是不会做的。
    引用狼Robot:给了钱不见票、车次选择权被剥夺、还商务次之旅游其次,都同样是给钱买票坐车,凭什么就要分三六九等?提升了用户体验吗,不觉得!真要按这个方案做,估计骂的人会更多吧。
     回复 引用 查看   
  • 早起的菜鸟      
    Posted @ 2012-01-12 23:33
    把api开放,给第三方做 不就行了 做的不知道多好  回复 引用 查看   
  • 新的开始      
    Posted @ 2012-01-13 00:18
    其实最关键的一点,还是铁道部拥有自己的支付平台,先充值,只有金额足够的情况下才允许订票,没排上队的就把金额打回账户。这样就避免了用户卡在下订单与支付这两步上,而使其他用户不能登录  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-13 00:32
    @新的开始
    一起期望这样的系统,最后也肯定会是这样的
     回复 引用 查看   
  • 新的开始      
    Posted @ 2012-01-13 09:19
    想了一晚上,按我在80楼的方法,尽量缩短订票与支付之间的时间差,提高订票速度,应该是可以解决订票时出现的一系列问题。不过对于疯狂刷新显示余票的行为,貌似是没有什么好方法了,因为现在的实际情况就是人多票少,而且大家期望的车次和乘车时间肯定会出现冲突的情况,这就会导致查余票的时候如果发现没票,就会产生“如果有人退票”的侥幸心理,结果就是大家继续刷票,解决这一点可能就只有从系统架构和硬件设备上下手了。  回复 引用 查看   
  • § 薄樱 §      
    Posted @ 2012-01-13 09:26
    我对火车票不感兴趣。我对你的思路很感兴趣。c#开发网站确实很快,只要思路和业务清晰。。。ps:为啥你的blog出现横向滚动条了?  回复 引用 查看   
  • 遗忘海岸      
    Posted @ 2012-01-13 13:41
    最好是分阶段进行售票  回复 引用 查看   
  • ilj      
    Posted @ 2012-01-13 13:49
    .net不适合这种大流量的东西。  回复 引用 查看   
  • ilj      
    Posted @ 2012-01-13 13:51
    每天2亿人次的访问量甚至会更高,那么设计应该考虑这个的,不仅仅是应用层面的。  回复 引用 查看   
  • 晓鹰      
    Posted @ 2012-01-13 14:36
    看了这么多评论,主要还是集中在系统机制上。有网站、窗口、电话3个系统,如何同步是个问题,估计CDN是考虑这个问题的,虽然效果没有得到认同。
    把票额放在起点站或者线路多的站,即在路局下再分子服务器,这样方便查询和汇总,和窗口、电话等系统数据一致。
    LZ的转串行化是个不错的思路,nodejs就是这样提高吞吐量的。在不大规模增加服务器集群的要求下,就只能优化流程,从减少点击量上下手。还有猜LZ说用SqlServer2008,估计指的是R2新增的stream insight
     回复 引用 查看   
  • LanceZhang      
    Posted @ 2012-01-13 14:48
    写的真乱!  回复 引用 查看   
  • 秋色      
    Posted @ 2012-01-13 15:16
    @ilj
    现在的每天访问量是10亿次。
     回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-13 15:30
    1、次数越多,说明浪费的国民时间越多
    2、流量真的是最最最基本的技术问题
    3、10亿次的网站,国内多的是。
    4、10亿次还浪费了多少纳税人的、互联网带宽啊?
     真正有本事的是,用0.1亿次就完成订票这事

    引用秋色:
    @ilj
    现在的每天访问量是10亿次。
     回复 引用 查看   
  • 落叶潇潇雨      
    Posted @ 2012-01-13 16:24
    技术的架构只是其中一个原因,中国的很多问题不是技术层面的,而是体制层面的。如果铁道部不是垄断,如果有更多的资本参与铁路建设,如果票这种资源是足够的,谁去抢票啊,票资源充足的话可以随到随走,订什么票?反之在中国这种体制,这种票资源不够的情况下,你这种架构怎么做到将有效的资源公平或合理的分配呢,就算有算法在后台处理了几天,然后告诉你没订成功或不是你想要的,你怎么办呢,订其他车,该其他交通工具,都是麻烦。所以天朝的问题归根结底在体制,体制不改一切都是屁话。(大家都是做程序的,相信不少人做的系统里面为领导留了什么特殊的操作,这点大家都懂的...)  回复 引用 查看   
  • 烤地瓜      
    Posted @ 2012-01-13 17:09
    @落叶潇潇雨
    当年在推行资源国有化时就说过,资源集中的优势是对资源的充分利用,哪时候中国是个各种资源匮乏的国家。但现在来看,别的可能搞开放竞争,铁路估计开放了也没人参与。投资太大了,资源有限。最主要是空间上,谁也不想看到家门口并排十条铁轨吧。
     回复 引用 查看   
  • xluo      
    Posted @ 2012-01-13 17:22
    楼主你他吗的个SB
    铁道部系统如果不卡 2分钟所有的票就全部没有了
    你还买个毛
    问题在于票不够 列车不够
    而不是系统买票慢
    系统再快 1天100W个票
    卖完了去买什么 请问
    不管系统怎么垃圾 100W一天的票可以卖完就可以
     回复 引用 查看   
  • 刑天      
    Posted @ 2012-01-13 17:26
    这个话题越扯越远了,现在谈论的是如何在现有体制下解决这个问题,我认为有2点很重要,一个是要简化和方便订票的流程,尽量减少用户在网站上的操作时间。另一个是要开放一个接口,提供给各个大型门户网站调用,来在此接口下分担主站的压力。这才是最可行的办法。  回复 引用 查看   
  • ryanding      
    Posted @ 2012-01-13 20:33
    可惜,那网站是Java做的。  回复 引用 查看   
  • gotolnc      
    Posted @ 2012-01-13 21:33
    参考机票销售处理,根本就不做前端网站,只做数据中心,开放接口引用代理网站,一切ok。  回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-13 23:07
    停留在“窗口售票的实时”错误思维中,通过网络个人自主购票,真不用实时处理。例:明天我出从A到B,我提交某个时段最理想的出行时间,注意,我根本就不关注什么车次问题,只需要返回给我哪个时间段,有没有票卖给我。现在的自动售票机的操作流程至少还可以减少一半的操作时间,且提搞高易用性  回复 引用 查看   
  • 落叶潇潇雨      
    Posted @ 2012-01-16 11:29
    @烤地瓜
    中国的确有私人资本参与铁路,但是中国的行政就是这审批那审批,审批了很多年,就是不下来,结果不了了之,更多的人是担心没有制度上的保障,资本进去了,却没有相应的收益,而且制度也没放开。这与当今中国为什么那么多将资本转移到国外是同样的道理,因为在国内这是没有制度保障的。
     回复 引用 查看   
  • 土豆天天      
    Posted @ 2012-01-16 14:24
    真是蛋疼的设计,给了钱还不知道有没有票,而且还不知道是哪天有。

    好好去看看淘宝聚划算的的架构设计吧。秒杀的订单是怎么样的架构和流程。
     回复 引用 查看   
  • 韩梦芫      
    Posted @ 2012-01-17 16:33
    哎呀 真不好说啊  回复 引用 查看   
  • 無悠      
    Posted @ 2012-01-18 13:33
    真是蛋疼的设计啊
    铁道要是真按你这个都设计开发,估计就给人拆了。
    只能希望你公司现在不要让你做业务分析类,害人啊。
    后台分配你也真敢说啊,有本事我为你今年分配你过年的车次试下。
    你直接将责任完全的划到铁道部,几亿人的责任他能扛不。
    别人做的系统至少能说过去,只是登陆、订票、付款,这个运行不行而已。
    最多只能骂骂。
    按你的设计做了,估计你明年就出不了门了.
     回复 引用 查看   
  • 个人知识管理      
    Posted @ 2012-01-18 16:18
    @無悠
    请问在票有限的情况下,如何解决民工的回家问题?

    民工只能靠排队,上网买票较难

    抢票就是最合理的?
    至少目前这种情况下,SH主义比ZB主义的好处在哪里啊? 我没看到。
     回复 引用 查看   
  • 無悠      
    Posted @ 2012-01-19 09:18
    像你这样的有什么好说的啊,再二也比不过你这样的,
    民工,你还比上不,他要回家,其他人就不回了是不,
    就你这样剥夺别人的权限,就你家是人,就你优先是不。
    你自己才该快点回家好好去建设自己的家乡,这样就不用出来抢票了
     回复 引用 查看   
评论共2页: 上一页 1 2