|
锁定老帖子 主题：讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-05
最后修改：2012-01-05
廖明华 写道 你采用的select,我没有猜错的话是数据库访问机制吧，如果你采用内存机制呢！ 内存的没用过，我就不发言了，如果内存数据库真有7W，那就非常应该上内存的了，希望楼上的环境和测试结果在这样的高并发应用中确实有效。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
zeeeitch 写道 廖明华 写道 你采用的select,我没有猜错的话是数据库访问机制吧，如果你采用内存机制呢！ 内存的没用过，我就不发言了，如果内存数据库真有7W，那就非常应该上内存的了，希望楼上的环境和测试结果在这样的高并发应用中确实有效。 在中国移动的项目中，采用过内存数据库方式，对本地数据库的操作和内存数据库的操作，差距真的太大了，你可以试试！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
自从有了这个系统，票贩子以后需要和程序员进行紧密合作了
|
| 返回顶楼 | |
|
发表时间：2012-01-05
这个网站、很多时候都打不开吧。。还好我今年不需要订票
|
| 返回顶楼 | |
|
发表时间：2012-01-05
估计可以有专业程序员做黄牛了
|
| 返回顶楼 | |
|
发表时间：2012-01-05
订到两次卧铺，其中一次买到了，另一次取消了
|
| 返回顶楼 | |
|
发表时间：2012-01-05
所谓码农 写道 mamingyaoqian 写道 大家讨论前是否搞清楚需求啊，我这在讲解下，理解错误地方请指出：
昨天看到官方信息（至于几号的不清楚） 说12306注册用户800万。你们讨论的是不是人数太多了。根据实际情况推算下人数可以这样定位：全国人口用14亿做基数。 1，除去短途和不需要流动的我把14亿除以2可以把？ 14/2=7 2，回家交通工具多样化现在除了火车汽车飞机轮船都是有的把，当然火车占大多数(7层) 7*0.7=4.9 3，现在人会上网的挺多，网上订票的貌似并不很多。 4.9/2=2.5 4，还有即使网购存在一个帐号购买多个的情况 2.5*0.8=2 5，其他购票途径的存在2/2=1 6，其他没想到因素+上面全是保守估算 1/2 = 5000万 小弟懂的少，只是把了解的估算了下，系统哪里要涉及到上亿的用户啊，前期设计到5000万就可以满足把。当然架构成熟了奔到上亿就可以了。 还有成本问题，铁路局娜段铁路不是上亿甚至几十亿啊，做个网站不用替他考虑钱，他有的你们懂的！ 个人见解求喷！ 这些数据还是比较靠谱 +1，事已至此，节哀。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
廖明华 写道 zeeeitch 写道 廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 每秒7W次太夸张了，楼上说有测试过，不知什么环境 至少在我映像中：最简单的页面处理一下select，几万元的服务器只能跑1000次/秒 你采用的select,我没有猜错的话是数据库访问机制吧，如果你采用内存机制呢！ 缓存 + 负载均衡 还是比较靠谱的。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
seanla 写道 其实不用铁道部自己做这个订票系统，直接交给淘宝做好了，不用花钱淘宝都愿意做；或者找电商门户来做
马云说：可以做，但是支付 必需用支付宝。。。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
廖明华 写道 采用内存数据库，将火车票的信息，采用文件存储，系统启动加载初始化文件，也可以通过web实现，将其最新的数据提交，按照高峰期每一天的最大数据量，提交到内存数据库（这个可以扩大，可以存放1亿等数据），每隔一段时间对内存数据进行过滤，进行异步存储，将已经卖出的票得信息进行数据迁移，同时在提交一部分新的火车票信息（可以考虑火车票预警信息方式）。在满足数据更新的同时，还能够保证在线用户数据的需求。购票者在进行购票的同时，对内存数据库的操作，速度会非常的快，每秒7W次并发应该是没有任何问题的，这个已经测试过。
尽量在数据交互的中间环节，采用队列方式，可以缓存部分数据，采用异步交互的方式，可以缓解数据并发量大的问题。个人意见！ 这个想法不现实，数据库早就设计好了的，而且也不只网上订票这一个系统用 |
| 返回顶楼 | |
