由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 继续掐12306
相关主题
分布式分票算法其实就是两党党争
为什么分布式搞不定12306?wei和好虫打的什么赌, 吧好虫搞自杀了?
大规模多核并发的系统PK大规模多机并发的系统铁路订票系统怎么强耦合了?12306绝对架构错了
说到底还是app 层 engineer 和 系统层engineer在斗法12306的后台数据库可以做到完全无耦合
在讨论12306前魏公公,赌局我接了,你把500万/秒的订票系统做出来
技术贴来了12306每秒500万
请老魏给出一个简单的文字解释我来提个方案,大家看合理不合理
除了model view controller (mvc)这种pattern还有什么pattern流行?transaction衡量都要有标准
相关话题的讨论汇总
话题: 12306话题: 多机话题: 能力话题: 架构话题: sql
进入Programming版参与讨论
1 (共1页)
T********i
发帖数: 2416
1
我还是这个架构。各位不服可以用任何现成的轮子搭一个。代码拿出来,用SQL的,把
query写出来。
车次联票,座位连号,退票,都支持也行。
我还是单机核心和你比性能。我的系统你来测。你的我来测。什么pattern的请求都允
许。比谁性能高。
可靠性测试。也不用纠结敲掉百分之多少机器了。双方定点敲。比如互相挑,敲掉1,2
,3,4。。。台。比赛总机器数需要多少还能保持服务。
w***g
发帖数: 5958
2
要搭得出来就怪了。我可以赌上我的ID,一个月之内这个版上没人能用现成的轮子
(不算你写的那个)搭出一个系统,用10倍以下机器,假设没有硬件故障的前提下,
在处理连票的情况下做到你那个程序相同的吞吐量(允许每个transaction <= 5张
票,吞吐量按票数算。)
我不是说技术上不可行。我是说本版ID总体来说吹牛比写code厉害。如果真出来这么
一个系统,我死一个ID也值了。

,2

【在 T********i 的大作中提到】
: 我还是这个架构。各位不服可以用任何现成的轮子搭一个。代码拿出来,用SQL的,把
: query写出来。
: 车次联票,座位连号,退票,都支持也行。
: 我还是单机核心和你比性能。我的系统你来测。你的我来测。什么pattern的请求都允
: 许。比谁性能高。
: 可靠性测试。也不用纠结敲掉百分之多少机器了。双方定点敲。比如互相挑,敲掉1,2
: ,3,4。。。台。比赛总机器数需要多少还能保持服务。

h*****a
发帖数: 1718
3
大家都上有老下有小,写程序多半都是为了谋生。不给钱做项目的除了几个有热情
或者已经财富自由的同学,对绝大部分ID来说是太大的奢侈了。:-)

【在 w***g 的大作中提到】
: 要搭得出来就怪了。我可以赌上我的ID,一个月之内这个版上没人能用现成的轮子
: (不算你写的那个)搭出一个系统,用10倍以下机器,假设没有硬件故障的前提下,
: 在处理连票的情况下做到你那个程序相同的吞吐量(允许每个transaction <= 5张
: 票,吞吐量按票数算。)
: 我不是说技术上不可行。我是说本版ID总体来说吹牛比写code厉害。如果真出来这么
: 一个系统,我死一个ID也值了。
:
: ,2

h*****a
发帖数: 1718
4
有动力也有能力人的不多很正常吧。
换句话说,如果这个task是个工作中的task,那很多人肯定能做完吧。另一个说法,
今天很多同学工作中写的code,复杂度也不会逊于写计数器吧。
只是想说没人接招的原因可能很多,只归结于没能力未免过于简化了一点。

【在 w***g 的大作中提到】
: 要搭得出来就怪了。我可以赌上我的ID,一个月之内这个版上没人能用现成的轮子
: (不算你写的那个)搭出一个系统,用10倍以下机器,假设没有硬件故障的前提下,
: 在处理连票的情况下做到你那个程序相同的吞吐量(允许每个transaction <= 5张
: 票,吞吐量按票数算。)
: 我不是说技术上不可行。我是说本版ID总体来说吹牛比写code厉害。如果真出来这么
: 一个系统,我死一个ID也值了。
:
: ,2

a*********a
发帖数: 3656
5
按你的说法,感觉这个版上比古德霸能力强的一抓一大把?

