假如我是12306架构师51CTO博客 - 娱乐之横扫全球

假如我是12306架构师51CTO博客

2019年04月04日14时27分28秒 | 作者: 沛槐 | 标签: 架构,效劳,数据库 | 浏览: 354

12306,由于体系问题,成了IT业界内咱们茶余酒后常常议论的论题。   先共享一个实在故事,我搭档看了12306这个网站,他说,这个网站做下来只需5万,我辩驳,被他讪笑。笑话终归笑话,没有挖苦铁道部,以及12306研制方的意思,我搭档是实习生,他不明白12306。   近来,咱们在一个技能群里评论了一个开放式论题:假如我是12306架构师,该怎样规划体系架构?   评论的内容太多,我只将评论的终究成果做些简略整理,并在我的blog:zouhui.blog.51cto.com上与咱们共享。   布景:12306,需求处理的一个中心问题是,千万级并发的问题。一起,12306应该有自己的特征,与新浪的千万级PV很不相同。根绝现在12306的事务,12306对带宽的要求其实并不大。   架构:与其他大型网站相同,需求选用分布式规划。   前端应该有CDN,尽量将静态内容放到这一级,并合作其他CDN的运用形式;下一级负载均衡应该是DNS,将流量均匀分配到不同的IP;再下一级应该是LVS,将拜访恳求分发到不同的物理效劳器,然后再下一层才是存储层。选用分布式形似能处理12306的并发问题,为什么12306仍是这么慢呢?   瓶颈在哪里?   瓶颈在数据库。尽可能削减抵达存储层的拜访恳求,这才是12306问题的关键所在。   12306底层的数据库应首选Oracle.   咱们假定:单数据库+单效劳器的方法,用比较好的Unix效劳器,运用OCI方法,关于非大字段(clob,blog字段),每秒的入库能够到达10W。   离千万并发还差两个数量级,因而数据库也有必要选用分布式。   10万的并发,WebServer有危险,实践单机apache很可能顶不住10W级并发,apache或iis很可挂了。   处理办法:选用N个效劳器M个数据库的架构方法。   将效劳器与数据库分隔,N个效劳器皆可拜访M个数据库。效劳器担任处理不同物理链路上的恳求,效劳器上选用使命均衡搬迁效劳,一起担任与各个数据库交互。   感性地知道这个架构,数据库依照区域区分,每个数据库做备分并做warehouse(数据仓库)将不同地域的IP分配到对应地域的效劳器集群上,比方10.0.0.x网段的集群担任处理成都铁路局始发的列车订票事务,那么这个网段的集群只需求保护成都铁道部辖区内的始发列车数据即可,关于IP解析与数据分发,需求重写一个LVS分发算法。关于上海,北京,广东这种抢手区域,需求做使命搬迁处理。   依照以上的架构,大约需求400个数据库,1000台效劳器。   最终,关于查票,定票,付宽,多学习支付宝的宏构,关于使命处理,多学习银行的使命分发。   特别感谢本群的:薛定谔的猫,那時花開,/bs暗夜未冥/bs,he,狼鱼,涛涛,等多为朋友对该论题的重视,并积极参与了评论。   假如你是12306架构师,该怎样规划体系架构?
版权声明
本文来源于网络,版权归原作者所有,其内容与观点不代表娱乐之横扫全球立场。转载文章仅为传播更有价值的信息,如采编人员采编有误或者版权原因,请与我们联系,我们核实后立即修改或删除。

猜您喜欢的文章