z*r
2 楼
没有仔细的看实现,但是几个最基本的事实需要考虑
1.数据量 考虑到要支持的车次,座位数目,和支持的时间段的组合,单机内存装不下
2.车票和车次的来源更新,这里没有固定的计数器, 有的只是动态票源
3.在2的基础上,实现抢票transaction的ACID, 用一个简单内存小程序加几个网络备份
是不现实的,这个不能想当然
4.复杂的transaction处理, 抢票之后要出票,退票,换票之类的更有问题
5.单机的availability问题
当把一个订票系统简化成静态计数器的时候,系统的价值就基本丧失了,不管你能一秒抢
多少票
1.数据量 考虑到要支持的车次,座位数目,和支持的时间段的组合,单机内存装不下
2.车票和车次的来源更新,这里没有固定的计数器, 有的只是动态票源
3.在2的基础上,实现抢票transaction的ACID, 用一个简单内存小程序加几个网络备份
是不现实的,这个不能想当然
4.复杂的transaction处理, 抢票之后要出票,退票,换票之类的更有问题
5.单机的availability问题
当把一个订票系统简化成静态计数器的时候,系统的价值就基本丧失了,不管你能一秒抢
多少票
w*s
3 楼
ios5 gm 里居然没SIRI
b*s
4 楼
有这么难懂吗
t*m
6 楼
看到第一行就不用看下去了
z*e
12 楼
你们上个世纪的人,除了暴力解,还有什么其他的招没有?
反正就是有冲突,就回单机,然后相互独立的部分就爆机器
只要相互不独立,就回去找单机,然后拼命拆逻辑
做各种精简,你不觉得你在回避问题么?
分布式的并发问题,关于如何处理分布式事务等等
都讨论了几十年了,最近十年尤为热门,乱七八糟的paper什么到处都是
你随便去个seminar,都可以听到演讲者在解释如何对付这些问题
为什么你还要回到上个时代的解法去捏?
就你那个联锁问题,是分布式的入门问题好不好?
一个联锁就把你吓得要回去用单机,也是服了
你们这些上个世纪的老头子实在是很幽默啊
【在 n*****t 的大作中提到】
: 老魏说得对,有些人你就让他们糊涂下去好了。
: 没办法,用惯轮子的人,已经形成思维定式了,老师没教过的一定不对、没有轮子可套
: 的一定不行,不要发明轮子就是他们的经典信条。
S*s
13 楼
那什么时候发布?
d*e
20 楼
实在看不下去了,本来不想搅混水的。
你就当抢票机是个cache. 现在的问题是n个请求对应一张票。
你让n个请求里面只有一个1hit好了,
剩下的丢给你传统的东西,这样就好理解了。
【在 z*******r 的大作中提到】
: 没有仔细的看实现,但是几个最基本的事实需要考虑
: 1.数据量 考虑到要支持的车次,座位数目,和支持的时间段的组合,单机内存装不下
: 2.车票和车次的来源更新,这里没有固定的计数器, 有的只是动态票源
: 3.在2的基础上,实现抢票transaction的ACID, 用一个简单内存小程序加几个网络备份
: 是不现实的,这个不能想当然
: 4.复杂的transaction处理, 抢票之后要出票,退票,换票之类的更有问题
: 5.单机的availability问题
: 当把一个订票系统简化成静态计数器的时候,系统的价值就基本丧失了,不管你能一秒抢
: 多少票
你就当抢票机是个cache. 现在的问题是n个请求对应一张票。
你让n个请求里面只有一个1hit好了,
剩下的丢给你传统的东西,这样就好理解了。
【在 z*******r 的大作中提到】
: 没有仔细的看实现,但是几个最基本的事实需要考虑
: 1.数据量 考虑到要支持的车次,座位数目,和支持的时间段的组合,单机内存装不下
: 2.车票和车次的来源更新,这里没有固定的计数器, 有的只是动态票源
: 3.在2的基础上,实现抢票transaction的ACID, 用一个简单内存小程序加几个网络备份
: 是不现实的,这个不能想当然
: 4.复杂的transaction处理, 抢票之后要出票,退票,换票之类的更有问题
: 5.单机的availability问题
: 当把一个订票系统简化成静态计数器的时候,系统的价值就基本丧失了,不管你能一秒抢
: 多少票
z*r
24 楼
很不幸,这个已经不是cache了,这是一个分布式transaction的核心部分, 因为他不是只
读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
timeout怎么办? 你怎么知道每一个transaction都persis好了
退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
【在 d******e 的大作中提到】
: 实在看不下去了,本来不想搅混水的。
: 你就当抢票机是个cache. 现在的问题是n个请求对应一张票。
: 你让n个请求里面只有一个1hit好了,
: 剩下的丢给你传统的东西,这样就好理解了。
读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
timeout怎么办? 你怎么知道每一个transaction都persis好了
退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
【在 d******e 的大作中提到】
: 实在看不下去了,本来不想搅混水的。
: 你就当抢票机是个cache. 现在的问题是n个请求对应一张票。
: 你让n个请求里面只有一个1hit好了,
: 剩下的丢给你传统的东西,这样就好理解了。
n*t
26 楼
所有问题你自己已经回答了:没有仔细的看实现。
简单说,这是一个 cache,不讨论怎么同步、灾难恢复、timeout 怎么处理,这个设计
的时候已经考虑,由协议实现。即使出现个别数据不同步,顶多就是抢票跟后端之间交
换几个报文来同步。
【在 z*******r 的大作中提到】
: 很不幸,这个已经不是cache了,这是一个分布式transaction的核心部分, 因为他不是只
: 读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
: 用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
: 掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
: timeout怎么办? 你怎么知道每一个transaction都persis好了
: 退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
简单说,这是一个 cache,不讨论怎么同步、灾难恢复、timeout 怎么处理,这个设计
的时候已经考虑,由协议实现。即使出现个别数据不同步,顶多就是抢票跟后端之间交
换几个报文来同步。
【在 z*******r 的大作中提到】
: 很不幸,这个已经不是cache了,这是一个分布式transaction的核心部分, 因为他不是只
: 读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
: 用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
: 掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
: timeout怎么办? 你怎么知道每一个transaction都persis好了
: 退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
a*g
27 楼
白等到现在.....
d*e
28 楼
你抢票阶段就那一个rain check.搞什么transaction.
就是机器死了就是rain check作废而已。
10亿人抢票,100万人拿到ran check,然后让它们进去慢慢排吧,这是该上什么
transcation就上什么。
不要把问题都搅和在一起。
另外123什么挡掉页主要是web端做得不好。抢票从来就不是问题。
【在 z*******r 的大作中提到】
: 很不幸,这个已经不是cache了,这是一个分布式transaction的核心部分, 因为他不是只
: 读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
: 用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
: 掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
: timeout怎么办? 你怎么知道每一个transaction都persis好了
: 退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
就是机器死了就是rain check作废而已。
10亿人抢票,100万人拿到ran check,然后让它们进去慢慢排吧,这是该上什么
transcation就上什么。
不要把问题都搅和在一起。
另外123什么挡掉页主要是web端做得不好。抢票从来就不是问题。
【在 z*******r 的大作中提到】
: 很不幸,这个已经不是cache了,这是一个分布式transaction的核心部分, 因为他不是只
: 读的.要改变状态并且记住状态, 需要满足对transaction的所有要求,
: 用内存单线程序列化可以解决transaction的某些问题,但是暴露了更多的问题
: 掉电怎么办? 网卡有问题怎么办? 文件系统出现坏块怎么办, 和其他组件间通信
: timeout怎么办? 你怎么知道每一个transaction都persis好了
: 退一万步只做cache,能100%实时反映另一个DB上的状态也是个很难的问题.
z*e
38 楼
首先第一个,这种估计没有意义,除非你打算卖机器
真要上的时候,实际测一下再说
我的确没做过12306,但是我说了
类似的public transportation和global payment system我都有经验
对此有怀疑的,我欢迎我跟对赌死全家
老魏就是见到这个就开始哭了
就我所见,老魏的方式,已经不用了
基本上上个世纪是用这种方式搞,尤其是要保证mainframe的稳定
广州那次出了一次事故,结果所有人过年都没过好
至于经不经得起猴子砸,这是目标,怎么实现可以讨论
需求必需经过讨论,明确后才开工,需求都不明确
开工了做什么?浪费时间
【在 g*****y 的大作中提到】
: 你做个简单的分布式系统,再给个估计,多少台机器,达到多少吞吐量。
: 不要整天12306怎么着怎么着的。那也不是你做的,你连它是不是有票必出都不知道。
: 到底经不经得起猴子砸。讨论起来没什么意义。
相关阅读
Refactoring long class step by step (2)some interview questions i met and rememberedPHP语法一问Why the number is not exact in C++How to encode YYYY-MM-DD?Refactoring long class step by step (1)MATLAB function call too slow这里有没有人用OpenSSL的?matlab: how to set defaul value for function arguments请教palindrome算法一道面试题how to print 2 exponential digits in windows by using PerlSegmentation faultmitbbs 包子监控机的设计设想及专利声明 (转载)an interview problemHow to generate random number in driver (build in DDK)关于C的数组大小Interview questionHow to change a string under gdb promptTop 100 H1B Visa Sponsors in IT