老男孩linux培训 发表于 2012-01-17 16:19 static/image/common/back.gif
这个思路非常的新颖，赞！
其实这个问题出问题的时候，我和几个朋友探讨过。
不过还真没登陆过！
很中肯
gotolinux 发表于 2012-01-17 17:01 static/image/common/back.gif
nosql还是不用的好，我认为这东西目前还不成熟，用的多的也就那几家科技公司。
nosql也有大型故障的示例， ...
对于实时性或许可以满足,但是对于数据一致性的实现...
本帖最后由 sania9 于 2012-01-17 17:44 编辑
亿级别的架构确实要考虑的太多，从编码规范到前端缓存、db压力，甚至带宽等等。
不过这会的优化可以先从业务流程上面走，分段放票什么的，造成“秒杀”型的压力，无形中自己创造了很多个高峰。
既然是实名制，业务流程可以这样（大意）：注册后提前1个月（或更长时间）提交行程信息，针对席位、日期分批多次抽取中签，并降低退票者的中签概率，分散购票高峰。
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显
个人觉得没必要在一个机房,一组服务器来承担全国的量
让每个铁路局负责自己站点的票? 用户数据都是从统一的数据源的一份拷贝
就比如运营商各个地方都有分站,办理业务只用上对应的分站,而不是一个portal
而且数据查询还是可以优化的,并不是每次点击查询都要去数据库
现在最突出的是查到了有票,但是提交不进去,因为全国的写操作都对一个库在操作
可想而知了
回复 19# yahoon
其实访问量最大的就是发票前后的那几个小时。
yahoon 发表于 2012-01-17 17:46 static/image/common/back.gif
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显
个 ...
数据库的操作应该是一个主数据库多个从数据库，读写分离的方式。
yahoon 发表于 2012-01-17 17:26 static/image/common/back.gif
并发值，10亿/3600/24=0.00011570亿，
这算得真没道理...
访问的高峰低谷都不分
这只是一个提供理论值而矣:)
另 关于投入的问题, 仅仅为了应付有限的几个热点时间段,就采购大量的服务器和带宽放在那,确实是有点浪费资源和带宽.
大家有啥想法,平时出租计算资源给啥统计局或者气象局之类的? 哈哈
yahoon 发表于 2012-01-17 17:46 static/image/common/back.gif
此业务的地域特征(北上广,加上几个大的中转站), 高峰时间段(每年也就那么几个节日), 实时要求特征明显
个 ...
数据库要改的N多，最主要的不能是总直接查询库，要有缓存；读写还得分离，库、表的设计也要跟行上，字段、值都是很大的，不知道有没有专业的人搞过。
谁把那个库的数据来展示一下:wink:
yuhongchun 发表于 2012-01-17 17:52 static/image/common/back.gif
这只是一个提供理论值而矣
我觉得最高并发是远高于这个数的 至少从24点到7点半之前,感觉访问的量不会特别大的