如何设计高并发高流量的12306在线票务系统

yahoon

老男孩linux培训 发表于 2012-01-17 16:19
这个思路非常的新颖，赞！
其实这个问题出问题的时候，我和几个朋友探讨过。
不过还真没登陆过！

很中肯

yahoon

gotolinux 发表于 2012-01-17 17:01
nosql还是不用的好，我认为这东西目前还不成熟，用的多的也就那几家科技公司。
nosql也有大型故障的示例， ...

对于实时性或许可以满足,但是对于数据一致性的实现...

sania9

亿级别的架构确实要考虑的太多，从编码规范到前端缓存、db压力，甚至带宽等等。
不过这会的优化可以先从业务流程上面走，分段放票什么的，造成“秒杀”型的压力，无形中自己创造了很多个高峰。
既然是实名制，业务流程可以这样（大意）：注册后提前1个月（或更长时间）提交行程信息，针对席位、日期分批多次抽取中签，并降低退票者的中签概率，分散购票高峰。
            

yahoon

此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显

个人觉得没必要在一个机房,一组服务器来承担全国的量
让每个铁路局负责自己站点的票? 用户数据都是从统一的数据源的一份拷贝

就比如运营商各个地方都有分站,办理业务只用上对应的分站,而不是一个portal

而且数据查询还是可以优化的,并不是每次点击查询都要去数据库
现在最突出的是查到了有票,但是提交不进去,因为全国的写操作都对一个库在操作
可想而知了

gotolinux

回复 19# yahoon


    其实访问量最大的就是发票前后的那几个小时。

gotolinux

yahoon 发表于 2012-01-17 17:46
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显

个 ...

数据库的操作应该是一个主数据库多个从数据库，读写分离的方式。

yuhongchun

yahoon 发表于 2012-01-17 17:26
并发值，10亿/3600/24=0.00011570亿，
这算得真没道理...
访问的高峰低谷都不分

这只是一个提供理论值而矣

yahoon

另 关于投入的问题, 仅仅为了应付有限的几个热点时间段,就采购大量的服务器和带宽放在那,确实是有点浪费资源和带宽.

大家有啥想法,平时出租计算资源给啥统计局或者气象局之类的? 哈哈

Gray1982

yahoon 发表于 2012-01-17 17:46
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显

个 ...

数据库要改的N多，最主要的不能是总直接查询库，要有缓存；读写还得分离，库、表的设计也要跟行上，字段、值都是很大的，不知道有没有专业的人搞过。
谁把那个库的数据来展示一下:wink:

yahoon

yuhongchun 发表于 2012-01-17 17:52
这只是一个提供理论值而矣

我觉得最高并发是远高于这个数的 至少从24点到7点半之前,感觉访问的量不会特别大的