T********i
发帖数: 2416 | 1 我的铁路售票系统的架构已经说的很清楚了。
www.mitbbs.com/article_t/Programming/31298609.html
如果铁道部要求系统数据是紧耦合的，那么我的架构是性能最好的。所谓的分布式架构
不可能比我的性能好。没啥好讨论的。
事实上根据现在的情况看来。数据紧耦合确实是有这个要求的。至少能够购买联票带来
的用户体验是最好的。
这个系统抢票的核心确实是单机。提供最好的性能。而且杜绝超卖。多台单机串一串提
供跨DC的可靠性，应该是正常智商就能想到的。
其实，添加无限数量的state cache server预先过滤一下。只有state cache server显
示有票才放用户到核心去抢票。这个系统可以无限scale out的。这也是正常智商就能
想到的。但是，单机核心的重要性不因state cache的引入而有丝毫减弱。
这个系统设计和实现都很简单。不能因为你不会做，就假定别人做不出来。你的所谓
“Your monolithic design make every single line of your code hardly reusable
in the parallel world.” 是不成立的。
退10000步来讲，即使不要求数据紧耦合。这个设计也是最简单可靠的。而且工程上讲
究足够用就好。这个设计用1/10甚至1/100数量的机器，就能满足来自全太阳系的网购
压力，足够了。而且，如果不要求数据紧耦合，也可以依样复制scale out。
至于你另外那些题外话，我感觉没意思，就不讨论了。 |
N******K
发帖数: 10202 | 2 你什么时候开源一套代码 大家学习一下
【在 T********i 的大作中提到】
: 我的铁路售票系统的架构已经说的很清楚了。
: www.mitbbs.com/article_t/Programming/31298609.html
: 如果铁道部要求系统数据是紧耦合的，那么我的架构是性能最好的。所谓的分布式架构
: 不可能比我的性能好。没啥好讨论的。
: 事实上根据现在的情况看来。数据紧耦合确实是有这个要求的。至少能够购买联票带来
: 的用户体验是最好的。
: 这个系统抢票的核心确实是单机。提供最好的性能。而且杜绝超卖。多台单机串一串提
: 供跨DC的可靠性，应该是正常智商就能想到的。
: 其实，添加无限数量的state cache server预先过滤一下。只有state cache server显
: 示有票才放用户到核心去抢票。这个系统可以无限scale out的。这也是正常智商就能
|
z****e
发帖数: 54598 | 3 老魏你更适合搞物联网
这种系统你就不要凑热闹了
第一句话还没说完，前半句就是错的
后面的所有都是建立在一个错误的前提上
【在 T********i 的大作中提到】
: 我的铁路售票系统的架构已经说的很清楚了。
: www.mitbbs.com/article_t/Programming/31298609.html
: 如果铁道部要求系统数据是紧耦合的，那么我的架构是性能最好的。所谓的分布式架构
: 不可能比我的性能好。没啥好讨论的。
: 事实上根据现在的情况看来。数据紧耦合确实是有这个要求的。至少能够购买联票带来
: 的用户体验是最好的。
: 这个系统抢票的核心确实是单机。提供最好的性能。而且杜绝超卖。多台单机串一串提
: 供跨DC的可靠性，应该是正常智商就能想到的。
: 其实，添加无限数量的state cache server预先过滤一下。只有state cache server显
: 示有票才放用户到核心去抢票。这个系统可以无限scale out的。这也是正常智商就能
|
T********i
发帖数: 2416 | 4 其实，真正需要开源的，也就那么几百行代码。等10年以后吧。
【在 N******K 的大作中提到】
: 你什么时候开源一套代码 大家学习一下
|
n****1
发帖数: 1136 | 5 How many threads do you prepare to use, except the 2 dealing with NIC?
Single thread or 14 thread? If multi-threaded, is their job symmetric? Why 1
thread is not enough, but 14 thread is enough for the whole solar system?
How is the data shared between them? Does each thread read/write a common
block of memory, or memory are thread-local? How to do inter-thread
communication?
If every thread read/write the same block of memory, how to ensure thread-
safety and no dead-lock? Don't say you are careful enough, you need a formal
proof base on your data model. Goodbug's solution is local-memory, so he
don't need to worry about this.
If threads' memory are not shared, how different is this compare to threads
running on multiple machines?
【在 T********i 的大作中提到】
: 我的铁路售票系统的架构已经说的很清楚了。
: www.mitbbs.com/article_t/Programming/31298609.html
: 如果铁道部要求系统数据是紧耦合的，那么我的架构是性能最好的。所谓的分布式架构
: 不可能比我的性能好。没啥好讨论的。
: 事实上根据现在的情况看来。数据紧耦合确实是有这个要求的。至少能够购买联票带来
: 的用户体验是最好的。
: 这个系统抢票的核心确实是单机。提供最好的性能。而且杜绝超卖。多台单机串一串提
: 供跨DC的可靠性，应该是正常智商就能想到的。
: 其实，添加无限数量的state cache server预先过滤一下。只有state cache server显
: 示有票才放用户到核心去抢票。这个系统可以无限scale out的。这也是正常智商就能
|
n****1
发帖数: 1136 | 6 And if you are really that into performance, why not use a GPU? Solve the
problem with <$5000, right? |
T********i
发帖数: 2416 | 7 你先确认这个架构逻辑上没问题。才可能讨论剩下的。
核心一串单机，只有打头的负责实现抢票。请求消息进来，如果抢不到，直接拒绝。如
果抢到了，消息发给后面的一台。后面的一台收到消息，转发给一串中下一台，同时更
新状态。
核心一串最后一台收到消息，发ack向上传递，直到传给第一台，核心抢票transaction
完成。实现eventual consistency。
核心消息就是transaction log，而且是journal log。如果任何一台或多台核心机死掉
，花一点点毫秒级重新拓扑，sync一点journal log，实现eventual consistency。
在eventual consistency的条件下，系统同时满足CAP。
如果你不认可上面这些，没必要继续讨论下去。
1
formal
【在 n****1 的大作中提到】
: How many threads do you prepare to use, except the 2 dealing with NIC?
: Single thread or 14 thread? If multi-threaded, is their job symmetric? Why 1
: thread is not enough, but 14 thread is enough for the whole solar system?
: How is the data shared between them? Does each thread read/write a common
: block of memory, or memory are thread-local? How to do inter-thread
: communication?
: If every thread read/write the same block of memory, how to ensure thread-
: safety and no dead-lock? Don't say you are careful enough, you need a formal
: proof base on your data model. Goodbug's solution is local-memory, so he
: don't need to worry about this.
|
n****1
发帖数: 1136 | 8 我这不就是在确认架构逻辑是否有问题么? 这些问题都是架构的一部分. 逻辑没问题的
话讨论就结束了.
transaction
【在 T********i 的大作中提到】
: 你先确认这个架构逻辑上没问题。才可能讨论剩下的。
: 核心一串单机，只有打头的负责实现抢票。请求消息进来，如果抢不到，直接拒绝。如
: 果抢到了，消息发给后面的一台。后面的一台收到消息，转发给一串中下一台，同时更
: 新状态。
: 核心一串最后一台收到消息，发ack向上传递，直到传给第一台，核心抢票transaction
: 完成。实现eventual consistency。
: 核心消息就是transaction log，而且是journal log。如果任何一台或多台核心机死掉
: ，花一点点毫秒级重新拓扑，sync一点journal log，实现eventual consistency。
: 在eventual consistency的条件下，系统同时满足CAP。
: 如果你不认可上面这些，没必要继续讨论下去。
|
T********i
发帖数: 2416 | 9 lock free sync技术很成熟。
先不论性能。假定核心每台单机都是单线程。你需要判断架构可靠性有无问题。
如果这个你判断不了，就没必要讨论了。
【在 n****1 的大作中提到】
: 我这不就是在确认架构逻辑是否有问题么? 这些问题都是架构的一部分. 逻辑没问题的
: 话讨论就结束了.
:
: transaction
|
N******K
发帖数: 10202 | 10 GPU是搞计算的 不是搞IO的
【在 n****1 的大作中提到】
: And if you are really that into performance, why not use a GPU? Solve the
: problem with <$5000, right?
|
|
|
n****1
发帖数: 1136 | 11 IO我同意用in ram db, 性能到顶了吧.
可余票计算与同步, 还有联程票最优化方案, 都要很高计算能力的. 莫非吹鼓单机的都
以为queue/schedule这么复杂的问题没有计算量? 这可是CS研究了几十年的问题.
【在 N******K 的大作中提到】
: GPU是搞计算的 不是搞IO的
|
n****1
发帖数: 1136 | 12 你指哪方面问题?
核心单线程不用考虑上锁, 自然没死锁, 不用管同步. 如果一秒钟只需要处理一个
request, 8086的cpu都没问题.
可是目前的数据量, 你跑单线程是会socket buffer overflow的, 没准还能把cpu烧坏.
现在系统里有多个要处理的问题: IO性能, 内存大小, cpu性能.
你搞in ram memory, 上大内存, 我都不反对, 可这只解决前两个问题. CPU要求高是因
为票的分配与组合逻辑本身非常复杂, 单线程受不了, 单机多线程也够呛, 最后只能上
多机.
【在 T********i 的大作中提到】
: lock free sync技术很成熟。
: 先不论性能。假定核心每台单机都是单线程。你需要判断架构可靠性有无问题。
: 如果这个你判断不了，就没必要讨论了。
|
T********i
发帖数: 2416 | 13 以前的讨论。Goodbug从来都分析不清楚这个架构。
他一口咬定，这个架构consistency不能保证。一旦核心任何机器死掉会丢数据。
如果你也这样认为，那没必要讨论。
如果你认为没有这些问题，同时你说uo没问题。至少说明goodbug脑袋进屎。
坏.
【在 n****1 的大作中提到】
: 你指哪方面问题?
: 核心单线程不用考虑上锁, 自然没死锁, 不用管同步. 如果一秒钟只需要处理一个
: request, 8086的cpu都没问题.
: 可是目前的数据量, 你跑单线程是会socket buffer overflow的, 没准还能把cpu烧坏.
: 现在系统里有多个要处理的问题: IO性能, 内存大小, cpu性能.
: 你搞in ram memory, 上大内存, 我都不反对, 可这只解决前两个问题. CPU要求高是因
: 为票的分配与组合逻辑本身非常复杂, 单线程受不了, 单机多线程也够呛, 最后只能上
: 多机.
|
n****1
发帖数: 1136 | 14 我不喜欢PA啊, 各人有自己的bias, 我也会有, 没必要上纲上线对骂的.
In ram db这个挺好的, 连google也在做. 我也同意搞创新的不能太risk averse, 只要
对新方案的缺点心知肚明就行, 不能因为没有successful business case就一棍子打死.
假定in ram db可以让你在单线程下的data consistence得到保证, 你怎么解决这个级
别的计算复杂度?
【在 T********i 的大作中提到】
: 以前的讨论。Goodbug从来都分析不清楚这个架构。
: 他一口咬定，这个架构consistency不能保证。一旦核心任何机器死掉会丢数据。
: 如果你也这样认为，那没必要讨论。
: 如果你认为没有这些问题，同时你说uo没问题。至少说明goodbug脑袋进屎。
:
: 坏.
|
g*****g
发帖数: 34805 | 15 魏公公你还有脸谈架构，无数人前仆后继给你打补丁，才勉强弄出个in memory db
cluster出来，
而且也不是不会丢数据，又延迟的网络传输，机器又会当，怎么可能保证不丢数据。
当然你最傻逼的就是吹破了天，单机秒了nasdaq峰值几百倍，丢人了都不敢出来混了。
这下觉得风头过了要出来翻案了是吧？
【在 T********i 的大作中提到】
: 以前的讨论。Goodbug从来都分析不清楚这个架构。
: 他一口咬定，这个架构consistency不能保证。一旦核心任何机器死掉会丢数据。
: 如果你也这样认为，那没必要讨论。
: 如果你认为没有这些问题，同时你说uo没问题。至少说明goodbug脑袋进屎。
:
: 坏.
|
T********i
发帖数: 2416 | 16 操你妈的你这两天每个帖子都PA我。给你讲道理消停了换一个帖子继续重复那些无脑傻
逼言论。
你这种人就是找抽型的。我走哪里见到你这样的都要直接打脸。
你是不是不要脸了？给你讲NASDAQ要保持book需要CPU计算你隔天就忘了。你是不是记
忆力只有半天智商低于80？你老爸当年把你射到墙上又被你妈捡回来的？先天脑残？才
会6行代码7个错误。
【在 g*****g 的大作中提到】
: 魏公公你还有脸谈架构，无数人前仆后继给你打补丁，才勉强弄出个in memory db
: cluster出来，
: 而且也不是不会丢数据，又延迟的网络传输，机器又会当，怎么可能保证不丢数据。
: 当然你最傻逼的就是吹破了天，单机秒了nasdaq峰值几百倍，丢人了都不敢出来混了。
: 这下觉得风头过了要出来翻案了是吧？
|
g*****g
发帖数: 34805 | 17 傻逼你又来了，才消停了几天，他妈的又来死撑。
nasdaq同样是io bound, 你丫死皮赖脸还有啥说的。
再说了，你单机秒了nasdaq几百倍，慢几百倍也是单机能撑nasdaq.
现在知道吹破脸皮傻逼了吧。你这种太监，server端应用都没做过，也有脸出来吹。
【在 T********i 的大作中提到】
: 操你妈的你这两天每个帖子都PA我。给你讲道理消停了换一个帖子继续重复那些无脑傻
: 逼言论。
: 你这种人就是找抽型的。我走哪里见到你这样的都要直接打脸。
: 你是不是不要脸了？给你讲NASDAQ要保持book需要CPU计算你隔天就忘了。你是不是记
: 忆力只有半天智商低于80？你老爸当年把你射到墙上又被你妈捡回来的？先天脑残？才
: 会6行代码7个错误。
|
T********i
发帖数: 2416 | 18 你懂什么IO？
6行IO程序7个错误。
还有脸在这里谈IO？
真知耻的话应该去死。把祖宗的脸都丢尽了。
【在 g*****g 的大作中提到】
: 傻逼你又来了，才消停了几天，他妈的又来死撑。
: nasdaq同样是io bound, 你丫死皮赖脸还有啥说的。
: 再说了，你单机秒了nasdaq几百倍，慢几百倍也是单机能撑nasdaq.
: 现在知道吹破脸皮傻逼了吧。你这种太监，server端应用都没做过，也有脸出来吹。
|
g*****g
发帖数: 34805 | 19 错误没啥，我没吹牛，吹牛吹破了，下面没有，变成太监了。难怪叫魏公公，家传的。
【在 T********i 的大作中提到】
: 你懂什么IO？
: 6行IO程序7个错误。
: 还有脸在这里谈IO？
: 真知耻的话应该去死。把祖宗的脸都丢尽了。
|
T********i
发帖数: 2416 | 20 不懂装懂不是吹牛？你好意思说你懂IO么？
不懂在这儿上窜下跳？看看你上面的帖子。张口IO闭口IO。跟我谈IO你有这个资格么？
看你这个操性，就能想象你爹妈啥样。你这是暴露了整个家族。
【在 g*****g 的大作中提到】
: 错误没啥，我没吹牛，吹牛吹破了，下面没有，变成太监了。难怪叫魏公公，家传的。
|
|
|
T********i
发帖数: 2416 | 21 你先给我一个确定的答复。
首先这个方案至少在设计上能保证consistency和availability。
请给个确定的答复，你同意不同意？如果这个你不能确定，没必要和你讨论。
死.
【在 n****1 的大作中提到】
: 我不喜欢PA啊, 各人有自己的bias, 我也会有, 没必要上纲上线对骂的.
: In ram db这个挺好的, 连google也在做. 我也同意搞创新的不能太risk averse, 只要
: 对新方案的缺点心知肚明就行, 不能因为没有successful business case就一棍子打死.
: 假定in ram db可以让你在单线程下的data consistence得到保证, 你怎么解决这个级
: 别的计算复杂度?
|
n****1
发帖数: 1136 | 22 I assume your data is consistent and available on SINGLE THREAD architecture
. There is nothing wrong with this assumption, and people make assumption
all the time. We assume the linux kernel is stable so we can start to build
things on top of it. Doesn't mean the kernel is always stable.
Do not expect me or anyone else to take things for granted so blindly. This
is not about trust on your ability, this is about thinking critically. If
you require your audience to trust you absolutely, you are not a good
teacher.
Can you go on talk about your design with this assumption?
【在 T********i 的大作中提到】
: 你先给我一个确定的答复。
: 首先这个方案至少在设计上能保证consistency和availability。
: 请给个确定的答复，你同意不同意？如果这个你不能确定，没必要和你讨论。
:
: 死.
|
g*****g
发帖数: 34805 | 23 我可没吹自己io专家，有个小错屁大的事，不像你傻逼吹破了躲了 半个月没脸见人。
【在 T********i 的大作中提到】
: 不懂装懂不是吹牛？你好意思说你懂IO么？
: 不懂在这儿上窜下跳？看看你上面的帖子。张口IO闭口IO。跟我谈IO你有这个资格么？
: 看你这个操性，就能想象你爹妈啥样。你这是暴露了整个家族。
|
T********i
发帖数: 2416 | 24 I wouldn't expect any trust from anybody at all.
I just want to make sure you are capable of making reasonable assumption
beyond reasonable doubt.
For example, I claim my 抢票核心 kernel is composed of a chain of monolithic
servers. Only the head of capable of making decision. Once the head granted
one ticket that single transaction is started by passing a message (as
trans log in the mean time) long the chain. Once the message reaches the
last node of the chain an ACK message will be generated and passed back
along the chain.
Only when the head received the ACK completes the single transaction and the
ACK is passed back to the client through a front-end server (e.g. web
server).
I claim even if some nodes of the chain of monolithic servers failed, as
long as there is one server up, the system can still guarantee consistency
and provide availability (though the topological rearrangement takes several
milliseconds).
I would expect you to be capable of designing a protocol, which, in case of
failure of some nodes, is able to re-arrange the topological structure of
the chain (and possibly reassigning the head or tail or both), and possibly
do some synchronization of the transaction log messages.
If you are capable of designing a protocol like that, you would assume that
I am right about the guarantee CAP of my system under the condition of
eventual consistency.
We shouldn't engage further discussion until we pass this step.
architecture
build
This
【在 n****1 的大作中提到】
: I assume your data is consistent and available on SINGLE THREAD architecture
: . There is nothing wrong with this assumption, and people make assumption
: all the time. We assume the linux kernel is stable so we can start to build
: things on top of it. Doesn't mean the kernel is always stable.
: Do not expect me or anyone else to take things for granted so blindly. This
: is not about trust on your ability, this is about thinking critically. If
: you require your audience to trust you absolutely, you are not a good
: teacher.
: Can you go on talk about your design with this assumption?
|
T********i
发帖数: 2416 | 25 你别不要脸了，连NASDAQ是I/O bound都敢断定，你还要怎么才不算吹。
根据你的表现，你根本没资格谈I/O。你这种傻逼俺确实需要躲。和你耗不起。
你给大家一个理由，你有什么资格谈I/O？
【在 g*****g 的大作中提到】
: 我可没吹自己io专家，有个小错屁大的事，不像你傻逼吹破了躲了 半个月没脸见人。
|
n****1
发帖数: 1136 | 26 Your design is very similar to Apache Hbase, in which nodes are asymmetric.
Multiple master-node exist but only one master node is active, others are
ready to take over in case the active one fails.
I totally agree that CAP is satisfied if only eventual consistency is
required, because hbase already did that. Now please move on!
monolithic
granted
the
【在 T********i 的大作中提到】
: I wouldn't expect any trust from anybody at all.
: I just want to make sure you are capable of making reasonable assumption
: beyond reasonable doubt.
: For example, I claim my 抢票核心 kernel is composed of a chain of monolithic
: servers. Only the head of capable of making decision. Once the head granted
: one ticket that single transaction is started by passing a message (as
: trans log in the mean time) long the chain. Once the message reaches the
: last node of the chain an ACK message will be generated and passed back
: along the chain.
: Only when the head received the ACK completes the single transaction and the
|
T********i
发帖数: 2416 | 27 呵呵，goodbug在这些问题上，连续两个月对我进行连篇累牍无耻的人身攻击。有任何
人说过一句公道话么？
好了，假定12306要求数据必须紧耦合，那么单机的性能最优，很容易证明。
我们在此假定中国火车线路任何两站之间的中间站不超过100个。总车站数量小于65536
个。那么一个抢票请求的消息有大约200字节。
这样，每秒500万的吞吐量不需要40G带宽。10G就够了。而且每机器带两网卡。每个网
卡5G。通信两个core绝对搞定。
其实这种应用用第三个core单线程都能搞定。我刚从中国回来，停留1个月，坐了两次
高铁。高铁卖票只卖等级不挑座位。抢票也就是最多100个加一。没抢着更麻烦些，因
为要把抢到的还回去，最多99个减一。最多10亿次加减法。因为抢票一般都是放票后同
一班次，数据几乎保证在L1 L2 cache中。
两个producer，一个consumer的lock free算法不难。但是我不想从我这里泄漏出去。
其实，两个producer，多个consumer的lock free算法是一样的。也就是几十行不到100
行代码。
单线程抢票，不用Atomic加减指令。多线程要用。
退10000步讲，即使我为了保险起见把指标降几倍。也比现有的11万/S快一个数量级没
问题。已经天下第一了，我有动力么？
.
【在 n****1 的大作中提到】
: Your design is very similar to Apache Hbase, in which nodes are asymmetric.
: Multiple master-node exist but only one master node is active, others are
: ready to take over in case the active one fails.
: I totally agree that CAP is satisfied if only eventual consistency is
: required, because hbase already did that. Now please move on!
:
: monolithic
: granted
: the
|
b*******s
发帖数: 5216 | 28 你们吵的，大多数人看不明白
你看不少人看到数据就认为是数据库
都在拿自己的一点认识套
65536
【在 T********i 的大作中提到】
: 呵呵，goodbug在这些问题上，连续两个月对我进行连篇累牍无耻的人身攻击。有任何
: 人说过一句公道话么？
: 好了，假定12306要求数据必须紧耦合，那么单机的性能最优，很容易证明。
: 我们在此假定中国火车线路任何两站之间的中间站不超过100个。总车站数量小于65536
: 个。那么一个抢票请求的消息有大约200字节。
: 这样，每秒500万的吞吐量不需要40G带宽。10G就够了。而且每机器带两网卡。每个网
: 卡5G。通信两个core绝对搞定。
: 其实这种应用用第三个core单线程都能搞定。我刚从中国回来，停留1个月，坐了两次
: 高铁。高铁卖票只卖等级不挑座位。抢票也就是最多100个加一。没抢着更麻烦些，因
: 为要把抢到的还回去，最多99个减一。最多10亿次加减法。因为抢票一般都是放票后同
|
n****1
发帖数: 1136 | 29 首先, 实际卖票逻辑比你形容的复杂多了. 譬如有列车:广州->武汉->郑州->北京. 车
上有个座位,广州->武汉卖掉了, 郑州->北京也卖掉了,那如果有个乘客需要武汉到郑州
的坐票, 你的业务逻辑能把这个座位卖个人家吗? 我还没提更复杂的联程票情况.
换句话说, 如果业务逻辑像你形容的这么简单, 那就是可以弱耦合了嘛!
你应该把你的数据模型写出来, 就像这个帖子一样:
http://www.mitbbs.com/article_t/Programming/31299459.html
然后大家才能看清这个模型是否强耦合,是否计算量像你说的那么简单.
其次, lockfree data/software transactional memory又不是啥新鲜玩意, 这早就是
haskell杀手应用, 那帮鸟人用haskell的STM写出的server比nodejs还快一倍. Java/C+
+里面也有类库实现类似的东西. 你别告诉我你的核心就是实现这个!
最后, 用单机的performance per dollar固然好, 可是这么复杂的逻辑, 这么大的运算
量, 单机承受力很值得怀疑. 譬如厦门到乌鲁木齐可能要转三四次车, 人家多几个这样
的联程票查询就能把你的单机搞挂掉.
65536
【在 T********i 的大作中提到】
: 呵呵，goodbug在这些问题上，连续两个月对我进行连篇累牍无耻的人身攻击。有任何
: 人说过一句公道话么？
: 好了，假定12306要求数据必须紧耦合，那么单机的性能最优，很容易证明。
: 我们在此假定中国火车线路任何两站之间的中间站不超过100个。总车站数量小于65536
: 个。那么一个抢票请求的消息有大约200字节。
: 这样，每秒500万的吞吐量不需要40G带宽。10G就够了。而且每机器带两网卡。每个网
: 卡5G。通信两个core绝对搞定。
: 其实这种应用用第三个core单线程都能搞定。我刚从中国回来，停留1个月，坐了两次
: 高铁。高铁卖票只卖等级不挑座位。抢票也就是最多100个加一。没抢着更麻烦些，因
: 为要把抢到的还回去，最多99个减一。最多10亿次加减法。因为抢票一般都是放票后同
|
g*****g
发帖数: 34805 | 30 nasdaq是i/o bound这是常识，你丫连这个都叫板，只能说明你实在太弱了。
【在 T********i 的大作中提到】
: 你别不要脸了，连NASDAQ是I/O bound都敢断定，你还要怎么才不算吹。
: 根据你的表现，你根本没资格谈I/O。你这种傻逼俺确实需要躲。和你耗不起。
: 你给大家一个理由，你有什么资格谈I/O？
|
|
|
g*****g
发帖数: 34805 | 31 可惜的是12306跟你一样强耦合，17个节点都没做下来。就你那一个2万美刀的能行？
像你这样的傻逼就是丢了脸不认错，这个板上哪怕挺你的哪个不是说你撑得太过。
你丫也不撒泡尿照照镜子。一点server端经验都没有，上来就我这个东西宇宙第一。
65536
【在 T********i 的大作中提到】
: 呵呵，goodbug在这些问题上，连续两个月对我进行连篇累牍无耻的人身攻击。有任何
: 人说过一句公道话么？
: 好了，假定12306要求数据必须紧耦合，那么单机的性能最优，很容易证明。
: 我们在此假定中国火车线路任何两站之间的中间站不超过100个。总车站数量小于65536
: 个。那么一个抢票请求的消息有大约200字节。
: 这样，每秒500万的吞吐量不需要40G带宽。10G就够了。而且每机器带两网卡。每个网
: 卡5G。通信两个core绝对搞定。
: 其实这种应用用第三个core单线程都能搞定。我刚从中国回来，停留1个月，坐了两次
: 高铁。高铁卖票只卖等级不挑座位。抢票也就是最多100个加一。没抢着更麻烦些，因
: 为要把抢到的还回去，最多99个减一。最多10亿次加减法。因为抢票一般都是放票后同
|
g*****g
发帖数: 34805 | 32 我受不了了。感情这班上一队人都是半路出家的吧，一点建模的意识都没有呀。
假定广州到北京线路叫A次，不失一般性假定就这么三段，每段100张票，数据库里三个
row
广州－》武汉 100
武汉－》郑州 100
郑州－》北京 100
你要广州到北京，就是每段1张，DB transaction，锁三个row出票，发现任何一段票数
小于0，roll back. 我实在想不明白这有啥难度。不就是三个商品，不允许超卖。你咋
组合都行。
后端是强耦合，前端没耦合。
C+
【在 n****1 的大作中提到】
: 首先, 实际卖票逻辑比你形容的复杂多了. 譬如有列车:广州->武汉->郑州->北京. 车
: 上有个座位,广州->武汉卖掉了, 郑州->北京也卖掉了,那如果有个乘客需要武汉到郑州
: 的坐票, 你的业务逻辑能把这个座位卖个人家吗? 我还没提更复杂的联程票情况.
: 换句话说, 如果业务逻辑像你形容的这么简单, 那就是可以弱耦合了嘛!
: 你应该把你的数据模型写出来, 就像这个帖子一样:
: http://www.mitbbs.com/article_t/Programming/31299459.html
: 然后大家才能看清这个模型是否强耦合,是否计算量像你说的那么简单.
: 其次, lockfree data/software transactional memory又不是啥新鲜玩意, 这早就是
: haskell杀手应用, 那帮鸟人用haskell的STM写出的server比nodejs还快一倍. Java/C+
: +里面也有类库实现类似的东西. 你别告诉我你的核心就是实现这个!
|
n****1
发帖数: 1136 | 33 你是不是中国人啊, 你不知道广州到北京中途至少30个站? 你准备分几段?
还有你的DB transaction怎么保证座位号一样? 如果人家买了广州到北京的票, 你不能
叫人家每过个站换个座位吧.
受不了就别回贴了
【在 g*****g 的大作中提到】
: 我受不了了。感情这班上一队人都是半路出家的吧，一点建模的意识都没有呀。
: 假定广州到北京线路叫A次，不失一般性假定就这么三段，每段100张票，数据库里三个
: row
: 广州－》武汉 100
: 武汉－》郑州 100
: 郑州－》北京 100
: 你要广州到北京，就是每段1张，DB transaction，锁三个row出票，发现任何一段票数
: 小于0，roll back. 我实在想不明白这有啥难度。不就是三个商品，不允许超卖。你咋
: 组合都行。
: 后端是强耦合，前端没耦合。
|
g*****g
发帖数: 34805 | 34 30站30段呀，事实上中国售票都是每站预留，所以都是不相干的票。A次广州出发，A次
郑州出发。
要不到春运，你要最大化，不是首发久没票了。
我再说一遍，后台不是实时出票，所以你大可以用最优的搜索算法来订票，这样的算法
有现成的。
【在 n****1 的大作中提到】
: 你是不是中国人啊, 你不知道广州到北京中途至少30个站? 你准备分几段?
: 还有你的DB transaction怎么保证座位号一样? 如果人家买了广州到北京的票, 你不能
: 叫人家每过个站换个座位吧.
: 受不了就别回贴了
|
T********i
发帖数: 2416 | 35 讲过多少次了。迄今没人理解。
再讲一次。全国铁路任何相邻两站是一个区段。注意这是本文定义。避免任何歧义。
每个区段一个唯一编号。
你的例子：
广州->武汉->郑州->北京
共三个区段，编号如下：
广州->武汉： 1
武汉->郑州：2
郑州->北京：3
全国所有的铁路区段都加起来也就是大约总车站的数量。能上万就不错了。是一个线性
数组。
你的例子： 广州->武汉卖掉了, 郑州->北京也卖掉了
那么：a[1]==0 a[3]==0
武汉到郑州是a[2],有票就可卖。
联程票才精彩。比如 广州->武汉->郑州都有票， 郑州->北京没票。
如果有人请求 广州->北京，那么该请求是1，2，3
执行如下：
a[1] > 0，则a[1] = a[1] - 1
a[2] > 0，则a[2] = a[2] - 1
但是a[3] == 0。则要把a[1]和a[2]再加一还回去，同时返回无票。
还记得我说的state cache server么？这些server可以实时cache当前所以区段的状态
。只不过是所有的transaction log的sync。一天才能出几百万张票，这点trans log同
步算个啥？
这些state cache server可以无限扩展。而且区段线路规划和有票初步检测在这里做。
因此用户买票，可以先规划，检测有票，再放进去抢。
这个设计是无敌最优，而且最实时的用户体验。
【 在 nod101 (exchange) 的大作中提到: 】
C+ |
T********i
发帖数: 2416 | 36 你的常识哪里来的，体育老师教的？
【在 g*****g 的大作中提到】
: nasdaq是i/o bound这是常识，你丫连这个都叫板，只能说明你实在太弱了。
|
T********i
发帖数: 2416 | 37 知道为啥飞机票都要临近登机才换登机牌么？
没有程序能预测未来。先给你票，最后时刻再优化座位是唯一的方法。
其实，火车票和飞机票，完全可以说一样的系统。
【在 n****1 的大作中提到】
: 你是不是中国人啊, 你不知道广州到北京中途至少30个站? 你准备分几段?
: 还有你的DB transaction怎么保证座位号一样? 如果人家买了广州到北京的票, 你不能
: 叫人家每过个站换个座位吧.
: 受不了就别回贴了
|
n****1
发帖数: 1136 | 38 车次与座位的分配与memory allocator非常相似, 需要保证memory defragmentation,
但复杂度更高.
每当收到一个内存申请(订票申请), allocator都需要先在已经分配的内存块(已经部分
出票的座位)中寻找空隙, 而且最好要找不大不小的空隙. 实在找不到了才向系统申请
新内存块(动用新座位). 这样才能保证所有座位的高效利用.
座位分配更麻烦在于, 内存申请只需大小合适就行, 座位分配还要指定在内存块中的位
置.
这个算法一点也不简单,学问大大的. |
T********i
发帖数: 2416 | 39 临出发换登机牌才能保证分配最优。缺点是额外手续带来的效率下降。
,
【在 n****1 的大作中提到】
: 车次与座位的分配与memory allocator非常相似, 需要保证memory defragmentation,
: 但复杂度更高.
: 每当收到一个内存申请(订票申请), allocator都需要先在已经分配的内存块(已经部分
: 出票的座位)中寻找空隙, 而且最好要找不大不小的空隙. 实在找不到了才向系统申请
: 新内存块(动用新座位). 这样才能保证所有座位的高效利用.
: 座位分配更麻烦在于, 内存申请只需大小合适就行, 座位分配还要指定在内存块中的位
: 置.
: 这个算法一点也不简单,学问大大的.
|
g*****g
发帖数: 34805 | 40 只有你做client端的才会没这个常识。server端都是用户多，nasdaq那个match的算法
复杂度很高？你忽悠谁呀。
【在 T********i 的大作中提到】
: 你的常识哪里来的，体育老师教的？
|
|
|
n****1
发帖数: 1136 | 41 首先不管技术可行性, 最后时刻才决定座位在政治上是行不通的, 媒体与群众无法接受
, 首长更加不会同意的. 不是说你的理念不先进, 而是人们已经习惯了, 不是那么好改
. 你能让全世界从qwerty键盘改成dvorak么?
乘客对座位要求很多的,一家人需要坐一起, 老人不喜欢上铺中铺.复杂度大大的.
程序员别整天想着改变世界运作方式, 以便自己编程简单点.
其次, 最后时刻分配座位, 往往发现座位不够, 或者需要乘客不停地中途换座位. 就像
内存分配一样, fragmentation只可以减少, 无法杜绝. 需要分配的内存永远大于需要
的内存.
机票简单多了, 因为每个订单都像一整块内存. 火车票则是一小部分.
【在 T********i 的大作中提到】
: 知道为啥飞机票都要临近登机才换登机牌么？
: 没有程序能预测未来。先给你票，最后时刻再优化座位是唯一的方法。
: 其实，火车票和飞机票，完全可以说一样的系统。
|
n****1
发帖数: 1136 | 42 我之所以同意你说业务是强耦合, 就是因为这些琐碎的考量.
如果做得像你这么简单, 那直接弱耦合上机群好了. |
T********i
发帖数: 2416 | 43 我的算法保证不会超卖。因此不会有超卖问题。
你的问题根本无解。人家支线挑好了座位，干线碎片就产生了。
铁道部的做法是高峰期只卖大区票。
数学上，啥能做，啥不能，很好证明。你再想想。
【在 n****1 的大作中提到】
: 首先不管技术可行性, 最后时刻才决定座位在政治上是行不通的, 媒体与群众无法接受
: , 首长更加不会同意的. 不是说你的理念不先进, 而是人们已经习惯了, 不是那么好改
: . 你能让全世界从qwerty键盘改成dvorak么?
: 乘客对座位要求很多的,一家人需要坐一起, 老人不喜欢上铺中铺.复杂度大大的.
: 程序员别整天想着改变世界运作方式, 以便自己编程简单点.
: 其次, 最后时刻分配座位, 往往发现座位不够, 或者需要乘客不停地中途换座位. 就像
: 内存分配一样, fragmentation只可以减少, 无法杜绝. 需要分配的内存永远大于需要
: 的内存.
: 机票简单多了, 因为每个订单都像一整块内存. 火车票则是一小部分.
|
T********i
发帖数: 2416 | 44 弱耦合不行，一旦区段锁定一半机器死了，锁定的票就还不回来了。
【在 n****1 的大作中提到】
: 我之所以同意你说业务是强耦合, 就是因为这些琐碎的考量.
: 如果做得像你这么简单, 那直接弱耦合上机群好了.
|
n****1
发帖数: 1136 | 45 弱耦合可以像goodbug说的那样分库, 怎么分的话需要分析历史春运数据. 分好了死锁
问题就没啥大不了的了. 反正有一年的时间做规划, 分得再细都行.
如果你的方案无法实时分配座位, 我只能彻底推翻你的方案支持上机群了, 没准这种精
心设计的机群还能保证实时回复余票+实时分配座位.
【在 T********i 的大作中提到】
: 弱耦合不行，一旦区段锁定一半机器死了，锁定的票就还不回来了。
|
T********i
发帖数: 2416 | 46 根据我的经历。现在也是网上订票，然后必须到车站窗口取票。
为什么？就是要一个时间缓冲。
先确保你有票。再找机会优化。
人家铁道部也不傻。
能实时确认有票就很了不起了，而且是最重要的。
【在 n****1 的大作中提到】
: 弱耦合可以像goodbug说的那样分库, 怎么分的话需要分析历史春运数据. 分好了死锁
: 问题就没啥大不了的了. 反正有一年的时间做规划, 分得再细都行.
: 如果你的方案无法实时分配座位, 我只能彻底推翻你的方案支持上机群了, 没准这种精
: 心设计的机群还能保证实时回复余票+实时分配座位.
|
n****1
发帖数: 1136 | 47 还有, 最后关头分配座位这个总是要人来做的, 而且计算复杂度很高, 你还准备单机做
么?
你这叫为了面子好看避重就轻, "单机解决12306"只是标题党, 没解决实际问题. |
n****1
发帖数: 1136 | 48 不是吧, 我帮我爸妈买卧铺票, 下单时/付款前就知道是哪个座位了, 上中下铺也是说
好了再给钱的.
【在 T********i 的大作中提到】
: 根据我的经历。现在也是网上订票，然后必须到车站窗口取票。
: 为什么？就是要一个时间缓冲。
: 先确保你有票。再找机会优化。
: 人家铁道部也不傻。
: 能实时确认有票就很了不起了，而且是最重要的。
|
T********i
发帖数: 2416 | 49 这个其实没你想的那么复杂。不应该是NP问题。
注意长途要优先分配。而且团体座位要集中，也要优先。剩下的随便，按照时间顺序好
了。
最终可能要认为微调，人民铁路为人民服务么。
【在 n****1 的大作中提到】
: 还有, 最后关头分配座位这个总是要人来做的, 而且计算复杂度很高, 你还准备单机做
: 么?
: 你这叫为了面子好看避重就轻, "单机解决12306"只是标题党, 没解决实际问题.
|
T********i
发帖数: 2416 | 50 说实话我的经历有限。这个确实不是很肯定。
【在 n****1 的大作中提到】
: 不是吧, 我帮我爸妈买卧铺票, 下单时/付款前就知道是哪个座位了, 上中下铺也是说
: 好了再给钱的.
|
