惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

博客园_首页
MyScale Blog
MyScale Blog
T
Tailwind CSS Blog
量子位
有赞技术团队
有赞技术团队
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
爱范儿
爱范儿
The Last Watchdog
The Last Watchdog
F
Fortinet All Blogs
博客园 - 叶小钗
Hugging Face - Blog
Hugging Face - Blog
博客园 - 司徒正美
Recent Announcements
Recent Announcements
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
Apple Machine Learning Research
Apple Machine Learning Research
云风的 BLOG
云风的 BLOG
Martin Fowler
Martin Fowler
美团技术团队
The GitHub Blog
The GitHub Blog
A
About on SuperTechFans
Stack Overflow Blog
Stack Overflow Blog
V
Visual Studio Blog
NISL@THU
NISL@THU
Last Week in AI
Last Week in AI
V
V2EX
S
Secure Thoughts
阮一峰的网络日志
阮一峰的网络日志
C
CXSECURITY Database RSS Feed - CXSecurity.com
U
Unit 42
T
The Blog of Author Tim Ferriss
雷峰网
雷峰网
宝玉的分享
宝玉的分享
P
Proofpoint News Feed
腾讯CDC
Attack and Defense Labs
Attack and Defense Labs
L
Lohrmann on Cybersecurity
J
Java Code Geeks
S
Securelist
P
Privacy International News Feed
Google Online Security Blog
Google Online Security Blog
M
MIT News - Artificial intelligence
N
News and Events Feed by Topic
H
Hackread – Cybersecurity News, Data Breaches, AI and More
Forbes - Security
Forbes - Security
V
Vulnerabilities – Threatpost
K
KPMG report finds enterprise disconnect between AI and its ROI | CIO
博客园 - 三生石上(FineUI控件)
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
W
WeLiveSecurity
Webroot Blog
Webroot Blog

博客园 - 左洸

Vim配置Java IDE U(优)盘安装FreeBSD-9.0+GNOME_lite桌面 12306 说:有时候,能排队也是一种幸福! ubuntu删除openjdk,安装 Sun JDK 用 PyMedia 解码并播放 mp3 文件 软件BUG造成本次动车追尾,警方已经拘留了两名 无证 程序员 SQLite 入门教程(四)增删改查,有讲究 SQLite 入门教程(三)好多约束 Constraints SQLite 入门教程(二)创建、修改、删除表 SQLite 入门教程(一)基本控制台(终端)命令 如何稳定地使用 Google 搜索 “拼木头”算法挑战赛:禁忌搜索算法,用Javascript 跑 计算机图形学(二)划线算法 计算机图形学(一) 图形系统综述 模拟退火算法应用于最优排列问题和最优组合问题 之 排列篇 wxPython 笔记(11)重定向程序输出到标准控制台窗口 wxPython 笔记(10)应用程序对象 wxPython 笔记(9)向窗体中加入控件 wxPython 笔记(8)设定窗体的样式
如果 12306 依赖反转 —— 都给劳资消停点,谁也别来找我,我会去找你们的
左洸 · 2012-10-01 · via 博客园 - 左洸

一说起12306,大家总爱和淘宝、谷歌、京东之类的高访问量网站比较。他们真的一样吗?我们来分析一下:

先分析谷歌。假如同一时间我谷歌“苹果”,从服务器 A 得到数据,你谷歌“橘子”,从服务器 B 得到数据,他同样谷歌“苹果”,却是从服务器 C 得到数据。这就是所谓的分布式架构。

再来分析淘宝,你买一件衣服,我买一双鞋子,业务请求很可能是从不同的服务器处理的。

淘宝、谷歌这类的网站,他们的特点是:每个用户的操作和其他用户的相关性不大;也可能相关性可能很大,但是从时间上来说却不需要立刻处理。在这个前提下,才有可能进行分布式架构。

12306的核心车票数据可以分布吗?我们再来分析一下:

你购买了一张北京到广州的车票,同一时间我也购买了一张北京到广州的车票。

假如系统是分布式的,会出现什么情况呢。

服务器 A 给你出了一张票,服务器 B 给我出了一张票,结果等车的时候发现,我们两个人的票是同一个座位,撞车了!

如何解决这个问题呢?那就是设置一个中心服务器!

外围分布式服务器可以处理一切和车票无关的业务,比如说注册、登陆、身份验证、购票请求、款项支付等等等等,因为这些数据只和你自己相关,和任何其他人都没有关系,这些数据可以用类似谷歌、淘宝之类的架构设计处理。

但是唯独车票数据例外,因为任何一张车票的数据发生了变化,系统必须立刻知道,并在紧接着的下一笔购票业务中反映出来,否则就会出现混乱。

会出现什么可怕的情况,大家想象一下。

真正可怕的不是一瞬间上亿的访问量,真正可怕的是上亿的访问在同一时刻必须依赖同一个“核心”!

对,就是一个“核心”。这个核心可能是一台服务器,也可能是几千台服务器。无论多少,从逻辑上看,他们就是一个核心

现在问题很清楚了,购票的业务逻辑必然导致一个依赖核心!而上亿的访问同一时刻依赖同一个“核心”必然导致崩溃!

似乎崩溃是必然的,但是如果我们将依赖反转过来就发现一切问题迎刃而解。

打个比方吧,大家电脑里都有一个中心处理器 ,即CPU ,他是一个核心。假如我们让几万个运算任务同一时间去抢 CPU 的控制权,CPU 必然会发呆的,给谁好呢? 

CPU 想了一下发话了,大家都别抢了,都给劳资消停点!所有人,都把数据准备好:放到磁盘、内存、一二三级缓存中,然后等着。

你们谁也别来找我,我会一个一个找你们的,每人一个时间片,只要劳资还能运转,大家的任务都能完成。

本来是海量请求依赖一个核心,现在成了核心主动去收集任务,依赖反转了。

12306 完全可以这样架构,外围的分布式系统处理一切和车票无关的非核心业务,同时接受购票请求并将购票请求缓存起来。而“核心”对外围分布式服务器进行时间片轮转通讯,收集购票请求,并根据即时情况进行处理。秩序恢复了,高速公路终于不是停车场了。

当然了,无论怎么架构,总还是有很多人买不到票,但是秩序恢复了,这不正是我们要追求的吗!