【在 h*****a 的大作中提到】
: 有动力也有能力人的不多很正常吧。
: 换句话说,如果这个task是个工作中的task,那很多人肯定能做完吧。另一个说法,
: 今天很多同学工作中写的code,复杂度也不会逊于写计数器吧。
: 只是想说没人接招的原因可能很多,只归结于没能力未免过于简化了一点。

d******e
发帖数: 2265
6
也不能这么说,不过java搞多了,脑壳坏掉的概率很大。

【在 a*********a 的大作中提到】
: 按你的说法,感觉这个版上比古德霸能力强的一抓一大把?
h*****a
发帖数: 1718
7
何以见得?你这问题不清楚,比如能力高如何定义?
不管哪方,建议还是多open minded一点,少点personal的东西比较好。

【在 a*********a 的大作中提到】
: 按你的说法,感觉这个版上比古德霸能力强的一抓一大把?
a********5
发帖数: 1631
8
半海大神,求推荐个真心交流技术的论坛。

【在 h*****a 的大作中提到】
: 何以见得?你这问题不清楚,比如能力高如何定义?
: 不管哪方,建议还是多open minded一点,少点personal的东西比较好。

h*****a
发帖数: 1718
9
别这么客气,我技术很滥,在这里只有围观的份。:)

【在 a********5 的大作中提到】
: 半海大神,求推荐个真心交流技术的论坛。
x****u
发帖数: 44466
10
人家12306是业务系统,需要能轻松上下新功能的架构,你搞个高频交易或者高频网游
,整个出发点就是错误的。
你干脆让人家和你比打俄罗斯方块掌机版,你能打赢代表你的架构厉害。

,2

【在 T********i 的大作中提到】
: 我还是这个架构。各位不服可以用任何现成的轮子搭一个。代码拿出来,用SQL的,把
: query写出来。
: 车次联票,座位连号,退票,都支持也行。
: 我还是单机核心和你比性能。我的系统你来测。你的我来测。什么pattern的请求都允
: 许。比谁性能高。
: 可靠性测试。也不用纠结敲掉百分之多少机器了。双方定点敲。比如互相挑,敲掉1,2
: ,3,4。。。台。比赛总机器数需要多少还能保持服务。

相关主题
技术贴来了12306其实就是两党党争
请老魏给出一个简单的文字解释wei和好虫打的什么赌, 吧好虫搞自杀了?
除了model view controller (mvc)这种pattern还有什么pattern流行?铁路订票系统怎么强耦合了?12306绝对架构错了
进入Programming版参与讨论
T********i
发帖数: 2416
11
为什么我的架构不能上下新功能?
比性能你比不过,比可靠性你比不过,给你100倍的机器你都不行。凭啥说我的架构上
新功能不轻松?

【在 x****u 的大作中提到】
: 人家12306是业务系统,需要能轻松上下新功能的架构,你搞个高频交易或者高频网游
: ,整个出发点就是错误的。
: 你干脆让人家和你比打俄罗斯方块掌机版,你能打赢代表你的架构厉害。
:
: ,2

m**u
发帖数: 541
12
哎。。。。 看了半天,其实一堆人还是没搞明白啊。。。
屁股决定立场,这还不明白么。 问题的本质不在技术,而是在利益,利益,啊兄弟。
你这个搞法,让一堆码农怎么活下去? 码农们需要的不断折腾自己才能保住饭碗,你
用这种搞法,让他们怎么显摆?怎么混饭吃?
c****3
发帖数: 10787
13
魏搞法和IT行业趋势背道而驰。
IT行业趋势就是不断重新发明轮子,主要目的是为了更容易用,让大妈也能上岗,架构
的目的是为了标准化,不被某些精英要挟。现有轮子是通用架构,不见得最高效。
所以魏的搞法,在这个上面效率,比现有轮子高,一点都不奇怪。问题是这样大妈就没
法维护了。
a*********a
发帖数: 3656
14
古德霸出来接招了,输了,死了。你又说能力强的不少,就是不出来接招。
也别说出来接老魏的招,赌约到期前一个礼拜,古德霸在这里找人做test case,有人
做吗?最后是跟老魏认认真真讨论问题的一个朋友做了。
http://www.mitbbs.com/mitbbs_postdoc.php?board=Programming&reid
你早一年就应该劝劝古德霸少点personal的东西,不要每帖必骂太监。或许这个ID现在
还活着。早一年,古德霸骂人家半路出家,卖银河系的票的时候,你指出他对计算机底
层performance的认识是错的,老魏/老姜的设计有他的可行性,或许这个ID现在还活
着。

