|
锁定老帖子 主题：讨论火车票订购网站架构
精华帖 (6) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (5)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-01-05
fackbook的架构师应该最有发言权。
|
| 返回顶楼 | |
|
发表时间：2012-01-05
从用户订票到产生订单应该是一个比较复杂的逻辑。
这个过程可以使用队列，当用户提交订单后，不需要实时产生订单，放入队列中。用户可以实时查看正在提交订单的状态。这样只需要对个人订单状态加行锁，并发压力小了很多。 如果是实时的，这么多用户并发操作肯定不行，只会导致用户体验更差。 个人见解，欢迎讨论。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
所谓码农 写道 aws 写道 所谓码农 写道 按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手： 1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。 2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。 3.缓存所有车票信息，提高查询的响应时间 你这个高峰期的计算逻辑本身就是错的 首先车票12天预售期是在15:00开卖，结果就是你这所谓的12小时出票的访问压力会基本上全部集中在15:00的前5分钟，后最多30分钟以内，特别是在15:00的前后5分钟，真按你的1543个并发去设计系统，那就等死去吧 首先买票的人绝对低于10亿，其次我只是提出一下解决问题的思路，不需要在数据上纠结,1543是理论值，实际上还会有查询、购票者还会不停的刷新，这些都是并发。 另外15：00是可以控制的，在售票方式上应尽量使其均衡，按地区分时段等 关键点来个理论值就一笔带过，理论好歹也得是同一数量级吧。 如果这项目是你来做，估计是一个德行。 这系统，京东不行，淘宝也够劲。铁道部是疯了，全国这么多人，运力还不够，再加上那么多秒杀程序。。。 |
| 返回顶楼 | |
|
发表时间：2012-01-05
我隔壁的同学在网上12306.cn上买到了15号，回湖北的卧铺票
|
| 返回顶楼 | |
|
发表时间：2012-01-05
最后修改：2012-01-05
大家讨论前是否搞清楚需求啊，我这在讲解下，理解错误地方请指出：
昨天看到官方信息（至于几号的不清楚） 说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万就可以满足把。当然架构成熟了奔到上亿就可以了。 还有成本问题，铁路局娜段铁路不是上亿甚至几十亿啊，做个网站不用替他考虑钱，他有的你们懂的！ 个人见解求喷！ |
| 返回顶楼 | |
|
发表时间：2012-01-05
zmcsut 写道 所谓码农 写道 aws 写道 所谓码农 写道 按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手： 1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。 2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。 3.缓存所有车票信息，提高查询的响应时间 你这个高峰期的计算逻辑本身就是错的 首先车票12天预售期是在15:00开卖，结果就是你这所谓的12小时出票的访问压力会基本上全部集中在15:00的前5分钟，后最多30分钟以内，特别是在15:00的前后5分钟，真按你的1543个并发去设计系统，那就等死去吧 首先买票的人绝对低于10亿，其次我只是提出一下解决问题的思路，不需要在数据上纠结,1543是理论值，实际上还会有查询、购票者还会不停的刷新，这些都是并发。 另外15：00是可以控制的，在售票方式上应尽量使其均衡，按地区分时段等 关键点来个理论值就一笔带过，理论好歹也得是同一数量级吧。 如果这项目是你来做，估计是一个德行。 这系统，京东不行，淘宝也够劲。铁道部是疯了，全国这么多人，运力还不够，再加上那么多秒杀程序。。。 就事论事，论人就没啥意义了，品行问题 |
| 返回顶楼 | |
|
发表时间：2012-01-05
所谓码农 写道 zmcsut 写道 所谓码农 写道 aws 写道 所谓码农 写道 按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手： 1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。 2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。 3.缓存所有车票信息，提高查询的响应时间 你这个高峰期的计算逻辑本身就是错的 首先车票12天预售期是在15:00开卖，结果就是你这所谓的12小时出票的访问压力会基本上全部集中在15:00的前5分钟，后最多30分钟以内，特别是在15:00的前后5分钟，真按你的1543个并发去设计系统，那就等死去吧 首先买票的人绝对低于10亿，其次我只是提出一下解决问题的思路，不需要在数据上纠结,1543是理论值，实际上还会有查询、购票者还会不停的刷新，这些都是并发。 另外15：00是可以控制的，在售票方式上应尽量使其均衡，按地区分时段等 关键点来个理论值就一笔带过，理论好歹也得是同一数量级吧。 如果这项目是你来做，估计是一个德行。 这系统，京东不行，淘宝也够劲。铁道部是疯了，全国这么多人，运力还不够，再加上那么多秒杀程序。。。 就事论事，论人就没啥意义了，品行问题 那句话论人呢？ 需求你明确了吗？ 需求你都没能明确就嚷着项目该怎么做，该采用什么什么技术，有用吗？ 铁道部是疯了，你也疯了。 会写秒杀程序的赶紧写吧，否则过几天人工抢票。。。淘宝有几个人工抢到的。。。 |
| 返回顶楼 | |
|
发表时间：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万就可以满足把。当然架构成熟了奔到上亿就可以了。 还有成本问题，铁路局娜段铁路不是上亿甚至几十亿啊，做个网站不用替他考虑钱，他有的你们懂的！ 个人见解求喷！ 这些数据还是比较靠谱 |
| 返回顶楼 | |
|
发表时间：2012-01-05
zmcsut 写道 所谓码农 写道 zmcsut 写道 所谓码农 写道 aws 写道 所谓码农 写道 按10亿人口（当然网络购票绝对不会有10亿人）、售票高峰15天，每天12小时出票来计算，若每次都能购票成功，则每秒的理论并发为1543个（事实上1543的并发完全不需要多余的负载）。但若出现阻塞的情况，就会导致用户不停的刷新，从而导致系统更加繁忙。
要解决这个问题，可以从几个方面下手： 1.使用异步排队的方式(或者AJAX提交，提交完后把页面给锁了，直到服务器响应)，当购票请求提交后提示用户“您正在排队，您前面有XXXX位。。”，当排队成功后，一天之内付款，购票成功！这样就可以避免购票者不断提交造成的压力。 2.提高系统并发，使用nginx作为HTTP服务器，据说nginx的并发高达3万，这个我没有具体测试，当然这个也取决于业务逻辑的复杂度。 3.缓存所有车票信息，提高查询的响应时间 你这个高峰期的计算逻辑本身就是错的 首先车票12天预售期是在15:00开卖，结果就是你这所谓的12小时出票的访问压力会基本上全部集中在15:00的前5分钟，后最多30分钟以内，特别是在15:00的前后5分钟，真按你的1543个并发去设计系统，那就等死去吧 首先买票的人绝对低于10亿，其次我只是提出一下解决问题的思路，不需要在数据上纠结,1543是理论值，实际上还会有查询、购票者还会不停的刷新，这些都是并发。 另外15：00是可以控制的，在售票方式上应尽量使其均衡，按地区分时段等 关键点来个理论值就一笔带过，理论好歹也得是同一数量级吧。 如果这项目是你来做，估计是一个德行。 这系统，京东不行，淘宝也够劲。铁道部是疯了，全国这么多人，运力还不够，再加上那么多秒杀程序。。。 就事论事，论人就没啥意义了，品行问题 那句话论人呢？ 需求你明确了吗？ 需求你都没能明确就嚷着项目该怎么做，该采用什么什么技术，有用吗？ 铁道部是疯了，你也疯了。 会写秒杀程序的赶紧写吧，否则过几天人工抢票。。。淘宝有几个人工抢到的。。。 我说什么了？这项目搁我做也是一个德行？？我做成什么样还没轮到你来品头论足 |
| 返回顶楼 | |
|
发表时间：2012-01-05
数据库分负荷，，对数据库的设置，根据身份证，编号分到不同的省份的数据库备份，
|
| 返回顶楼 | |
