分库分表跟不分库分表，整个架构是完全不一样的。像铁票的售票系统、淘宝、电信、银行等，绝对要采用分库分表的数据存储方案， 来解决数据量的增长而不影响性能的问题。

是为了解决票有限的情况下，如春节时，如何更公平一些的做法啊。
春节是一特殊的节日，优先满足回家的人们，应该没错吧。
不够，有说话权的都是有钱人、商人等，估计这个和他们个人利益不符合的事是不会做的。

引用

狼Robot：给了钱不见票、车次选择权被剥夺、还商务次之旅游其次，都同样是给钱买票坐车，凭什么就要分三六九等？提升了用户体验吗，不觉得！真要按这个方案做，估计骂的人会更多吧。

@铃兰草
铁付通有限公司，估计已经成立了吧。
反正我是非常非常铁道部成立这样的公司，
每次为买票浪费不少时间。
虽然不值钱，也可以做不少事

所以要加入分配的优先级规则，照顾学生、民工兄弟等
身份认证方式还是可以从职业、个税、工商系统等获取的。
然后再加上出行目的限制（可以从人的户口信息、历史出行记录中分析），就能更大程度上实现公平。如春节期间，优先满足回家，商务次之，旅游其次等

引用

iGrfx：根本问题就是只有一张票,但是现在要10个人去抢,你怎么设计都没法解决这个问题.

就是这个意思，更进一步的是可以提前N天预订，作为出行管理。这样后台有足够的时间来处理订单，对就是”接订单后处理“的思路，不是什么淘宝商量抢购的思路。

引用

陈梓瀚(vczh)：其实所有的问题，只要12306有“充值”功能就好办了。先把钱冲进去，然后选择购票，然后就可以离开了。如果两个小时或者多久的时间内票没有了导致你失败，那就发短信告知。买到了也可以发短信告知。如果实在没票，反正钱还在12306里面，还能用来下次买。这样每个人只需要登陆一次就可以知道结果，不需要在那里不停地刷啊刷啊，根本不会造成一天10亿的局面——尼玛一天怎么会有10亿个人去买票呢？

@风中独火
已经说过了，预订方案不存在海量数据问题，不检查余票、不作其它规则验证。就一件事：Add 一条记录。
这会有海量数据问题？？
--多数人为何老停留在既有的海量数据，
是不是那样才能体现技术能力。
将更多的数据处理，放在后台迟后处理。

前台架构要轻，将更多的计算资源放在后台“迟后”进行。
用这种思路重新改造一下系统，也能解决现在的问题。
思路不一样，很多东西就会变得不一样的。
有时候，我们真的是想复杂了。

　　再说一次，不是访问量的问题，是用户停留在网站的同一资源过程过长造成的，如查余票、抢票等。
　国内应该有很多很多的公司，可以搞上千万访问的系统，关键是前台架构要轻，加一台服务器就能一下子解决很多人访问。
　而不是200个在A服务器上卡死了。
　
　想像一下网站的问题是CPU、内存、I/O资源还有数据库的锁！！！
　（数据库事务、业务的ACID等归结为锁的问题）

引用

iRead：
说的好简单！！！
建议你搞一个网站，然后来个几百万的并发量。看你的服务器能承受得了不！！

@火星大能猫
是提前预订，不是提前１０天那一种，可以提前３０天以上。
如果运输资源一再来，过几分钟再通知你结果，不用即时告诉你结果。
不要停留在“抢票”的心态来考虑问题。

得起飞机外，
　　　一个原因就是不想浪费时间在各个环节
　××××
　一个国家，啥时开始考虑为国民节省时间，
　那才真的是进步啊！...

@诺贝尔
赞成！经你的启发，完善系统如下：
１、前台部分：
　PC端：由前台预订系统、身证验证子系统、网银子系统、防止入侵子系统、业务监控系统
　智能手机：修改适合手机特点的预订系统
２、后台部分
　订票确权服务器（是否有预计资格）、车票分配服务器、取票通知服务器、业务监控系统、资源管理和分配规则管理系统等组成
３、结算部分
　另开发结算管理系统，处理帐务、退钱、退票等

多成熟的解决方案，人家不愿意用，你有什么办法。”...

本文就大概一个思路，让大家骂铁道部时，也提出自己好的建议。
现有的订票方案，１）是即时的，需要很多很多计算资源；搞得订票过程耗时２）技术难度大：如余票查询、数量扣除锁等，都有很大的架构难度。而新的火车新订票系统，将计算资源分离，没有大的技术难度问题。

可以通过下述网址下载：1、博客园下载http://files.cnblogs.com/pinpkm/PinPkm.rar2、本地下载http://www.pinpkm.com/pinpkm.rar 3...

再说明一下，票的数量是一定的，总有人订不到。
说明采用预订+分配的原则，就可以方便照顾到学生、民工兄弟等
【那么很多人都会上去先预订一个座位了，到年底真正需要回家的人估计就不好买票了】

采用预订就付费的原则。
如果退订，不好意思，你的信用，你的优先级就会下降。
大家看的，新的玩法，多有意思。至少比抢票有意思、有创新吧。
【那么很多人都会上去先预订一个座位了，到年底真正需要回家的人估计就不好买票了】

@kiler
请大家注意，是预订；分配票是由后台多台的服务器在哪慢慢处理的，不是即时交易的那一种

引用

kiler：
２核的一秒就可以处理1000张票以上。
这牛皮吹的，国人的做软件的态度决定了了质量肯定好不了。

@assiwe
晕，例你在１２月１日预计１２月２０日的票，１２月１０日的运输资源和分配规则出来后，你就可以知道有没有票了。

有时思路不正确，软件做死了也搞不好真的。　所以做软件架构师，思维导图和个人知识管理是必须的。此文放在主页，让大家讨论一下：软件开发中的“思路决定出路”的重要性

不知是我想简单了，还是专家们想复杂了。　铁道部的专家还停留在线下售票方案中拨不出来；　线上售票系统简单得多了。　骂完铁道部后，提供一简单又可行的解决方案。 查询余票、防止超售、防止黄牛，一般的...

一种解决 VS2010 自带的Asp.net Web 服务器 WebDev.Webserver4 ，可以用任意IP地址访问的方法，可方便用于支付宝接口本机调试或作简单的Web 服务器使用。附近源代码供...

现象：在开发asp.net自定义控件，在测试项目拖动控件进提示，无效的FORMATETC 结构 分析：之前已经将此自定义控件部署到GAC区，估计只认到GAC区的DLL，没有认到当前新生成的DLL 解...

近期在网上流传的用友致远“佣金门”，很大程度上可以说明软件的价值所在。一、软件是好东西，但同时容易为别人留下证据 用友致远“佣金门”的资料来自于自身的O...

“博客园的后台”不能删除文件的解决方法吗?点删除有反应，实际上没有删除 。

以过桥算法来谈如何满足客户的需求和程序设计步骤 如果答案只停留在解决题目的表面，而不能抽象出此类问题，是不及格的。正如，开发应用型软件，应站在行业的高度和全局去思考，而不仅仅是解决局部的问题。所以实际的项目中，应有架构师来统领全局，看得更多更远一些。一、需求四个女人过桥，夜间有一火把，每次最多过两...

选择数据库产品和应用规模、客户对象、运行环境等息息相关；下面总结了几条，可以适当开发多数应用型的软件作参考。请大家一起来完善要考虑的事项，让更多的人减少走弯路。一、开发方面1、数据库连接和并发2、数据库的指标：数据库文件大小限制、表的记录量限制、支持的数据类型、支持的SQL语句、不支持的SQL语句3...