【在 h*****a 的大作中提到】
: 何以见得?你这问题不清楚,比如能力高如何定义?
: 不管哪方,建议还是多open minded一点,少点personal的东西比较好。

h*****a
发帖数: 1718
15
goodbug这个ID活不活着不是我在这个版上发帖的motivation. 大家都是成年人,遵循
自己的标准对自己负责就好了。我前面说的主要是针对“没人接招就是因为水平低”,
也仅仅是希望这样想的人能更open minded一点。
肯在这里实实在在的写code show project是很好的,但既需要passion又需要能力。我
只能说这个版上有能力的人可能不少,但同时又有passion有motivation在自己的业余
时间做和全职job无关的技术工作的人就不多了,前面也说过了,我觉得对很多人来说
是一个"luxury". 你如果非要我给你数据justify那我拿不出来。我只能用common
sense.
Anyway, 我的这些观点都是灌水而已,没有一点技术含量,也不用再多纠结了吧。

【在 a*********a 的大作中提到】
: 古德霸出来接招了,输了,死了。你又说能力强的不少,就是不出来接招。
: 也别说出来接老魏的招,赌约到期前一个礼拜,古德霸在这里找人做test case,有人
: 做吗?最后是跟老魏认认真真讨论问题的一个朋友做了。
: http://www.mitbbs.com/mitbbs_postdoc.php?board=Programming&reid
: 你早一年就应该劝劝古德霸少点personal的东西,不要每帖必骂太监。或许这个ID现在
: 还活着。早一年,古德霸骂人家半路出家,卖银河系的票的时候,你指出他对计算机底
: 层performance的认识是错的,老魏/老姜的设计有他的可行性,或许这个ID现在还活
: 着。

T********i
发帖数: 2416
16
其实我以为,大家不妨分析一下,这个考虑车次联票,连座,实时优化座位出票的系统
,需要满足什么条件分布式抢票才有意义?当然还要把实时查询算上。
能做这个标准实际意义不是太大。慢100倍,同时机器多100倍,也能出票。
amdahl's law挂嘴边的一大把,这个case也不复杂,分析不对似乎有点那个了。

【在 h*****a 的大作中提到】
: goodbug这个ID活不活着不是我在这个版上发帖的motivation. 大家都是成年人,遵循
: 自己的标准对自己负责就好了。我前面说的主要是针对“没人接招就是因为水平低”,
: 也仅仅是希望这样想的人能更open minded一点。
: 肯在这里实实在在的写code show project是很好的,但既需要passion又需要能力。我
: 只能说这个版上有能力的人可能不少,但同时又有passion有motivation在自己的业余
: 时间做和全职job无关的技术工作的人就不多了,前面也说过了,我觉得对很多人来说
: 是一个"luxury". 你如果非要我给你数据justify那我拿不出来。我只能用common
: sense.
: Anyway, 我的这些观点都是灌水而已,没有一点技术含量,也不用再多纠结了吧。

n*******7
发帖数: 181
17
毕竟单机是有物理上限的。scale up会变得不现实或太昂贵。当scale需求接近物理上
限时,分布式就是必要了。
赌约这个问题只是scale没有达到物理上限。
其实就是分布式,也应该尽量把问题分割成关联最小的几个小问题,对每个小问题同样
单机处理。当然,这样的方式不太通用。

【在 T********i 的大作中提到】
: 其实我以为,大家不妨分析一下,这个考虑车次联票,连座,实时优化座位出票的系统
: ,需要满足什么条件分布式抢票才有意义?当然还要把实时查询算上。
: 能做这个标准实际意义不是太大。慢100倍,同时机器多100倍,也能出票。
: amdahl's law挂嘴边的一大把,这个case也不复杂,分析不对似乎有点那个了。

p*****y
发帖数: 529
18
没看出来分布式怎么就无限scale up了? 平常做ppt习惯了随嘴就来?

