很多东东要是我来设计，会很不一样# Programming - 葵花宝典
c*d
1 楼
马上就要回国了，一个香港的朋友邀请我去看看。我托家里人问了一下，港澳通行证办
理需要20多天。请问还有什么方法能在10天内搞到去香港的通行证么？
理需要20多天。请问还有什么方法能在10天内搞到去香港的通行证么？
h*j
2 楼
招聘兼职，全职
Part time job
寻找ebay合作伙伴！！！
专业从事网络国际贸易业务，具有竞争力的产品和价格的优势，已形成比较成熟的产品
供应，产品在欧美等地的销售具有竟争力，销售前景乐观！公司一直以诚信视为生命。
只有诚信才可以走得更远。现招募海外的！中国移民或留学生兼职！(可以作为你的第
二职业来做)。有不错的发展前景和学习机会.
工作类型：网上兼职.（只需要晚上的1-2个小时）
工资待遇：MSN或QQ 上详谈
要求：
1、英语基础好。
2、上网方便,每天抽1-2个小时就足够。
3、具备良好的沟通能力、有责任心
如大家有兴趣做eBay网络销售的。
请与我联系：
QQ：349101602
MSN：f********[email protected]
E-mail：f********[email protected]
本广告长期有效！
期待广大华人、留学生的加盟！
Part time job
寻找ebay合作伙伴！！！
专业从事网络国际贸易业务，具有竞争力的产品和价格的优势，已形成比较成熟的产品
供应，产品在欧美等地的销售具有竟争力，销售前景乐观！公司一直以诚信视为生命。
只有诚信才可以走得更远。现招募海外的！中国移民或留学生兼职！(可以作为你的第
二职业来做)。有不错的发展前景和学习机会.
工作类型：网上兼职.（只需要晚上的1-2个小时）
工资待遇：MSN或QQ 上详谈
要求：
1、英语基础好。
2、上网方便,每天抽1-2个小时就足够。
3、具备良好的沟通能力、有责任心
如大家有兴趣做eBay网络销售的。
请与我联系：
QQ：349101602
MSN：f********[email protected]
E-mail：f********[email protected]
本广告长期有效！
期待广大华人、留学生的加盟！
l*l
3 楼
我发现了，人的潜力，都是在生活绝境中才迸发出来的，很多都是被逼出来的，现在我
也几乎到了绝境，看来我也要逼迫自己一把了，我对自己很有信心。
不在绝境中爆发，就在绝境中灭亡，咱是80后，小时候也是吃过苦的，不是那种脆弱和
矫情的人，所以面对困境甚至说绝境，都不会放弃，一定可以迸发出潜力，渡过难关，
不就是钱吗，想办法赚就是了，留得青山在不愁没柴烧，只要身体还好，就是最大的财
富了。
到了中年这个时候，上有老，下有小，完全是要靠自己的，自己不给自己打气，谁还能
鼓励自己呢，有时候事情也许并不像我们自己想的那么糟糕，看似已经走到了绝境，但
是努努力，或者想想办法，就又有了新的出路。
正所谓，山穷水尽疑无路，柳暗花明又一村。
现在除了给自己加油鼓劲，然后爆发出自己的小宇宙，没有别的办法，亲爹亲妈都靠不
住的，只能靠自己，我也相信，天无绝人之路，只要自己想办法，总是可以解决困境的。
每个中年人，都有自己的沉重负担，我也不例外，谁不是在坚强而又苦逼的活着，有句
话说的有道理，舒服是留给死人的，活着不是一件容易的事情。
也几乎到了绝境，看来我也要逼迫自己一把了，我对自己很有信心。
不在绝境中爆发，就在绝境中灭亡，咱是80后，小时候也是吃过苦的，不是那种脆弱和
矫情的人，所以面对困境甚至说绝境，都不会放弃，一定可以迸发出潜力，渡过难关，
不就是钱吗，想办法赚就是了，留得青山在不愁没柴烧，只要身体还好，就是最大的财
富了。
到了中年这个时候，上有老，下有小，完全是要靠自己的，自己不给自己打气，谁还能
鼓励自己呢，有时候事情也许并不像我们自己想的那么糟糕，看似已经走到了绝境，但
是努努力，或者想想办法，就又有了新的出路。
正所谓，山穷水尽疑无路，柳暗花明又一村。
现在除了给自己加油鼓劲，然后爆发出自己的小宇宙，没有别的办法，亲爹亲妈都靠不
住的，只能靠自己，我也相信，天无绝人之路，只要自己想办法，总是可以解决困境的。
每个中年人，都有自己的沉重负担，我也不例外，谁不是在坚强而又苦逼的活着，有句
话说的有道理，舒服是留给死人的，活着不是一件容易的事情。
T*i
4 楼
比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
一切都是虚的，只有throughput才是实实在在的。
当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
你已经做到头了。
一切都是虚的，只有throughput才是实实在在的。
当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
你已经做到头了。
g*A
5 楼
你可以路过住一个礼拜啊
不需要通行证
不需要通行证
s*o
6 楼
人生就是一个不断战胜困难的过程
g*g
7 楼
Because the bottleneck is not on application server, it's on DB server.
Until you can make DB running faster/lower DB load/scale out DB usage, you
can use assembly to write the app and it won't matter.
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
Until you can make DB running faster/lower DB load/scale out DB usage, you
can use assembly to write the app and it won't matter.
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
c*d
8 楼
问题就是不路过。临时决定去的。机票买的是到北京的往返。
【在 g*****A 的大作中提到】
: 你可以路过住一个礼拜啊
: 不需要通行证
【在 g*****A 的大作中提到】
: 你可以路过住一个礼拜啊
: 不需要通行证
T*i
9 楼
已经很多年没用现成的db了。后台的db用啥都无所谓。
关键是中间的cache层。
cache关键是
data partition
messaging bus
系统做成基于消息的，也就没有同步异步的区别了。都是异步的了。unicast和
multicast还是有区别的。
其实网卡本身就是transaction manager。message acknowledge回来transaction就完
成了。因为信息已经写到另外一台机器去了。不要问我两台机器都死掉怎么办？世界末
日了你是不是还关心tech support? 实在不放心就用multicast好了。
我只关心message encoding / decoding schema就好了。
折腾来折腾去，就是把信息搬过来搬过去，五马倒六羊地穷折腾。中间没有产生任何有
用的新信息。做这东西，很难产生成就感。
【在 g*****g 的大作中提到】
: Because the bottleneck is not on application server, it's on DB server.
: Until you can make DB running faster/lower DB load/scale out DB usage, you
: can use assembly to write the app and it won't matter.
关键是中间的cache层。
cache关键是
data partition
messaging bus
系统做成基于消息的，也就没有同步异步的区别了。都是异步的了。unicast和
multicast还是有区别的。
其实网卡本身就是transaction manager。message acknowledge回来transaction就完
成了。因为信息已经写到另外一台机器去了。不要问我两台机器都死掉怎么办？世界末
日了你是不是还关心tech support? 实在不放心就用multicast好了。
我只关心message encoding / decoding schema就好了。
折腾来折腾去，就是把信息搬过来搬过去，五马倒六羊地穷折腾。中间没有产生任何有
用的新信息。做这东西，很难产生成就感。
【在 g*****g 的大作中提到】
: Because the bottleneck is not on application server, it's on DB server.
: Until you can make DB running faster/lower DB load/scale out DB usage, you
: can use assembly to write the app and it won't matter.
R*T
10 楼
只要你的护照上有其他国家的签证，你就可以进入香港，理由是由香港机场打飞机。
绝大多数情况下，过关不看你的机票。
如果不放心，凭你的护照在口岸让那些旅行社随便给你出个行程，也能蒙混过关。
【在 c****d 的大作中提到】
: 马上就要回国了，一个香港的朋友邀请我去看看。我托家里人问了一下，港澳通行证办
: 理需要20多天。请问还有什么方法能在10天内搞到去香港的通行证么？
绝大多数情况下，过关不看你的机票。
如果不放心，凭你的护照在口岸让那些旅行社随便给你出个行程，也能蒙混过关。
【在 c****d 的大作中提到】
: 马上就要回国了，一个香港的朋友邀请我去看看。我托家里人问了一下，港澳通行证办
: 理需要20多天。请问还有什么方法能在10天内搞到去香港的通行证么？
g*g
11 楼
Data partition is the key. But it's easier said than done.
If data partition is really that simple, there's no need for NoSQL DBs in
the first place.
When your DB is the bottleneck, it doesn't matter you have sync or async
architecture either.
【在 T********i 的大作中提到】
: 已经很多年没用现成的db了。后台的db用啥都无所谓。
: 关键是中间的cache层。
: cache关键是
: data partition
: messaging bus
: 系统做成基于消息的，也就没有同步异步的区别了。都是异步的了。unicast和
: multicast还是有区别的。
: 其实网卡本身就是transaction manager。message acknowledge回来transaction就完
: 成了。因为信息已经写到另外一台机器去了。不要问我两台机器都死掉怎么办？世界末
: 日了你是不是还关心tech support? 实在不放心就用multicast好了。
If data partition is really that simple, there's no need for NoSQL DBs in
the first place.
When your DB is the bottleneck, it doesn't matter you have sync or async
architecture either.
【在 T********i 的大作中提到】
: 已经很多年没用现成的db了。后台的db用啥都无所谓。
: 关键是中间的cache层。
: cache关键是
: data partition
: messaging bus
: 系统做成基于消息的，也就没有同步异步的区别了。都是异步的了。unicast和
: multicast还是有区别的。
: 其实网卡本身就是transaction manager。message acknowledge回来transaction就完
: 成了。因为信息已经写到另外一台机器去了。不要问我两台机器都死掉怎么办？世界末
: 日了你是不是还关心tech support? 实在不放心就用multicast好了。
T*i
12 楼
It is easy to prove a message based system is optimal. It matters because
semantically current frameworks are not efficient.
DB could be bottleneck. Bue if your design is optimal you can claim no one
can do better.
Current frameworks are still far from that stage.
【在 g*****g 的大作中提到】
: Data partition is the key. But it's easier said than done.
: If data partition is really that simple, there's no need for NoSQL DBs in
: the first place.
: When your DB is the bottleneck, it doesn't matter you have sync or async
: architecture either.
semantically current frameworks are not efficient.
DB could be bottleneck. Bue if your design is optimal you can claim no one
can do better.
Current frameworks are still far from that stage.
【在 g*****g 的大作中提到】
: Data partition is the key. But it's easier said than done.
: If data partition is really that simple, there's no need for NoSQL DBs in
: the first place.
: When your DB is the bottleneck, it doesn't matter you have sync or async
: architecture either.
g*g
13 楼
You know what's bottleneck do you? When you hit bottleneck, the rest of your
system can't get to their max throughput. You can be twice as efficient for
those parts and it barely improves your throughput. I don't care about no
one do better part, I am more concerned of solving the bottleneck and
achieve SLA requirement.
【在 T********i 的大作中提到】
: It is easy to prove a message based system is optimal. It matters because
: semantically current frameworks are not efficient.
: DB could be bottleneck. Bue if your design is optimal you can claim no one
: can do better.
: Current frameworks are still far from that stage.
system can't get to their max throughput. You can be twice as efficient for
those parts and it barely improves your throughput. I don't care about no
one do better part, I am more concerned of solving the bottleneck and
achieve SLA requirement.
【在 T********i 的大作中提到】
: It is easy to prove a message based system is optimal. It matters because
: semantically current frameworks are not efficient.
: DB could be bottleneck. Bue if your design is optimal you can claim no one
: can do better.
: Current frameworks are still far from that stage.
T*i
14 楼
Bottleneck can not be solved. If it can be solved, it's not real bottleneck.
A shitty system can claim there are bottlenecks everywhere.
In reality I have never had data dependency that can't be efficiently
partitioned. It is always the easiest part because talking is cheap. It is
no one can do better part that is always the fun part.
your
for
【在 g*****g 的大作中提到】
: You know what's bottleneck do you? When you hit bottleneck, the rest of your
: system can't get to their max throughput. You can be twice as efficient for
: those parts and it barely improves your throughput. I don't care about no
: one do better part, I am more concerned of solving the bottleneck and
: achieve SLA requirement.
A shitty system can claim there are bottlenecks everywhere.
In reality I have never had data dependency that can't be efficiently
partitioned. It is always the easiest part because talking is cheap. It is
no one can do better part that is always the fun part.
your
for
【在 g*****g 的大作中提到】
: You know what's bottleneck do you? When you hit bottleneck, the rest of your
: system can't get to their max throughput. You can be twice as efficient for
: those parts and it barely improves your throughput. I don't care about no
: one do better part, I am more concerned of solving the bottleneck and
: achieve SLA requirement.
g*g
15 楼
Sure data can be efficiently partitioned, but it takes time and efforts. app
server on the other hand, can be doubled, tripled or even configured on
demand on the cloud to meet the load. Hardware is cheap.
There's a reason we are talking about big data and NoSQL these days.
bottleneck.
【在 T********i 的大作中提到】
: Bottleneck can not be solved. If it can be solved, it's not real bottleneck.
: A shitty system can claim there are bottlenecks everywhere.
: In reality I have never had data dependency that can't be efficiently
: partitioned. It is always the easiest part because talking is cheap. It is
: no one can do better part that is always the fun part.
:
: your
: for
server on the other hand, can be doubled, tripled or even configured on
demand on the cloud to meet the load. Hardware is cheap.
There's a reason we are talking about big data and NoSQL these days.
bottleneck.
【在 T********i 的大作中提到】
: Bottleneck can not be solved. If it can be solved, it's not real bottleneck.
: A shitty system can claim there are bottlenecks everywhere.
: In reality I have never had data dependency that can't be efficiently
: partitioned. It is always the easiest part because talking is cheap. It is
: no one can do better part that is always the fun part.
:
: your
: for
T*i
16 楼
As I said, data partitionibg is the easiest thing among the problems.
Given the constraints such as the framework, it doesn't take a genius to
partition it right.
Assuming the data is properly partitioned, a shitty application server can
still create bottleneck everythere.
So in my test, under optimal condition, if a node can't consume or generate
constant 20G of throughput, it is by design inefficient and no one can help
you with that.
app
【在 g*****g 的大作中提到】
: Sure data can be efficiently partitioned, but it takes time and efforts. app
: server on the other hand, can be doubled, tripled or even configured on
: demand on the cloud to meet the load. Hardware is cheap.
: There's a reason we are talking about big data and NoSQL these days.
:
: bottleneck.
Given the constraints such as the framework, it doesn't take a genius to
partition it right.
Assuming the data is properly partitioned, a shitty application server can
still create bottleneck everythere.
So in my test, under optimal condition, if a node can't consume or generate
constant 20G of throughput, it is by design inefficient and no one can help
you with that.
app
【在 g*****g 的大作中提到】
: Sure data can be efficiently partitioned, but it takes time and efforts. app
: server on the other hand, can be doubled, tripled or even configured on
: demand on the cloud to meet the load. Hardware is cheap.
: There's a reason we are talking about big data and NoSQL these days.
:
: bottleneck.
z*e
17 楼
app server的scalability的问题十年前就搞定了
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
g*g
18 楼
On the contrary, it's the hardest problem otherwise people won't come out
with all sorts of NoSQL solutions. You can solve application server
inefficiency by throwing hardware at it, not optimal but a quick and simple
solution nonetheless, you can't do the same for DB.
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
with all sorts of NoSQL solutions. You can solve application server
inefficiency by throwing hardware at it, not optimal but a quick and simple
solution nonetheless, you can't do the same for DB.
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
z*e
19 楼
这种涉及到钱的交易，又是关联的数据非常难搞
几乎是分布式的死结，分布式没有几个真把这个问题搞定的
基本上都死得惨惨的
这种领域基本上就跟物流一样
没有办法做到完美，很多时候只能靠speculation
几乎是分布式的死结，分布式没有几个真把这个问题搞定的
基本上都死得惨惨的
这种领域基本上就跟物流一样
没有办法做到完美，很多时候只能靠speculation
T*i
20 楼
10年前app server只有ejb。你给我说说那烂得像屎一样的东东怎么搞定scalability的？
【在 z****e 的大作中提到】
: app server的scalability的问题十年前就搞定了
:
: generate
: help
【在 z****e 的大作中提到】
: app server的scalability的问题十年前就搞定了
:
: generate
: help
T*i
21 楼
分布式不能真正解决瓶颈。真的瓶颈只不过从一处转移到了另一处。
比如global inventory check之类的，最后还要靠单机性能。
【在 z****e 的大作中提到】
: 这种涉及到钱的交易，又是关联的数据非常难搞
: 几乎是分布式的死结，分布式没有几个真把这个问题搞定的
: 基本上都死得惨惨的
: 这种领域基本上就跟物流一样
: 没有办法做到完美，很多时候只能靠speculation
比如global inventory check之类的，最后还要靠单机性能。
【在 z****e 的大作中提到】
: 这种涉及到钱的交易，又是关联的数据非常难搞
: 几乎是分布式的死结，分布式没有几个真把这个问题搞定的
: 基本上都死得惨惨的
: 这种领域基本上就跟物流一样
: 没有办法做到完美，很多时候只能靠speculation
g*g
22 楼
I don't see why ejb had scalability issue. It's a lot of boiler plate code,
that was the issue.
的？
【在 T********i 的大作中提到】
: 10年前app server只有ejb。你给我说说那烂得像屎一样的东东怎么搞定scalability的？
that was the issue.
的？
【在 T********i 的大作中提到】
: 10年前app server只有ejb。你给我说说那烂得像屎一样的东东怎么搞定scalability的？
g*g
23 楼
不懂瞎说，绝大多数的应用都不需要global lock。比如FB，需要啥global lock。
【在 T********i 的大作中提到】
: 分布式不能真正解决瓶颈。真的瓶颈只不过从一处转移到了另一处。
: 比如global inventory check之类的，最后还要靠单机性能。
【在 T********i 的大作中提到】
: 分布式不能真正解决瓶颈。真的瓶颈只不过从一处转移到了另一处。
: 比如global inventory check之类的，最后还要靠单机性能。
z*e
24 楼
今天商业银行不都在用这种烂得跟屎一样得东西？
你以为你写的不是烂得跟屎一样？
的？
【在 T********i 的大作中提到】
: 10年前app server只有ejb。你给我说说那烂得像屎一样的东东怎么搞定scalability的？
你以为你写的不是烂得跟屎一样？
的？
【在 T********i 的大作中提到】
: 10年前app server只有ejb。你给我说说那烂得像屎一样的东东怎么搞定scalability的？
z*e
25 楼
那就是回头去上主机了对不对？
行了，都回去写cobol吧
【在 T********i 的大作中提到】
: 分布式不能真正解决瓶颈。真的瓶颈只不过从一处转移到了另一处。
: 比如global inventory check之类的，最后还要靠单机性能。
行了，都回去写cobol吧
【在 T********i 的大作中提到】
: 分布式不能真正解决瓶颈。真的瓶颈只不过从一处转移到了另一处。
: 比如global inventory check之类的，最后还要靠单机性能。
T*i
26 楼
商业银行本身就烂得像屎。难道错了？
我写的怎么样你不见得有机会见识。
【在 z****e 的大作中提到】
: 今天商业银行不都在用这种烂得跟屎一样得东西？
: 你以为你写的不是烂得跟屎一样？
:
: 的？
我写的怎么样你不见得有机会见识。
【在 z****e 的大作中提到】
: 今天商业银行不都在用这种烂得跟屎一样得东西？
: 你以为你写的不是烂得跟屎一样？
:
: 的？
T*i
27 楼
春运这样的要check沿线。
交易要check global inventory。
FB之类都是小儿科。
【在 g*****g 的大作中提到】
: 不懂瞎说，绝大多数的应用都不需要global lock。比如FB，需要啥global lock。
交易要check global inventory。
FB之类都是小儿科。
【在 g*****g 的大作中提到】
: 不懂瞎说，绝大多数的应用都不需要global lock。比如FB，需要啥global lock。
T*i
28 楼
假定一个春运系统，需要check沿线的。动不动每秒上百万请求的，你分布一下给我看
看？
【在 T********i 的大作中提到】
: 春运这样的要check沿线。
: 交易要check global inventory。
: FB之类都是小儿科。
看？
【在 T********i 的大作中提到】
: 春运这样的要check沿线。
: 交易要check global inventory。
: FB之类都是小儿科。
z*e
29 楼
这好歹是金钱相关而且比较大型的系统
最后也算是成功的项目，拿出去可以跟人说，你看这个成功了
所以有理由相信你那个有能成功
【在 T********i 的大作中提到】
: 商业银行本身就烂得像屎。难道错了？
: 我写的怎么样你不见得有机会见识。
最后也算是成功的项目，拿出去可以跟人说，你看这个成功了
所以有理由相信你那个有能成功
【在 T********i 的大作中提到】
: 商业银行本身就烂得像屎。难道错了？
: 我写的怎么样你不见得有机会见识。
T*i
30 楼
你怎么证明是你做的？呵呵。
【在 z****e 的大作中提到】
: 这好歹是金钱相关而且比较大型的系统
: 最后也算是成功的项目，拿出去可以跟人说，你看这个成功了
: 所以有理由相信你那个有能成功
【在 z****e 的大作中提到】
: 这好歹是金钱相关而且比较大型的系统
: 最后也算是成功的项目，拿出去可以跟人说，你看这个成功了
: 所以有理由相信你那个有能成功
z*e
31 楼
我证明不了，但是ibm之类的，很容易证明
现在也就是它们的客户在用ejb，难道你用？
【在 T********i 的大作中提到】
: 你怎么证明是你做的？呵呵。
现在也就是它们的客户在用ejb，难道你用？
【在 T********i 的大作中提到】
: 你怎么证明是你做的？呵呵。
T*i
32 楼
给我这么多钱，要求用quick basic我也能做到。
金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
几十台服务器，延迟在个位微秒的实时系统。
【在 z****e 的大作中提到】
: 我证明不了，但是ibm之类的，很容易证明
: 现在也就是它们的客户在用ejb，难道你用？
金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
几十台服务器，延迟在个位微秒的实时系统。
【在 z****e 的大作中提到】
: 我证明不了，但是ibm之类的，很容易证明
: 现在也就是它们的客户在用ejb，难道你用？
z*e
33 楼
time, scope, quality和cost
scope无法更改，而且time当时非常紧张，春运没有办法推迟
cost如果不是问题的话，ibm的报价当时就拿下了，之所以决定自己搞
就是嫌ibm的方案太贵，那都这样了，你还想保证quality?
你最近没喝高吧？
【在 T********i 的大作中提到】
: 给我这么多钱，要求用quick basic我也能做到。
: 金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
: 几十台服务器，延迟在个位微秒的实时系统。
scope无法更改，而且time当时非常紧张，春运没有办法推迟
cost如果不是问题的话，ibm的报价当时就拿下了，之所以决定自己搞
就是嫌ibm的方案太贵，那都这样了，你还想保证quality?
你最近没喝高吧？
【在 T********i 的大作中提到】
: 给我这么多钱，要求用quick basic我也能做到。
: 金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
: 几十台服务器，延迟在个位微秒的实时系统。
T*i
34 楼
那你来说说，这个系统你怎么用ejb能分布出来？
【在 z****e 的大作中提到】
: time, scope, quality和cost
: scope无法更改，而且time当时非常紧张，春运没有办法推迟
: cost如果不是问题的话，ibm的报价当时就拿下了，之所以决定自己搞
: 就是嫌ibm的方案太贵，那都这样了，你还想保证quality?
: 你最近没喝高吧？
【在 z****e 的大作中提到】
: time, scope, quality和cost
: scope无法更改，而且time当时非常紧张，春运没有办法推迟
: cost如果不是问题的话，ibm的报价当时就拿下了，之所以决定自己搞
: 就是嫌ibm的方案太贵，那都这样了，你还想保证quality?
: 你最近没喝高吧？
z*e
35 楼
很难，但是不是不可能
需要一步一步来
如果时间如此紧张的前提下，尤其是当时那个时间跨度
坚决用ibm的主机是最好的选择，然后再一步一步从主机中剥离出各种逻辑
先用oracle的db来替换ibm的主机系统，然后再逐步分流各种负载压力
用不用ejb那是次要的，只要明白多线程以及singleton其实不会被blocked
加上各种speculation以及nosql等技术，慢慢把负载分流到分布式系统上去
这也不是什么很神奇的东西，天朝机票就是这么搞的
你什么时候听说机票卖得崩溃了？都是拼命抢特价票
没听说有人买着买着系统就崩了吧？
【在 T********i 的大作中提到】
: 那你来说说，这个系统你怎么用ejb能分布出来？
需要一步一步来
如果时间如此紧张的前提下，尤其是当时那个时间跨度
坚决用ibm的主机是最好的选择，然后再一步一步从主机中剥离出各种逻辑
先用oracle的db来替换ibm的主机系统，然后再逐步分流各种负载压力
用不用ejb那是次要的，只要明白多线程以及singleton其实不会被blocked
加上各种speculation以及nosql等技术，慢慢把负载分流到分布式系统上去
这也不是什么很神奇的东西，天朝机票就是这么搞的
你什么时候听说机票卖得崩溃了？都是拼命抢特价票
没听说有人买着买着系统就崩了吧？
【在 T********i 的大作中提到】
: 那你来说说，这个系统你怎么用ejb能分布出来？
z*e
36 楼
其实全世界机票都是这么搞的，全世界40％的机票是科罗拉多丹佛那个数据中心出的
民航总局计算机中心有成功的经验不去借鉴，想装自己搞
那这个没办法了，该挂就挂给你看
民航总局计算机中心有成功的经验不去借鉴，想装自己搞
那这个没办法了，该挂就挂给你看
T*i
37 楼
我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
不保险，搞三四台。
其他都是外围打酱油的。
你把全世界的服务器都分布进来性能也不如我的。
1-2万行代码就搞定了。哪来这么麻烦？
【在 z****e 的大作中提到】
: 很难，但是不是不可能
: 需要一步一步来
: 如果时间如此紧张的前提下，尤其是当时那个时间跨度
: 坚决用ibm的主机是最好的选择，然后再一步一步从主机中剥离出各种逻辑
: 先用oracle的db来替换ibm的主机系统，然后再逐步分流各种负载压力
: 用不用ejb那是次要的，只要明白多线程以及singleton其实不会被blocked
: 加上各种speculation以及nosql等技术，慢慢把负载分流到分布式系统上去
: 这也不是什么很神奇的东西，天朝机票就是这么搞的
: 你什么时候听说机票卖得崩溃了？都是拼命抢特价票
: 没听说有人买着买着系统就崩了吧？
不保险，搞三四台。
其他都是外围打酱油的。
你把全世界的服务器都分布进来性能也不如我的。
1-2万行代码就搞定了。哪来这么麻烦？
【在 z****e 的大作中提到】
: 很难，但是不是不可能
: 需要一步一步来
: 如果时间如此紧张的前提下，尤其是当时那个时间跨度
: 坚决用ibm的主机是最好的选择，然后再一步一步从主机中剥离出各种逻辑
: 先用oracle的db来替换ibm的主机系统，然后再逐步分流各种负载压力
: 用不用ejb那是次要的，只要明白多线程以及singleton其实不会被blocked
: 加上各种speculation以及nosql等技术，慢慢把负载分流到分布式系统上去
: 这也不是什么很神奇的东西，天朝机票就是这么搞的
: 你什么时候听说机票卖得崩溃了？都是拼命抢特价票
: 没听说有人买着买着系统就崩了吧？
z*e
38 楼
吹吧，吹牛不上税，你觉得铁道部是那种出不起钱买3－4个server的地方么？
估计这点钱还不够刘志君包杨幂一周的开销
你要能搞定这个，直接给沃尔玛之类的投简历
这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
估计这点钱还不够刘志君包杨幂一周的开销
你要能搞定这个，直接给沃尔玛之类的投简历
这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
T*i
39 楼
这种数据依赖性紧耦合的系统，你凭什么说分布式的性能一定比一台server要好？
先把这个关键搞清楚。随便扣帽子没意思。
【在 z****e 的大作中提到】
: 吹吧，吹牛不上税，你觉得铁道部是那种出不起钱买3－4个server的地方么？
: 估计这点钱还不够刘志君包杨幂一周的开销
: 你要能搞定这个，直接给沃尔玛之类的投简历
: 这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
先把这个关键搞清楚。随便扣帽子没意思。
【在 z****e 的大作中提到】
: 吹吧，吹牛不上税，你觉得铁道部是那种出不起钱买3－4个server的地方么？
: 估计这点钱还不够刘志君包杨幂一周的开销
: 你要能搞定这个，直接给沃尔玛之类的投简历
: 这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
N*K
40 楼
你是不是搞比特币交易的？
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
z*e
41 楼
你怎么不想想那种量，一台server够么？
你是不是不懂什么是server？
【在 T********i 的大作中提到】
: 这种数据依赖性紧耦合的系统，你凭什么说分布式的性能一定比一台server要好？
: 先把这个关键搞清楚。随便扣帽子没意思。
你是不是不懂什么是server？
【在 T********i 的大作中提到】
: 这种数据依赖性紧耦合的系统，你凭什么说分布式的性能一定比一台server要好？
: 先把这个关键搞清楚。随便扣帽子没意思。
T*i
42 楼
最核心的撮合系统，一台server够了。关键是server多了性能不见得更好。外围的多少
都无所谓，比如serve static content或者session distributor。
【在 z****e 的大作中提到】
: 你怎么不想想那种量，一台server够么？
: 你是不是不懂什么是server？
都无所谓，比如serve static content或者session distributor。
【在 z****e 的大作中提到】
: 你怎么不想想那种量，一台server够么？
: 你是不是不懂什么是server？
z*e
43 楼
你就吹吧
一台server连一个省的民工访问量都支撑不了
【在 T********i 的大作中提到】
: 最核心的撮合系统，一台server够了。关键是server多了性能不见得更好。外围的多少
: 都无所谓，比如serve static content或者session distributor。
一台server连一个省的民工访问量都支撑不了
【在 T********i 的大作中提到】
: 最核心的撮合系统，一台server够了。关键是server多了性能不见得更好。外围的多少
: 都无所谓，比如serve static content或者session distributor。
T*i
44 楼
看来你理解力有问题。
这台server专管所有线路的inventory的transaction。送给它的请求都是过滤过的。每
秒近80G的吞吐量，有什么不够的?
【在 z****e 的大作中提到】
: 你就吹吧
: 一台server连一个省的民工访问量都支撑不了
这台server专管所有线路的inventory的transaction。送给它的请求都是过滤过的。每
秒近80G的吞吐量，有什么不够的?
【在 z****e 的大作中提到】
: 你就吹吧
: 一台server连一个省的民工访问量都支撑不了
N*K
45 楼
IBM mainframe？
【在 T********i 的大作中提到】
: 看来你理解力有问题。
: 这台server专管所有线路的inventory的transaction。送给它的请求都是过滤过的。每
: 秒近80G的吞吐量，有什么不够的?
【在 T********i 的大作中提到】
: 看来你理解力有问题。
: 这台server专管所有线路的inventory的transaction。送给它的请求都是过滤过的。每
: 秒近80G的吞吐量，有什么不够的?
T*i
46 楼
随便一台intel xeon足够了。
另外，我不做比特币交易。我是做low latency trading的。
【在 N******K 的大作中提到】
: IBM mainframe？
另外，我不做比特币交易。我是做low latency trading的。
【在 N******K 的大作中提到】
: IBM mainframe？
b*s
47 楼
做高频的？
【在 T********i 的大作中提到】
: 给我这么多钱，要求用quick basic我也能做到。
: 金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
: 几十台服务器，延迟在个位微秒的实时系统。
【在 T********i 的大作中提到】
: 给我这么多钱，要求用quick basic我也能做到。
: 金钱相关的我也一直在做，都是每天交易上亿美金的系统。运行数年无故障的。
: 几十台服务器，延迟在个位微秒的实时系统。
b*s
48 楼
是可能的
【在 z****e 的大作中提到】
: 你就吹吧
: 一台server连一个省的民工访问量都支撑不了
【在 z****e 的大作中提到】
: 你就吹吧
: 一台server连一个省的民工访问量都支撑不了
b*s
49 楼
做高频的是这样的，一般是几个us就能完成一次交易，行业内的基本都行
他的思路我觉得是不考虑rollback之类的情况，无数据库
从理论上讲性能是能达到的，java则完全不可能
【在 z****e 的大作中提到】
: 你怎么不想想那种量，一台server够么？
: 你是不是不懂什么是server？
他的思路我觉得是不考虑rollback之类的情况，无数据库
从理论上讲性能是能达到的，java则完全不可能
【在 z****e 的大作中提到】
: 你怎么不想想那种量，一台server够么？
: 你是不是不懂什么是server？
g*g
50 楼
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的。
【在 T********i 的大作中提到】
: 假定一个春运系统，需要check沿线的。动不动每秒上百万请求的，你分布一下给我看
: 看？
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的。
【在 T********i 的大作中提到】
: 假定一个春运系统，需要check沿线的。动不动每秒上百万请求的，你分布一下给我看
: 看？
z*e
51 楼
我估计它根本没有想过要rollback这回事
涉及到这种交易，如果一次失败不能rollback的话
民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
否则全部做成静态页面，然后异步处理，肯定能搞定
但是问题在于，火车票卖票还有一个需求就是时效性
买不买得到，最好当天就反馈，否则也不需要上网站
每个民工领个号订票，第二天来查就好了
【在 b*******s 的大作中提到】
: 做高频的是这样的，一般是几个us就能完成一次交易，行业内的基本都行
: 他的思路我觉得是不考虑rollback之类的情况，无数据库
: 从理论上讲性能是能达到的，java则完全不可能
涉及到这种交易，如果一次失败不能rollback的话
民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
否则全部做成静态页面，然后异步处理，肯定能搞定
但是问题在于，火车票卖票还有一个需求就是时效性
买不买得到，最好当天就反馈，否则也不需要上网站
每个民工领个号订票，第二天来查就好了
【在 b*******s 的大作中提到】
: 做高频的是这样的，一般是几个us就能完成一次交易，行业内的基本都行
: 他的思路我觉得是不考虑rollback之类的情况，无数据库
: 从理论上讲性能是能达到的，java则完全不可能
b*s
52 楼
rollback他的设计其实也是可以做的，利用logging就可以
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
b*s
53 楼
主要是transaction的概念是不是能取消，如果可以，他的方案可行
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
z*e
54 楼
量太大，用logging很不好做
【在 b*******s 的大作中提到】
: rollback他的设计其实也是可以做的，利用logging就可以
【在 b*******s 的大作中提到】
: rollback他的设计其实也是可以做的，利用logging就可以
b*s
55 楼
rollback不一定要实时
【在 z****e 的大作中提到】
: 量太大，用logging很不好做
【在 z****e 的大作中提到】
: 量太大，用logging很不好做
z*e
56 楼
如果不要transaction，连db都不用
而且这个rollback还不是那么容易的rollback
钱收了人家的钱，退款是多么麻烦的一件事
中间会计多了很多事
【在 b*******s 的大作中提到】
: 主要是transaction的概念是不是能取消，如果可以，他的方案可行
而且这个rollback还不是那么容易的rollback
钱收了人家的钱，退款是多么麻烦的一件事
中间会计多了很多事
【在 b*******s 的大作中提到】
: 主要是transaction的概念是不是能取消，如果可以，他的方案可行
b*s
57 楼
他的方案的关键就是不要transaction
当然也不要db，这样io瓶颈一下子就没了，而计算性能是他的特长
现代c++出来的代码完全可以比java快两个数量级甚至更多
【在 z****e 的大作中提到】
: 如果不要transaction，连db都不用
: 而且这个rollback还不是那么容易的rollback
: 钱收了人家的钱，退款是多么麻烦的一件事
: 中间会计多了很多事
当然也不要db，这样io瓶颈一下子就没了，而计算性能是他的特长
现代c++出来的代码完全可以比java快两个数量级甚至更多
【在 z****e 的大作中提到】
: 如果不要transaction，连db都不用
: 而且这个rollback还不是那么容易的rollback
: 钱收了人家的钱，退款是多么麻烦的一件事
: 中间会计多了很多事
z*e
58 楼
java不是问题，问题在于throughput
计算快慢不是主要问题，主要latency是io上，一直都是io上比较慢
不要transaction的话，这种事会出错
各种你想都想不到的错误，如果不能rollback问题很严重
【在 b*******s 的大作中提到】
: 他的方案的关键就是不要transaction
: 当然也不要db，这样io瓶颈一下子就没了，而计算性能是他的特长
: 现代c++出来的代码完全可以比java快两个数量级甚至更多
计算快慢不是主要问题，主要latency是io上，一直都是io上比较慢
不要transaction的话，这种事会出错
各种你想都想不到的错误，如果不能rollback问题很严重
【在 b*******s 的大作中提到】
: 他的方案的关键就是不要transaction
: 当然也不要db，这样io瓶颈一下子就没了，而计算性能是他的特长
: 现代c++出来的代码完全可以比java快两个数量级甚至更多
T*i
59 楼
和你讨论确实有点困难。
这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
standby打酱油的。
还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
这东东你估计都没听说过。
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
standby打酱油的。
还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
这东东你估计都没听说过。
【在 z****e 的大作中提到】
: 我估计它根本没有想过要rollback这回事
: 涉及到这种交易，如果一次失败不能rollback的话
: 民工会把柜台给砸了，这个系统的难处并不仅仅在于大并发
: 还在于不允许错，两个一叠加，网站根本撑不住这么大的访问量
: 否则全部做成静态页面，然后异步处理，肯定能搞定
: 但是问题在于，火车票卖票还有一个需求就是时效性
: 买不买得到，最好当天就反馈，否则也不需要上网站
: 每个民工领个号订票，第二天来查就好了
z*e
60 楼
纳秒？现在cpu有几个能精确到纳秒？
你说了半天连硬件都要定制
那还不如直接去买主机拉倒
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
你说了半天连硬件都要定制
那还不如直接去买主机拉倒
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
z*e
61 楼
如果不实时的话，会引发巨多不必要的麻烦
你设想一下退款流程
【在 b*******s 的大作中提到】
: rollback不一定要实时
你设想一下退款流程
【在 b*******s 的大作中提到】
: rollback不一定要实时
b*s
62 楼
c++最强壮的领域啊
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
b*s
63 楼
不一定要硬实时，我没讲清楚
【在 z****e 的大作中提到】
: 如果不实时的话，会引发巨多不必要的麻烦
: 你设想一下退款流程
【在 z****e 的大作中提到】
: 如果不实时的话，会引发巨多不必要的麻烦
: 你设想一下退款流程
b*s
64 楼
不需要特别特殊的硬件定制，好一点的intel cpu就行
【在 z****e 的大作中提到】
: 纳秒？现在cpu有几个能精确到纳秒？
: 你说了半天连硬件都要定制
: 那还不如直接去买主机拉倒
【在 z****e 的大作中提到】
: 纳秒？现在cpu有几个能精确到纳秒？
: 你说了半天连硬件都要定制
: 那还不如直接去买主机拉倒
z*e
65 楼
这些东西都是可以慢慢做的
但是项目本身有上线时间
就像我前面说的
scope, time, cost都有很强的限制
在这三个都没有办法变通的前提下
quality是无法保证的
最好的方法就是加大投入cost
先从ibm搞台主机回来，直接挪用机票那一套解决方案
然后再慢慢剥离主机负载，最后淘汰掉主机
【在 b*******s 的大作中提到】
: 不一定要硬实时，我没讲清楚
但是项目本身有上线时间
就像我前面说的
scope, time, cost都有很强的限制
在这三个都没有办法变通的前提下
quality是无法保证的
最好的方法就是加大投入cost
先从ibm搞台主机回来，直接挪用机票那一套解决方案
然后再慢慢剥离主机负载，最后淘汰掉主机
【在 b*******s 的大作中提到】
: 不一定要硬实时，我没讲清楚
T*i
66 楼
指令执行的时钟周期可以算出来是纳秒级别的。
我的系统从来不挑硬件，随便买台服务器就好了。
其实唯一的不确定性是cpu cache miss。其实这个也能掌控。
【在 z****e 的大作中提到】
: 纳秒？现在cpu有几个能精确到纳秒？
: 你说了半天连硬件都要定制
: 那还不如直接去买主机拉倒
我的系统从来不挑硬件，随便买台服务器就好了。
其实唯一的不确定性是cpu cache miss。其实这个也能掌控。
【在 z****e 的大作中提到】
: 纳秒？现在cpu有几个能精确到纳秒？
: 你说了半天连硬件都要定制
: 那还不如直接去买主机拉倒
z*e
67 楼
测试怎么办？你怎么知道你写的不会有问题？
维护怎么办？你怎么保证别人都看懂你在做什么？
兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
你怎么跟这个做兼容？
这些东西说难也不难，有钱有时间都好说
但是一开始之所以不用ibm的解决方案
就是因为cost太高，想省钱
加上没有太多时间可以投入，所以匆忙上线
才有了后面的各种问题
【在 T********i 的大作中提到】
: 指令执行的时钟周期可以算出来是纳秒级别的。
: 我的系统从来不挑硬件，随便买台服务器就好了。
: 其实唯一的不确定性是cpu cache miss。其实这个也能掌控。
维护怎么办？你怎么保证别人都看懂你在做什么？
兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
你怎么跟这个做兼容？
这些东西说难也不难，有钱有时间都好说
但是一开始之所以不用ibm的解决方案
就是因为cost太高，想省钱
加上没有太多时间可以投入，所以匆忙上线
才有了后面的各种问题
【在 T********i 的大作中提到】
: 指令执行的时钟周期可以算出来是纳秒级别的。
: 我的系统从来不挑硬件，随便买台服务器就好了。
: 其实唯一的不确定性是cpu cache miss。其实这个也能掌控。
g*g
68 楼
每天所有的火车票都不过千万级别，你要那么多transaction干啥？我提出的方案
是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
都是闲着。
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
都是闲着。
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
b*s
69 楼
java就是瓶颈，java是运行时决定类型，蜗牛一样的jvm，不能用到处理器特性
就比如锁，c++有非锁同步的能力，用cpu指令集实现的
还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
【在 z****e 的大作中提到】
: java不是问题，问题在于throughput
: 计算快慢不是主要问题，主要latency是io上，一直都是io上比较慢
: 不要transaction的话，这种事会出错
: 各种你想都想不到的错误，如果不能rollback问题很严重
就比如锁，c++有非锁同步的能力，用cpu指令集实现的
还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
【在 z****e 的大作中提到】
: java不是问题，问题在于throughput
: 计算快慢不是主要问题，主要latency是io上，一直都是io上比较慢
: 不要transaction的话，这种事会出错
: 各种你想都想不到的错误，如果不能rollback问题很严重
T*i
70 楼
你那个不行，性能差了几个数量级。
平时
【在 g*****g 的大作中提到】
: 每天所有的火车票都不过千万级别，你要那么多transaction干啥？我提出的方案
: 是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
: 都是闲着。
平时
【在 g*****g 的大作中提到】
: 每天所有的火车票都不过千万级别，你要那么多transaction干啥？我提出的方案
: 是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
: 都是闲着。
b*s
71 楼
unit test 在c++开发中是无比重要
【在 z****e 的大作中提到】
: 测试怎么办？你怎么知道你写的不会有问题？
: 维护怎么办？你怎么保证别人都看懂你在做什么？
: 兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
: 你怎么跟这个做兼容？
: 这些东西说难也不难，有钱有时间都好说
: 但是一开始之所以不用ibm的解决方案
: 就是因为cost太高，想省钱
: 加上没有太多时间可以投入，所以匆忙上线
: 才有了后面的各种问题
【在 z****e 的大作中提到】
: 测试怎么办？你怎么知道你写的不会有问题？
: 维护怎么办？你怎么保证别人都看懂你在做什么？
: 兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
: 你怎么跟这个做兼容？
: 这些东西说难也不难，有钱有时间都好说
: 但是一开始之所以不用ibm的解决方案
: 就是因为cost太高，想省钱
: 加上没有太多时间可以投入，所以匆忙上线
: 才有了后面的各种问题
z*e
72 楼
少扯淡，java的gc停顿可以通过多个server并行来减少gc停顿时间
storm就是这么操作的，最慢的肯定是io的latency，随便一个网络的延迟都要远远超过
gc的停顿
c++还cache，你代码量上十万之后别人能不能看懂都是个大问题
还谈什么可预测
【在 b*******s 的大作中提到】
: java就是瓶颈，java是运行时决定类型，蜗牛一样的jvm，不能用到处理器特性
: 就比如锁，c++有非锁同步的能力，用cpu指令集实现的
: 还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
storm就是这么操作的，最慢的肯定是io的latency，随便一个网络的延迟都要远远超过
gc的停顿
c++还cache，你代码量上十万之后别人能不能看懂都是个大问题
还谈什么可预测
【在 b*******s 的大作中提到】
: java就是瓶颈，java是运行时决定类型，蜗牛一样的jvm，不能用到处理器特性
: 就比如锁，c++有非锁同步的能力，用cpu指令集实现的
: 还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
g*g
73 楼
又不是stock exchange那种系统，latency很关键。这种IO bound的系统瓶颈都在数据
库上，
让你拿C++写也不会更快，开发的成本和周期都慢好几倍。
【在 b*******s 的大作中提到】
: java就是瓶颈，java是运行时决定类型，蜗牛一样的jvm，不能用到处理器特性
: 就比如锁，c++有非锁同步的能力，用cpu指令集实现的
: 还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
库上，
让你拿C++写也不会更快，开发的成本和周期都慢好几倍。
【在 b*******s 的大作中提到】
: java就是瓶颈，java是运行时决定类型，蜗牛一样的jvm，不能用到处理器特性
: 就比如锁，c++有非锁同步的能力，用cpu指令集实现的
: 还有cache管理，c++很容易写出可预测的代码，能大幅度提高cache hit rate
b*s
74 楼
他的方案不需要很多服务器，成本绝对比铁道部那个低多了
可能几十分之一吧，也许更少
平时
【在 g*****g 的大作中提到】
: 每天所有的火车票都不过千万级别，你要那么多transaction干啥？我提出的方案
: 是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
: 都是闲着。
可能几十分之一吧，也许更少
平时
【在 g*****g 的大作中提到】
: 每天所有的火车票都不过千万级别，你要那么多transaction干啥？我提出的方案
: 是可以在云上，机器不强都能跑起来的。春运系统elastic才是关键，买一堆服务器平时
: 都是闲着。
z*e
75 楼
我哭了，指望qa去给你纠错
我还不如指望chaos monkey呢
【在 b*******s 的大作中提到】
: unit test 在c++开发中是无比重要
我还不如指望chaos monkey呢
【在 b*******s 的大作中提到】
: unit test 在c++开发中是无比重要
g*g
76 楼
别扯蛋了，一秒处理所有订单的方案我都提出来了，只要机器够。
【在 T********i 的大作中提到】
: 你那个不行，性能差了几个数量级。
:
: 平时
【在 T********i 的大作中提到】
: 你那个不行，性能差了几个数量级。
:
: 平时
b*s
77 楼
呵呵，大哥你对c++的印象顶多还是在c++0x的时代
【在 z****e 的大作中提到】
: 少扯淡，java的gc停顿可以通过多个server并行来减少gc停顿时间
: storm就是这么操作的，最慢的肯定是io的latency，随便一个网络的延迟都要远远超过
: gc的停顿
: c++还cache，你代码量上十万之后别人能不能看懂都是个大问题
: 还谈什么可预测
【在 z****e 的大作中提到】
: 少扯淡，java的gc停顿可以通过多个server并行来减少gc停顿时间
: storm就是这么操作的，最慢的肯定是io的latency，随便一个网络的延迟都要远远超过
: gc的停顿
: c++还cache，你代码量上十万之后别人能不能看懂都是个大问题
: 还谈什么可预测
z*e
78 楼
理论上可行
谁敢让它做？
如果出了一个小问题导致整个系统挂了怎么办？
当年民航总局一个小停电，导致整个华南区机票两天卖不出去
几个副总全部滚蛋了，有一个还差点被告上法庭
你当这种事是小孩子过家家？
【在 b*******s 的大作中提到】
: 他的方案不需要很多服务器，成本绝对比铁道部那个低多了
: 可能几十分之一吧，也许更少
:
: 平时
谁敢让它做？
如果出了一个小问题导致整个系统挂了怎么办？
当年民航总局一个小停电，导致整个华南区机票两天卖不出去
几个副总全部滚蛋了，有一个还差点被告上法庭
你当这种事是小孩子过家家？
【在 b*******s 的大作中提到】
: 他的方案不需要很多服务器，成本绝对比铁道部那个低多了
: 可能几十分之一吧，也许更少
:
: 平时
b*s
79 楼
现在的比较牛的c++开发组织，都是没有qa的
不信你问问刚才那位
【在 z****e 的大作中提到】
: 我哭了，指望qa去给你纠错
: 我还不如指望chaos monkey呢
不信你问问刚才那位
【在 z****e 的大作中提到】
: 我哭了，指望qa去给你纠错
: 我还不如指望chaos monkey呢
z*e
80 楼
我说的是java如何搞定这些延迟问题
你说什么？
【在 b*******s 的大作中提到】
: 呵呵，大哥你对c++的印象顶多还是在c++0x的时代
你说什么？
【在 b*******s 的大作中提到】
: 呵呵，大哥你对c++的印象顶多还是在c++0x的时代
T*i
81 楼
这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
attributes。
其他的都能通过message queue分布出去。
外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
【在 z****e 的大作中提到】
: 测试怎么办？你怎么知道你写的不会有问题？
: 维护怎么办？你怎么保证别人都看懂你在做什么？
: 兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
: 你怎么跟这个做兼容？
: 这些东西说难也不难，有钱有时间都好说
: 但是一开始之所以不用ibm的解决方案
: 就是因为cost太高，想省钱
: 加上没有太多时间可以投入，所以匆忙上线
: 才有了后面的各种问题
attributes。
其他的都能通过message queue分布出去。
外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
【在 z****e 的大作中提到】
: 测试怎么办？你怎么知道你写的不会有问题？
: 维护怎么办？你怎么保证别人都看懂你在做什么？
: 兼容性怎么办？铁道部卖票的系统肯定有一个legacy system
: 你怎么跟这个做兼容？
: 这些东西说难也不难，有钱有时间都好说
: 但是一开始之所以不用ibm的解决方案
: 就是因为cost太高，想省钱
: 加上没有太多时间可以投入，所以匆忙上线
: 才有了后面的各种问题
g*g
82 楼
屁，关键的读写怎么分，写如何分，这些关键的东西都没提出来。我EC2上几千台服务
器每年跑
那么几天，跑个10年，成本还没它一台顶级服务器贵呢。
【在 b*******s 的大作中提到】
: 他的方案不需要很多服务器，成本绝对比铁道部那个低多了
: 可能几十分之一吧，也许更少
:
: 平时
器每年跑
那么几天，跑个10年，成本还没它一台顶级服务器贵呢。
【在 b*******s 的大作中提到】
: 他的方案不需要很多服务器，成本绝对比铁道部那个低多了
: 可能几十分之一吧，也许更少
:
: 平时
z*e
83 楼
所以不能相信这种系统
【在 b*******s 的大作中提到】
: 现在的比较牛的c++开发组织，都是没有qa的
: 不信你问问刚才那位
【在 b*******s 的大作中提到】
: 现在的比较牛的c++开发组织，都是没有qa的
: 不信你问问刚才那位
z*e
84 楼
那你可以试试去竞标
别光说不做
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
别光说不做
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
b*s
85 楼
他们那个做高频的，出了事情，直接就冲击金融市场
比卖火车票的问题严重多了
【在 z****e 的大作中提到】
: 理论上可行
: 谁敢让它做？
: 如果出了一个小问题导致整个系统挂了怎么办？
: 当年民航总局一个小停电，导致整个华南区机票两天卖不出去
: 几个副总全部滚蛋了，有一个还差点被告上法庭
: 你当这种事是小孩子过家家？
比卖火车票的问题严重多了
【在 z****e 的大作中提到】
: 理论上可行
: 谁敢让它做？
: 如果出了一个小问题导致整个系统挂了怎么办？
: 当年民航总局一个小停电，导致整个华南区机票两天卖不出去
: 几个副总全部滚蛋了，有一个还差点被告上法庭
: 你当这种事是小孩子过家家？
z*e
86 楼
少扯淡了，就冲击你们的客户罢了
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
b*s
87 楼
有虚拟机在，再怎么优化都是不行的
【在 z****e 的大作中提到】
: 我说的是java如何搞定这些延迟问题
: 你说什么？
【在 z****e 的大作中提到】
: 我说的是java如何搞定这些延迟问题
: 你说什么？
z*e
88 楼
多几个虚拟机，分开处理
总有available的node存在
谁没事把鸡蛋放一台机器上
怎么说机房都是至少两台机器待命
【在 b*******s 的大作中提到】
: 有虚拟机在，再怎么优化都是不行的
总有available的node存在
谁没事把鸡蛋放一台机器上
怎么说机房都是至少两台机器待命
【在 b*******s 的大作中提到】
: 有虚拟机在，再怎么优化都是不行的
b*s
89 楼
方法论不一样，事实上运行得很好，我在的公司也是无qa的，还没有过严重的线上bug
【在 z****e 的大作中提到】
: 所以不能相信这种系统
【在 z****e 的大作中提到】
: 所以不能相信这种系统
T*i
90 楼
我一台机器一毫秒能发10000个单子。
而且我的系统源代码除了我没有第二个人读到过。
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
而且我的系统源代码除了我没有第二个人读到过。
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
z*e
91 楼
again
你们公司而已
你们公司挂了就挂了，不用担什么责任
无非一个破产保护了事
bug
【在 b*******s 的大作中提到】
: 方法论不一样，事实上运行得很好，我在的公司也是无qa的，还没有过严重的线上bug
你们公司而已
你们公司挂了就挂了，不用担什么责任
无非一个破产保护了事
bug
【在 b*******s 的大作中提到】
: 方法论不一样，事实上运行得很好，我在的公司也是无qa的，还没有过严重的线上bug
g*g
92 楼
不是说C++不能做，二是光开发周期就慢好几倍，黄花菜都凉了。
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
【在 b*******s 的大作中提到】
: 他们那个做高频的，出了事情，直接就冲击金融市场
: 比卖火车票的问题严重多了
z*e
93 楼
所以不能相信你
【在 T********i 的大作中提到】
: 我一台机器一毫秒能发10000个单子。
: 而且我的系统源代码除了我没有第二个人读到过。
【在 T********i 的大作中提到】
: 我一台机器一毫秒能发10000个单子。
: 而且我的系统源代码除了我没有第二个人读到过。
b*s
94 楼
我觉得兄弟你在很多方面很厉害，但是对cpu bound的performance tuning不够了解
【在 z****e 的大作中提到】
: 多几个虚拟机，分开处理
: 总有available的node存在
: 谁没事把鸡蛋放一台机器上
: 怎么说机房都是至少两台机器待命
【在 z****e 的大作中提到】
: 多几个虚拟机，分开处理
: 总有available的node存在
: 谁没事把鸡蛋放一台机器上
: 怎么说机房都是至少两台机器待命
T*i
95 楼
你搜一下去年knight capital如何在45分钟内亏400多M的。
【在 z****e 的大作中提到】
: 少扯淡了，就冲击你们的客户罢了
【在 z****e 的大作中提到】
: 少扯淡了，就冲击你们的客户罢了
g*g
96 楼
火车票订单能CPU bound，I服了U。
【在 b*******s 的大作中提到】
: 我觉得兄弟你在很多方面很厉害，但是对cpu bound的performance tuning不够了解
【在 b*******s 的大作中提到】
: 我觉得兄弟你在很多方面很厉害，但是对cpu bound的performance tuning不够了解
z*e
97 楼
我做分布式从本科开始就在做了
这种风险管控，从理论到实践，肯定比你多多了
【在 b*******s 的大作中提到】
: 我觉得兄弟你在很多方面很厉害，但是对cpu bound的performance tuning不够了解
这种风险管控，从理论到实践，肯定比你多多了
【在 b*******s 的大作中提到】
: 我觉得兄弟你在很多方面很厉害，但是对cpu bound的performance tuning不够了解
b*s
98 楼
他的设计是无db的，不是io bound的
【在 g*****g 的大作中提到】
: 火车票订单能CPU bound，I服了U。
【在 g*****g 的大作中提到】
: 火车票订单能CPU bound，I服了U。
T*i
99 楼
相信我的人多的是，系统每天都在运转。
【在 z****e 的大作中提到】
: 所以不能相信你
【在 z****e 的大作中提到】
: 所以不能相信你
b*s
100 楼
你还没有明白，他的设计不是一个分布式系统，而是一个throughput能力极高的单机系统
【在 z****e 的大作中提到】
: 我做分布式从本科开始就在做了
: 这种风险管控，从理论到实践，肯定比你多多了
【在 z****e 的大作中提到】
: 我做分布式从本科开始就在做了
: 这种风险管控，从理论到实践，肯定比你多多了
g*g
101 楼
无DB? LOL，设计金钱交易的没transaction，出点问题找谁去？
钱交了，票没给，还不得冲击中南海。
【在 b*******s 的大作中提到】
: 他的设计是无db的，不是io bound的
钱交了，票没给，还不得冲击中南海。
【在 b*******s 的大作中提到】
: 他的设计是无db的，不是io bound的
z*e
102 楼
那又怎样？这两个不是一个领域
你凭什么认为其它领域应该相信你？
你要是美帝的间谍怎么办？
【在 T********i 的大作中提到】
: 你搜一下去年knight capital如何在45分钟内亏400多M的。
你凭什么认为其它领域应该相信你？
你要是美帝的间谍怎么办？
【在 T********i 的大作中提到】
: 你搜一下去年knight capital如何在45分钟内亏400多M的。
z*e
103 楼
那你认为比起ibm的主机来说，谁更值得相信？
系统
【在 b*******s 的大作中提到】
: 你还没有明白，他的设计不是一个分布式系统，而是一个throughput能力极高的单机系统
系统
【在 b*******s 的大作中提到】
: 你还没有明白，他的设计不是一个分布式系统，而是一个throughput能力极高的单机系统
b*s
104 楼
这样已经好几年啦，几年没什么大问题，你不觉得很棒吗
我们的客户也都是有几千万用户的呀
【在 z****e 的大作中提到】
: again
: 你们公司而已
: 你们公司挂了就挂了，不用担什么责任
: 无非一个破产保护了事
:
: bug
我们的客户也都是有几千万用户的呀
【在 z****e 的大作中提到】
: again
: 你们公司而已
: 你们公司挂了就挂了，不用担什么责任
: 无非一个破产保护了事
:
: bug
T*i
105 楼
其实是io bound的。
只能带4个10G ethernet。全双工能接近80G的吞吐量。
但是，这种订票请求和回答，都是几十上百byte的。
【在 b*******s 的大作中提到】
: 他的设计是无db的，不是io bound的
只能带4个10G ethernet。全双工能接近80G的吞吐量。
但是，这种订票请求和回答，都是几十上百byte的。
【在 b*******s 的大作中提到】
: 他的设计是无db的，不是io bound的
z*e
106 楼
so？
其它领域的就应该对你跪舔还是怎么着？
你拿什么东西来保证你的系统一定ok？
如果不ok是不是就枪决你？
【在 T********i 的大作中提到】
: 相信我的人多的是，系统每天都在运转。
其它领域的就应该对你跪舔还是怎么着？
你拿什么东西来保证你的系统一定ok？
如果不ok是不是就枪决你？
【在 T********i 的大作中提到】
: 相信我的人多的是，系统每天都在运转。
b*s
107 楼
所以我前面一直在问可不可以没有transaction
不过我觉得至少抢票占座是不一定需要transcation的，而付钱的环节，冲击并不大
【在 g*****g 的大作中提到】
: 无DB? LOL，设计金钱交易的没transaction，出点问题找谁去？
: 钱交了，票没给，还不得冲击中南海。
不过我觉得至少抢票占座是不一定需要transcation的，而付钱的环节，冲击并不大
【在 g*****g 的大作中提到】
: 无DB? LOL，设计金钱交易的没transaction，出点问题找谁去？
: 钱交了，票没给，还不得冲击中南海。
z*e
108 楼
不觉得很棒阿，公司和政府是两回事
公司可以做一些很低级的尝试，反正失败了就丢掉市场就是了
政府错一点，搞不好就要上刑事法庭
比如放一个劫机犯上飞机的话
【在 b*******s 的大作中提到】
: 这样已经好几年啦，几年没什么大问题，你不觉得很棒吗
: 我们的客户也都是有几千万用户的呀
公司可以做一些很低级的尝试，反正失败了就丢掉市场就是了
政府错一点，搞不好就要上刑事法庭
比如放一个劫机犯上飞机的话
【在 b*******s 的大作中提到】
: 这样已经好几年啦，几年没什么大问题，你不觉得很棒吗
: 我们的客户也都是有几千万用户的呀
b*s
109 楼
哦，忘记网络了，但是不是在数据库那种和存储相关的
【在 T********i 的大作中提到】
: 其实是io bound的。
: 只能带4个10G ethernet。全双工能接近80G的吞吐量。
: 但是，这种订票请求和回答，都是几十上百byte的。
【在 T********i 的大作中提到】
: 其实是io bound的。
: 只能带4个10G ethernet。全双工能接近80G的吞吐量。
: 但是，这种订票请求和回答，都是几十上百byte的。
T*i
110 楼
你们这种啥叫db都搞不清楚的，怎么成为板上大牛的？
【在 g*****g 的大作中提到】
: 无DB? LOL，设计金钱交易的没transaction，出点问题找谁去？
: 钱交了，票没给，还不得冲击中南海。
【在 g*****g 的大作中提到】
: 无DB? LOL，设计金钱交易的没transaction，出点问题找谁去？
: 钱交了，票没给，还不得冲击中南海。
z*e
111 楼
这也不大那也不大，那出了问题是不是你来负责？
你来买单？比如这个系统因为某个bug丢了几百万
谁来买单？农民工肯定不会认倒霉，拿不到钱，砸了柜台很正常
【在 b*******s 的大作中提到】
: 所以我前面一直在问可不可以没有transaction
: 不过我觉得至少抢票占座是不一定需要transcation的，而付钱的环节，冲击并不大
你来买单？比如这个系统因为某个bug丢了几百万
谁来买单？农民工肯定不会认倒霉，拿不到钱，砸了柜台很正常
【在 b*******s 的大作中提到】
: 所以我前面一直在问可不可以没有transaction
: 不过我觉得至少抢票占座是不一定需要transcation的，而付钱的环节，冲击并不大
T*i
112 楼
这个必须是存储相关的。每个transaction都有log。log后才算数。
其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
就算完成了。
这个过程大约5微秒。但是stream line的through就可以是最大带宽。
因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
【在 b*******s 的大作中提到】
: 哦，忘记网络了，但是不是在数据库那种和存储相关的
其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
就算完成了。
这个过程大约5微秒。但是stream line的through就可以是最大带宽。
因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
【在 b*******s 的大作中提到】
: 哦，忘记网络了，但是不是在数据库那种和存储相关的
g*g
113 楼
你光吹有蛋用，莫非你比我懂？
【在 T********i 的大作中提到】
: 你们这种啥叫db都搞不清楚的，怎么成为板上大牛的？
【在 T********i 的大作中提到】
: 你们这种啥叫db都搞不清楚的，怎么成为板上大牛的？
z*e
114 楼
因为这也不用考虑，那也不用考虑
所以最简单，所以最安全
就你说的大概5ms，如果达不到呢？超过5ms怎么办？
一般出了一个事故，一个副总要下台，这辈子不得再入这个行当
你是不是也用这个来保证？这叫对人民负责的态度
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
所以最简单，所以最安全
就你说的大概5ms，如果达不到呢？超过5ms怎么办？
一般出了一个事故，一个副总要下台，这辈子不得再入这个行当
你是不是也用这个来保证？这叫对人民负责的态度
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
b*s
115 楼
log你准备怎么设计呢？
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
T*i
116 楼
实在人，不吹牛。楼上那贴都告诉你怎么做的了。
【在 g*****g 的大作中提到】
: 你光吹有蛋用，莫非你比我懂？
【在 g*****g 的大作中提到】
: 你光吹有蛋用，莫非你比我懂？
b*s
117 楼
我觉得你可以给个更完整的设计，这样讨论起来会更有效率，我大致能猜你会怎么做，
但是有时会猜错
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
但是有时会猜错
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
g*g
118 楼
commit log的实现可以参考cassandra。
【在 b*******s 的大作中提到】
: log你准备怎么设计呢？
:
: transaction
【在 b*******s 的大作中提到】
: log你准备怎么设计呢？
:
: transaction
N*K
119 楼
把代码贴出来才算实在人
【在 T********i 的大作中提到】
: 实在人，不吹牛。楼上那贴都告诉你怎么做的了。
【在 T********i 的大作中提到】
: 实在人，不吹牛。楼上那贴都告诉你怎么做的了。
g*g
120 楼
还楼上那贴，不就是重复我前面说得commit log queue + 离线交易的做法。
【在 T********i 的大作中提到】
: 实在人，不吹牛。楼上那贴都告诉你怎么做的了。
【在 T********i 的大作中提到】
: 实在人，不吹牛。楼上那贴都告诉你怎么做的了。
T*i
121 楼
就是一个journal。多台机器都能收到multicast，直接写到flat file好了。
其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
【在 b*******s 的大作中提到】
: log你准备怎么设计呢？
:
: transaction
其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
【在 b*******s 的大作中提到】
: log你准备怎么设计呢？
:
: transaction
b*s
122 楼
这个太催毛求疵了
我只想听听计算量如何估计，核心的数据结构如何设计
协议怎么设计，同步怎么做，logging怎么设计，throughput怎么计算这些
差不多也就够了
【在 N******K 的大作中提到】
: 把代码贴出来才算实在人
我只想听听计算量如何估计，核心的数据结构如何设计
协议怎么设计，同步怎么做，logging怎么设计，throughput怎么计算这些
差不多也就够了
【在 N******K 的大作中提到】
: 把代码贴出来才算实在人
T*i
123 楼
你只能做离线。
我这个是实时的，而且是强实时系统。guarantee多少毫秒有响应的。
【在 g*****g 的大作中提到】
: 还楼上那贴，不就是重复我前面说得commit log queue + 离线交易的做法。
我这个是实时的，而且是强实时系统。guarantee多少毫秒有响应的。
【在 g*****g 的大作中提到】
: 还楼上那贴，不就是重复我前面说得commit log queue + 离线交易的做法。
b*s
124 楼
嗯，算了一下，的确不是大问题
抢票你怎么设计的？
【在 T********i 的大作中提到】
: 就是一个journal。多台机器都能收到multicast，直接写到flat file好了。
: 其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
抢票你怎么设计的？
【在 T********i 的大作中提到】
: 就是一个journal。多台机器都能收到multicast，直接写到flat file好了。
: 其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
b*s
125 楼
写到flat file，万一要做rollback，你怎么保证实时？
【在 T********i 的大作中提到】
: 就是一个journal。多台机器都能收到multicast，直接写到flat file好了。
: 其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
【在 T********i 的大作中提到】
: 就是一个journal。多台机器都能收到multicast，直接写到flat file好了。
: 其实大多是查询，不要log的。真正的订单，就那么几亿张，log起来跟玩儿一样。
g*g
126 楼
LOL，你这就是不自量力了，不懂瞎说了。订单放下写commit log可以，反正也不保证
能成。
订单处理要连到银行去收钱。光网络延迟就不只毫秒了。
【在 T********i 的大作中提到】
: 你只能做离线。
: 我这个是实时的，而且是强实时系统。guarantee多少毫秒有响应的。
能成。
订单处理要连到银行去收钱。光网络延迟就不只毫秒了。
【在 T********i 的大作中提到】
: 你只能做离线。
: 我这个是实时的，而且是强实时系统。guarantee多少毫秒有响应的。
z*e
127 楼
这里面有哪怕一个涉及到真实的business logic没？
比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
没有legacy system？
【在 b*******s 的大作中提到】
: 这个太催毛求疵了
: 我只想听听计算量如何估计，核心的数据结构如何设计
: 协议怎么设计，同步怎么做，logging怎么设计，throughput怎么计算这些
: 差不多也就够了
比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
没有legacy system？
【在 b*******s 的大作中提到】
: 这个太催毛求疵了
: 我只想听听计算量如何估计，核心的数据结构如何设计
: 协议怎么设计，同步怎么做，logging怎么设计，throughput怎么计算这些
: 差不多也就够了
T*i
128 楼
你根本不懂我在说啥。系统肯定是毫秒级别的。
至于多少毫秒需要详细毛估估一下。
一般是理论rtt x 10。
至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
一台hot standby顶上。没有任何状态损失。
这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
想不出错，最好是尽量少写。
【在 z****e 的大作中提到】
: 因为这也不用考虑，那也不用考虑
: 所以最简单，所以最安全
: 就你说的大概5ms，如果达不到呢？超过5ms怎么办？
: 一般出了一个事故，一个副总要下台，这辈子不得再入这个行当
: 你是不是也用这个来保证？这叫对人民负责的态度
:
: transaction
至于多少毫秒需要详细毛估估一下。
一般是理论rtt x 10。
至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
一台hot standby顶上。没有任何状态损失。
这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
想不出错，最好是尽量少写。
【在 z****e 的大作中提到】
: 因为这也不用考虑，那也不用考虑
: 所以最简单，所以最安全
: 就你说的大概5ms，如果达不到呢？超过5ms怎么办？
: 一般出了一个事故，一个副总要下台，这辈子不得再入这个行当
: 你是不是也用这个来保证？这叫对人民负责的态度
:
: transaction
b*s
129 楼
真实的business logic都在里面，比如核心数据结构如何设计，肯定是照着来的
【在 z****e 的大作中提到】
: 这里面有哪怕一个涉及到真实的business logic没？
: 比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
: 没有legacy system？
【在 z****e 的大作中提到】
: 这里面有哪怕一个涉及到真实的business logic没？
: 比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
: 没有legacy system？
z*e
130 楼
你怎么保证系统在ms级？
我就问你，数据源在哪里？票的数据和钱的数据，这两个往往是分离的
而且是地理位置上的分离，一个在北京，一个在上海，正常
你怎么保证交易在这两个之间进行可以实现ms级？
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
我就问你，数据源在哪里？票的数据和钱的数据，这两个往往是分离的
而且是地理位置上的分离，一个在北京，一个在上海，正常
你怎么保证交易在这两个之间进行可以实现ms级？
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
z*e
131 楼
瞎扯，票务信息和个人账户信息肯定分离
一个在铁道部的legacy system里面
另外一个在各个银行自身的数据中心里面
还照着来，现实生活中大多数时候不是照着来
【在 b*******s 的大作中提到】
: 真实的business logic都在里面，比如核心数据结构如何设计，肯定是照着来的
一个在铁道部的legacy system里面
另外一个在各个银行自身的数据中心里面
还照着来，现实生活中大多数时候不是照着来
【在 b*******s 的大作中提到】
: 真实的business logic都在里面，比如核心数据结构如何设计，肯定是照着来的
T*i
132 楼
transaction在机器内做。抢到票才log。没抢到就是某个中间线路没票。直接rollback
。当作啥事没发生。
这就是紧耦合系统的好处。
只有系统转着，就保证状态正确
log的是状态变化而异。
就那几亿次状态变化，算个屁呀？
【在 b*******s 的大作中提到】
: 写到flat file，万一要做rollback，你怎么保证实时？
。当作啥事没发生。
这就是紧耦合系统的好处。
只有系统转着，就保证状态正确
log的是状态变化而异。
就那几亿次状态变化，算个屁呀？
【在 b*******s 的大作中提到】
: 写到flat file，万一要做rollback，你怎么保证实时？
z*e
133 楼
你的系统不会只有单机吧？
不会认为票和钱都在一台机器上吧？
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
不会认为票和钱都在一台机器上吧？
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
z*e
134 楼
你确定铁道部内部这么多年了
连个像样的系统都没有吗？
rollback
【在 T********i 的大作中提到】
: transaction在机器内做。抢到票才log。没抢到就是某个中间线路没票。直接rollback
: 。当作啥事没发生。
: 这就是紧耦合系统的好处。
: 只有系统转着，就保证状态正确
: log的是状态变化而异。
: 就那几亿次状态变化，算个屁呀？
连个像样的系统都没有吗？
rollback
【在 T********i 的大作中提到】
: transaction在机器内做。抢到票才log。没抢到就是某个中间线路没票。直接rollback
: 。当作啥事没发生。
: 这就是紧耦合系统的好处。
: 只有系统转着，就保证状态正确
: log的是状态变化而异。
: 就那几亿次状态变化，算个屁呀？
b*s
135 楼
rollback不光是抢票，还有我付了钱突然想退票
rollback
【在 T********i 的大作中提到】
: transaction在机器内做。抢到票才log。没抢到就是某个中间线路没票。直接rollback
: 。当作啥事没发生。
: 这就是紧耦合系统的好处。
: 只有系统转着，就保证状态正确
: log的是状态变化而异。
: 就那几亿次状态变化，算个屁呀？
rollback
【在 T********i 的大作中提到】
: transaction在机器内做。抢到票才log。没抢到就是某个中间线路没票。直接rollback
: 。当作啥事没发生。
: 这就是紧耦合系统的好处。
: 只有系统转着，就保证状态正确
: log的是状态变化而异。
: 就那几亿次状态变化，算个屁呀？
T*i
136 楼
其它的账户管理之类的都能分布。数据划分太容易了。我说过，雇你这样的民工我放心。
【在 z****e 的大作中提到】
: 瞎扯，票务信息和个人账户信息肯定分离
: 一个在铁道部的legacy system里面
: 另外一个在各个银行自身的数据中心里面
: 还照着来，现实生活中大多数时候不是照着来
【在 z****e 的大作中提到】
: 瞎扯，票务信息和个人账户信息肯定分离
: 一个在铁道部的legacy system里面
: 另外一个在各个银行自身的数据中心里面
: 还照着来，现实生活中大多数时候不是照着来
z*e
137 楼
哦，是么？那也就是脏活其它人去做
然后你就跳出来说，我这个机器肯定能搞定就行了是么？
那我也行，明年我就能让这里所有人登陆火星
搞不定都是你这个民工的责任，我负责写startup部分程序
main(){
//剩下的你搞定
}
心。
【在 T********i 的大作中提到】
: 其它的账户管理之类的都能分布。数据划分太容易了。我说过，雇你这样的民工我放心。
然后你就跳出来说，我这个机器肯定能搞定就行了是么？
那我也行，明年我就能让这里所有人登陆火星
搞不定都是你这个民工的责任，我负责写startup部分程序
main(){
//剩下的你搞定
}
心。
【在 T********i 的大作中提到】
: 其它的账户管理之类的都能分布。数据划分太容易了。我说过，雇你这样的民工我放心。
T*i
138 楼
退票就是沿途interlocked increment。每个线路大约100ns。guarantee成功。
然后multicast log，wait for ack。.transaction完成了。
【在 b*******s 的大作中提到】
: rollback不光是抢票，还有我付了钱突然想退票
:
: rollback
然后multicast log，wait for ack。.transaction完成了。
【在 b*******s 的大作中提到】
: rollback不光是抢票，还有我付了钱突然想退票
:
: rollback
f*4
139 楼
你这个方案把所有耗时的工作都扔给打酱油的待机服务器上了。支持rollback，但是不
是一旦rollback之后，就像股市那样，从某个时间点之后的交易全部作废？？
你用单机集中处理message，throughput就是网络最大带宽。但你这台单机需要down的
时候hot standby是怎么switch上去的？
一个几万行代码的东西，一个人做，完全可以做到及其稳定。
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
是一旦rollback之后，就像股市那样，从某个时间点之后的交易全部作废？？
你用单机集中处理message，throughput就是网络最大带宽。但你这台单机需要down的
时候hot standby是怎么switch上去的？
一个几万行代码的东西，一个人做，完全可以做到及其稳定。
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
b*s
140 楼
不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
要更利于快速查找才行
【在 T********i 的大作中提到】
: 退票就是沿途interlocked increment。每个线路大约100ns。guarantee成功。
: 然后multicast log，wait for ack。.transaction完成了。
即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
要更利于快速查找才行
【在 T********i 的大作中提到】
: 退票就是沿途interlocked increment。每个线路大约100ns。guarantee成功。
: 然后multicast log，wait for ack。.transaction完成了。
g*g
141 楼
你根本就是胡说，但凡涉及到第三方系统的交易没有保证毫秒级的。如果是每秒每线几
百万的交易量，也就是每秒上亿的外部request，第一个要看的是外部系统SLA，直接
drop request，long latency都是再正常不过了。
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
百万的交易量，也就是每秒上亿的外部request，第一个要看的是外部系统SLA，直接
drop request，long latency都是再正常不过了。
【在 T********i 的大作中提到】
: 你根本不懂我在说啥。系统肯定是毫秒级别的。
: 至于多少毫秒需要详细毛估估一下。
: 一般是理论rtt x 10。
: 至于超时，则肯定是硬件错误。恭喜你中彩票了。只不过当前transaction fail。另外
: 一台hot standby顶上。没有任何状态损失。
: 这种软件很好调试的。或者work或者不work。因为代码量实在太少了。
: 想不出错，最好是尽量少写。
T*i
142 楼
update和rollback都是一次状态变化。有啥区别呢?
我说过了，这是一个非常简单的状态自动机。
network communication是transaction的一部分。你再仔细想想。
【在 f****4 的大作中提到】
: 你这个方案把所有耗时的工作都扔给打酱油的待机服务器上了。支持rollback，但是不
: 是一旦rollback之后，就像股市那样，从某个时间点之后的交易全部作废？？
: 你用单机集中处理message，throughput就是网络最大带宽。但你这台单机需要down的
: 时候hot standby是怎么switch上去的？
: 一个几万行代码的东西，一个人做，完全可以做到及其稳定。
:
: transaction
我说过了，这是一个非常简单的状态自动机。
network communication是transaction的一部分。你再仔细想想。
【在 f****4 的大作中提到】
: 你这个方案把所有耗时的工作都扔给打酱油的待机服务器上了。支持rollback，但是不
: 是一旦rollback之后，就像股市那样，从某个时间点之后的交易全部作废？？
: 你用单机集中处理message，throughput就是网络最大带宽。但你这台单机需要down的
: 时候hot standby是怎么switch上去的？
: 一个几万行代码的东西，一个人做，完全可以做到及其稳定。
:
: transaction
b*s
143 楼
如何update和rollback还需要你更多的设计细节，不一样的设计差异很大
【在 T********i 的大作中提到】
: update和rollback都是一次状态变化。有啥区别呢?
: 我说过了，这是一个非常简单的状态自动机。
: network communication是transaction的一部分。你再仔细想想。
【在 T********i 的大作中提到】
: update和rollback都是一次状态变化。有啥区别呢?
: 我说过了，这是一个非常简单的状态自动机。
: network communication是transaction的一部分。你再仔细想想。
g*g
144 楼
commit log只是写快，读是很慢的，再加上涉及第三方。所以极高并发量是没法保证在
线的，更不用论
实时了。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
线的，更不用论
实时了。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
f*4
145 楼
不用那么复杂，退票只要主机沿线空票+1，让别的待机去退钱。只要找到log记录，取
消银行交易即可。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
消银行交易即可。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
x*u
146 楼
新警察吧，用C++写大规模的web应用只会导致更慢的速度。。。
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
f*4
147 楼
恩，我刚才没看到你之前的几个回帖。
你的主机只管是否有票；standby处理慢的事情。只要有log就能处理银行交易。而这个
过程慢一点不影响整个系统throughput。
【在 T********i 的大作中提到】
: update和rollback都是一次状态变化。有啥区别呢?
: 我说过了，这是一个非常简单的状态自动机。
: network communication是transaction的一部分。你再仔细想想。
你的主机只管是否有票；standby处理慢的事情。只要有log就能处理银行交易。而这个
过程慢一点不影响整个系统throughput。
【在 T********i 的大作中提到】
: update和rollback都是一次状态变化。有啥区别呢?
: 我说过了，这是一个非常简单的状态自动机。
: network communication是transaction的一部分。你再仔细想想。
b*s
148 楼
这就是我说的非硬实时的rollback，但是空票＋1这样的设计我觉得是不行的，至少要
精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
关的
【在 f****4 的大作中提到】
: 不用那么复杂，退票只要主机沿线空票+1，让别的待机去退钱。只要找到log记录，取
: 消银行交易即可。
:
: logging
精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
关的
【在 f****4 的大作中提到】
: 不用那么复杂，退票只要主机沿线空票+1，让别的待机去退钱。只要找到log记录，取
: 消银行交易即可。
:
: logging
b*s
149 楼
这不是个web应用
【在 x****u 的大作中提到】
: 新警察吧，用C++写大规模的web应用只会导致更慢的速度。。。
【在 x****u 的大作中提到】
: 新警察吧，用C++写大规模的web应用只会导致更慢的速度。。。
z*e
150 楼
它压根没考虑web部分
只考虑怎么更新票数据的部分
【在 x****u 的大作中提到】
: 新警察吧，用C++写大规模的web应用只会导致更慢的速度。。。
只考虑怎么更新票数据的部分
【在 x****u 的大作中提到】
: 新警察吧，用C++写大规模的web应用只会导致更慢的速度。。。
f*4
151 楼
我只是懒得打字了。。。
【在 b*******s 的大作中提到】
: 这就是我说的非硬实时的rollback，但是空票＋1这样的设计我觉得是不行的，至少要
: 精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
: 关的
【在 b*******s 的大作中提到】
: 这就是我说的非硬实时的rollback，但是空票＋1这样的设计我觉得是不行的，至少要
: 精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
: 关的
z*e
152 楼
诶，这个还真是web应用
说的就是网站，但是楼主不愿意说太多web的东西
只愿意考虑update状态那个部分
剩下的都是脏活，都交给民工们去干
【在 b*******s 的大作中提到】
: 这不是个web应用
说的就是网站，但是楼主不愿意说太多web的东西
只愿意考虑update状态那个部分
剩下的都是脏活，都交给民工们去干
【在 b*******s 的大作中提到】
: 这不是个web应用
T*i
153 楼
别忘了，买过的票就那么几亿张。
用传统数据库和完全的in memory cache完全能解决。
这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
方便记这样叫没错。
我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
和筛选过的。
外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
这就是我能做别人不能做的。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
用传统数据库和完全的in memory cache完全能解决。
这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
方便记这样叫没错。
我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
和筛选过的。
外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
这就是我能做别人不能做的。
logging
【在 b*******s 的大作中提到】
: 不是那么简单的，比如我1号买了20号的票，到了19号我要退票，你写flat file的话
: 即使你进行了切分，依然有disk i/o和需要遍历一定数量的记录，所以我觉得logging
: 要更利于快速查找才行
b*s
154 楼
我觉得大家在讨论时都在假设别人已经完全理解了自己的潜台词，呵呵
【在 f****4 的大作中提到】
: 我只是懒得打字了。。。
【在 f****4 的大作中提到】
: 我只是懒得打字了。。。
g*g
155 楼
我再说一遍，写log做到实时没问题，交易提交了，回头看到没票了，或者银行账户错
了，再给你cancel了那不叫实时系统。并发量够大连在线都做不到，除非在线等15分钟
才有结果也算在线。
【在 f****4 的大作中提到】
: 恩，我刚才没看到你之前的几个回帖。
: 你的主机只管是否有票；standby处理慢的事情。只要有log就能处理银行交易。而这个
: 过程慢一点不影响整个系统throughput。
了，再给你cancel了那不叫实时系统。并发量够大连在线都做不到，除非在线等15分钟
才有结果也算在线。
【在 f****4 的大作中提到】
: 恩，我刚才没看到你之前的几个回帖。
: 你的主机只管是否有票；standby处理慢的事情。只要有log就能处理银行交易。而这个
: 过程慢一点不影响整个系统throughput。
z*e
156 楼
你的核心能强耦合？
我打赌你做不到
票的信息肯定在legacy system里面
而且还不是很常规的那种系统
估计票务信息是独立的db server
你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
我打赌你做不到
票的信息肯定在legacy system里面
而且还不是很常规的那种系统
估计票务信息是独立的db server
你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
x*u
157 楼
12306又不是慢在票数据上啊。
【在 z****e 的大作中提到】
: 它压根没考虑web部分
: 只考虑怎么更新票数据的部分
【在 z****e 的大作中提到】
: 它压根没考虑web部分
: 只考虑怎么更新票数据的部分
z*e
158 楼
顺便说一下
你见过哪个公司的传统db里面只有那么一两个核心数据？
没有外键？没有关联表？没有一堆schema？
数据库迁移没做过？
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
你见过哪个公司的传统db里面只有那么一两个核心数据？
没有外键？没有关联表？没有一堆schema？
数据库迁移没做过？
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
b*s
159 楼
legacy system是作弊，可以全部移植到新系统
【在 z****e 的大作中提到】
: 你的核心能强耦合？
: 我打赌你做不到
: 票的信息肯定在legacy system里面
: 而且还不是很常规的那种系统
: 估计票务信息是独立的db server
: 你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
【在 z****e 的大作中提到】
: 你的核心能强耦合？
: 我打赌你做不到
: 票的信息肯定在legacy system里面
: 而且还不是很常规的那种系统
: 估计票务信息是独立的db server
: 你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
z*e
160 楼
所以说它比较弱，都不知道问题出在哪
【在 x****u 的大作中提到】
: 12306又不是慢在票数据上啊。
【在 x****u 的大作中提到】
: 12306又不是慢在票数据上啊。
x*u
161 楼
万一哪天网管吃泡面洒在你的server上，全国人民的车票就泡汤了。
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
【在 T********i 的大作中提到】
: 别忘了，买过的票就那么几亿张。
: 用传统数据库和完全的in memory cache完全能解决。
: 这些都是外围打酱油的服务器。也就是static content cache。其实不完全static。为
: 方便记这样叫没错。
: 我的核心是状态自动机。是处理数亿人的刷屏查询和实时订票的。发给他的请求是验证
: 和筛选过的。
: 外围的那些，数据划分太容易了。而我的核心，由于依赖性，必须紧耦合。
: 这就是我能做别人不能做的。
:
: logging
T*i
162 楼
这就是有向图的算法。
我一直强调区间段的 。
至于座位，则是简单的attribute。讨论可忽略。
【在 b*******s 的大作中提到】
: 这就是我说的非硬实时的rollback，但是空票＋1这样的设计我觉得是不行的，至少要
: 精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
: 关的
我一直强调区间段的 。
至于座位，则是简单的attribute。讨论可忽略。
【在 b*******s 的大作中提到】
: 这就是我说的非硬实时的rollback，但是空票＋1这样的设计我觉得是不行的，至少要
: 精确到座位和区间段，这样的话，你至少要知道这次rollback是和哪个座位以及区间相
: 关的
z*e
163 楼
哈？连legacy system都要重构阿？
这个代价太大了，还是ibm的主机吧
【在 b*******s 的大作中提到】
: legacy system是作弊，可以全部移植到新系统
这个代价太大了，还是ibm的主机吧
【在 b*******s 的大作中提到】
: legacy system是作弊，可以全部移植到新系统
g*g
164 楼
他那是高频exchange一个严重错误，今天后面的交易都取消的做法。掉个电直接
都玩完。
【在 x****u 的大作中提到】
: 万一哪天网管吃泡面洒在你的server上，全国人民的车票就泡汤了。
都玩完。
【在 x****u 的大作中提到】
: 万一哪天网管吃泡面洒在你的server上，全国人民的车票就泡汤了。
z*e
165 楼
座位十有八九是另外一张甚至几张表里面
【在 T********i 的大作中提到】
: 这就是有向图的算法。
: 我一直强调区间段的 。
: 至于座位，则是简单的attribute。讨论可忽略。
【在 T********i 的大作中提到】
: 这就是有向图的算法。
: 我一直强调区间段的 。
: 至于座位，则是简单的attribute。讨论可忽略。
b*s
166 楼
我是说，票的信息不在legacy系统里
【在 z****e 的大作中提到】
: 哈？连legacy system都要重构阿？
: 这个代价太大了，还是ibm的主机吧
【在 z****e 的大作中提到】
: 哈？连legacy system都要重构阿？
: 这个代价太大了，还是ibm的主机吧
z*e
167 楼
那在哪里？
感情这个系统上线前人民都不用计算机系统了？
【在 b*******s 的大作中提到】
: 我是说，票的信息不在legacy系统里
感情这个系统上线前人民都不用计算机系统了？
【在 b*******s 的大作中提到】
: 我是说，票的信息不在legacy系统里
f*4
168 楼
到了log这一步就是抢到票了，不会有没票的可能。
银行账户出错，message根本到不了核心的主机那里去更新状态。用户看到的必然是付
款错误。
【在 g*****g 的大作中提到】
: 我再说一遍，写log做到实时没问题，交易提交了，回头看到没票了，或者银行账户错
: 了，再给你cancel了那不叫实时系统。并发量够大连在线都做不到，除非在线等15分钟
: 才有结果也算在线。
银行账户出错，message根本到不了核心的主机那里去更新状态。用户看到的必然是付
款错误。
【在 g*****g 的大作中提到】
: 我再说一遍，写log做到实时没问题，交易提交了，回头看到没票了，或者银行账户错
: 了，再给你cancel了那不叫实时系统。并发量够大连在线都做不到，除非在线等15分钟
: 才有结果也算在线。
g*g
169 楼
他的所谓实时系统，只从应用服务器提交到DB写完commit log那么远。正常人类说的实
时系统，是从用户提交订单到订单确认，差别大了。
时系统，是从用户提交订单到订单确认，差别大了。
T*i
170 楼
无聊，睡了。
美国任何一个证交所的交易都能处理每秒百万tran*级别的。这个我可以肯定地讲你们
中间谁做不出来。
美国任何一个证交所的交易都能处理每秒百万tran*级别的。这个我可以肯定地讲你们
中间谁做不出来。
f*4
171 楼
你没做过hot standby的东西？
【在 x****u 的大作中提到】
: 万一哪天网管吃泡面洒在你的server上，全国人民的车票就泡汤了。
【在 x****u 的大作中提到】
: 万一哪天网管吃泡面洒在你的server上，全国人民的车票就泡汤了。
b*s
172 楼
直接把信息输入新系统，旧系统就停了，你这个一定要用旧系统是作弊，相当于给刘翔
穿1吨重的铁背心
【在 z****e 的大作中提到】
: 那在哪里？
: 感情这个系统上线前人民都不用计算机系统了？
穿1吨重的铁背心
【在 z****e 的大作中提到】
: 那在哪里？
: 感情这个系统上线前人民都不用计算机系统了？
z*e
173 楼
你做过db migration么？
【在 b*******s 的大作中提到】
: 直接把信息输入新系统，旧系统就停了，你这个一定要用旧系统是作弊，相当于给刘翔
: 穿1吨重的铁背心
【在 b*******s 的大作中提到】
: 直接把信息输入新系统，旧系统就停了，你这个一定要用旧系统是作弊，相当于给刘翔
: 穿1吨重的铁背心
b*s
174 楼
呵呵
【在 f****4 的大作中提到】
: 你没做过hot standby的东西？
【在 f****4 的大作中提到】
: 你没做过hot standby的东西？
b*s
175 楼
他的系统不是db
【在 z****e 的大作中提到】
: 你做过db migration么？
【在 z****e 的大作中提到】
: 你做过db migration么？
g*g
176 楼
啥叫没有没票的可能？只写不读怎么保证计数器不<0。
【在 f****4 的大作中提到】
: 到了log这一步就是抢到票了，不会有没票的可能。
: 银行账户出错，message根本到不了核心的主机那里去更新状态。用户看到的必然是付
: 款错误。
【在 f****4 的大作中提到】
: 到了log这一步就是抢到票了，不会有没票的可能。
: 银行账户出错，message根本到不了核心的主机那里去更新状态。用户看到的必然是付
: 款错误。
z*e
177 楼
你要把db丢掉换成file system，你觉得这里面有多大的阻力？
【在 b*******s 的大作中提到】
: 他的系统不是db
【在 b*******s 的大作中提到】
: 他的系统不是db
T*i
178 楼
你没吃过猪肉见过猪跑没？
10分钟后银行出错。订单取消。只给核心发一个消息把票还回去。剩下的是外围的事。
你没上网买过东西？
【在 g*****g 的大作中提到】
: 他的所谓实时系统，只从应用服务器提交到DB写完commit log那么远。正常人类说的实
: 时系统，是从用户提交订单到订单确认，差别大了。
10分钟后银行出错。订单取消。只给核心发一个消息把票还回去。剩下的是外围的事。
你没上网买过东西？
【在 g*****g 的大作中提到】
: 他的所谓实时系统，只从应用服务器提交到DB写完commit log那么远。正常人类说的实
: 时系统，是从用户提交订单到订单确认，差别大了。
b*s
179 楼
你们一直在用db的概念套，不如先回答transaction是否必要
否则一点意义都没有，各讲各的
【在 z****e 的大作中提到】
: 你做过db migration么？
否则一点意义都没有，各讲各的
【在 z****e 的大作中提到】
: 你做过db migration么？
z*e
180 楼
db是客观存在的事实
难道你不认为铁道部的这些数据会有极大可能在db里面？
【在 b*******s 的大作中提到】
: 你们一直在用db的概念套，不如先回答transaction是否必要
: 否则一点意义都没有，各讲各的
难道你不认为铁道部的这些数据会有极大可能在db里面？
【在 b*******s 的大作中提到】
: 你们一直在用db的概念套，不如先回答transaction是否必要
: 否则一点意义都没有，各讲各的
b*s
181 楼
新系统会卖过去的票吗？
【在 z****e 的大作中提到】
: db是客观存在的事实
: 难道你不认为铁道部的这些数据会有极大可能在db里面？
【在 z****e 的大作中提到】
: db是客观存在的事实
: 难道你不认为铁道部的这些数据会有极大可能在db里面？
g*g
182 楼
你丫吹了半天牛，现在回过神来还是我说的离线订单了？但凡不是当场端到端确认订单
，包括银行付款
的，都是离线订单。几毫米的实时系统都吹出来了，一下子又缩回去了。做人不吹牛会
死吗？
【在 T********i 的大作中提到】
: 你没吃过猪肉见过猪跑没？
: 10分钟后银行出错。订单取消。只给核心发一个消息把票还回去。剩下的是外围的事。
: 你没上网买过东西？
，包括银行付款
的，都是离线订单。几毫米的实时系统都吹出来了，一下子又缩回去了。做人不吹牛会
死吗？
【在 T********i 的大作中提到】
: 你没吃过猪肉见过猪跑没？
: 10分钟后银行出错。订单取消。只给核心发一个消息把票还回去。剩下的是外围的事。
: 你没上网买过东西？
z*e
183 楼
什么过去不过去，所有的票的信息都在一个大db clusters里面
你不这样认为？
【在 b*******s 的大作中提到】
: 新系统会卖过去的票吗？
你不这样认为？
【在 b*******s 的大作中提到】
: 新系统会卖过去的票吗？
z*e
184 楼
你定义一下过去和将来的票的界限在哪里
【在 b*******s 的大作中提到】
: 新系统会卖过去的票吗？
【在 b*******s 的大作中提到】
: 新系统会卖过去的票吗？
f*4
185 楼
票务信息？主机那里不需要票务的信息，主机那说你抢到票了，才会生成票务记录。不
需要去查询的。
你与其说这个，不如问他，某个班次的车给取消了，他怎么rollback来得实际。
【在 z****e 的大作中提到】
: 你的核心能强耦合？
: 我打赌你做不到
: 票的信息肯定在legacy system里面
: 而且还不是很常规的那种系统
: 估计票务信息是独立的db server
: 你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
需要去查询的。
你与其说这个，不如问他，某个班次的车给取消了，他怎么rollback来得实际。
【在 z****e 的大作中提到】
: 你的核心能强耦合？
: 我打赌你做不到
: 票的信息肯定在legacy system里面
: 而且还不是很常规的那种系统
: 估计票务信息是独立的db server
: 你一定要通过网络连接，那么网络连接中间会出现数据中断等各种问题
b*s
186 楼
我的观点是，所谓的“票”的概念，都是在交易时才存在的，更直接的描述是某列车，
某张座位，在某个区间的占据
【在 z****e 的大作中提到】
: 什么过去不过去，所有的票的信息都在一个大db clusters里面
: 你不这样认为？
某张座位，在某个区间的占据
【在 z****e 的大作中提到】
: 什么过去不过去，所有的票的信息都在一个大db clusters里面
: 你不这样认为？
g*g
187 楼
魏老师吹了半天牛，从几毫米的实时系统一下子缩到到10分钟才能确认，这个差距实在
太大了。
太大了。
z*e
188 楼
那这个位置是否提供，这个信息不需要数据库存？
【在 f****4 的大作中提到】
: 票务信息？主机那里不需要票务的信息，主机那说你抢到票了，才会生成票务记录。不
: 需要去查询的。
: 你与其说这个，不如问他，某个班次的车给取消了，他怎么rollback来得实际。
【在 f****4 的大作中提到】
: 票务信息？主机那里不需要票务的信息，主机那说你抢到票了，才会生成票务记录。不
: 需要去查询的。
: 你与其说这个，不如问他，某个班次的车给取消了，他怎么rollback来得实际。
f*4
189 楼
你还没明白，他这是把所有慢的东西都放到standby的机器上去。。。
到主机的message都是干净的，所以主机逻辑最简单
【在 z****e 的大作中提到】
: 你要把db丢掉换成file system，你觉得这里面有多大的阻力？
到主机的message都是干净的，所以主机逻辑最简单
【在 z****e 的大作中提到】
: 你要把db丢掉换成file system，你觉得这里面有多大的阻力？
f*4
190 楼
他主机就干这一件事情啊！！！
【在 z****e 的大作中提到】
: 那这个位置是否提供，这个信息不需要数据库存？
【在 z****e 的大作中提到】
: 那这个位置是否提供，这个信息不需要数据库存？
z*e
191 楼
这个部分的负载十年前就搞定了
它在吹什么？
瓶颈都在数据层面上
【在 f****4 的大作中提到】
: 你还没明白，他这是把所有慢的东西都放到standby的机器上去。。。
: 到主机的message都是干净的，所以主机逻辑最简单
它在吹什么？
瓶颈都在数据层面上
【在 f****4 的大作中提到】
: 你还没明白，他这是把所有慢的东西都放到standby的机器上去。。。
: 到主机的message都是干净的，所以主机逻辑最简单
x*u
192 楼
上证都是外星人做的。
【在 T********i 的大作中提到】
: 无聊，睡了。
: 美国任何一个证交所的交易都能处理每秒百万tran*级别的。这个我可以肯定地讲你们
: 中间谁做不出来。
【在 T********i 的大作中提到】
: 无聊，睡了。
: 美国任何一个证交所的交易都能处理每秒百万tran*级别的。这个我可以肯定地讲你们
: 中间谁做不出来。
g*g
193 楼
就干这一件事情也不能保证交易成功。不去银行把钱刷了，哪能叫交易成功。
光写个commit log，我要他干啥，cassandra不是干的好好的。
【在 f****4 的大作中提到】
: 他主机就干这一件事情啊！！！
光写个commit log，我要他干啥，cassandra不是干的好好的。
【在 f****4 的大作中提到】
: 他主机就干这一件事情啊！！！
f*4
194 楼
写了之后再广播log
【在 g*****g 的大作中提到】
: 啥叫没有没票的可能？只写不读怎么保证计数器不<0。
【在 g*****g 的大作中提到】
: 啥叫没有没票的可能？只写不读怎么保证计数器不<0。
z*e
195 楼
其中一半log反馈，失败，请回滚
剩下一半log反馈，哦也，成功了
怎么办？
【在 f****4 的大作中提到】
: 写了之后再广播log
剩下一半log反馈，哦也，成功了
怎么办？
【在 f****4 的大作中提到】
: 写了之后再广播log
f*4
196 楼
应该这么问：你能把卖过一次的票再卖一次么？
不能的话要查票务信息做什么？
【在 z****e 的大作中提到】
: 什么过去不过去，所有的票的信息都在一个大db clusters里面
: 你不这样认为？
不能的话要查票务信息做什么？
【在 z****e 的大作中提到】
: 什么过去不过去，所有的票的信息都在一个大db clusters里面
: 你不这样认为？
b*s
197 楼
上证是禁止高频的
【在 x****u 的大作中提到】
: 上证都是外星人做的。
【在 x****u 的大作中提到】
: 上证都是外星人做的。
z*e
198 楼
有可能哦，如果划帐失败的话，同一票会出第二次
【在 f****4 的大作中提到】
: 应该这么问：你能把卖过一次的票再卖一次么？
: 不能的话要查票务信息做什么？
【在 f****4 的大作中提到】
: 应该这么问：你能把卖过一次的票再卖一次么？
: 不能的话要查票务信息做什么？
b*s
199 楼
按他的设计，不可能的，只有等rollback完成
【在 z****e 的大作中提到】
: 有可能哦，如果划帐失败的话，同一票会出第二次
【在 z****e 的大作中提到】
: 有可能哦，如果划帐失败的话，同一票会出第二次
g*g
200 楼
还广播呢，就让你单机，你要知道当前计数难道不需要把整个commit log处理了？
光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
是transaction。
这些都是CAP里面证明过的东西，没法beat的。
【在 f****4 的大作中提到】
: 写了之后再广播log
光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
是transaction。
这些都是CAP里面证明过的东西，没法beat的。
【在 f****4 的大作中提到】
: 写了之后再广播log
z*e
201 楼
again
其实这里不是出瓶颈的地方
十年前就搞定了
【在 b*******s 的大作中提到】
: 按他的设计，不可能的，只有等rollback完成
其实这里不是出瓶颈的地方
十年前就搞定了
【在 b*******s 的大作中提到】
: 按他的设计，不可能的，只有等rollback完成
b*s
202 楼
按他的设计，旧系统的瓶颈在哪里不重要，基本架构都不一样了
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
f*4
203 楼
别的机器划到钱了再来主机抢票不就好了？抢不到票别的机器再去银行取消好了。
淘宝都能把货卖爆了，事后退款。。。
【在 g*****g 的大作中提到】
: 就干这一件事情也不能保证交易成功。不去银行把钱刷了，哪能叫交易成功。
: 光写个commit log，我要他干啥，cassandra不是干的好好的。
淘宝都能把货卖爆了，事后退款。。。
【在 g*****g 的大作中提到】
: 就干这一件事情也不能保证交易成功。不去银行把钱刷了，哪能叫交易成功。
: 光写个commit log，我要他干啥，cassandra不是干的好好的。
b*s
204 楼
你的潜台词是，一定要transcation，不知道老兄注意到了没有
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
z*e
205 楼
我说的是它的新系统新设计
它先要去旧的系统里面，把所有座位的信息给拿到，存起来
否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
人工输入？
【在 b*******s 的大作中提到】
: 按他的设计，旧系统的瓶颈在哪里不重要，基本架构都不一样了
它先要去旧的系统里面，把所有座位的信息给拿到，存起来
否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
人工输入？
【在 b*******s 的大作中提到】
: 按他的设计，旧系统的瓶颈在哪里不重要，基本架构都不一样了
f*4
206 楼
麻烦你看看帖子好不好？
这个log根本就不是用来做计数的！
【在 g*****g 的大作中提到】
: 还广播呢，就让你单机，你要知道当前计数难道不需要把整个commit log处理了？
: 光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
: 是transaction。
: 这些都是CAP里面证明过的东西，没法beat的。
这个log根本就不是用来做计数的！
【在 g*****g 的大作中提到】
: 还广播呢，就让你单机，你要知道当前计数难道不需要把整个commit log处理了？
: 光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
: 是transaction。
: 这些都是CAP里面证明过的东西，没法beat的。
g*g
207 楼
这个可以做，问题那不就是我说的吗。commit log + 离线交易。魏老师吹这半天牛，
几毫米的强实时系统都出来了，最后就拾我牙慧呀？
【在 f****4 的大作中提到】
: 别的机器划到钱了再来主机抢票不就好了？抢不到票别的机器再去银行取消好了。
: 淘宝都能把货卖爆了，事后退款。。。
几毫米的强实时系统都出来了，最后就拾我牙慧呀？
【在 f****4 的大作中提到】
: 别的机器划到钱了再来主机抢票不就好了？抢不到票别的机器再去银行取消好了。
: 淘宝都能把货卖爆了，事后退款。。。
z*e
208 楼
因为我的前提是瓶颈出在persistence这一层上
不知道为什么你没有看到这一层才是真正出问题的地方
而不是什么app server，那个十年前就搞定了，没有瓶颈问题
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
不知道为什么你没有看到这一层才是真正出问题的地方
而不是什么app server，那个十年前就搞定了，没有瓶颈问题
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
g*g
209 楼
你懂不懂啥叫transaction？不管咋整都算成功，过后离线cancel了，那不叫
transaction. 不叫实时系统。
【在 f****4 的大作中提到】
: 麻烦你看看帖子好不好？
: 这个log根本就不是用来做计数的！
transaction. 不叫实时系统。
【在 f****4 的大作中提到】
: 麻烦你看看帖子好不好？
: 这个log根本就不是用来做计数的！
z*e
210 楼
我的第一个贴
发信人: zhaoce (米高蜥蜴), 信区: Programming
标 题: Re: 很多东东要是我来设计，会很不一样
发信站: BBS 未名空间站 (Thu Nov 21 18:26:40 2013, 美东)
app server的scalability的问题十年前就搞定了
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
发信人: zhaoce (米高蜥蜴), 信区: Programming
标 题: Re: 很多东东要是我来设计，会很不一样
发信站: BBS 未名空间站 (Thu Nov 21 18:26:40 2013, 美东)
app server的scalability的问题十年前就搞定了
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
b*s
211 楼
他初始化到有向图里面了，中间基本不需要了
【在 z****e 的大作中提到】
: 我说的是它的新系统新设计
: 它先要去旧的系统里面，把所有座位的信息给拿到，存起来
: 否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
: 人工输入？
【在 z****e 的大作中提到】
: 我说的是它的新系统新设计
: 它先要去旧的系统里面，把所有座位的信息给拿到，存起来
: 否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
: 人工输入？
b*s
212 楼
他的一致性就是在那个有向图上做的
如果我正确理解了他
【在 z****e 的大作中提到】
: 因为我的前提是瓶颈出在persistence这一层上
: 不知道为什么你没有看到这一层才是真正出问题的地方
: 而不是什么app server，那个十年前就搞定了，没有瓶颈问题
如果我正确理解了他
【在 z****e 的大作中提到】
: 因为我的前提是瓶颈出在persistence这一层上
: 不知道为什么你没有看到这一层才是真正出问题的地方
: 而不是什么app server，那个十年前就搞定了，没有瓶颈问题
z*e
213 楼
就像小菊花说的，一碗泡面毁了全部人民的火车票
别告诉我这个有向图不在内存里面
【在 b*******s 的大作中提到】
: 他初始化到有向图里面了，中间基本不需要了
别告诉我这个有向图不在内存里面
【在 b*******s 的大作中提到】
: 他初始化到有向图里面了，中间基本不需要了
b*s
214 楼
他说的不是scalability，是throughput
【在 z****e 的大作中提到】
: 我的第一个贴
: 发信人: zhaoce (米高蜥蜴), 信区: Programming
: 标 题: Re: 很多东东要是我来设计，会很不一样
: 发信站: BBS 未名空间站 (Thu Nov 21 18:26:40 2013, 美东)
: app server的scalability的问题十年前就搞定了
【在 z****e 的大作中提到】
: 我的第一个贴
: 发信人: zhaoce (米高蜥蜴), 信区: Programming
: 标 题: Re: 很多东东要是我来设计，会很不一样
: 发信站: BBS 未名空间站 (Thu Nov 21 18:26:40 2013, 美东)
: app server的scalability的问题十年前就搞定了
z*e
215 楼
你还是要读进来，多大的数据阿
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
g*g
216 楼
不用扯了，我43楼把全套方案都写出来了。他吹了半天牛也没偏离我的方案，
就是细节差多了。
发信人: goodbug (好虫), 信区: Programming
标 题: Re: 很多东东要是我来设计，会很不一样
发信站: BBS 未名空间站 (Thu Nov 21 22:39:15 2013, 美东)
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的。
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
就是细节差多了。
发信人: goodbug (好虫), 信区: Programming
标 题: Re: 很多东东要是我来设计，会很不一样
发信站: BBS 未名空间站 (Thu Nov 21 22:39:15 2013, 美东)
架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
，所有的数据库读都是cache发起的。用户读只hit cache。
接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
无限
分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
日期)发到不同的queue上以commit log的性质写，这个没有锁，极快。然后处理这个
queue就完了。一个好的数据库服务器处理每秒1万的transaction不是问题。一整个
queue一秒钟就处理完了，票卖完了后面直接通知买不到。
这个架构底下，所有线路所有天的票一秒钟就处理了，所以可以往回放，比如不用分日
期，不用分
线路等等。当
然事实上是没这么理想的，还要等外部支付系统确认交易成功等等，但撑住是没问题的。
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
z*e
217 楼
这两个不是一回事么？难道scalability是为了解决latency用的？
【在 b*******s 的大作中提到】
: 他说的不是scalability，是throughput
【在 b*******s 的大作中提到】
: 他说的不是scalability，是throughput
b*s
218 楼
他是一个集群，状态一致的集群，standby的随时切到main的
【在 z****e 的大作中提到】
: 就像小菊花说的，一碗泡面毁了全部人民的火车票
: 别告诉我这个有向图不在内存里面
【在 z****e 的大作中提到】
: 就像小菊花说的，一碗泡面毁了全部人民的火车票
: 别告诉我这个有向图不在内存里面
h*a
219 楼
你前面说过，不过还是想知道，两台服务器一起down掉的可能是不是存在，会有多大。
在你这个设计里面，两个服务器应该physically在一起吧？
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
在你这个设计里面，两个服务器应该physically在一起吧？
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
z*e
220 楼
这也不是出问题的主要地方
主要问题是，这么大数据，你一次性全部读到内存里去？
然后再在各个机器之间做一个状态一致的保证？
这样等于实现了两个系统，一模一样的系统
【在 b*******s 的大作中提到】
: 他是一个集群，状态一致的集群，standby的随时切到main的
主要问题是，这么大数据，你一次性全部读到内存里去？
然后再在各个机器之间做一个状态一致的保证？
这样等于实现了两个系统，一模一样的系统
【在 b*******s 的大作中提到】
: 他是一个集群，状态一致的集群，standby的随时切到main的
g*g
221 楼
别吹了，就一commit log实现。Cassandra直接写quorum consistency就可以了，只要
结点够，掉几个结点都没影响。这东西还需要他设计，早他妈讨论烂了。
【在 b*******s 的大作中提到】
: 他是一个集群，状态一致的集群，standby的随时切到main的
结点够，掉几个结点都没影响。这东西还需要他设计，早他妈讨论烂了。
【在 b*******s 的大作中提到】
: 他是一个集群，状态一致的集群，standby的随时切到main的
b*s
222 楼
没多大数据的
比如春运每天1000列车，每列车20节车厢，没车厢200个座
一个座要经历32个站
那么一天的存储量不过是32MB，预售30天才多少？
【在 z****e 的大作中提到】
: 你还是要读进来，多大的数据阿
比如春运每天1000列车，每列车20节车厢，没车厢200个座
一个座要经历32个站
那么一天的存储量不过是32MB，预售30天才多少？
【在 z****e 的大作中提到】
: 你还是要读进来，多大的数据阿
z*e
223 楼
还可以通过zookeeper来管理存储就好了
不需要全部弄到内存里去，真心浪费
【在 g*****g 的大作中提到】
: 别吹了，就一commit log实现。Cassandra直接写quorum consistency就可以了，只要
: 结点够，掉几个结点都没影响。这东西还需要他设计，早他妈讨论烂了。
不需要全部弄到内存里去，真心浪费
【在 g*****g 的大作中提到】
: 别吹了，就一commit log实现。Cassandra直接写quorum consistency就可以了，只要
: 结点够，掉几个结点都没影响。这东西还需要他设计，早他妈讨论烂了。
g*g
224 楼
他对availability这东西一知半解。你要跟他说3 zone * 2 region这种failover策略
，他会疯掉的。
【在 h*****a 的大作中提到】
: 你前面说过，不过还是想知道，两台服务器一起down掉的可能是不是存在，会有多大。
: 在你这个设计里面，两个服务器应该physically在一起吧？
:
: transaction
，他会疯掉的。
【在 h*****a 的大作中提到】
: 你前面说过，不过还是想知道，两台服务器一起down掉的可能是不是存在，会有多大。
: 在你这个设计里面，两个服务器应该physically在一起吧？
:
: transaction
z*e
225 楼
找一个分布式的锁系统就好了
哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
图本身还有路径的构建，慢得要死
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
图本身还有路径的构建，慢得要死
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
g*g
226 楼
魏老师说我的设计不好，因为订单是离线的。到最后来一句银行钱划不了，过10分钟
cancel就是了。完全自打耳光了。难怪土遁了。
cancel就是了。完全自打耳光了。难怪土遁了。
z*e
227 楼
还有站票，春运火车票大概在2.4亿人次
again，处理这个2.4亿本身不难，瓶颈都在其它地方
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
again，处理这个2.4亿本身不难，瓶颈都在其它地方
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
b*s
228 楼
图和路径的构建，一次性的
【在 z****e 的大作中提到】
: 找一个分布式的锁系统就好了
: 哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
: 图本身还有路径的构建，慢得要死
【在 z****e 的大作中提到】
: 找一个分布式的锁系统就好了
: 哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
: 图本身还有路径的构建，慢得要死
b*s
229 楼
瓶颈我不是很了解，你介绍一下吧，我一直以为是throughput方面的
【在 z****e 的大作中提到】
: 还有站票，春运火车票大概在2.4亿人次
: again，处理这个2.4亿本身不难，瓶颈都在其它地方
【在 z****e 的大作中提到】
: 还有站票，春运火车票大概在2.4亿人次
: again，处理这个2.4亿本身不难，瓶颈都在其它地方
z*e
230 楼
还有就是内存里面争抢资源容易死锁
b*s
231 楼
这个是c++的优势，无锁也有同步的技术，很轻量化
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
b*s
232 楼
死锁看你怎么设计了，四条件破坏其一就行，c++多线程的困难之处我觉得不是这个
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
z*e
233 楼
是数据处理上的争抢
比如a-b-c线路
你要定这条线路，然后锁住了b，等a和c
古德霸也要定，锁住了a，等b和c
我也要定，锁住了c，等a和b
怎么办？
一般情况下直接超时踢出去
但是并发量太大，会导致几乎每一次都是死锁
【在 b*******s 的大作中提到】
: 瓶颈我不是很了解，你介绍一下吧，我一直以为是throughput方面的
比如a-b-c线路
你要定这条线路，然后锁住了b，等a和c
古德霸也要定，锁住了a，等b和c
我也要定，锁住了c，等a和b
怎么办？
一般情况下直接超时踢出去
但是并发量太大，会导致几乎每一次都是死锁
【在 b*******s 的大作中提到】
: 瓶颈我不是很了解，你介绍一下吧，我一直以为是throughput方面的
z*e
234 楼
铁路数据互相依赖强
同一条线路会有很多种组合
【在 b*******s 的大作中提到】
: 死锁看你怎么设计了，四条件破坏其一就行，c++多线程的困难之处我觉得不是这个
同一条线路会有很多种组合
【在 b*******s 的大作中提到】
: 死锁看你怎么设计了，四条件破坏其一就行，c++多线程的困难之处我觉得不是这个
z*e
235 楼
不过楼主可能打算用的是单线程来处理
但是这样的话，web server等起来就痛苦了
但是这样的话，web server等起来就痛苦了
z*e
236 楼
它总算领悟到了session expire的真谛
【在 g*****g 的大作中提到】
: 魏老师说我的设计不好，因为订单是离线的。到最后来一句银行钱划不了，过10分钟
: cancel就是了。完全自打耳光了。难怪土遁了。
【在 g*****g 的大作中提到】
: 魏老师说我的设计不好，因为订单是离线的。到最后来一句银行钱划不了，过10分钟
: cancel就是了。完全自打耳光了。难怪土遁了。
b*s
237 楼
这个对于他的方案，其实是不难解决的，我去吃东西
下回我说说我的话如何解决这个
【在 z****e 的大作中提到】
: 是数据处理上的争抢
: 比如a-b-c线路
: 你要定这条线路，然后锁住了b，等a和c
: 古德霸也要定，锁住了a，等b和c
: 我也要定，锁住了c，等a和b
: 怎么办？
: 一般情况下直接超时踢出去
: 但是并发量太大，会导致几乎每一次都是死锁
下回我说说我的话如何解决这个
【在 z****e 的大作中提到】
: 是数据处理上的争抢
: 比如a-b-c线路
: 你要定这条线路，然后锁住了b，等a和c
: 古德霸也要定，锁住了a，等b和c
: 我也要定，锁住了c，等a和b
: 怎么办？
: 一般情况下直接超时踢出去
: 但是并发量太大，会导致几乎每一次都是死锁
g*g
238 楼
到了读写分离，按线路分，按天数分，还离线处理这个程度。一天总共几千张票。
考虑啥有向图，就是数据库transaction，也就是锁表row足以，性能也够。
再大白话说一遍，就是每小段一个row，有个计数器。订票所有段row锁住，-1, 退票+1，
数据库就是干这个的。要啥算法，切。
考虑啥有向图，就是数据库transaction，也就是锁表row足以，性能也够。
再大白话说一遍，就是每小段一个row，有个计数器。订票所有段row锁住，-1, 退票+1，
数据库就是干这个的。要啥算法，切。
b*s
239 楼
你同一时刻，车次信息是固定的，售卖信息不同于运行信息，没那么多变化
【在 z****e 的大作中提到】
: 铁路数据互相依赖强
: 同一条线路会有很多种组合
【在 z****e 的大作中提到】
: 铁路数据互相依赖强
: 同一条线路会有很多种组合
b*s
240 楼
怎么可能是单线程么，呵呵
【在 z****e 的大作中提到】
: 不过楼主可能打算用的是单线程来处理
: 但是这样的话，web server等起来就痛苦了
【在 z****e 的大作中提到】
: 不过楼主可能打算用的是单线程来处理
: 但是这样的话，web server等起来就痛苦了
b*s
241 楼
他是把你们的完整的transaction给拆了，把非实时要求的都分出去了
只处理实时性要求高的部分
【在 z****e 的大作中提到】
: 它总算领悟到了session expire的真谛
只处理实时性要求高的部分
【在 z****e 的大作中提到】
: 它总算领悟到了session expire的真谛
g*g
242 楼
这用得着他吹吗？分表都分到每天几千张票了，一天几千个transaction 单线程也没压
力。事实上几秒就弄完了。还有向图呢。
【在 b*******s 的大作中提到】
: 他是把你们的完整的transaction给拆了，把非实时要求的都分出去了
: 只处理实时性要求高的部分
力。事实上几秒就弄完了。还有向图呢。
【在 b*******s 的大作中提到】
: 他是把你们的完整的transaction给拆了，把非实时要求的都分出去了
: 只处理实时性要求高的部分
z*e
243 楼
transaction关键是金融的数据，非票本身的数据
这个错了要回滚，这个一般涉及到银行等机构
所以会比较慢
【在 b*******s 的大作中提到】
: 他是把你们的完整的transaction给拆了，把非实时要求的都分出去了
: 只处理实时性要求高的部分
这个错了要回滚，这个一般涉及到银行等机构
所以会比较慢
【在 b*******s 的大作中提到】
: 他是把你们的完整的transaction给拆了，把非实时要求的都分出去了
: 只处理实时性要求高的部分
z*e
244 楼
有哦，比如厦门－福州－温州
如果福州的票全部被锁住了，那么厦门－温州其它段都无法正常发售
【在 b*******s 的大作中提到】
: 你同一时刻，车次信息是固定的，售卖信息不同于运行信息，没那么多变化
如果福州的票全部被锁住了，那么厦门－温州其它段都无法正常发售
【在 b*******s 的大作中提到】
: 你同一时刻，车次信息是固定的，售卖信息不同于运行信息，没那么多变化
z*e
245 楼
把数据全部读到内存里面去也就是减少了io操作
不过in house的话，这点io其实用不了多少资源
最占资源的是跟银行的communication
因为要等银行的transaction完成，这边才能commit
否则commit是没有意义的，而且这个commit之前不能随便释放锁
否则会被抢走，这样锁住了关键资源之后，其它线程要等
不过in house的话，这点io其实用不了多少资源
最占资源的是跟银行的communication
因为要等银行的transaction完成，这边才能commit
否则commit是没有意义的，而且这个commit之前不能随便释放锁
否则会被抢走，这样锁住了关键资源之后，其它线程要等
f*4
246 楼
log为什么要反馈？multicast的东西你还指望收到ack？
哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
【在 z****e 的大作中提到】
: 其中一半log反馈，失败，请回滚
: 剩下一半log反馈，哦也，成功了
: 怎么办？
哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
【在 z****e 的大作中提到】
: 其中一半log反馈，失败，请回滚
: 剩下一半log反馈，哦也，成功了
: 怎么办？
f*4
247 楼
就算你没做过类似的东西，也麻烦用用常识看看人家到底在说什么好不好？都说几遍了
，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
，通过message来抢。
你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
了，主机上对应的座位少一个。你要查log做什么？
并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
【在 g*****g 的大作中提到】
: 还广播呢，就让你单机，你要知道当前计数难道不需要把整个commit log处理了？
: 光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
: 是transaction。
: 这些都是CAP里面证明过的东西，没法beat的。
，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
，通过message来抢。
你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
了，主机上对应的座位少一个。你要查log做什么？
并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
【在 g*****g 的大作中提到】
: 还广播呢，就让你单机，你要知道当前计数难道不需要把整个commit log处理了？
: 光写不读可以极快，因为没锁。能不能写取决于读就快不了。而先成功写后取消那就不
: 是transaction。
: 这些都是CAP里面证明过的东西，没法beat的。
T*i
248 楼
log确实需要反馈。因为只有收到ACK才算Transaction成功。
Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
要rollback当前订单的。
确实只要有一台发出ACK交易就成功了。
至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
这些逻辑我都是现成的，两行代码搞定。
【在 f****4 的大作中提到】
: log为什么要反馈？multicast的东西你还指望收到ack？
: 哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
要rollback当前订单的。
确实只要有一台发出ACK交易就成功了。
至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
这些逻辑我都是现成的，两行代码搞定。
【在 f****4 的大作中提到】
: log为什么要反馈？multicast的东西你还指望收到ack？
: 哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
f*4
249 楼
恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
【在 z****e 的大作中提到】
: again
: 其实这里不是出瓶颈的地方
: 十年前就搞定了
f*4
250 楼
然后他们的理解就是网页上刷到有票就必须要保证他们买到了 -_-
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
【在 b*******s 的大作中提到】
: 你的潜台词是，一定要transcation，不知道老兄注意到了没有
T*i
251 楼
这个解释是对的。赞一个。
【在 f****4 的大作中提到】
: 就算你没做过类似的东西，也麻烦用用常识看看人家到底在说什么好不好？都说几遍了
: ，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
: ，通过message来抢。
: 你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
: 了，主机上对应的座位少一个。你要查log做什么？
: 并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
【在 f****4 的大作中提到】
: 就算你没做过类似的东西，也麻烦用用常识看看人家到底在说什么好不好？都说几遍了
: ，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
: ，通过message来抢。
: 你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
: 了，主机上对应的座位少一个。你要查log做什么？
: 并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
f*4
252 楼
你不知道旧系统就是人工输入的？？？？
一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
的道理。
【在 z****e 的大作中提到】
: 我说的是它的新系统新设计
: 它先要去旧的系统里面，把所有座位的信息给拿到，存起来
: 否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
: 人工输入？
一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
的道理。
【在 z****e 的大作中提到】
: 我说的是它的新系统新设计
: 它先要去旧的系统里面，把所有座位的信息给拿到，存起来
: 否则新系统不得不跟旧系统打交道，要不然线路，座位的信息去哪里搞？
: 人工输入？
T*i
253 楼
这种static content cache之类的nginx已经做得很好了。
load balancing也都是现成的方案。
其他的用户信息之类的数据都能容易并行划分。而且加上cache以后就是无状态的。适
合HTTP处理。
关键的瓶颈的方案，我的方案快他100倍。他有什么不服气的？
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
load balancing也都是现成的方案。
其他的用户信息之类的数据都能容易并行划分。而且加上cache以后就是无状态的。适
合HTTP处理。
关键的瓶颈的方案，我的方案快他100倍。他有什么不服气的？
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
f*4
254 楼
后来想了想，其实不需要先划钱。
划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
。这个是不对的。。。
【在 g*****g 的大作中提到】
: 这个可以做，问题那不就是我说的吗。commit log + 离线交易。魏老师吹这半天牛，
: 几毫米的强实时系统都出来了，最后就拾我牙慧呀？
划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
。这个是不对的。。。
【在 g*****g 的大作中提到】
: 这个可以做，问题那不就是我说的吗。commit log + 离线交易。魏老师吹这半天牛，
: 几毫米的强实时系统都出来了，最后就拾我牙慧呀？
f*4
255 楼
如果你搜一下旧闻，貌似大家抱怨的是上不去网站，上去了网站买票排队时间太长，就
是排队了，最后交易可能失败。
这个方案解决了排队时间长，哪怕最后银行交易失败，也很快显示了。
【在 z****e 的大作中提到】
: 因为我的前提是瓶颈出在persistence这一层上
: 不知道为什么你没有看到这一层才是真正出问题的地方
: 而不是什么app server，那个十年前就搞定了，没有瓶颈问题
是排队了，最后交易可能失败。
这个方案解决了排队时间长，哪怕最后银行交易失败，也很快显示了。
【在 z****e 的大作中提到】
: 因为我的前提是瓶颈出在persistence这一层上
: 不知道为什么你没有看到这一层才是真正出问题的地方
: 而不是什么app server，那个十年前就搞定了，没有瓶颈问题
T*i
256 楼
你这个解释也是对的。
其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
其实也就是几秒钟到几分钟的事情。
这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
楚。
不懂技术，就不懂用户需求。
只有懂技术的，才会比用户还懂用户需求。
【在 f****4 的大作中提到】
: 后来想了想，其实不需要先划钱。
: 划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
: 但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
: 还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
: 。这个是不对的。。。
其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
其实也就是几秒钟到几分钟的事情。
这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
楚。
不懂技术，就不懂用户需求。
只有懂技术的，才会比用户还懂用户需求。
【在 f****4 的大作中提到】
: 后来想了想，其实不需要先划钱。
: 划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
: 但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
: 还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
: 。这个是不对的。。。
f*4
257 楼
你对实时系统的理解就是我在web上看到有票了，我就一定能买到。你这个的确叫实时
系统，但那玩意一般都用在军工上的，卖个火车票用不到，淘宝没用这个，amz也用不
上去。
还有，我最早做transaction的时候用的还是vb6，也就能支持24小时不到2亿条数据。见
笑了。
【在 g*****g 的大作中提到】
: 你懂不懂啥叫transaction？不管咋整都算成功，过后离线cancel了，那不叫
: transaction. 不叫实时系统。
系统，但那玩意一般都用在军工上的，卖个火车票用不到，淘宝没用这个，amz也用不
上去。
还有，我最早做transaction的时候用的还是vb6，也就能支持24小时不到2亿条数据。见
笑了。
【在 g*****g 的大作中提到】
: 你懂不懂啥叫transaction？不管咋整都算成功，过后离线cancel了，那不叫
: transaction. 不叫实时系统。
T*i
258 楼
其实网站static content堆机器就可以。
关键是dynamic content，也就是查票买票是瓶颈。
这部分解决不了，网站就会表现为上不去。
如果我的核心服务器sustained throughput达到50G。那么能支撑整个系统总流量至少
上千G。给全球订票都可以了。
【在 f****4 的大作中提到】
: 如果你搜一下旧闻，貌似大家抱怨的是上不去网站，上去了网站买票排队时间太长，就
: 是排队了，最后交易可能失败。
: 这个方案解决了排队时间长，哪怕最后银行交易失败，也很快显示了。
关键是dynamic content，也就是查票买票是瓶颈。
这部分解决不了，网站就会表现为上不去。
如果我的核心服务器sustained throughput达到50G。那么能支撑整个系统总流量至少
上千G。给全球订票都可以了。
【在 f****4 的大作中提到】
: 如果你搜一下旧闻，貌似大家抱怨的是上不去网站，上去了网站买票排队时间太长，就
: 是排队了，最后交易可能失败。
: 这个方案解决了排队时间长，哪怕最后银行交易失败，也很快显示了。
f*4
259 楼
对的，他就用单机解决了一致性的问题。
并且，对票的查询，返回有票不代表你就买到这张票了。如果你非要说这不一致，那么
100个人同时抢一张票，怎么解决？
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
并且，对票的查询，返回有票不代表你就买到这张票了。如果你非要说这不一致，那么
100个人同时抢一张票，怎么解决？
【在 b*******s 的大作中提到】
: 他的一致性就是在那个有向图上做的
: 如果我正确理解了他
f*4
260 楼
做web的就真没hot standby server的概念？？？
简单来讲，如何重要的server，都有1～n个hot standby，只要一出问题，其中一个hot
standby就take over原来的server了
根据实现的不同，这个switch的时间大多都是在ms级别的。但是要做到无缝switch，还
是很难的。但是相对的，只要原来server逻辑越简单，实现无缝switch的可能越高。
【在 z****e 的大作中提到】
: 就像小菊花说的，一碗泡面毁了全部人民的火车票
: 别告诉我这个有向图不在内存里面
简单来讲，如何重要的server，都有1～n个hot standby，只要一出问题，其中一个hot
standby就take over原来的server了
根据实现的不同，这个switch的时间大多都是在ms级别的。但是要做到无缝switch，还
是很难的。但是相对的，只要原来server逻辑越简单，实现无缝switch的可能越高。
【在 z****e 的大作中提到】
: 就像小菊花说的，一碗泡面毁了全部人民的火车票
: 别告诉我这个有向图不在内存里面
f*4
261 楼
卖火车票都是提前预售的，你只要在开买前读进来就好了
【在 z****e 的大作中提到】
: 你还是要读进来，多大的数据阿
【在 z****e 的大作中提到】
: 你还是要读进来，多大的数据阿
r*y
262 楼
我擦... 人"材" 啊
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
【在 T********i 的大作中提到】
: 比如困扰板上很多人的春运网站。我来做的话内核直接上c++。
: 一切都是虚的，只有throughput才是实实在在的。
: 当你一个2 socket server + 两个solarflare card throuhtput做到接近20G，你知道
: 你已经做到头了。
m*t
263 楼
火车票有路径依赖的问题，淘宝的要简单些，只是单个物品，很容易partition
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
f*4
264 楼
你的就缺了一个高throughput的抢票方案。。。
他的就少了n多的web相关的细节
cache
路&
【在 g*****g 的大作中提到】
: 不用扯了，我43楼把全套方案都写出来了。他吹了半天牛也没偏离我的方案，
: 就是细节差多了。
: 发信人: goodbug (好虫), 信区: Programming
: 标 题: Re: 很多东东要是我来设计，会很不一样
: 发信站: BBS 未名空间站 (Thu Nov 21 22:39:15 2013, 美东)
: 架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
: ，所有的数据库读都是cache发起的。用户读只hit cache。
: 接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
: 无限
: 分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
他的就少了n多的web相关的细节
cache
路&
【在 g*****g 的大作中提到】
: 不用扯了，我43楼把全套方案都写出来了。他吹了半天牛也没偏离我的方案，
: 就是细节差多了。
: 发信人: goodbug (好虫), 信区: Programming
: 标 题: Re: 很多东东要是我来设计，会很不一样
: 发信站: BBS 未名空间站 (Thu Nov 21 22:39:15 2013, 美东)
: 架构本身倒没什么难得。读写分离，数据库要有cluster，readonly node。读有cache
: ，所有的数据库读都是cache发起的。用户读只hit cache。
: 接下来按线路分表，再按发车日期分表。每线路每天不过几千张票而已。用户本身可以
: 无限
: 分表，不是问题。如果这个还不够，终极杀器就是离线订单。所有发来的请求以(线路&
f*4
265 楼
这不是一回事，你说的分布式支持scalability的方案，会出现淘宝把货卖爆的情况。
他的这个方法不会。
这是最大区别。
【在 z****e 的大作中提到】
: 这两个不是一回事么？难道scalability是为了解决latency用的？
他的这个方法不会。
这是最大区别。
【在 z****e 的大作中提到】
: 这两个不是一回事么？难道scalability是为了解决latency用的？
f*4
266 楼
一般会放在3个地方，每个地方都会有多个standby
同一个地方的standby switch的时候可以做到ms级别；异地switch很难。。。
但同一时间只有一台main在run，别的standby会catch up main的状态
【在 h*****a 的大作中提到】
: 你前面说过，不过还是想知道，两台服务器一起down掉的可能是不是存在，会有多大。
: 在你这个设计里面，两个服务器应该physically在一起吧？
:
: transaction
同一个地方的standby switch的时候可以做到ms级别；异地switch很难。。。
但同一时间只有一台main在run，别的standby会catch up main的状态
【在 h*****a 的大作中提到】
: 你前面说过，不过还是想知道，两台服务器一起down掉的可能是不是存在，会有多大。
: 在你这个设计里面，两个服务器应该physically在一起吧？
:
: transaction
f*4
267 楼
已经有解决方案的了。。。
【在 z****e 的大作中提到】
: 这也不是出问题的主要地方
: 主要问题是，这么大数据，你一次性全部读到内存里去？
: 然后再在各个机器之间做一个状态一致的保证？
: 这样等于实现了两个系统，一模一样的系统
【在 z****e 的大作中提到】
: 这也不是出问题的主要地方
: 主要问题是，这么大数据，你一次性全部读到内存里去？
: 然后再在各个机器之间做一个状态一致的保证？
: 这样等于实现了两个系统，一模一样的系统
f*4
268 楼
你一分布就会出现一张票卖多个人，你要是能解决，马云会来请你的
【在 z****e 的大作中提到】
: 找一个分布式的锁系统就好了
: 哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
: 图本身还有路径的构建，慢得要死
【在 z****e 的大作中提到】
: 找一个分布式的锁系统就好了
: 哪里要弄内存，内存爆了怎么办？还有停电导致不一致的话怎么办？
: 图本身还有路径的构建，慢得要死
f*4
269 楼
这个赞同。网站的网络并发完全没提。
不过，这个系统难道还要管银行付钱慢么？那是不是也要管网络速度啊？顺带把社会主
义建设一下？
【在 z****e 的大作中提到】
: 还有站票，春运火车票大概在2.4亿人次
: again，处理这个2.4亿本身不难，瓶颈都在其它地方
不过，这个系统难道还要管银行付钱慢么？那是不是也要管网络速度啊？顺带把社会主
义建设一下？
【在 z****e 的大作中提到】
: 还有站票，春运火车票大概在2.4亿人次
: again，处理这个2.4亿本身不难，瓶颈都在其它地方
e*0
270 楼
这位哥, 你的这个系统卖不? 我用我家煤矿和你换咋样?
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
【在 T********i 的大作中提到】
: 我来做，核心的撮合系统两台4 socket的server足够了。一台做hot standby。如果怕
: 不保险，搞三四台。
: 其他都是外围打酱油的。
: 你把全世界的服务器都分布进来性能也不如我的。
: 1-2万行代码就搞定了。哪来这么麻烦？
f*4
271 楼
看贴不认真，他的单机实现，input就是queued message
需不需要多线程都难说，因为最后限制是网络的最大输入的80G
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
需不需要多线程都难说，因为最后限制是网络的最大输入的80G
【在 z****e 的大作中提到】
: 还有就是内存里面争抢资源容易死锁
f*4
272 楼
你要定不带表你定到了！
你的请求先来，你定到了。goodbug的后来，没票就失败了。
哪来的数据争抢？？？
看到票不代表买到票。
【在 z****e 的大作中提到】
: 是数据处理上的争抢
: 比如a-b-c线路
: 你要定这条线路，然后锁住了b，等a和c
: 古德霸也要定，锁住了a，等b和c
: 我也要定，锁住了c，等a和b
: 怎么办？
: 一般情况下直接超时踢出去
: 但是并发量太大，会导致几乎每一次都是死锁
你的请求先来，你定到了。goodbug的后来，没票就失败了。
哪来的数据争抢？？？
看到票不代表买到票。
【在 z****e 的大作中提到】
: 是数据处理上的争抢
: 比如a-b-c线路
: 你要定这条线路，然后锁住了b，等a和c
: 古德霸也要定，锁住了a，等b和c
: 我也要定，锁住了c，等a和b
: 怎么办？
: 一般情况下直接超时踢出去
: 但是并发量太大，会导致几乎每一次都是死锁
f*4
273 楼
web server查询数据可以从standby走
【在 z****e 的大作中提到】
: 不过楼主可能打算用的是单线程来处理
: 但是这样的话，web server等起来就痛苦了
【在 z****e 的大作中提到】
: 不过楼主可能打算用的是单线程来处理
: 但是这样的话，web server等起来就痛苦了
f*4
274 楼
这个很不好。。。
+1，
【在 g*****g 的大作中提到】
: 到了读写分离，按线路分，按天数分，还离线处理这个程度。一天总共几千张票。
: 考虑啥有向图，就是数据库transaction，也就是锁表row足以，性能也够。
: 再大白话说一遍，就是每小段一个row，有个计数器。订票所有段row锁住，-1, 退票+1，
: 数据库就是干这个的。要啥算法，切。
+1，
【在 g*****g 的大作中提到】
: 到了读写分离，按线路分，按天数分，还离线处理这个程度。一天总共几千张票。
: 考虑啥有向图，就是数据库transaction，也就是锁表row足以，性能也够。
: 再大白话说一遍，就是每小段一个row，有个计数器。订票所有段row锁住，-1, 退票+1，
: 数据库就是干这个的。要啥算法，切。
f*4
275 楼
不要看不起multiprocessing，和多线程实现一直都是nix下面的两大主流好不好
【在 b*******s 的大作中提到】
: 怎么可能是单线程么，呵呵
【在 b*******s 的大作中提到】
: 怎么可能是单线程么，呵呵
f*4
276 楼
但是在你抢票的时候只有有票没票两个结果。
你抢到了，后面的就没票了。
这里不存在路径依赖。
【在 m******t 的大作中提到】
: 火车票有路径依赖的问题，淘宝的要简单些，只是单个物品，很容易partition
你抢到了，后面的就没票了。
这里不存在路径依赖。
【在 m******t 的大作中提到】
: 火车票有路径依赖的问题，淘宝的要简单些，只是单个物品，很容易partition
l*9
277 楼
商业银行concurrent UI 和车票网站比起来是小儿科
【在 z****e 的大作中提到】
: 今天商业银行不都在用这种烂得跟屎一样得东西？
: 你以为你写的不是烂得跟屎一样？
:
: 的？
【在 z****e 的大作中提到】
: 今天商业银行不都在用这种烂得跟屎一样得东西？
: 你以为你写的不是烂得跟屎一样？
:
: 的？
f*4
278 楼
你这个办法能检测到硬件故障，不错。
【在 T********i 的大作中提到】
: log确实需要反馈。因为只有收到ACK才算Transaction成功。
: Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
: 要rollback当前订单的。
: 确实只要有一台发出ACK交易就成功了。
: 至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
: 现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
: hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
: 这些逻辑我都是现成的，两行代码搞定。
【在 T********i 的大作中提到】
: log确实需要反馈。因为只有收到ACK才算Transaction成功。
: Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
: 要rollback当前订单的。
: 确实只要有一台发出ACK交易就成功了。
: 至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
: 现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
: hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
: 这些逻辑我都是现成的，两行代码搞定。
f*4
279 楼
卖火车票，或者股票，都有自己的特殊性，所以适合高throughput处理。
更熟悉通用方案的，都不认真想想看。就想当然的把那套套上来，哪怕把不需要放db的
也放db，不需要等待的等待。
【在 T********i 的大作中提到】
: 你这个解释也是对的。
: 其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
: 其实也就是几秒钟到几分钟的事情。
: 这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
: 楚。
: 不懂技术，就不懂用户需求。
: 只有懂技术的，才会比用户还懂用户需求。
更熟悉通用方案的，都不认真想想看。就想当然的把那套套上来，哪怕把不需要放db的
也放db，不需要等待的等待。
【在 T********i 的大作中提到】
: 你这个解释也是对的。
: 其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
: 其实也就是几秒钟到几分钟的事情。
: 这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
: 楚。
: 不懂技术，就不懂用户需求。
: 只有懂技术的，才会比用户还懂用户需求。
z*e
280 楼
出问题的不就是web么？
web那块让别人做，那还对付个毛瓶颈？
淘宝是可以做下来，但是经过多少年？
多少次失败？罗马又不是一夜建成的
说话跟玩一样，你以为马云没玩挂掉过？
这里有人也说过了，当年m$整个团队过去搞infrastructure
华丽滴挂了
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
web那块让别人做，那还对付个毛瓶颈？
淘宝是可以做下来，但是经过多少年？
多少次失败？罗马又不是一夜建成的
说话跟玩一样，你以为马云没玩挂掉过？
这里有人也说过了，当年m$整个团队过去搞infrastructure
华丽滴挂了
【在 f****4 的大作中提到】
: 恩，他只提了抢票的实现，但对web那块怎么支持高流量没提。
: 不过淘宝双11都做下来了，这块也是能实现的。真要给方案可以外包给淘宝。
z*e
281 楼
那如果都失败了呢？message从来没有一种机制能保证百分百成功
如果就是因为某个原因消息丢掉了，咋办？
【在 f****4 的大作中提到】
: log为什么要反馈？multicast的东西你还指望收到ack？
: 哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
如果就是因为某个原因消息丢掉了，咋办？
【在 f****4 的大作中提到】
: log为什么要反馈？multicast的东西你还指望收到ack？
: 哪怕99台standby机器没收到log，但只要一台机器有记录交易就是成功的。
z*e
282 楼
到底说的是主机还是app server
主机可以解决类似问题，这个早被实践过很多年了
但是app server能解决中间环节的问题，这个也不是什么新闻
重复这些没有意义
【在 f****4 的大作中提到】
: 就算你没做过类似的东西，也麻烦用用常识看看人家到底在说什么好不好？都说几遍了
: ，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
: ，通过message来抢。
: 你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
: 了，主机上对应的座位少一个。你要查log做什么？
: 并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
主机可以解决类似问题，这个早被实践过很多年了
但是app server能解决中间环节的问题，这个也不是什么新闻
重复这些没有意义
【在 f****4 的大作中提到】
: 就算你没做过类似的东西，也麻烦用用常识看看人家到底在说什么好不好？都说几遍了
: ，他这设计就把慢的活放standby上去了，唯一有限的核心资源，票，是放在单机上面
: ，通过message来抢。
: 你查票的时候看到上海到南京12月31号K335有座位，这个信息是在主机上的。你抢到票
: 了，主机上对应的座位少一个。你要查log做什么？
: 并且查到票不代表你能抢到票。你网上购物，看到货物数量显示1，你就一定能买到？
z*e
283 楼
1－2ms反馈
我的天，你的message能做到这个精度？
这里面可是有网络的latency的
吹吧，吹牛不上税
【在 T********i 的大作中提到】
: log确实需要反馈。因为只有收到ACK才算Transaction成功。
: Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
: 要rollback当前订单的。
: 确实只要有一台发出ACK交易就成功了。
: 至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
: 现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
: hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
: 这些逻辑我都是现成的，两行代码搞定。
我的天，你的message能做到这个精度？
这里面可是有网络的latency的
吹吧，吹牛不上税
【在 T********i 的大作中提到】
: log确实需要反馈。因为只有收到ACK才算Transaction成功。
: Hard realtime system，可以指定1-2毫秒内必须收到ACK。如果没收到就是硬件故障。
: 要rollback当前订单的。
: 确实只要有一台发出ACK交易就成功了。
: 至于其他standby机器如何sync linear log，这个简单。因为不需要强实时。
: 现在的switch，能够保证局域网内multicast永不丢包。因为都是物理连接。没有中间
: hop。而且存储转发延迟两年前号称是500ns。现在我已经不关心了。
: 这些逻辑我都是现成的，两行代码搞定。
z*e
284 楼
你觉得全部读到内存里面去跟放在硬盘上有多大区别？
你实在觉得麻烦，直接在db上扩充一个cache
把db数据全部放到内存中去就好了
没有必要把这些数据读到app server那一层去
反正它的设计都要经过网络，没看到它说，都得反馈吗？
【在 f****4 的大作中提到】
: 你不知道旧系统就是人工输入的？？？？
: 一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
: 春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
: 的道理。
你实在觉得麻烦，直接在db上扩充一个cache
把db数据全部放到内存中去就好了
没有必要把这些数据读到app server那一层去
反正它的设计都要经过网络，没看到它说，都得反馈吗？
【在 f****4 的大作中提到】
: 你不知道旧系统就是人工输入的？？？？
: 一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
: 春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
: 的道理。
z*e
285 楼
是不对，但是银行交易失败回滚需要时间
这段时间会出现大量拥堵的情况
你说的这个不就是最初的一个解决方案么？
正常人都会这么想，又不是只有你这么想
【在 f****4 的大作中提到】
: 后来想了想，其实不需要先划钱。
: 划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
: 但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
: 还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
: 。这个是不对的。。。
这段时间会出现大量拥堵的情况
你说的这个不就是最初的一个解决方案么？
正常人都会这么想，又不是只有你这么想
【在 f****4 的大作中提到】
: 后来想了想，其实不需要先划钱。
: 划钱不成功回滚就可以了。唯一坏处就是在划钱这段时间，这个座位别人买不到而已。
: 但这也是符合逻辑的，后面的人买票的时候这个座位已经不空着了，和退票一样处理。
: 还有你对这个的理解就是我在web上看到票了，就要保证我一定能买到，银行交易成功
: 。这个是不对的。。。
z*e
286 楼
什么时候读？每天早上4点读一次？还是晚上11点？
内存中的数据的革命在哪个时间点实现？
你以为卖票不是24小时全天候运转的？
【在 f****4 的大作中提到】
: 卖火车票都是提前预售的，你只要在开买前读进来就好了
内存中的数据的革命在哪个时间点实现？
你以为卖票不是24小时全天候运转的？
【在 f****4 的大作中提到】
: 卖火车票都是提前预售的，你只要在开买前读进来就好了
z*e
287 楼
主机能搞定又不是什么新闻
【在 f****4 的大作中提到】
: 对的，他就用单机解决了一致性的问题。
: 并且，对票的查询，返回有票不代表你就买到这张票了。如果你非要说这不一致，那么
: 100个人同时抢一张票，怎么解决？
【在 f****4 的大作中提到】
: 对的，他就用单机解决了一致性的问题。
: 并且，对票的查询，返回有票不代表你就买到这张票了。如果你非要说这不一致，那么
: 100个人同时抢一张票，怎么解决？
z*e
288 楼
火车票你认为逻辑会很简单吗？
原来的legacy system不需要处理？
你确定？
hot
【在 f****4 的大作中提到】
: 做web的就真没hot standby server的概念？？？
: 简单来讲，如何重要的server，都有1～n个hot standby，只要一出问题，其中一个hot
: standby就take over原来的server了
: 根据实现的不同，这个switch的时间大多都是在ms级别的。但是要做到无缝switch，还
: 是很难的。但是相对的，只要原来server逻辑越简单，实现无缝switch的可能越高。
原来的legacy system不需要处理？
你确定？
hot
【在 f****4 的大作中提到】
: 做web的就真没hot standby server的概念？？？
: 简单来讲，如何重要的server，都有1～n个hot standby，只要一出问题，其中一个hot
: standby就take over原来的server了
: 根据实现的不同，这个switch的时间大多都是在ms级别的。但是要做到无缝switch，还
: 是很难的。但是相对的，只要原来server逻辑越简单，实现无缝switch的可能越高。
z*e
289 楼
一个db一个web
都是出问题的主要地方
问题在于，楼主两个都不提
只说了中间的business logic
这个十年前就搞定了，为什么还要继续说？
ejb做这个小意思
【在 f****4 的大作中提到】
: 已经有解决方案的了。。。
都是出问题的主要地方
问题在于，楼主两个都不提
只说了中间的business logic
这个十年前就搞定了，为什么还要继续说？
ejb做这个小意思
【在 f****4 的大作中提到】
: 已经有解决方案的了。。。
z*e
290 楼
内存中的锁跟分布式的锁原理上是一样的
我就有同学在天猫，还有同学在腾讯这些，这种事我们搞分布式的不就是本行么？
【在 f****4 的大作中提到】
: 你一分布就会出现一张票卖多个人，你要是能解决，马云会来请你的
我就有同学在天猫，还有同学在腾讯这些，这种事我们搞分布式的不就是本行么？
【在 f****4 的大作中提到】
: 你一分布就会出现一张票卖多个人，你要是能解决，马云会来请你的
z*e
291 楼
不用银行的接口付钱，金钱交易怎么进行？
【在 f****4 的大作中提到】
: 这个赞同。网站的网络并发完全没提。
: 不过，这个系统难道还要管银行付钱慢么？那是不是也要管网络速度啊？顺带把社会主
: 义建设一下？
【在 f****4 的大作中提到】
: 这个赞同。网站的网络并发完全没提。
: 不过，这个系统难道还要管银行付钱慢么？那是不是也要管网络速度啊？顺带把社会主
: 义建设一下？
z*e
292 楼
都用queue了，多线程难道不更能发挥多核的优势？
要不然还queue了干什么哦，单线程不就是为了对付并发冲突时候用的么？
【在 f****4 的大作中提到】
: 看贴不认真，他的单机实现，input就是queued message
: 需不需要多线程都难说，因为最后限制是网络的最大输入的80G
要不然还queue了干什么哦，单线程不就是为了对付并发冲突时候用的么？
【在 f****4 的大作中提到】
: 看贴不认真，他的单机实现，input就是queued message
: 需不需要多线程都难说，因为最后限制是网络的最大输入的80G
z*e
293 楼
good这样整个表都要锁
你的锁越来越大了
最简单的例子，厦门到福州到温州，剩下一张票
其中一个线程申请从厦门到福州段的票
另外一个线程同时申请从福州到温州的票
两个线程一起冲进来，同时申请，两个都在等，都等不到
你怎么办？哦对了，用queue
但是queue有一个问题，那就是前面的处理没完成
后面的不让处理，那这种顺序处理难道不是瓶颈？
尤其是在大并发的时候？上千万人在同时发送请求
你要求他们顺序处理？
【在 f****4 的大作中提到】
: 你要定不带表你定到了！
: 你的请求先来，你定到了。goodbug的后来，没票就失败了。
: 哪来的数据争抢？？？
: 看到票不代表买到票。
你的锁越来越大了
最简单的例子，厦门到福州到温州，剩下一张票
其中一个线程申请从厦门到福州段的票
另外一个线程同时申请从福州到温州的票
两个线程一起冲进来，同时申请，两个都在等，都等不到
你怎么办？哦对了，用queue
但是queue有一个问题，那就是前面的处理没完成
后面的不让处理，那这种顺序处理难道不是瓶颈？
尤其是在大并发的时候？上千万人在同时发送请求
你要求他们顺序处理？
【在 f****4 的大作中提到】
: 你要定不带表你定到了！
: 你的请求先来，你定到了。goodbug的后来，没票就失败了。
: 哪来的数据争抢？？？
: 看到票不代表买到票。
z*e
294 楼
楼主没考虑过ui和web部分
【在 l*****9 的大作中提到】
: 商业银行concurrent UI 和车票网站比起来是小儿科
【在 l*****9 的大作中提到】
: 商业银行concurrent UI 和车票网站比起来是小儿科
f*4
295 楼
那淘宝怎么把人家货给卖爆了？
【在 z****e 的大作中提到】
: 内存中的锁跟分布式的锁原理上是一样的
: 我就有同学在天猫，还有同学在腾讯这些，这种事我们搞分布式的不就是本行么？
【在 z****e 的大作中提到】
: 内存中的锁跟分布式的锁原理上是一样的
: 我就有同学在天猫，还有同学在腾讯这些，这种事我们搞分布式的不就是本行么？
z*e
296 楼
那你为什么不建议淘宝用一台server就可以了？
天朝也就是十几亿人，小意思啦，如果transaction简单的话
【在 f****4 的大作中提到】
: 那淘宝怎么把人家货给卖爆了？
天朝也就是十几亿人，小意思啦，如果transaction简单的话
【在 f****4 的大作中提到】
: 那淘宝怎么把人家货给卖爆了？
g*g
297 楼
就是一个量嘛。我前面说了，量至少差100倍。如果说火车票系统15分钟延迟银行就把
你的交易处理了，
淘宝就得1天。买个东西，10分钟后说没买着也罢，过一天才说没买着就过分了。所以
取舍就不一样，宁可让交易通过超卖呗。
【在 f****4 的大作中提到】
: 那淘宝怎么把人家货给卖爆了？
你的交易处理了，
淘宝就得1天。买个东西，10分钟后说没买着也罢，过一天才说没买着就过分了。所以
取舍就不一样，宁可让交易通过超卖呗。
【在 f****4 的大作中提到】
: 那淘宝怎么把人家货给卖爆了？
P*l
298 楼
啥叫 concurrent UI? UI一般是单线程的. 难道你想点完删除再点保存? 还商业银行 -
- 那麻烦你举个例子好不好? 哪个商业银行是concurrent UI?
车票网站的UI一点也不复杂, 至少没银行的client要求高. 还小儿科...
【在 l*****9 的大作中提到】
: 商业银行concurrent UI 和车票网站比起来是小儿科
- 那麻烦你举个例子好不好? 哪个商业银行是concurrent UI?
车票网站的UI一点也不复杂, 至少没银行的client要求高. 还小儿科...
【在 l*****9 的大作中提到】
: 商业银行concurrent UI 和车票网站比起来是小儿科
k*i
299 楼
最小路径是系统boot时都计算加载好，每当用户一查询，就直接hit cache吗？
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
l*n
300 楼
其实你们讨论的分歧实际上都是跟业务有关而不是技术上的差异。用做trading系统的
思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
是否成立都需要看还有票没。
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
是否成立都需要看还有票没。
transaction
【在 T********i 的大作中提到】
: 这个必须是存储相关的。每个transaction都有log。log后才算数。
: 其实一个multicast给其他打酱油的待机服务器，然后收到ack。这个log的transaction
: 就算完成了。
: 这个过程大约5微秒。但是stream line的through就可以是最大带宽。
: 因此，我的系统最简单，最安全。每行代码都能被audit。而且可证明是技术的极限。
z*e
301 楼
明白人
【在 l*n 的大作中提到】
: 其实你们讨论的分歧实际上都是跟业务有关而不是技术上的差异。用做trading系统的
: 思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
: 统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
: 是否成立都需要看还有票没。
:
: transaction
【在 l*n 的大作中提到】
: 其实你们讨论的分歧实际上都是跟业务有关而不是技术上的差异。用做trading系统的
: 思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
: 统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
: 是否成立都需要看还有票没。
:
: transaction
b*s
302 楼
原先的legacy是个票务信息靠手工输入的东西，最早是基于foxpro的，以后逐次改进还
是相当之落后，兼容legacy不应该是一个教条，否则你看到的不是产品，而是历史陈列
链表
【在 z****e 的大作中提到】
: 火车票你认为逻辑会很简单吗？
: 原来的legacy system不需要处理？
: 你确定？
:
: hot
是相当之落后，兼容legacy不应该是一个教条，否则你看到的不是产品，而是历史陈列
链表
【在 z****e 的大作中提到】
: 火车票你认为逻辑会很简单吗？
: 原来的legacy system不需要处理？
: 你确定？
:
: hot
b*s
303 楼
我只能说你没看懂他的设计
【在 l*n 的大作中提到】
: 其实你们讨论的分歧实际上都是跟业务有关而不是技术上的差异。用做trading系统的
: 思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
: 统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
: 是否成立都需要看还有票没。
:
: transaction
【在 l*n 的大作中提到】
: 其实你们讨论的分歧实际上都是跟业务有关而不是技术上的差异。用做trading系统的
: 思路来做售票，首要一点就是要看二者的业务逻辑是否能百分百互相转换。trading系
: 统里怎么处理没买上我不知道，但是售票好像都是没票了绝对不扣钱，这时候任何交易
: 是否成立都需要看还有票没。
:
: transaction
z*e
304 楼
问题在于那么短时间内，你怎么可能全面翻新？
不过几十年过去了，铁道部居然还在用foxpro？
是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
民航部门90年代就是ibm，oracle这些的大客户了
铁道部落后这么多有些不可思议
【在 b*******s 的大作中提到】
: 原先的legacy是个票务信息靠手工输入的东西，最早是基于foxpro的，以后逐次改进还
: 是相当之落后，兼容legacy不应该是一个教条，否则你看到的不是产品，而是历史陈列
: 链表
不过几十年过去了，铁道部居然还在用foxpro？
是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
民航部门90年代就是ibm，oracle这些的大客户了
铁道部落后这么多有些不可思议
【在 b*******s 的大作中提到】
: 原先的legacy是个票务信息靠手工输入的东西，最早是基于foxpro的，以后逐次改进还
: 是相当之落后，兼容legacy不应该是一个教条，否则你看到的不是产品，而是历史陈列
: 链表
b*s
305 楼
从那个系统开始的，现在顶多也是换了sql server一类的东西。他们的业务模式一直是
手工录入，手工查询，查询时还锁定票，都是速度极慢的交易，极其落后，全扔了也没
什么可惜的
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
手工录入，手工查询，查询时还锁定票，都是速度极慢的交易，极其落后，全扔了也没
什么可惜的
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
b*s
306 楼
我觉得铁道部本身的业务逻辑就不是考虑用户的，最需要改的就是他们的业务逻辑
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
b*s
307 楼
最早的时候他们还是分票的
比如上海站有去北京的票100张，南京站20张
互相没有通讯，结果你上海如果多10张票，南京有30个额外客户
这30个客户就是买不到票，熟悉他们系统的就会先坐车去上海，然后重新买票
今年春运出现半空列车，而大批人买不到票。很可能就是legacy系统里一些东西带进来的
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
比如上海站有去北京的票100张，南京站20张
互相没有通讯，结果你上海如果多10张票，南京有30个额外客户
这30个客户就是买不到票，熟悉他们系统的就会先坐车去上海，然后重新买票
今年春运出现半空列车，而大批人买不到票。很可能就是legacy系统里一些东西带进来的
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
b*s
308 楼
国内的系统，别太当回事，内部出错应该是不罕见的。我前年回国，还看到工行还是建
行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
【在 z****e 的大作中提到】
: 问题在于那么短时间内，你怎么可能全面翻新？
: 不过几十年过去了，铁道部居然还在用foxpro？
: 是不是真的啊？虽然落伍是可以猜到的，但是也不至于落伍成这样吧？
: 民航部门90年代就是ibm，oracle这些的大客户了
: 铁道部落后这么多有些不可思议
z*e
309 楼
内部出错是不罕见，但是用foxpro也太行为艺术了
【在 b*******s 的大作中提到】
: 国内的系统，别太当回事，内部出错应该是不罕见的。我前年回国，还看到工行还是建
: 行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
【在 b*******s 的大作中提到】
: 国内的系统，别太当回事，内部出错应该是不罕见的。我前年回国，还看到工行还是建
: 行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
z*e
310 楼
全扔了是不可惜，问题是短时间内铁道部的工作人员怎么快速上手适应新系统？
【在 b*******s 的大作中提到】
: 从那个系统开始的，现在顶多也是换了sql server一类的东西。他们的业务模式一直是
: 手工录入，手工查询，查询时还锁定票，都是速度极慢的交易，极其落后，全扔了也没
: 什么可惜的
【在 b*******s 的大作中提到】
: 从那个系统开始的，现在顶多也是换了sql server一类的东西。他们的业务模式一直是
: 手工录入，手工查询，查询时还锁定票，都是速度极慢的交易，极其落后，全扔了也没
: 什么可惜的
z*e
311 楼
你们这种嘴上说的都不靠谱，最后还是要靠java的兄弟
自己看看产品，这些产品不能算是弱，至少比foxpro要强上一万倍
这些东西你说你改得动？哼哼
发信人: swjtuer (想归俺交的群272361847), 信区: Programming
标 题: Re: 如果要做一个铁路售票网站
发信站: BBS 未名空间站 (Sun Nov 24 01:01:33 2013, 美东)
中国铁路客票发售与预订系统由中央级、地区级和车站级三层结构组成，包括全国票务
中心管理系统、地区票务中心管理系统和车站电子售票系统。
系统采取集中与分布相结合的方案，在全路票务中心内安装中央数据库，Sybase数据库
产品Adaptive Server Enterprise、Replication Server、Sybase IQ，中间件产品
Open Client、Open Server以及开发工具PowerBuilder和PowerDesigner在其中都有着
非常重要的应用；这一系统主要用于计划与调度全系统的数据，并接收下一系统的统计
数据和财务结算数据。
来的
【在 b*******s 的大作中提到】
: 最早的时候他们还是分票的
: 比如上海站有去北京的票100张，南京站20张
: 互相没有通讯，结果你上海如果多10张票，南京有30个额外客户
: 这30个客户就是买不到票，熟悉他们系统的就会先坐车去上海，然后重新买票
: 今年春运出现半空列车，而大批人买不到票。很可能就是legacy系统里一些东西带进来的
自己看看产品，这些产品不能算是弱，至少比foxpro要强上一万倍
这些东西你说你改得动？哼哼
发信人: swjtuer (想归俺交的群272361847), 信区: Programming
标 题: Re: 如果要做一个铁路售票网站
发信站: BBS 未名空间站 (Sun Nov 24 01:01:33 2013, 美东)
中国铁路客票发售与预订系统由中央级、地区级和车站级三层结构组成，包括全国票务
中心管理系统、地区票务中心管理系统和车站电子售票系统。
系统采取集中与分布相结合的方案，在全路票务中心内安装中央数据库，Sybase数据库
产品Adaptive Server Enterprise、Replication Server、Sybase IQ，中间件产品
Open Client、Open Server以及开发工具PowerBuilder和PowerDesigner在其中都有着
非常重要的应用；这一系统主要用于计划与调度全系统的数据，并接收下一系统的统计
数据和财务结算数据。
来的
【在 b*******s 的大作中提到】
: 最早的时候他们还是分票的
: 比如上海站有去北京的票100张，南京站20张
: 互相没有通讯，结果你上海如果多10张票，南京有30个额外客户
: 这30个客户就是买不到票，熟悉他们系统的就会先坐车去上海，然后重新买票
: 今年春运出现半空列车，而大批人买不到票。很可能就是legacy系统里一些东西带进来的
z*e
312 楼
看来Sybase的东西比较多
Sybase虽然不能算是很牛逼
但是也不是弱得连魏老师都比不上的地步
至少这么大一家公司，里面还是能找得出点牛人来的
魏老师要真是牛到这个地步，Sybase应该花高价给挖过去才对
哪里用得着在花街看人眼色
Sybase虽然不能算是很牛逼
但是也不是弱得连魏老师都比不上的地步
至少这么大一家公司，里面还是能找得出点牛人来的
魏老师要真是牛到这个地步，Sybase应该花高价给挖过去才对
哪里用得着在花街看人眼色
z*e
313 楼
sybase收购价是五十亿八千万美元
购主是sap
所以谁觉得自己比sybase牛的
可以考虑一下，做点东西，卖给sap
保守估价，60亿吧
购主是sap
所以谁觉得自己比sybase牛的
可以考虑一下，做点东西，卖给sap
保守估价，60亿吧
g*g
314 楼
这个倒没什么，ATM也就是个终端而已。银行里同样用windows做终端。又不是服务器。
【在 b*******s 的大作中提到】
: 国内的系统，别太当回事，内部出错应该是不罕见的。我前年回国，还看到工行还是建
: 行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
【在 b*******s 的大作中提到】
: 国内的系统，别太当回事，内部出错应该是不罕见的。我前年回国，还看到工行还是建
: 行的ATM死机后出现windows蓝屏，这么大的银行用windows哦
s*r
315 楼
一旦设计到钱和银行，就只能老老实实地用isolation level 3，不然ACID无法保证。
随便一个问题，就够忙活几天，几天的人工费算下来，远高于transaction fee啊。
这是企业软件的天下，只有小公司才敢用mysql
【在 z****e 的大作中提到】
: 这种涉及到钱的交易，又是关联的数据非常难搞
: 几乎是分布式的死结，分布式没有几个真把这个问题搞定的
: 基本上都死得惨惨的
: 这种领域基本上就跟物流一样
: 没有办法做到完美，很多时候只能靠speculation
随便一个问题，就够忙活几天，几天的人工费算下来，远高于transaction fee啊。
这是企业软件的天下，只有小公司才敢用mysql
【在 z****e 的大作中提到】
: 这种涉及到钱的交易，又是关联的数据非常难搞
: 几乎是分布式的死结，分布式没有几个真把这个问题搞定的
: 基本上都死得惨惨的
: 这种领域基本上就跟物流一样
: 没有办法做到完美，很多时候只能靠speculation
g*g
316 楼
NoSQL是不敢用，MySQL是真没啥。人淘宝一天300个亿的单子，就是从MySQL走的。
这更多的只是个观念问题。
【在 s*****r 的大作中提到】
: 一旦设计到钱和银行，就只能老老实实地用isolation level 3，不然ACID无法保证。
: 随便一个问题，就够忙活几天，几天的人工费算下来，远高于transaction fee啊。
: 这是企业软件的天下，只有小公司才敢用mysql
这更多的只是个观念问题。
【在 s*****r 的大作中提到】
: 一旦设计到钱和银行，就只能老老实实地用isolation level 3，不然ACID无法保证。
: 随便一个问题，就够忙活几天，几天的人工费算下来，远高于transaction fee啊。
: 这是企业软件的天下，只有小公司才敢用mysql
s*r
317 楼
主要还是金融服务业比较初级吧，没有什么规定，随便搞搞就行了
【在 g*****g 的大作中提到】
: NoSQL是不敢用，MySQL是真没啥。人淘宝一天300个亿的单子，就是从MySQL走的。
: 这更多的只是个观念问题。
【在 g*****g 的大作中提到】
: NoSQL是不敢用，MySQL是真没啥。人淘宝一天300个亿的单子，就是从MySQL走的。
: 这更多的只是个观念问题。
c*d
318 楼
靠。 最后两句话说的挺牛逼， 上来赞一下。
【在 T********i 的大作中提到】
: 你这个解释也是对的。
: 其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
: 其实也就是几秒钟到几分钟的事情。
: 这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
: 楚。
: 不懂技术，就不懂用户需求。
: 只有懂技术的，才会比用户还懂用户需求。
【在 T********i 的大作中提到】
: 你这个解释也是对的。
: 其实划钱成功与否，本来就不是hard realtime。取决于和银行的连接效率。
: 其实也就是几秒钟到几分钟的事情。
: 这些所谓的业务骨干，连那些操作必须是atomic的因此必须transactional都划分不清
: 楚。
: 不懂技术，就不懂用户需求。
: 只有懂技术的，才会比用户还懂用户需求。
g*g
319 楼
是挺牛逼，可惜只是说而已。连单机跟分布式系统那个throughput高的常识都没有。
【在 c***d 的大作中提到】
: 靠。 最后两句话说的挺牛逼， 上来赞一下。
【在 c***d 的大作中提到】
: 靠。 最后两句话说的挺牛逼， 上来赞一下。
b*s
320 楼
他的话有很多前提假设的。比如中国人口不会一下子到几百亿，基本就是那么多。然后
他处理速度快，一台顶你几百台，所以就能放到单机里面。
其实他的方案稍微改改，一样是可以分布式的。不难
不过他的假设是主要的瓶颈是在抢票而不是别的，他的设计也就是如何应付抢票
【在 g*****g 的大作中提到】
: 是挺牛逼，可惜只是说而已。连单机跟分布式系统那个throughput高的常识都没有。
他处理速度快，一台顶你几百台，所以就能放到单机里面。
其实他的方案稍微改改，一样是可以分布式的。不难
不过他的假设是主要的瓶颈是在抢票而不是别的，他的设计也就是如何应付抢票
【在 g*****g 的大作中提到】
: 是挺牛逼，可惜只是说而已。连单机跟分布式系统那个throughput高的常识都没有。
x*u
321 楼
这种人坐火车都是爹妈排队买的票。
【在 b*******s 的大作中提到】
: 他的话有很多前提假设的。比如中国人口不会一下子到几百亿，基本就是那么多。然后
: 他处理速度快，一台顶你几百台，所以就能放到单机里面。
: 其实他的方案稍微改改，一样是可以分布式的。不难
: 不过他的假设是主要的瓶颈是在抢票而不是别的，他的设计也就是如何应付抢票
【在 b*******s 的大作中提到】
: 他的话有很多前提假设的。比如中国人口不会一下子到几百亿，基本就是那么多。然后
: 他处理速度快，一台顶你几百台，所以就能放到单机里面。
: 其实他的方案稍微改改，一样是可以分布式的。不难
: 不过他的假设是主要的瓶颈是在抢票而不是别的，他的设计也就是如何应付抢票
b*s
322 楼
你想说什么
【在 x****u 的大作中提到】
: 这种人坐火车都是爹妈排队买的票。
【在 x****u 的大作中提到】
: 这种人坐火车都是爹妈排队买的票。
x*u
323 楼
入门马公觉得自己能搞定大项目，归根结底还是因为对社会复杂性的认识不足。
【在 b*******s 的大作中提到】
: 你想说什么
【在 b*******s 的大作中提到】
: 你想说什么
s*r
324 楼
火车票很难实现partition的，长途旅客多，如果中途需要换车，另外一趟车就是别的
票务数据中心管理。最简单的购买返程长途票，也需要访问别地的票务数据中心
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
票务数据中心管理。最简单的购买返程长途票，也需要访问别地的票务数据中心
generate
help
【在 T********i 的大作中提到】
: As I said, data partitionibg is the easiest thing among the problems.
: Given the constraints such as the framework, it doesn't take a genius to
: partition it right.
: Assuming the data is properly partitioned, a shitty application server can
: still create bottleneck everythere.
: So in my test, under optimal condition, if a node can't consume or generate
: constant 20G of throughput, it is by design inefficient and no one can help
: you with that.
:
: app
s*r
325 楼
机票的访问量远不如火车票，中国那么多屌丝和民工，坐火车是主流
【在 z****e 的大作中提到】
: 其实全世界机票都是这么搞的，全世界40％的机票是科罗拉多丹佛那个数据中心出的
: 民航总局计算机中心有成功的经验不去借鉴，想装自己搞
: 那这个没办法了，该挂就挂给你看
【在 z****e 的大作中提到】
: 其实全世界机票都是这么搞的，全世界40％的机票是科罗拉多丹佛那个数据中心出的
: 民航总局计算机中心有成功的经验不去借鉴，想装自己搞
: 那这个没办法了，该挂就挂给你看
s*r
326 楼
小杨一次应该值好几台server了
【在 z****e 的大作中提到】
: 吹吧，吹牛不上税，你觉得铁道部是那种出不起钱买3－4个server的地方么？
: 估计这点钱还不够刘志君包杨幂一周的开销
: 你要能搞定这个，直接给沃尔玛之类的投简历
: 这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
【在 z****e 的大作中提到】
: 吹吧，吹牛不上税，你觉得铁道部是那种出不起钱买3－4个server的地方么？
: 估计这点钱还不够刘志君包杨幂一周的开销
: 你要能搞定这个，直接给沃尔玛之类的投简历
: 这个理论直接用在物流上，搞定了，然后斯坦福迫不及待滴给你发荣誉博士
s*r
327 楼
涉及支付问题，非常麻烦。是先收钱还是先出票，从铁路利益来讲，肯定是先收钱。电
子商务系统也都是先收钱，后提供服务。
一个大问题就是钱收了，票没了，咋办。要是把票先lock住，万一收钱失败，票还要重
新放回去，business logic更复杂。
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
子商务系统也都是先收钱，后提供服务。
一个大问题就是钱收了，票没了，咋办。要是把票先lock住，万一收钱失败，票还要重
新放回去，business logic更复杂。
【在 T********i 的大作中提到】
: 和你讨论确实有点困难。
: 这种系统，update和rollback就是每条线一个interlocked decrement/increment。都
: 是纳秒级别的。每秒钟transaction数量都是上百万的。增加一台server主要是hot
: standby打酱油的。
: 还什么订票第二天查？这是强实时系统。规定的多少毫秒内guarantee有响应的。
: 这东东你估计都没听说过。
s*r
328 楼
哪有这么简单。
就像你建议的，火车票现在是partition的，有23个地区票务中心。每个中心只管理自
己的车票，短途的车票可以在中心内解决。但长途客票，需要买返程票或者中转票，必
须访问其他票务中心。
铁路是个网，两点之间可以有多条线路通行，还有日期车次车票的限制，这种搜索技术
非常难搞。
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
就像你建议的，火车票现在是partition的，有23个地区票务中心。每个中心只管理自
己的车票，短途的车票可以在中心内解决。但长途客票，需要买返程票或者中转票，必
须访问其他票务中心。
铁路是个网，两点之间可以有多条线路通行，还有日期车次车票的限制，这种搜索技术
非常难搞。
【在 T********i 的大作中提到】
: 这东东也就1-20000行代码搞定的。就是有向图的最小路径算法。每个节点带一些
: attributes。
: 其他的都能通过message queue分布出去。
: 外围打酱油的那些花里胡哨的雇你这样的民工去做我还是放心的。
s*r
329 楼
貌似核心就是写log，这也太省事，不用起server，用Linux写个kernel module估计都
可以
【在 z****e 的大作中提到】
: 这里面有哪怕一个涉及到真实的business logic没？
: 比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
: 没有legacy system？
可以
【在 z****e 的大作中提到】
: 这里面有哪怕一个涉及到真实的business logic没？
: 比如设计交易，交易如何实现呢？你知道票的数据是以什么形式存在的？
: 没有legacy system？
s*r
330 楼
如果退钱失败咋办，取消银行交易不是那么简单的
【在 f****4 的大作中提到】
: 不用那么复杂，退票只要主机沿线空票+1，让别的待机去退钱。只要找到log记录，取
: 消银行交易即可。
:
: logging
【在 f****4 的大作中提到】
: 不用那么复杂，退票只要主机沿线空票+1，让别的待机去退钱。只要找到log记录，取
: 消银行交易即可。
:
: logging
s*r
331 楼
一个座位还可以分出几张车票，shema要比机票复杂，座位分配还涉及优化问题，坐两
小时车的和坐20小时的，哪个更有优先权，问题越想越复杂。
【在 z****e 的大作中提到】
: 座位十有八九是另外一张甚至几张表里面
小时车的和坐20小时的，哪个更有优先权，问题越想越复杂。
【在 z****e 的大作中提到】
: 座位十有八九是另外一张甚至几张表里面
s*r
332 楼
真正的实时，应该是服务马上开始，这个可以实现。货物立刻出现在门口，这是不可能
的。
【在 g*****g 的大作中提到】
: 他的所谓实时系统，只从应用服务器提交到DB写完commit log那么远。正常人类说的实
: 时系统，是从用户提交订单到订单确认，差别大了。
的。
【在 g*****g 的大作中提到】
: 他的所谓实时系统，只从应用服务器提交到DB写完commit log那么远。正常人类说的实
: 时系统，是从用户提交订单到订单确认，差别大了。
s*r
333 楼
每天1000列车，光祖要去撞墙了
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
【在 b*******s 的大作中提到】
: 没多大数据的
: 比如春运每天1000列车，每列车20节车厢，没车厢200个座
: 一个座要经历32个站
: 那么一天的存储量不过是32MB，预售30天才多少？
b*i
334 楼
应该lock住。甚至因该查询的时候就lock住5分钟，否则，甚至点击购买键的时候发现
没有了，又得重新搜索。
【在 s*****r 的大作中提到】
: 涉及支付问题，非常麻烦。是先收钱还是先出票，从铁路利益来讲，肯定是先收钱。电
: 子商务系统也都是先收钱，后提供服务。
: 一个大问题就是钱收了，票没了，咋办。要是把票先lock住，万一收钱失败，票还要重
: 新放回去，business logic更复杂。
没有了，又得重新搜索。
【在 s*****r 的大作中提到】
: 涉及支付问题，非常麻烦。是先收钱还是先出票，从铁路利益来讲，肯定是先收钱。电
: 子商务系统也都是先收钱，后提供服务。
: 一个大问题就是钱收了，票没了，咋办。要是把票先lock住，万一收钱失败，票还要重
: 新放回去，business logic更复杂。
g*g
335 楼
春运大多是单向流量大，预售10日节前节后也不能一块买。本来就得买两次。
总之拿历史数据做个聚类，是能保证90%以上的交易不需要distributed transaction的。
【在 s*****r 的大作中提到】
: 火车票很难实现partition的，长途旅客多，如果中途需要换车，另外一趟车就是别的
: 票务数据中心管理。最简单的购买返程长途票，也需要访问别地的票务数据中心
:
: generate
: help
总之拿历史数据做个聚类，是能保证90%以上的交易不需要distributed transaction的。
【在 s*****r 的大作中提到】
: 火车票很难实现partition的，长途旅客多，如果中途需要换车，另外一趟车就是别的
: 票务数据中心管理。最简单的购买返程长途票，也需要访问别地的票务数据中心
:
: generate
: help
s*r
336 楼
事先确定的那是硬纸票时代，铁路信息化售票已经搞了十几年，你去火车站买票，哪怕
是个小站，不是窗口电脑就是自动售票机，那里有事先打印好的的。
车站售票系统本身没多大问题，现在的难题是几亿屌丝上网刷票，就那么点车票资源，
几亿人来抢，技术上如何支持。
【在 f****4 的大作中提到】
: 你不知道旧系统就是人工输入的？？？？
: 一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
: 春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
: 的道理。
是个小站，不是窗口电脑就是自动售票机，那里有事先打印好的的。
车站售票系统本身没多大问题，现在的难题是几亿屌丝上网刷票，就那么点车票资源，
几亿人来抢，技术上如何支持。
【在 f****4 的大作中提到】
: 你不知道旧系统就是人工输入的？？？？
: 一条铁路上能开多少多少趟车，各个车站怎么停靠都是事先确定的。
: 春运期间只会增加车次，真要有车次被取消，乘客只能在车站退票，买票。和机票一样
: 的道理。
b*s
337 楼
我觉得你对锁理解有点问题
【在 z****e 的大作中提到】
: 有哦，比如厦门－福州－温州
: 如果福州的票全部被锁住了，那么厦门－温州其它段都无法正常发售
【在 z****e 的大作中提到】
: 有哦，比如厦门－福州－温州
: 如果福州的票全部被锁住了，那么厦门－温州其它段都无法正常发售
相关阅读
Go什么时候可能支持Generic?The future of Javascript module management finally comes有大牛可以解释下bloom filter是在什么条件下使用最好马斯克：我们的世界跑在虚拟机上 (转载)【科技】 来晒一晒你觉得最黑的科技 (转载)daxu06 封 jobhuntinger 在 Basketball 版 (转载)请教一个网站架构的问题golang现在发展的如何了？？在各大公司。90后贪玩CEO,被扎克伯格相中,创20亿收购神话(图)其实有时候google多了会脑残的c字符串的问题streamwriter and filestreamGoogle drive这么多年了，还是烂得一坨屎java为啥在学术界不受推崇？project architecture方面有什么好书值得推荐的？有人用过Postgres 中 FDW模型吗？未上市公司的RSU如果vested了是不是还得算收入报税？IntelliJ热部署经常失败是什么原因？程序员就是产品/项目经理的爹啊c的问题