33,008
社区成员
发帖
与我相关
我的任务
分享给铁路订票系统支招
1.优化方向
1)用空间换时间 2）特殊线路特殊处理 3）合理的有损服务
详细的说就是我们要用一些冗余的存储，来减少查询的过程，从而达到加速的目的。火车票的线路非常多，但是我们不能一概而论，要区分对待，对于一些热门线路要做特殊的处理，只要把这些热门线路优化好，系统的吞吐和稳定性都会上来。订票系统的准确性和安全性肯定是非常重要的。但是我们仍然有可以提供有损服务的空间。比如余票的张数可以有一定的误差，这样就可以不需要完全的实时同步，通过多个镜像库来减缓系统的压力。比如一个票还剩50张和48张，对用户来说没有区别。但是还剩1张和已经没有票，这个就有了本质的区别，会导致购票失败，所以可以有预留，比如有些线路还有10张，就显示没有票了，只有在数据库同步的一瞬间有买入的，可以通过预留票给用户。
详见 http://blog.csdn.net/xiaomps_search/article/details/8006470
1)用空间换时间 2）特殊线路特殊处理 3）合理的有损服务
详细的说就是我们要用一些冗余的存储，来减少查询的过程，从而达到加速的目的。火车票的线路非常多，但是我们不能一概而论，要区分对待，对于一些热门线路要做特殊的处理，只要把这些热门线路优化好，系统的吞吐和稳定性都会上来。订票系统的准确性和安全性肯定是非常重要的。但是我们仍然有可以提供有损服务的空间。比如余票的张数可以有一定的误差，这样就可以不需要完全的实时同步，通过多个镜像库来减缓系统的压力。比如一个票还剩50张和48张，对用户来说没有区别。但是还剩1张和已经没有票，这个就有了本质的区别，会导致购票失败，所以可以有预留，比如有些线路还有10张，就显示没有票了，只有在数据库同步的一瞬间有买入的，可以通过预留票给用户。
详见 http://blog.csdn.net/xiaomps_search/article/details/8006470
...全文
请发表友善的回复…
发表回复
showjim 2012-10-11
- 打赏
- 举报
[Quote=引用 22 楼 的回复:]
之前爆出的新闻说12306用的就是数据库...而且SQL语句还是where ..like..这样的简单语句，那是假新闻？？？
[/Quote]
应该是真的吧，我还能说什么呢^-^
之前爆出的新闻说12306用的就是数据库...而且SQL语句还是where ..like..这样的简单语句，那是假新闻？？？
[/Quote]
应该是真的吧，我还能说什么呢^-^
q503959 2012-10-07
- 打赏
- 举报
之前爆出的新闻说12306用的就是数据库...而且SQL语句还是where ..like..这样的简单语句，那是假新闻？？？ [Quote=引用 4 楼 sbwwkmyd 的回复:]
像这样的应用根本就不应该访问数据库，纯内存访问+多机日志队列，一般人都想得到的。
我相信12306的人应该不会菜到直接用数据库来处理请求。
[/Quote]
像这样的应用根本就不应该访问数据库，纯内存访问+多机日志队列，一般人都想得到的。
我相信12306的人应该不会菜到直接用数据库来处理请求。
[/Quote]
tkminigame 2012-09-25
- 打赏
- 举报
需求并不复杂，就是一段时间并发比较大，最根本的解决之道是避免并发
1.分流
2.排队
3.票务流程数据cache到内存，前端可实现无阻塞查询
4.铁道部的渣渣们，给哥一百万，哥帮做了。多剩下的钱返给全国人民当福利
1.分流
2.排队
3.票务流程数据cache到内存，前端可实现无阻塞查询
4.铁道部的渣渣们，给哥一百万，哥帮做了。多剩下的钱返给全国人民当福利
bacmoz 2012-09-25
- 打赏
- 举报
核心问题是如何保证用户查到的车票数额是实时的
所以必须简化查询到有票之后的操作，购票张数，身份证号，席位类型都可以在查询之前输入，甚至可以保存
根据这些信息查询出来的结果至少可以认为在那一瞬间是正确的，只要迅速点击购买，就能锁定相应的票额
服务器不是问题
所以必须简化查询到有票之后的操作，购票张数，身份证号，席位类型都可以在查询之前输入，甚至可以保存
根据这些信息查询出来的结果至少可以认为在那一瞬间是正确的，只要迅速点击购买，就能锁定相应的票额
服务器不是问题
bacmoz 2012-09-25
- 打赏
- 举报
提前输入身份证，银行卡等信息，并且事先对银行卡进行虚拟支付验证，就像快捷支付一样
购票时一键购买，一旦点击购买，用户不再干预，如购买时已无票，则返回失败，否则锁定所购买的车票，转为自动支付过程，如支付失败，则释放车票
购票时一键购买，一旦点击购买，用户不再干预，如购买时已无票，则返回失败，否则锁定所购买的车票，转为自动支付过程，如支付失败，则释放车票
showjim 2012-09-24
- 打赏
- 举报
[Quote=引用 13 楼 的回复:]
大家有兴趣可以看看云风的blog，有一篇是说这个问题的。
电子商务要比大家想象的复杂。具体细节我就不多说了，因为我说的也没有云风说得好。
只是大家要注意一个问题：就是放票的一瞬间，峰值压力太大。
[/Quote]
如果12306有自己的充值系统，不依赖银行接口，商务流也不会有太大问题。
大家有兴趣可以看看云风的blog，有一篇是说这个问题的。
电子商务要比大家想象的复杂。具体细节我就不多说了，因为我说的也没有云风说得好。
只是大家要注意一个问题：就是放票的一瞬间，峰值压力太大。
[/Quote]
如果12306有自己的充值系统，不依赖银行接口，商务流也不会有太大问题。
zara 2012-09-24
- 打赏
- 举报
分流哎，最起码那些中短途的段内车次的售票，下放到各自段的网站就是了。甚至跨段的也可以根据一定的规则进行下放。以前不就有段网站网上售票的吗，南京火车站的网站就做过吧。
不过，这个下放，好像太天真了不是？！
不过，这个下放，好像太天真了不是？！
haorengoodman 2012-09-24
- 打赏
- 举报
再建一个12306++，铁道部只管售票。那个系统好，那个系统买票快，那个系统服务好，我们就用哪个。
总结:引入竞争。
总结:引入竞争。
flyoversky 2012-09-24
- 打赏
- 举报
应该推倒重新设计开发
云淡风清-北京 2012-09-24
- 打赏
- 举报
最好的方法是再多开点列车，这样不用上12306想坐车直接去火车站就行
天下第一好大人 2012-09-24
- 打赏
- 举报
大家有兴趣可以看看云风的blog，有一篇是说这个问题的。
电子商务要比大家想象的复杂。具体细节我就不多说了，因为我说的也没有云风说得好。
只是大家要注意一个问题：就是放票的一瞬间，峰值压力太大。
电子商务要比大家想象的复杂。具体细节我就不多说了，因为我说的也没有云风说得好。
只是大家要注意一个问题：就是放票的一瞬间，峰值压力太大。
Quebradawill 2012-09-24
- 打赏
- 举报
票少人多，高峰时进不去。
showjim 2012-09-23
- 打赏
- 举报
最主要的问题其实是没有票可以卖
showjim 2012-09-23
- 打赏
- 举报
我认为12306的问题在于放票机制与购票流程，应该不是技术性能问题。
showjim 2012-09-23
- 打赏
- 举报
我只是在技术层面分析12306的状况，至于购票难的问题我认为主要的问题不是技术问题。
共享数据修改可以不用锁？不知道你用什么东西保证数据的有效性。
共享数据修改可以不用锁？不知道你用什么东西保证数据的有效性。
xiaomps_search 2012-09-23
- 打赏
- 举报
http://v.163.com/zixun/V5HPA8RLS/V8AVTTHNA.html 新闻说是扛不住了。当然不能用锁，用锁肯定会影响速度的。
showjim 2012-09-23
- 打赏
- 举报
内存访问+日志队列，怎么还有同步更新问题呢？有同步问题，也只是内存锁问题。
说系统繁忙并没有意味着服务器没抗住，应该仅仅是一种出票策略。真要没抗住，那就是服务不可用或者崩溃了。
说系统繁忙并没有意味着服务器没抗住，应该仅仅是一种出票策略。真要没抗住，那就是服务不可用或者崩溃了。
xiaomps_search 2012-09-23
- 打赏
- 举报
不是铁道部的人，不知道他们为什么没有撑住，总是说系统繁忙，要排队。有更好的想法希望多多指教。
xiaomps_search 2012-09-23
- 打赏
- 举报
肯定不是直接去访问通用的数据库，要自己设计数据存储方式。内存访问，多机这个方向是很容易的。最主要的是数据的同步更新，负载均衡，还有对访问频率高的数据的特殊处理。只有这些细节都能够做好，才能保证系统的高性能。系统要做好是很多细节的点积累在一起达到的。
showjim 2012-09-23
- 打赏
- 举报
像这样的应用根本就不应该访问数据库，纯内存访问+多机日志队列，一般人都想得到的。
我相信12306的人应该不会菜到直接用数据库来处理请求。
我相信12306的人应该不会菜到直接用数据库来处理请求。
加载更多回复（3）