【在 n*******7 的大作中提到】
: 毕竟单机是有物理上限的。scale up会变得不现实或太昂贵。当scale需求接近物理上
: 限时,分布式就是必要了。
: 赌约这个问题只是scale没有达到物理上限。
: 其实就是分布式,也应该尽量把问题分割成关联最小的几个小问题,对每个小问题同样
: 单机处理。当然,这样的方式不太通用。

n*******7
发帖数: 181
19
好好说话好吗?你肯定是误解我的意思了。

【在 p*****y 的大作中提到】
: 没看出来分布式怎么就无限scale up了? 平常做ppt习惯了随嘴就来?
T********i
发帖数: 2416
20
分布最怕的就是数据依赖性。如果数据完全没有依赖性就是linear scale。
这种人一联票,即使车次内也有连座优化问题的,是强耦合。如果性能分析按照worst
case的话,单机核心就是最优解。分布方案根本没戏。
这个问题是amdahl's law决定性能上限。注意这个性能在现有技术水平下是有上限的。
上限并不是取决于机器多少。

【在 n*******7 的大作中提到】
: 毕竟单机是有物理上限的。scale up会变得不现实或太昂贵。当scale需求接近物理上
: 限时,分布式就是必要了。
: 赌约这个问题只是scale没有达到物理上限。
: 其实就是分布式,也应该尽量把问题分割成关联最小的几个小问题,对每个小问题同样
: 单机处理。当然,这样的方式不太通用。

相关主题
12306的后台数据库可以做到完全无耦合我来提个方案,大家看合理不合理
魏公公,赌局我接了,你把500万/秒的订票系统做出来transaction衡量都要有标准
每秒500万搞技术的,要有起码的是非观念 by 老魏
进入Programming版参与讨论
n*******7
发帖数: 181
21
数据依赖性也是有一些方法可以减弱。有些方面和cache coherency的设计是想通的。
multicore系统内每一个core看到的memory的值可被其它所有cores改变,这也是一个强
耦合关系,逻辑上这就是分布式。硬件实现cache coherency的一套成熟的protocol,
软件分布式也可以照做。
q*c
发帖数: 9453
22
老魏,我都给你方案了, 12306. 实时出票每秒几千万上亿, 你前面不是看到了? 都
是成熟技术,不靠你老魏一个人的人品。
唯一的是每列车最后一张票有个毫秒范围的不确定性,根本不是问题。
而且我那方案可靠性强,扩展性好,每列车 1000 站不影响,你的办法就慢 10000 倍
。 我那办法可以轻易扩展到 无人驾驶汽车上,哪怕之间 10 万个H站。

【在 T********i 的大作中提到】
: 其实我以为,大家不妨分析一下,这个考虑车次联票,连座,实时优化座位出票的系统
: ,需要满足什么条件分布式抢票才有意义?当然还要把实时查询算上。
: 能做这个标准实际意义不是太大。慢100倍,同时机器多100倍,也能出票。
: amdahl's law挂嘴边的一大把,这个case也不复杂,分析不对似乎有点那个了。

g*****y
发帖数: 7271
23
12306每秒出票一千来张而已。

【在 q*c 的大作中提到】
: 老魏,我都给你方案了, 12306. 实时出票每秒几千万上亿, 你前面不是看到了? 都
: 是成熟技术,不靠你老魏一个人的人品。
: 唯一的是每列车最后一张票有个毫秒范围的不确定性,根本不是问题。
: 而且我那方案可靠性强,扩展性好,每列车 1000 站不影响,你的办法就慢 10000 倍
: 。 我那办法可以轻易扩展到 无人驾驶汽车上,哪怕之间 10 万个H站。

b***e
发帖数: 1419
24
Fairly speaking, 就有因为这个"太大的奢侈"好虫可是追着魏老师的屁股叫了两年的
太监。连坐老姜和wdong,以及任何"装逼"一并叫成阉党。先不说谁技术牛逼, 谁更正确
。这他妈是什么德行?
按说好虫已死, 我并无意鞭尸, 但是有些事情大家也要公平些。

【在 h*****a 的大作中提到】
: 大家都上有老下有小,写程序多半都是为了谋生。不给钱做项目的除了几个有热情
: 或者已经财富自由的同学,对绝大部分ID来说是太大的奢侈了。:-)

b*******s
发帖数: 5216
25
是这样的

