关于12360网站的架构优化

首先 本人在8号去订19号的票. 听说网站从6点开始登录,放票时间8点,10点.  然后5点起来在一家网吧守候着.当6点01分的时候,就登录.结果登不进去.

每隔1分钟登陆一下直到10点就彻底放弃了.

 后来听说有10亿的PV量,嗨嗨

然后在公司登啊登, 同事用登录软件登了进去,下不了单被踢出来了. 还有订到了单,可付款超过45分钟就OVER了 可谓是步步惊心!

 

总得来讲该网站比较简单, 简单易懂! 或许真的碰到春运这个全球难题. 日均10亿PV峰值.

 

看后台使用JSP 估计采用JAVA代码编写的中间应用程序. JAVA WEB一向来都是低性能的代名词.

 

什么 STRUCTE  SPRING HIEBRTATE 只是用来OO意淫的对象. 无法满足高并发,高流量的网站需求.

 

它满足金融的安全需求和稳定需求.

 

好吧  我们用 JSP+JAVABEAN+ORACLE的数据库 做为开发基础.   用TOMCATE APACHE作为中间容器和应用服务器.

数据库做RAC集群

TOMCAT和APACHE也做集群和负载均衡.

如果觉得不够还可以加个NGIX服务器

 

来看看页面情况 大部分都是静态页面, 动态页面就是车次和车票量而已.

 

也就是说大部分页面可以内存缓存起来. 用IE涮新页面应该很迅速,无论是网通,铁通,联通,电信,3G都可以.

 

好我们来谈谈登录页面 登录语句很简单 一个查询用户信息表.  在数据我们做个简单的用户信息登录表 就记录些 注册号,密码两个字段. 然后把它缓冲到内存中.

13亿人口,13亿用户,2个字段 占内存不大. 秒杀出来.

 

如果登录后会占大量的SESSION 也就是网页连接对象. 其实进去后,大家干的就是查询工作.然后下订单,然后再支付.

 

这样可以采用漏斗法, 下订单可以采用拿号排队机制.让用户可以看到前面有几个人? 同时看到票的递减数. 其他人就玩查询

这样用户体验就不会那么差. 毕竟能打开网页,毕竟能登录,毕竟能修改信息增加购票人的信息.毕竟可以查询车次. 下单就可以排队等候.

就不会被骂如此狗血

 

比如一天就放几趟车,每车就2千票. 实在太简单了. 两三台机器就可以完成业务处理. 虽然有上万人抢,当都被挡在外面.

页面打开机器

登录机器

信息修改机器

车次查询机器,

拿号订单机器

订单交易机器,

支付机器.

 

 

剩下就是分流用户. 深圳,北京,上海 广州用户 按IP地址把他们分流到不同的机器集群上.

高铁,动车线 是高端客户. 不管在哪里把他们集中在另外个机器集群中.

 

 补充些总体而言就是分流客户量
1 根据接入网 分 电信网络,联通网通,北方网络 三大网络
2 根据客服IP地址分,主要把热点客服流分开. 北京,上海,深圳,广州.反程客流城市.
3 可根据客服高端分,动车,普通客车,临时客车.
4 根据购票流程 分打开主页,登录页面,注册页面,信息修改页面,查询车次页面,订单预定页面,支付页面. 这几个功能可以分在不同的序列中. 每个序列都有页面响应服务器,中间业务服务器,和数据库服务器.
5 最后在各个服务器上增加MEMCACH缓冲
6 每个服务器都做负载均衡和集群.
7 支付时间应该是24小时. 并且可以网下支付.比如在售票窗口.
跟电话订票拿到订单号去窗口买票一样.

 

上面不是组合而是层层剥离  把全国客流分成三大网, 按IP地址 分成 4大城市和其他城市, 客户类型分成三大部分. 然后按购买流程分成8个服务器组.

全国客户分成 3*4*3=24部分  10亿PV除以24  每个服务器队列就压力小了.

 

 

 

像这样拆分法  用MYSQL +LINUX+普通PC机+PHP+APACHE 3-5百台普通PC机 摆平