[讨论]从12306浅谈大型网站架构演变之路（获奖名单已公布）

南非蚂蚁

这里总结下网站架构的演变过程：


架构演变第一步：物理分离webserver和数据库



架构演变第二步：增加页面缓存


架构演变第三步：增加页面片段缓存

南非蚂蚁

架构演变第四步：数据缓存



架构演变第五步：前段增加webserver


架构演变第六步：数据库分库

hbsycw

回复 52# 南非蚂蚁

个人习惯的架构是：WEB Server+APP Server+DB Server, 然后每层再有针对性的实施水平扩展（SCALE OUT）方案。


   

ak47mig

king_819 发表于 2012-02-23 09:27
回复 29# liang3391

12306数据库的实时性要求非常高的，数据实时刷新的，还缓存，怎么缓存

说到缓存。其实得根据买票这个业务来具体的看。

数据是实时刷新的，但是除非购买，不用真正跟数据库交互。
如果只是查询。一秒钟更新一次缓存也足够了，真正订票的时候大家一秒钟并发很高的。

ak47mig

a2433 发表于 2012-02-22 18:01
上面说按车次 估计不大现实  太麻烦了   我想是不是按 铁路局  划分呢   按照所选的车次 自动或者  地点  自 ...

按车次分还好吧。

我觉得我们在这里讨论也是外人指路，最好还是有12306的日志看看，哪些车次是高频率车次。或者根据铁路局之前的经验来看，哪些线路可能订票比较多。对于热点线路单独分一个库我觉得是不为过的。

一些非热点线路可以根据负载情况分到其他库里。

另外很可能一个线路今天几个小时就售罄了这个时候数据库就空闲了。可以移出。

ak47mig

sery 发表于 2012-02-22 18:09
12306使用网宿的cdn，但从它的具体情况得知大部分是动态对象，不适合网宿那种加速方式。本来访问的用户多， ...

对。这种cdn的使用方法还是很傻的。


可能是他们一开始也没估算好。在设计的时候没有完全把动静态分开。

把静态资源上cdn，保证用户的浏览正常，尽量做小动态资源部分。我觉得从设计上还是可以把动态资源做到最小的。

另外刚才提到的一个极端方法：一个线路一个数据库，我觉得在cdn上也可以做类似的考虑。比如剩余票数查询完全可以跟cdn商协商。也是一秒钟一更新跟源站取数据，但是坚决避免除此之外的回源。

真正让网站把资源节省到用户订票的写操作上。

ak47mig

南非蚂蚁 发表于 2012-02-28 09:07
数据缓存

其实原理也就是cache，更多的cache和分拆，更合理的分拆。

楼主的哪个设计只是保证了基本的性能和基础的冗余性。如果运算本身就是很多，还是需要将负担放在更多机器上去的。所以就是分拆，分库。

我们不可能把用户的需求减少：只能将请求减轻（更小数据个头的数据量请求，将静态请求剥离），更浅（比如非写入的尽量落到更靠前的cache上）。


另外其实app和database的优化在这个时候可能也会更有效一些。

比如是否能把update改成别的方式。起码mysql的update肯定容易锁表的。数据库里面的数据能否只是简单的数据符号。

ak47mig

齐达内553847981 发表于 2012-02-24 21:19
前端应该有 CDN，尽量将静态内容放到这一级，并配合其他CDN的应用模式；下一级负载均衡应该是DNS，将 ...

我倒觉得数据库不一定非得选oracle....当然最终的存储选择oracle是没问题的，但是订票时段并发太高，oracle性能不适合吧。


其实对于车票这种特殊的应用，我觉得可能自己写个特殊的数据库放在订票时段用更合适一些。因为车票的特点就是一个人一个坑，一个车次总坑数是一定的。


而对于订票来说，订票时间写入是高峰，这个写入只是说让你入坑而已。所以我觉得不如很多东西错峰来做（比如校验用户的真实性，生成车票相关信息之类的）：订票的时候就是让这些人入坑（可以只是简单的打log，或者数据库的insert操作，但是会判断有座无座以免卖超了）。然后等低峰的时候慢慢从log里回放，让大家选座之类的。这些最终信息再慢慢入总库。

南非蚂蚁

ak47mig 发表于 2012-02-28 13:20
其实原理也就是cache，更多的cache和分拆，更合理的分拆。

楼主的哪个设计只是保证了基本的性能和基 ...

分析的很有道理，感谢分享经验！

南非蚂蚁

继续接52楼

架构演变第七步：分表、DAL和分布式缓存





架构演变第八步：增加更多的webserver，分布式文件系统




架构演变第九步：数据读写分离加廉价存储方案