|
锁定老帖子 主题：讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-05
最后修改：2012-01-05
廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 |
| 返回顶楼 | |
|
发表时间：2012-01-05
ahyyxx222 写道 所谓码农 写道 按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手： 1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。 2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。 3.缓存所有车票信息，提高查询的响应时间 实际高峰期是刚出票的那个时间点，那几分钟内每秒有几十万点击不奇怪，类似于秒杀。 排队系统也不完善，排入队内的那次点击应该是选好了票和填完了身份信息，然后点下单的那次请求，这次请求将被排入队内，但由于下单成功后现在有45分钟的时间支付，这段时间内这张票状态是锁定的，所以，实际上队伍前进一批人基本要等上45分钟，所以他拿到排队名次并无多大实际意义，因为45分钟后队里有些人已经不在线了，不可能排上队的都分一张剩余的票。 当然如果不能连续承受几十万每秒的登陆和查询请求，那根本就到不了下单的页面。 电话订票也丝毫没有好处，接电话那头的人也一样在使用一个类似的订票系统，那系统没崩掉的原因只不过是接电话的人有限，那些人又不会连续点击。实际状况和现在的用户忙差不多，变成了你电话打不进去。 如果你幸运的成为了网站上没出现用户忙，而挤进去的那个人，那你也在线订上了 和我的想法差不多，加上排队队列，最好加上一个通知系统，通过短信或者语音电话来通知已经可以购买票了（铁老大再霸道一点的话，可以强制自己去刷新页面查看），还可以把这个模块做成一个单独的系统！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
肯定有办法解决的，就看那些有没有去想，有没有去出那个钱做，为与不为！
|
| 返回顶楼 | |
|
发表时间：2012-01-05
aws 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 根据我坐火车的经历貌似没有"如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了" 这个情况 有人在南京下了，那这个位置就空了，在路上的谁抢到谁坐，火车站是不会再卖的了 |
| 返回顶楼 | |
|
发表时间：2012-01-05
有高并发架构或者调优经验再说话，连个tomcat都用不好，还乱叫！tomcat并非1000杠杠的！人不行就不要怪路不平！
|
| 返回顶楼 | |
|
发表时间：2012-01-05
hu437 写道 aws 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 根据我坐火车的经历貌似没有"如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了" 这个情况 有人在南京下了，那这个位置就空了，在路上的谁抢到谁坐，火车站是不会再卖的了 那不过是你没遇到过中途上车罢了 |
| 返回顶楼 | |
|
发表时间：2012-01-05
hu437 写道 aws 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 根据我坐火车的经历貌似没有"如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了" 这个情况 有人在南京下了，那这个位置就空了，在路上的谁抢到谁坐，火车站是不会再卖的了 这个你out了，你说的是以前的情况，现在真的是分段重复卖一个座号的 |
| 返回顶楼 | |
|
发表时间：2012-01-05
不论铁道部花了多少钱，到程序员手里面的还不是一个月几千块。
能做成这个德行，已经不容易了。这样的压力下，居然还是有人订到票了，系统很健壮嘛。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
redouble 写道 不论铁道部花了多少钱，到程序员手里面的还不是一个月几千块。
能做成这个德行，已经不容易了。这样的压力下，居然还是有人订到票了，系统很健壮嘛。 这位仁兄说的很是对呀...... 就那一点的工资做成这样很不错了... |
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
hu437 写道 aws 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 不行的，火车票不是商品，单纯论个数的 简单的说比如 仅有一张从上海到北京的票，如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了 而铁路的线路图，算可以出的票和余票比这个例子要复杂至少几百个维度 而且这些都是实时的，还有各种事务和事务补偿问题 对数据的读和写的操作比你这个设想要复杂的多 根据我坐火车的经历貌似没有"如果有人买了从上海到南京，那么接下来就只剩下从南京到北京的可以买了" 这个情况 有人在南京下了，那这个位置就空了，在路上的谁抢到谁坐，火车站是不会再卖的了 我就有过经历，有次坐火车我的座就是刚有人下车腾出来的。 也碰到过好多拿着票对号找座的，那些座也好多是别人刚下车。 |
| 返回顶楼 | |
