Gray1982 发表于 2012-01-17 17:55 static/image/common/back.gif
数据库要改的N多，最主要的不能是总直接查询库，要有缓存；读写还得分离，库、表的设计也要跟行上，字段 ...
据我实际使用发现,现在他查的方式就是缓存
sania9 发表于 2012-01-17 17:43 static/image/common/back.gif
亿级别的架构确实要考虑的太多，从编码规范到前端缓存、db压力，甚至带宽等等。
不过这会的优化可以先从业 ...
中签这个有点意思
感觉跟北京汽车摇号一样
我顶一下
同样是拼人品和运气,摇号总比这样哄抢好.
另外,必须是第三方机构负责摇号
头两天，是网站打不开，如yanyangtian4502所说，应该要优化web代码。CDN是必须的，事实上也是上了CDN。
用户登录，可以对用户进行分区，认证模块用内存+文件的cache。用户登录时利用索引路由到分区的认证模块。session可以用专门的session server管理，而不是web app管理。
上亿注册用户，每天百万级别的活跃用户，目前没大问题，也可随意扩容。
个人见解。
政府网站一向既难看又难用，一点都不顾及用户的感受，费用支出却是最高的。
非常赞成基础架构没做好的说法，基础没弄好其它的都白扯。
我认为这篇讨论大部分地方可以参考：http://bbs.chinaunix.net/thread-3626937-7-1.html
主要值得提出来的地方，我认为有以下几点：
1.流量分析，其实这个在应用上架前就能做好，铁道部可以从以往的人口流量映射访问流量。当然这样会有一定的偏差，同时也涉及到地域性流动人口的知识架构。
不过现阶段的工作是改进，对于已经运行这么长时间的系统，流量的掌握应该已经到了比较精确的地步。
下一步就是cache服务器的部署、CDN的选择、各种负载均衡系统的选择等等问题，这些都可以参照以前的讨论《千万级pv高性能高并发网站架构与设计交流探讨帖》http://bbs.chinaunix.net/thread-3626937-7-1.html。
2.应用本身的架构，也就是此次讨论的主旨——在线票务系统的架构。
首先，就是开发语言的选择，从页面上来看，应该是java。
其次，开发框架的选择。
再次，脚本服务器的选择，从曾经出错的信息上看有网友说是JBoss。
换架构可以说是不可能的是，只能优化、优化、再优化。
3.应用的部署
扯开分布式部署、负载均衡等技术不说。我认为，这个大规模的应用完全可以采取省级部署的方式，分别用二级域名来引导进入不同地域进行购票。比如：广东就用gd.12306.com，湖南就用hn.12306.com，把整个系统划分为多个小系统，并在后端集中。
4.其他方面
（1）系统忙会造成用户强行退出，用户不得不多次登陆，这也增加了系统的负载，同时也成就了大量的刷票软件的存在。
（2）支付方面，需要在一定时间内完成付款，否则订单取消。其实可以做个充值功能，用户先查好所需车票的金额，冲入账户，如购票失败则可随时申请退款。
（3）数据库方面。12306的数据库主要涉及两方面：用户信息和票务信息。这两方面的数据分离我认为是必须的，即减轻系统负载，也增加系统相应。读写分离、cache、负载就不多说了。
曾经接触过一个政府的项目，要求由一国产的中间件换成websphere，给了一个月的时间，硬是没完成，最后也只能将就着用。
政府项目有其特殊性，有其特殊的招标渠道、有指定的投标商。
其实这些不可避免的“人文因素”往往会照成系统的“弱应用性”。
回复 1# 无风之谷
"是否是无证程序员"
本帖最后由 老男孩linux培训 于 2012-01-17 20:43 编辑
回复 36# gotolinux
我认为这篇讨论大部分地方可以参考：http://bbs.chinaunix.net/thread-3626937-7-1.html
主要值得提出来的地方，我认为有以下几点：
1.流量分析，其实这个在应用上架前就能做好，铁道部可以从以往的人口流量映射访问流量。当然这样会有一定的偏差，同时也涉及到地域性流动人口的知识架构。
不过现阶段的工作是改进，对于已经运行这么长时间的系统，流量的掌握应该已经到了比较精确的地步。
下一步就是cache服务器的部署、CDN的选择、各种负载均衡系统的选择等等问题，这些都可以参照以前的讨论《千万级pv高性能高并发网站架构与设计交流探讨帖》http://bbs.chinaunix.net/thread-3626937-7-1.html。
2.应用本身的架构，也就是此次讨论的主旨——在线票务系统的架构。
首先，就是开发语言的选择，从页面上来看，应该是java。
其次，开发框架的选择。
再次，脚本服务器的选择，从曾经出错的信息上看有网友说是JBoss。
换架构可以说是不可能的是，只能优化、优化、再优化。
3.应用的部署
扯开分布式部署、负载均衡等技术不说。我认为，这个大规模的应用完全可以采取省级部署的方式，分别用二级域名来引导进入不同地域进行购票。比如：广东就用gd.12306.com，湖南就用hn.12306.com，把整个系统划分为多个小系统，并在后端集中。
4.其他方面
（1）系统忙会造成用户强行退出，用户不得不多次登陆，这也增加了系统的负载，同时也成就了大量的刷票软件的存在。
（2）支付方面，需要在一定时间内完成付款，否则订单取消。其实可以做个充值功能，用户先查好所需车票的金额，冲入账户，如购票失败则可随时申请退款。
（3）数据库方面。12306的数据库主要涉及两方面：用户信息和票务信息。这两方面的数据分离我认为是必须的，即减轻系统负载，也增加系统相应。读写分离、cache、负载就不多说了。
=======================
老男孩评：考虑的很多，赞！
能事先分析需求，并按地域分域名思路很不错，不过这个不同地点购票可能难做，这个要和现有的不同地区的铁路售票系统节点对接（资金太大），
找几个核心骨干的售票系统对接就好。
之所以堵，这个和对接的铁路售票系统 的节点多少及铁路售票系统整个吞吐有关。网络除了并发大，还要连续刷新。是平时各个点售票并发的好多倍。
比如平时北京也就上千个售票点，大家排队就是队列。。。现在在这个队列没了，海量的人直接打开页面刷。并发页面访问10几万都有可能。
考虑到铁路的实际售票系统的吞吐情况，提交数据 使用队列 可能是必须的，否则，就得改造传统的售票系统了。
除了和售票系统对接交换数据外，网站本身也需要一个分布式的数据库。
先写这么多。
扔个分布式票务架构模型图：
回复 3# yuhongchun
如果是j2ee的应用，很多项目的实施中是不会考虑前端的web应用服务器采用Nginx调度，多数是直接用j2ee的应用平台的。而且此类大型系统比人是要用到小鸡的，目前国内的行业基本上是如此。开源技术多数是在互联网领域应用很多的。
yanyangtian4502 发表于 2012-01-17 16:06 static/image/common/back.gif
说实在的，我之前没有使用过12306，最近也是看到很多朋友放映12306不给力，我就看了下！
首先不说别的，页 ...
这个就是 做互联网运维的兄弟 看到的真实的状况，在那些开发此类系统的人员来说，是不会考虑这些细节问题的。
一个好的建议，在这个讨论结束的时候，以CU社区的名义出提出一个针对性的优化建议 ，不过想想也很遥远，有多少几率会被接受。
在此讨论此问题就是来思考好互联网我们熟悉的领域中的运维该如何优化提升性能。
这个讨论话题就不咋得体 ，如何基于开源架构设计一套在线票务系统应该比较的贴切，可以根据目前的春运来做讨论