|
锁定老帖子 主题：讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-05
san皮 写道 hu437 写道 aws 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 根据我坐火车的经历貌似没有"如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了" 这个情况 有人在南京下了，那这个位置就空了，在路上的谁抢到谁坐，火车站是不会再卖的了 我就有过经历，有次坐火车我的座就是刚有人下车腾出来的。 也碰到过好多拿着票对号找座的，那些座也好多是别人刚下车。 这个是算法问题 |
| 返回顶楼 | |
|
发表时间：2012-01-05
zeeeitch 写道 mamingyaoqian 写道 zeeeitch 写道 所谓码农 写道 .使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”
这个很好做吗，你想过没有？ 假设10万人被堵在外面，在排队，每个人刷总数，数据库条件：“我前面”的，你知道10万人，每秒点击一次要多少台服务器才能扛住？ 每秒10万次点击，查询我前面有xxxx位，每台服务器1000次/秒，就要100台了 每个人5秒点击一次，好2万次/秒，20台服务器 铁道部有钱的，兄弟。现在网上订票手续费5元，代售点买票5元，其他不说，光赚代理费都要上亿把。哎。。 讲的是设计，光有钱上服务器就行了？服务器多了就省事了？ 服务器间协调就复杂了 有的人一讲设计就信口开河了 这个我要解释下，技术是必须的，我肯定不是讲光上服务器就行了。但是，服务器多了可以减轻技术压力，这个是肯定的。据说12306连集群都没舍得做，即使技术再牛硬件跟不上也搞不起来啊。 “服务器多了就省事了？”服务器间协调就复杂了” 这个我有点不认同，说的对就听听，说错了，多批评。我认为设计好的前提下，多增加服务器并不会增加复杂度。很简单你把系统设计成蜘蛛网的话就是服务器越多就越复杂，但是你要是设计成树型的也会复杂吗？比如现在一棵树（12306）系统特别慢，压力特别大，如果我复制2个系统出来，多种2棵树。 构成3系统的平台。包含分别只预售G，D，普通车系统，改动上只要增加一个统一的门户，多3个选择。协调上3个系统分别提供原来对应一种的服务。这样做会复杂吗？ 无非多种了2棵树，多的是服务器代码架构上都不会改变什么。当然这样就需要原来3倍的服务器，不过承载能力*3不过分把。 欢迎点评，或许又是信口开合，但是我觉得这样做可以解决很多问题。 嘿嘿，还是那句话，系统设计，技术都很重要，我从来不否认。^-^ |
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
当然这么大的系统，肯定需要服务器群了。可能跑题了，前面是在说“排队页”这个东西，不要随便就撂下，10万人排队也是不好做的
谁能设计设计,多上服务器？ 10万人一直在查询"我前面有多少人"。 首先我们得标识每个浏览器 1 不登录：保存sessionid或者其他能标识浏览器的东西 2 登录，那就用用户ID表示吧 这就是数据端，不管后台用DB还是内存，这个就不能分到多个服务器了，否则查询起来那就又要协调了。 看看查询负荷吧， 1 没有缓存的话，select count(*) from ... where time < mytime and online='t'; 这个也算不小了 2 做了缓存,缓存多久更新,如何更新，缓存数据如何存储等等 看看如何确定人还在线吧,超时判断,多长时间超时；心跳？本来就是为了减少负荷，又引入心跳，这个负担不起啊 人不在线了，update xxx set online='f' where userid='...'; 好吧这一下有Write了，负荷一下就上来了 |
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
yszy 写道 有高并发架构或者调优经验再说话，连个tomcat都用不好，还乱叫！tomcat并非1000杠杠的！人不行就不要怪路不平！
tomcat jboss apache，不做缓存，其实都差不多，纯页面响应也就由CPU来扛了。 做过几个千人系统，简单的一两条insert update的页面，双核服务器100次/秒,cpu就70%了,不敢上了。当然这100次是服务器受到的连续点击数，相当于500-1000人在线了 |
| 返回顶楼 | |
|
发表时间：2012-01-05
查询不需要完全实时
查询和订票可以分开 可以按线路切分 进入订票流程后方考虑一致性 保证支付的有效性 ...... 不知道硬体支撑如何，不过使用友好度可以提升 |
| 返回顶楼 | |
|
发表时间：2012-01-05
放在天津国家级计算机中心天河一号服务器上吧!
|
| 返回顶楼 | |
|
发表时间：2012-01-05
这种架构还用讨论？
支付宝去找个架构师 或者 去聚划算挖个 架构师过来。 轻松应付了。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
hipx 写道 啥架构不架构的，民航的订票是跑在单台过亿的大型机上，春运时候还是非常紧张，铁路起码比民航高一个数量级，这么短时间根本不可能构建出可靠的系统，系统五年能完善算是有效率，看评论大家都喜欢喷啊
深有同感 |
| 返回顶楼 | |
|
发表时间：2012-01-05
Mirima 写道 查询不需要完全实时
查询和订票可以分开 可以按线路切分 进入订票流程后方考虑一致性 保证支付的有效性 ...... 不知道硬体支撑如何，不过使用友好度可以提升 就第一条，你说的就已经是扯淡了 |
| 返回顶楼 | |
|
发表时间：2012-01-05
jokiye 写道 hipx 写道 啥架构不架构的，民航的订票是跑在单台过亿的大型机上，春运时候还是非常紧张，铁路起码比民航高一个数量级，这么短时间根本不可能构建出可靠的系统，系统五年能完善算是有效率，看评论大家都喜欢喷啊
深有同感 应该上超级计算机，股票交易这个数量级应该差不多了吧，没见过有什么问题 |
| 返回顶楼 | |