【在 n*******7 的大作中提到】
: 数据依赖性也是有一些方法可以减弱。有些方面和cache coherency的设计是想通的。
: multicore系统内每一个core看到的memory的值可被其它所有cores改变,这也是一个强
: 耦合关系,逻辑上这就是分布式。硬件实现cache coherency的一套成熟的protocol,
: 软件分布式也可以照做。

x****u
发帖数: 44466
26
你猜当年为什么人民发明了SQL,而不是直接用C语言写文件?

【在 T********i 的大作中提到】
: 为什么我的架构不能上下新功能?
: 比性能你比不过,比可靠性你比不过,给你100倍的机器你都不行。凭啥说我的架构上
: 新功能不轻松?

n*******7
发帖数: 181
27
因为通用。用轮子可以很快搭出很多东西。但是,用轮子去比性能,就是忘了轮子的短
处了。
x****u
发帖数: 44466
28
因为速度快效率高
SQL修改个业务结构,一条命令即可,耗时比修改C代码,rebuild,测试发布等快N个数
量级。

【在 n*******7 的大作中提到】
: 因为通用。用轮子可以很快搭出很多东西。但是,用轮子去比性能,就是忘了轮子的短
: 处了。

T********i
发帖数: 2416
29
这是我回老Q的帖子:
http://www.mitbbs.com/article/Programming/31466119_0.html

【在 x****u 的大作中提到】
: 因为速度快效率高
: SQL修改个业务结构,一条命令即可,耗时比修改C代码,rebuild,测试发布等快N个数
: 量级。

b***i
发帖数: 3043
30
我提一个要求
能动态增加车次吗,比如过节加车,过后去掉那种。你用不要重启?

,2

【在 T********i 的大作中提到】
: 我还是这个架构。各位不服可以用任何现成的轮子搭一个。代码拿出来,用SQL的,把
: query写出来。
: 车次联票,座位连号,退票,都支持也行。
: 我还是单机核心和你比性能。我的系统你来测。你的我来测。什么pattern的请求都允
: 许。比谁性能高。
: 可靠性测试。也不用纠结敲掉百分之多少机器了。双方定点敲。比如互相挑,敲掉1,2
: ,3,4。。。台。比赛总机器数需要多少还能保持服务。

相关主题
数据库分票策略为什么分布式搞不定12306?
goodbug的设计为啥不能撑过100K/s?大规模多核并发的系统PK大规模多机并发的系统
分布式分票算法说到底还是app 层 engineer 和 系统层engineer在斗法
进入Programming版参与讨论
x****u
发帖数: 44466
31
您老的高频系统不适合12306.
比起效率,灵活适应变动对人家更重要。

【在 T********i 的大作中提到】
: 这是我回老Q的帖子:
: http://www.mitbbs.com/article/Programming/31466119_0.html

n*******7
发帖数: 181
32
老魏code里各车次都是独立的,根本不受影响。

【在 b***i 的大作中提到】
: 我提一个要求
: 能动态增加车次吗,比如过节加车,过后去掉那种。你用不要重启?
:
: ,2

x****u
发帖数: 44466
33
你让谁给你改呢?SQL网管多少钱一斤?出了事你要拔毫毛变一群小猴子么?

【在 T********i 的大作中提到】
: 为什么我的架构不能上下新功能?
: 比性能你比不过,比可靠性你比不过,给你100倍的机器你都不行。凭啥说我的架构上
: 新功能不轻松?

T********i
发帖数: 2416
34
金融市场regulation基本上每天都变。也没见出大灾难。
铁道部不差钱。几十行的算法。找你不放心的话,找wdong维护好了。

【在 x****u 的大作中提到】
: 你让谁给你改呢?SQL网管多少钱一斤?出了事你要拔毫毛变一群小猴子么?
d*****t
发帖数: 7903
35
我个人觉得吧,你没有把“能力”的定义搞清楚。有passion, 有本事把家里家外搞清
爽,有闲时间搞点喜欢的,再加上编程技巧高,这一切加起来才是真能力。如果把能力
仅仅局限在编程技巧,说明你还没活明白。

