|
锁定老帖子 主题：讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-05
zeeeitch 写道 所谓码农 写道 zeeeitch 写道 所谓码农 写道 .使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”
这个很好做吗，你想过没有？ 假设10万人被堵在外面，在排队，每个人刷总数，数据库条件：“我前面”的，你知道10万人，每秒点击一次要多少台服务器才能扛住？ 每秒10万次点击，查询我前面有xxxx位，每台服务器1000次/秒，就要100台了 每个人5秒点击一次，好2万次/秒，20台服务器 没人要你去查数据库，前面有多少位是取队列的总数。 5秒点击一次？你是刷票还是买票？ 设服务器1000次/秒，如果前面有10万人，如果使用一台服务器，那么你等10秒即可处理。 异步排队的目的在于，避免用户不断的刷新。 前面有多少人，也要数据库的，还得保存sessionid，一天下来也有百八十万条了 不用数据库怎么搞？ KEY/VALUE一样，百千万条数据，效率比数据库能高几个数量级？ 你需要知道的是前面有多少人，并不关心别人买了什么票。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
把这个系统外包给淘宝做算了
|
| 返回顶楼 | |
|
发表时间：2012-01-05
zeeeitch 写道 hipx 写道 啥架构不架构的，民航的订票是跑在单台过亿的大型机上，春运时候还是非常紧张，铁路起码比民航高一个数量级，这么短时间根本不可能构建出可靠的系统，系统五年能完善算是有效率，看评论大家都喜欢喷啊
同感，应该欢迎铁道部这样的举措，首要好处就是打击黄牛，不劳而获的鸟人 5年。。。 还不如优先解决运力问题。 运力够的话，谁还来秒杀啊 |
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
所谓码农 写道 你需要知道的是前面有多少人，并不关心别人买了什么票。 说的就是前面有多少人，看似简单。大量人进入这个查询页，把这个页搞垮了，后面怎么办 现在这种“服务忙，请稍后再试”，就是最小负荷的方法 |
| 返回顶楼 | |
|
发表时间：2012-01-05
zmcsut 写道 5年。。。 还不如优先解决运力问题。 运力够的话，谁还来秒杀啊 同意，运力！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 每秒7W次太夸张了，楼上说有测试过，不知什么环境 至少在我映像中：最简单的页面处理一下select，几万元的服务器只能跑1000次/秒 |
| 返回顶楼 | |
|
发表时间：2012-01-05
mamingyaoqian 写道 zeeeitch 写道 所谓码农 写道 .使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”
这个很好做吗，你想过没有？ 假设10万人被堵在外面，在排队，每个人刷总数，数据库条件：“我前面”的，你知道10万人，每秒点击一次要多少台服务器才能扛住？ 每秒10万次点击，查询我前面有xxxx位，每台服务器1000次/秒，就要100台了 每个人5秒点击一次，好2万次/秒，20台服务器 铁道部有钱的，兄弟。现在网上订票手续费5元，代售点买票5元，其他不说，光赚代理费都要上亿把。哎。。 这位兄弟说的很对，性能如果单一的靠程序是没有办法解决的，主要还是要硬件的支持，全国够买火车票的人数有多少，在一个省的人数就已经很多了，部署几百台服务器不浪费的！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
zeeeitch 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 每秒7W次太夸张了，楼上说有测试过，不知什么环境 至少在我映像中：最简单的页面处理一下select，几万元的服务器只能跑1000次/秒 你采用的select,我没有猜错的话是数据库访问机制吧，如果你采用内存机制呢！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
廖明华 写道 这位兄弟说的很对，性能如果单一的靠程序是没有办法解决的，主要还是要硬件的支持，全国够买火车票的人数有多少，在一个省的人数就已经很多了，部署几百台服务器不浪费的！ 上服务器当然是对的，只是说前面朋友，简单撂下一句话，排队。应该多考虑，任何简单的方式实现细节，如最简单的排队 |
| 返回顶楼 | |
