T********i
发帖数: 2416 | |
h******b
发帖数: 6055 | 2 平心而论，古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
的。其实古德霸从投资到技术到篮球贴，给我的感觉就好像Amazon上销量排名最高的东
西一样，基本上都是大流，很少见他爆冷门的。 就算不是最优，你跟着他走基本上不
用担心会被坑。
您的架构，不是说不行，但至少在互联网很少见到。 众人皆梦我独醒，赵策这些人扣
上过时的帽子也是可以理解。
说到底就是成王败寇，古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
交易平台，还有新的家居平台要是出了名了，立刻就碾压板上所有不同意见了。 |
T********i
发帖数: 2416 | 3 我何时在乎过碾压本版的不同意见？
我是被人无中生有追着骂了两年多，找回一个公道而已。
我真不在乎什么不同意见。不能容忍的是无耻而已。
至于什么架构，版上见过世面也不少。没见过世面大多也不会不要廉耻。 |
g****u
发帖数: 252 | 4 netflix是一个媒体公司，技术做得好坏有很大的余地，做技术的成本控制也有很大的
余地，用netflix的搞法，去别的公司未必能行得通。
特定于这次12306的架构，你的观点我同意。就是如果自己技术水平一般且没什么
判断力，走goodbug的套路比走HFT的套路更靠谱。
【在 h******b 的大作中提到】
: 平心而论，古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴，给我的感觉就好像Amazon上销量排名最高的东
: 西一样，基本上都是大流，很少见他爆冷门的。 就算不是最优，你跟着他走基本上不
: 用担心会被坑。
: 您的架构，不是说不行，但至少在互联网很少见到。 众人皆梦我独醒，赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇，古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台，还有新的家居平台要是出了名了，立刻就碾压板上所有不同意见了。
|
T********i
发帖数: 2416 | 5 Netflix用C*也没错。我要是Netflix CTO也会这么搞。
问题是，并不是每个人都锤子眼里所有问题都是钉子的。就算有，连续两年多追着人骂
的，也是极品了。
【在 g****u 的大作中提到】
: netflix是一个媒体公司，技术做得好坏有很大的余地，做技术的成本控制也有很大的
: 余地，用netflix的搞法，去别的公司未必能行得通。
: 特定于这次12306的架构，你的观点我同意。就是如果自己技术水平一般且没什么
: 判断力，走goodbug的套路比走HFT的套路更靠谱。
|
p**r
发帖数: 5853 | 6 我没看你的代码，也没兴趣。
因为看你名字就已经很烦了。
【在 T********i 的大作中提到】
: 除了古德霸以外。
: 都报个名上来，让大家看看。
|
g********n
发帖数: 296 | 7 我更佩服古德霸，过去几年从他的帖子收益很多，也基本是从他的帖子和赵策的帖子
了解技术的大趋势的。
就具体问题而言， 我认为魏老师赢了。我搞了十几年的底层编程， 都不需要认真看老
魏的代码就可以知道他大致是对的。这不过暴露了古德吧底层不大熟而已。
两位都是大高手，都不要太计较言语得失了。欢迎两位接着发言。中国人在美国it混得
其实很惨，正需要二位指点啊。
【在 T********i 的大作中提到】
: 除了古德霸以外。
: 都报个名上来，让大家看看。
|
k**0
发帖数: 19737 | 8 你没看懂他们的设计， 两个都能做， 但是老魏的方按简洁实用， 要好很多。
【在 h******b 的大作中提到】
: 平心而论，古德霸提出的架构的确更容易让人接受。 毕竟现在大规模网站都是那么做
: 的。其实古德霸从投资到技术到篮球贴，给我的感觉就好像Amazon上销量排名最高的东
: 西一样，基本上都是大流，很少见他爆冷门的。 就算不是最优，你跟着他走基本上不
: 用担心会被坑。
: 您的架构，不是说不行，但至少在互联网很少见到。 众人皆梦我独醒，赵策这些人扣
: 上过时的帽子也是可以理解。
: 说到底就是成王败寇，古德霸好歹是netflix, 代表的就是当代最主流的架构。 您的
: 交易平台，还有新的家居平台要是出了名了，立刻就碾压板上所有不同意见了。
|
k**0
发帖数: 19737 | 9 这个事情很多人都应该当作一个lesson。
【在 g********n 的大作中提到】
: 我更佩服古德霸，过去几年从他的帖子收益很多，也基本是从他的帖子和赵策的帖子
: 了解技术的大趋势的。
: 就具体问题而言， 我认为魏老师赢了。我搞了十几年的底层编程， 都不需要认真看老
: 魏的代码就可以知道他大致是对的。这不过暴露了古德吧底层不大熟而已。
: 两位都是大高手，都不要太计较言语得失了。欢迎两位接着发言。中国人在美国it混得
: 其实很惨，正需要二位指点啊。
|
z****e
发帖数: 54598 | 10 快给我拉倒，老年人别丢人了
单线程你做个屁transaction
要多傻叉才会把你的破烂当回事啊 |
|
|
z****e
发帖数: 54598 | 11
别逗了，见过谁用搞hft的搞法搞网站的？
脑残吗？
【在 g****u 的大作中提到】
: netflix是一个媒体公司，技术做得好坏有很大的余地，做技术的成本控制也有很大的
: 余地，用netflix的搞法，去别的公司未必能行得通。
: 特定于这次12306的架构，你的观点我同意。就是如果自己技术水平一般且没什么
: 判断力，走goodbug的套路比走HFT的套路更靠谱。
|
z****e
发帖数: 54598 | 12
别逗了
要多蠢才会觉得老魏的单机可行啊？
上个世纪的破烂，居然还有人捧
我的天，都是卖机器的吗？
【在 k**0 的大作中提到】
: 这个事情很多人都应该当作一个lesson。
|
z****e
发帖数: 54598 | 13
你觉得现实中票的操作就是内存中做一个标记那么简单是吧？
你给我找出来，什么票是内存中的int16的赋值操作
你找出来，哪怕是加拿大的灰狗都没有这么简单
【在 k**0 的大作中提到】
: 你没看懂他们的设计， 两个都能做， 但是老魏的方按简洁实用， 要好很多。
|
z****e
发帖数: 54598 | 14
那你去投标啊
看看会不会中
别光说不练啊
就我所知，就没有不学netflix搞法的公司
除了上个世纪的老年人学不会以外
现在连银联都是这套搞法
【在 g****u 的大作中提到】
: netflix是一个媒体公司，技术做得好坏有很大的余地，做技术的成本控制也有很大的
: 余地，用netflix的搞法，去别的公司未必能行得通。
: 特定于这次12306的架构，你的观点我同意。就是如果自己技术水平一般且没什么
: 判断力，走goodbug的套路比走HFT的套路更靠谱。
|
k******n
发帖数: 184 | 15 刚休假回来。 我之前好像有一些关于赌约的回复被删了，考古了会。
姓wei的po出了东西，大致看了下代码和协议， 我觉得就是做了一个找票的toy。 单机
，暴力查找， 无容灾备份的一个纯跑在mem上的程序， 各种列出来的条件似乎是特意
回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来，c++我不是很熟悉
， 但这离单机版的web service都不是， 差远了。
鉴于赌约就是如此， 我向姓wei的表示认输罢， 之前喷姓wei的应下赌约就是看不惯之
前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派， 恶心死了
。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢， 你能po出东
西就行， 即便最后是玩具至少也比之前那一套做派好得多。
赌约我认输，不过赌约之外这还是个toy, 单机server没有资格谈架构。 |
k******n
发帖数: 184 | 16
agree, 劣币驱逐良币的lesson。
【在 k**0 的大作中提到】
: 这个事情很多人都应该当作一个lesson。
|
T********i
发帖数: 2416 | 17 当时我offer了两次，你们一起上，同样条件，能做到1M/s，连网络服务都不用，就算
你们赢。
你当时没卵子，现在咋有脸上来？你的脸皮和廉耻都被狗吃了？
你FB的。我记得你。
【在 k******n 的大作中提到】
:
: agree, 劣币驱逐良币的lesson。
|
k******n
发帖数: 184 | 18
就你offer个屁呀。
要不是你撒泼打滚说必须3个人都接赌约才写出这个toy的模样我才懒得接，另外一个人
的是linear scalability你到底接了没有我就不记得了， 你自己立了赌约急着催别人
接到底为什么你还不知道吗？ 要不应着你刻意设计的单机版赌约你就尽着做attension
whore了， 哪个帖子没打脸哪个帖子重新开。
我比你年轻，但我rp比你好得多， 就算你做的是toy我也认输了。 我可不像你时时刻
刻在坛子里。
bye, toyman。
【在 T********i 的大作中提到】
: 当时我offer了两次，你们一起上，同样条件，能做到1M/s，连网络服务都不用，就算
: 你们赢。
: 你当时没卵子，现在咋有脸上来？你的脸皮和廉耻都被狗吃了？
: 你FB的。我记得你。
|
T********i
发帖数: 2416 | 19 你真有脸说。直接说你自己狗屁不懂算了。赚多少钱也改变不了你自己的智商。
【在 k******n 的大作中提到】
:
: 就你offer个屁呀。
: 要不是你撒泼打滚说必须3个人都接赌约才写出这个toy的模样我才懒得接，另外一个人
: 的是linear scalability你到底接了没有我就不记得了， 你自己立了赌约急着催别人
: 接到底为什么你还不知道吗？ 要不应着你刻意设计的单机版赌约你就尽着做attension
: whore了， 哪个帖子没打脸哪个帖子重新开。
: 我比你年轻，但我rp比你好得多， 就算你做的是toy我也认输了。 我可不像你时时刻
: 刻在坛子里。
: bye, toyman。
|
k******n
发帖数: 184 | 20
我智商是一般， 门萨普通会员，也就2%而已。 你去judge门萨的bar吧lol
不和你犟嘴了， 和40多岁的人为个玩具扯来扯去没意思。
【在 T********i 的大作中提到】
: 你真有脸说。直接说你自己狗屁不懂算了。赚多少钱也改变不了你自己的智商。
|
|
|
T********i
发帖数: 2416 | 21 有用么？无知和无耻都被你占全了。尤其是无耻这一条，连你们FB的同时都看不下去了。
你有种就继续。
【在 k******n 的大作中提到】
:
: 我智商是一般， 门萨普通会员，也就2%而已。 你去judge门萨的bar吧lol
: 不和你犟嘴了， 和40多岁的人为个玩具扯来扯去没意思。
|
a*********a
发帖数: 3656 | 22 拌凳子瞻仰门萨会员。
【在 k******n 的大作中提到】
:
: 我智商是一般， 门萨普通会员，也就2%而已。 你去judge门萨的bar吧lol
: 不和你犟嘴了， 和40多岁的人为个玩具扯来扯去没意思。
|
k**0
发帖数: 19737 | 23 你那个架构加上退票联票更本就是（分布）锁得一塌糊涂，在设计上老魏的方按优化好
得多。
这个问题上次就说过了，堆机器也有聪明的堆法，这没什么可多讨论的了。
【在 z****e 的大作中提到】
:
: 那你去投标啊
: 看看会不会中
: 别光说不练啊
: 就我所知，就没有不学netflix搞法的公司
: 除了上个世纪的老年人学不会以外
: 现在连银联都是这套搞法
|
k**0
发帖数: 19737 | 24 知识没有好坏之分，懂多一点是没有坏处的
【在 k******n 的大作中提到】
:
: 我智商是一般， 门萨普通会员，也就2%而已。 你去judge门萨的bar吧lol
: 不和你犟嘴了， 和40多岁的人为个玩具扯来扯去没意思。
|
k******n
发帖数: 184 | 25
不带上下文你这句话说得对。 其实就算带了上下文， 我也许也可以看代码学一些c++
的用法， 不过平常工作不用倒一会就忘了。
【在 k**0 的大作中提到】
: 知识没有好坏之分，懂多一点是没有坏处的
|
T********i
发帖数: 2416 | 26 Boy! You made my day.
【在 k******n 的大作中提到】
:
: 不带上下文你这句话说得对。 其实就算带了上下文， 我也许也可以看代码学一些c++
: 的用法， 不过平常工作不用倒一会就忘了。
|
g********n
发帖数: 296 | 27 我是古德吧的扇子， 但就具体问题而言，我认为老魏是这些问题的专家，古派甚至
都没有搞清楚问题的实质。
在这里做一个标记就是关键问题，业务逻辑再复杂， 都可以推到别的core，可以有
各种方案。古派对这些问题甚至没有数量级的概念， 不认输是不行的。做java的人不
一定知道如何把thread安排到不同的指定的ｃｏｒｅ，这没关系，但要在这些领域与老
魏较量，你们实在赢不了。
当然工业界一般用你们的方案，这有别的原因。
老魏也别得势不饶人，你的水平有CODE作证了，不必多说了：）
【在 T********i 的大作中提到】
: 除了古德霸以外。
: 都报个名上来，让大家看看。
|
d***a
发帖数: 13752 | 28 我同意这两个观点。老魏的做法，属于非常传统，六七十年代mainframe上的做法。对
于这个具体的问题，传统做法可以比分布式的做法效率高得多，一台机器可以抵过成千
上万台机器（如果不是更多）。但另一方面，国人掐架不应该搞得这么厉害。技术讨论
，就事论事，对和错都可以学到东西。不要人参公鸡，没什么意思。
【在 g********n 的大作中提到】
: 我是古德吧的扇子， 但就具体问题而言，我认为老魏是这些问题的专家，古派甚至
: 都没有搞清楚问题的实质。
: 在这里做一个标记就是关键问题，业务逻辑再复杂， 都可以推到别的core，可以有
: 各种方案。古派对这些问题甚至没有数量级的概念， 不认输是不行的。做java的人不
: 一定知道如何把thread安排到不同的指定的ｃｏｒｅ，这没关系，但要在这些领域与老
: 魏较量，你们实在赢不了。
: 当然工业界一般用你们的方案，这有别的原因。
: 老魏也别得势不饶人，你的水平有CODE作证了，不必多说了：）
|
b*******s
发帖数: 5216 | 29 其实你没看懂,不管是好虫还是老q,他们的方案都是用户体验不行的
另外技术是迭代进步的，云计算问题解决得差不多的时候，也就不是显学了
【在 d***a 的大作中提到】
: 我同意这两个观点。老魏的做法，属于非常传统，六七十年代mainframe上的做法。对
: 于这个具体的问题，传统做法可以比分布式的做法效率高得多，一台机器可以抵过成千
: 上万台机器（如果不是更多）。但另一方面，国人掐架不应该搞得这么厉害。技术讨论
: ，就事论事，对和错都可以学到东西。不要人参公鸡，没什么意思。
|
w***g
发帖数: 5958 | 30 云计算本来就不是什么显学。云计算是“不需要学”，直接可以上手的。
【在 b*******s 的大作中提到】
: 其实你没看懂,不管是好虫还是老q,他们的方案都是用户体验不行的
: 另外技术是迭代进步的，云计算问题解决得差不多的时候，也就不是显学了
|
|
|
k**0
发帖数: 19737 | 31 你没看懂
【在 d***a 的大作中提到】
: 我同意这两个观点。老魏的做法，属于非常传统，六七十年代mainframe上的做法。对
: 于这个具体的问题，传统做法可以比分布式的做法效率高得多，一台机器可以抵过成千
: 上万台机器（如果不是更多）。但另一方面，国人掐架不应该搞得这么厉害。技术讨论
: ，就事论事，对和错都可以学到东西。不要人参公鸡，没什么意思。
|
b*******s
发帖数: 5216 | 32 从市场反应来说这阵子和数据挖掘都是显学，起码给得还不错
【在 w***g 的大作中提到】
: 云计算本来就不是什么显学。云计算是“不需要学”，直接可以上手的。
|
d***a
发帖数: 13752 | 33 要我说，云计算就是一个炒出来的概念。这个俺都炒过。:)
【在 w***g 的大作中提到】
: 云计算本来就不是什么显学。云计算是“不需要学”，直接可以上手的。
|
a****i
发帖数: 1182 | 34 我就说这个赌只不过证明了后面的确没有了。就是一个计数器。连他自已说的“全国一
盘棋”都没有，联票是必须的。
【在 k******n 的大作中提到】
: 刚休假回来。 我之前好像有一些关于赌约的回复被删了，考古了会。
: 姓wei的po出了东西，大致看了下代码和协议， 我觉得就是做了一个找票的toy。 单机
: ，暴力查找， 无容灾备份的一个纯跑在mem上的程序， 各种列出来的条件似乎是特意
: 回避了真正的瓶颈。 也可能有什么特殊的地方我水平不够没看出来，c++我不是很熟悉
: ， 但这离单机版的web service都不是， 差远了。
: 鉴于赌约就是如此， 我向姓wei的表示认输罢， 之前喷姓wei的应下赌约就是看不惯之
: 前报告hr和只说不做的被打脸了动不动新开帖attention whore那一套做派， 恶心死了
: 。 我没怎么仔细看赌约条款也没在乎里边有没有陷阱以及并不care输赢， 你能po出东
: 西就行， 即便最后是玩具至少也比之前那一套做派好得多。
: 赌约我认输，不过赌约之外这还是个toy, 单机server没有资格谈架构。
|
T********i
发帖数: 2416 | 35 现在还纠结联票的。真让我无话可说。
【在 a****i 的大作中提到】
: 我就说这个赌只不过证明了后面的确没有了。就是一个计数器。连他自已说的“全国一
: 盘棋”都没有，联票是必须的。
|
n*******7
发帖数: 181 | 36 说别人“后面没有”的能不能先拿出个前面有后面有的方案？
这方面qxc做得很好。他拿出了一个方案。我们就可以具体分析讨论，共同学习提高。
请aaaiii (酱爆)先说说是否赞同qxc的方案，是不是这个方案前面后面都有了。如果不
是，自己有何补充，还是可以另外拿出一套更好的？
先亮出一套自己觉得该有都有的方案来与老魏的code比较，再说老魏的code什么没有
才有意义。
【在 a****i 的大作中提到】
: 我就说这个赌只不过证明了后面的确没有了。就是一个计数器。连他自已说的“全国一
: 盘棋”都没有，联票是必须的。
|
a****i
发帖数: 1182 | 37 qxc的方案我当然赞同啊，有前有后，完整的一套
弄个计数器就唬倒一片也是挺奇怪的
前端的路线选择，换车，后面的付款出票；中间不买了，票怎么返回……
谈的是12306的方案是不？
你要是追一年多前的，TW开始号称是web服务器也放在这个单机上
“最佳方案，没有之一”的那种
【在 n*******7 的大作中提到】
: 说别人“后面没有”的能不能先拿出个前面有后面有的方案？
: 这方面qxc做得很好。他拿出了一个方案。我们就可以具体分析讨论，共同学习提高。
: 请aaaiii (酱爆)先说说是否赞同qxc的方案，是不是这个方案前面后面都有了。如果不
: 是，自己有何补充，还是可以另外拿出一套更好的？
: 先亮出一套自己觉得该有都有的方案来与老魏的code比较，再说老魏的code什么没有
: 才有意义。
|
n*******7
发帖数: 181 | 38 按你的意见老魏的方案只是个计数器。那么你说说qxc方案里的5000个db
是不是计数器？
我们在qxc帖子里已经详细讨论比较了。老魏的方案其实就是db实现的
优化版，功能和scalability完全相同，除了更快没有区别。
你同意这个结论吗？如果不同意请说出来它们有什么不同,到底有什么地方qxc的db
做到而老魏的计数器没做到的。
如果同意，那你是在说qxc那5000个db也只是个计数器？你看qxc答应不答应。:)
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊，有前有后，完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择，换车，后面的付款出票；中间不买了，票怎么返回……
: 谈的是12306的方案是不？
: 你要是追一年多前的，TW开始号称是web服务器也放在这个单机上
: “最佳方案，没有之一”的那种
|
n*******7
发帖数: 181 | 39 再来讨论“后面”。：）
先探讨一下在qxc方案里什么是关键核心部分。应该不是web界面，不是对5000 后端db
分发锁票请求的中间服务器，而就是那存着所有余票的找票锁票的5000 后端 db。这应该
没有什么异议吧？
老魏的code直接就是那5000 db的drop-in replacement，以高得多的效率完成同样的功
能。 你说qxc 方案是完整的一套。那么老魏code 加上 qxc 方案去掉5000 db后的其它
非关键外围逻辑，是不是就是完整的一套？
所以，老魏code就是实现了qxc的12306的方案的关键核心部分。后面就是qxc方案里的
那些外围逻辑。怎么能说后面没有了？
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊，有前有后，完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择，换车，后面的付款出票；中间不买了，票怎么返回……
: 谈的是12306的方案是不？
: 你要是追一年多前的，TW开始号称是web服务器也放在这个单机上
: “最佳方案，没有之一”的那种
|
d***a
发帖数: 13752 | 40 理解票务中央调度方案（老魏称之为抢票机）的关键是，票务调度并不参与ACID。票务
调度只是给一个预售票方案，实际售票还是由前端票务机和后端数据库机来完成。
有了票务调度，前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位
。如果在卖票过程中出了问题，因为数据库系统有ACID的支持，不会出现卖了票却没收
到钱，或者联票卖出了一段，另一段却拿不到座位的情况。
从系统设计角度来说，票务中央调度大大降低了后端数据库机的负担。在同等硬件下，
系统吞吐量大增。否则后端数据库机系统得做得很大，用非常多的机器才能满足查询和
预占空位的请求。票务调度是一个紧密耦合的计算任务，用一台机器集中来做，比用成
千上万台机器来做，效率要高得多。
我说的这个方案，和老魏的方案可能稍有（或没有）不同。我没有跟后来的争论，有些
细节不是很了解。两年前，这版上有不少人是支持票务调度的集中式处理方案的。这个
方案从总体上说，是不难理解的。吵成这个样子，实在是过了。
【在 a****i 的大作中提到】
: qxc的方案我当然赞同啊，有前有后，完整的一套
: 弄个计数器就唬倒一片也是挺奇怪的
: 前端的路线选择，换车，后面的付款出票；中间不买了，票怎么返回……
: 谈的是12306的方案是不？
: 你要是追一年多前的，TW开始号称是web服务器也放在这个单机上
: “最佳方案，没有之一”的那种
|
|
|
T********i
发帖数: 2416 | 41 咱俩说的基本一码事。
你看看好虫两年前发的帖子：《应该给魏大师发10个图灵奖》
http://www.mitbbs.com/article_t1/Programming/31287951_0_1.html
对单机核心和ACID冷嘲热讽。
这两年，我是一直被恩追着骂的。这么简单的道理，非要写代码。写了代码还有人不懂
，也是醉了。
【在 d***a 的大作中提到】
: 理解票务中央调度方案（老魏称之为抢票机）的关键是，票务调度并不参与ACID。票务
: 调度只是给一个预售票方案，实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度，前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位
: 。如果在卖票过程中出了问题，因为数据库系统有ACID的支持，不会出现卖了票却没收
: 到钱，或者联票卖出了一段，另一段却拿不到座位的情况。
: 从系统设计角度来说，票务中央调度大大降低了后端数据库机的负担。在同等硬件下，
: 系统吞吐量大增。否则后端数据库机系统得做得很大，用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务，用一台机器集中来做，比用成
: 千上万台机器来做，效率要高得多。
: 我说的这个方案，和老魏的方案可能稍有（或没有）不同。我没有跟后来的争论，有些
|
n*******7
发帖数: 181 | 42 很多人就是接受不了用一台机子集中做，认为是上个世纪的，不符合他们现代的分布式
理念。
【在 d***a 的大作中提到】
: 理解票务中央调度方案（老魏称之为抢票机）的关键是，票务调度并不参与ACID。票务
: 调度只是给一个预售票方案，实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度，前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位
: 。如果在卖票过程中出了问题，因为数据库系统有ACID的支持，不会出现卖了票却没收
: 到钱，或者联票卖出了一段，另一段却拿不到座位的情况。
: 从系统设计角度来说，票务中央调度大大降低了后端数据库机的负担。在同等硬件下，
: 系统吞吐量大增。否则后端数据库机系统得做得很大，用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务，用一台机器集中来做，比用成
: 千上万台机器来做，效率要高得多。
: 我说的这个方案，和老魏的方案可能稍有（或没有）不同。我没有跟后来的争论，有些
|
c****3
发帖数: 10787 | 43 没办法，搞软件的很多人就是没法接受“条条大路通罗马”这个基本道理。觉得自己喜
欢的才是真理，其他都是歪门邪道。
搞软件就是在公司看谁的权势大，势力大就能控制方向。其实只要不离谱，其实各种方
法都能走通，达到完成任务的结果。最后差别就是效率差别和用户反应好坏不同而已。
【在 n*******7 的大作中提到】
: 很多人就是接受不了用一台机子集中做，认为是上个世纪的，不符合他们现代的分布式
: 理念。
|
a****i
发帖数: 1182 | 44 你说的是票务调度，而我说的是整个12306
12306是从查票到抢票到付款买票再加上退票。只有抢票快，就是最佳方案了？
你觉得分布式就不能做票务调度还是怎么的？我把票都load到redis里行不行？在redis
里做调度行不行？
用redis做replication，你要砸哪台机器？
前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位…
这不就是好虫和qxz的分布式设计嘛
我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
卖票过程中出了问题，因为数据库系统有ACID的支持, 那不还是好虫他们的设计？
【在 d***a 的大作中提到】
: 理解票务中央调度方案（老魏称之为抢票机）的关键是，票务调度并不参与ACID。票务
: 调度只是给一个预售票方案，实际售票还是由前端票务机和后端数据库机来完成。
: 有了票务调度，前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位
: 。如果在卖票过程中出了问题，因为数据库系统有ACID的支持，不会出现卖了票却没收
: 到钱，或者联票卖出了一段，另一段却拿不到座位的情况。
: 从系统设计角度来说，票务中央调度大大降低了后端数据库机的负担。在同等硬件下，
: 系统吞吐量大增。否则后端数据库机系统得做得很大，用非常多的机器才能满足查询和
: 预占空位的请求。票务调度是一个紧密耦合的计算任务，用一台机器集中来做，比用成
: 千上万台机器来做，效率要高得多。
: 我说的这个方案，和老魏的方案可能稍有（或没有）不同。我没有跟后来的争论，有些
|
d***a
发帖数: 13752 | 45 别这么激动...你这么做当然可以，机器资源投入足够大就行。这里只是做技术性讨论
，看哪一种方案效率高。
如前面所说，很多方案最终都可以达到结果，只不过效率不同。在公司里，很多时候并
不是以技术决定谁的方案会被使用，是看谁的power更大。一个低效的方案，多砸几十
倍的资金，有的时候也可行。但不是任何时候都可行，要看具体的问题，对性能的需要
有多大，等等。
象12306的问题，按他们现有的系统架构，我个人觉得，要保证春运时不崩溃，加几倍
甚至十倍的硬件投入，都不知道能不能保证。但从领导的角度来说，加硬件是最简单的
，并且可以让本部门的重要性进一步提高，也许是更好的办法。
至于你后面说的方案，并不是12306现有的系统架构吧。把查询和预占空位的功能从数
据库系统里拿出来，另外用一个分布式的构件来实现，当然可以。但是这个功能，用单
机来实现，在性能上绰绰有余，在实现上简单得多，也可靠得多，那为什么要用分布式
的做法呢？当然，如果你从哲学角度出发，一定要用分布式的做法，也是可以的，但这
并不意味着单机方案本身在技术上有什么问题。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度，而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快，就是最佳方案了？
: 你觉得分布式就不能做票务调度还是怎么的？我把票都load到redis里行不行？在redis
: 里做调度行不行？
: 用redis做replication，你要砸哪台机器？
: 前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题，因为数据库系统有ACID的支持, 那不还是好虫他们的设计？
|
T********i
发帖数: 2416 | 46 其实吧，我这个人确实说话比较直接。我也知道，这么大岁数了，不想改，也改不了了。
直接跟你讲，redis做调度不行。不服你就拿代码出来。给我们讲清楚，加一个redis有
啥用？能起什么正面作用？
我刚才讲了奥卡姆剃刀原则。如无必要，勿增实体。这个原则，我的IoT平台网站上就
有。
另外给你讲，我的方案，不知抢票快，查询更快，退票也是最快，没有之一。
至于付款，我不想说。该咋办咋办，这种能够无限scale out的，我懒的说。
redis
【在 a****i 的大作中提到】
: 你说的是票务调度，而我说的是整个12306
: 12306是从查票到抢票到付款买票再加上退票。只有抢票快，就是最佳方案了？
: 你觉得分布式就不能做票务调度还是怎么的？我把票都load到redis里行不行？在redis
: 里做调度行不行？
: 用redis做replication，你要砸哪台机器？
: 前端票务机不用去后端数据库机做费时的查找，就能找到和预占据空位…
: 这不就是好虫和qxz的分布式设计嘛
: 我不知道你们怎么老想着会去查数据库。起码的cache概念能有吧。
: 卖票过程中出了问题，因为数据库系统有ACID的支持, 那不还是好虫他们的设计？
|
b*******s
发帖数: 5216 | 47 还是老话，合格程序员得有三个本事
会造轮子
知道什么时候不造轮子
知道什么时候造轮子
不能偏执 |