【在 h*****a 的大作中提到】
: goodbug这个ID活不活着不是我在这个版上发帖的motivation. 大家都是成年人,遵循
: 自己的标准对自己负责就好了。我前面说的主要是针对“没人接招就是因为水平低”,
: 也仅仅是希望这样想的人能更open minded一点。
: 肯在这里实实在在的写code show project是很好的,但既需要passion又需要能力。我
: 只能说这个版上有能力的人可能不少,但同时又有passion有motivation在自己的业余
: 时间做和全职job无关的技术工作的人就不多了,前面也说过了,我觉得对很多人来说
: 是一个"luxury". 你如果非要我给你数据justify那我拿不出来。我只能用common
: sense.
: Anyway, 我的这些观点都是灌水而已,没有一点技术含量,也不用再多纠结了吧。

w******f
发帖数: 620
36
我觉得大家讨论一下挺好的,没有必要像打擂台一样争个高下,现在的社会成功都是集
团作战的,把时间花在这种比较个人某一方面水平高下且没有直接价值的事情上,对我
来说都是不值得的。

【在 d*****t 的大作中提到】
: 我个人觉得吧,你没有把“能力”的定义搞清楚。有passion, 有本事把家里家外搞清
: 爽,有闲时间搞点喜欢的,再加上编程技巧高,这一切加起来才是真能力。如果把能力
: 仅仅局限在编程技巧,说明你还没活明白。

N********n
发帖数: 8363
37

这个是关键。JAVA党总是叫唤“多机、多机”,其实根本没多机。就是收单时候
多了一把。出票时后台数据库是耦合的,搞成多机数据库最后要跨库锁等于无用
功,骨子里还是单机。JAVA党就是想不清楚这一点,拿着互联网过家家那一套出
来生搬硬套,最后弄个异步出票。异步还用你来做?铁道部自己就会做异步。

【在 T********i 的大作中提到】
: 分布最怕的就是数据依赖性。如果数据完全没有依赖性就是linear scale。
: 这种人一联票,即使车次内也有连座优化问题的,是强耦合。如果性能分析按照worst
: case的话,单机核心就是最优解。分布方案根本没戏。
: 这个问题是amdahl's law决定性能上限。注意这个性能在现有技术水平下是有上限的。
: 上限并不是取决于机器多少。

k**0
发帖数: 19737
38
re, 在出票机这一环节上,搞分布多机就是和自己过不去。

【在 N********n 的大作中提到】
:
: 这个是关键。JAVA党总是叫唤“多机、多机”,其实根本没多机。就是收单时候
: 多了一把。出票时后台数据库是耦合的,搞成多机数据库最后要跨库锁等于无用
: 功,骨子里还是单机。JAVA党就是想不清楚这一点,拿着互联网过家家那一套出
: 来生搬硬套,最后弄个异步出票。异步还用你来做?铁道部自己就会做异步。

N********n
发帖数: 8363
39

每个TIER都是多机才是真正的多机。如果MID TIER多,DATA TIER锁在一起那这
是个伪多机。用互联网那种弱耦合或者根本就是零耦合的方案出来套12306是拍
拍脑子想当然。

【在 k**0 的大作中提到】
: re, 在出票机这一环节上,搞分布多机就是和自己过不去。
h*****a
发帖数: 1718
40
hehe, 为啥你对能力的定义就正确呢?见仁见智好了

【在 d*****t 的大作中提到】
: 我个人觉得吧,你没有把“能力”的定义搞清楚。有passion, 有本事把家里家外搞清
: 爽,有闲时间搞点喜欢的,再加上编程技巧高,这一切加起来才是真能力。如果把能力
: 仅仅局限在编程技巧,说明你还没活明白。

1 (共1页)
进入Programming版参与讨论
相关主题
transaction衡量都要有标准在讨论12306前
搞技术的,要有起码的是非观念 by 老魏技术贴来了12306
数据库分票策略请老魏给出一个简单的文字解释
goodbug的设计为啥不能撑过100K/s?除了model view controller (mvc)这种pattern还有什么pattern流行?
分布式分票算法其实就是两党党争
为什么分布式搞不定12306?wei和好虫打的什么赌, 吧好虫搞自杀了?
大规模多核并发的系统PK大规模多机并发的系统铁路订票系统怎么强耦合了?12306绝对架构错了
说到底还是app 层 engineer 和 系统层engineer在斗法12306的后台数据库可以做到完全无耦合
相关话题的讨论汇总
话题: 12306话题: 多机话题: 能力话题: 架构话题: sql