Redian新闻
>
春运网站架构之争 MapReduce vs MPI
avatar
春运网站架构之争 MapReduce vs MPI# Programming - 葵花宝典
t*u
1
本人现有AA里程6,757点,有效期到5月21日,有需要的朋友快快行动!
抓紧哦!
avatar
n*r
2
请问B2申请延期一般要多久
如果我现在申请的话,年底之前拿到的可能性多大?
如果是7/2来的,12/31就半年了,打算现在申请延期再呆半年,来不来得及?
还有就是如果B2签证明年3月份过期
那么如果延期来不及的话,今年12月按期回国然后带2周再飞回来
还可以带多久?半年还是只能带到3月份?
如果只能呆到3月份,那么明年1月过来立刻办理延期是不是可以延到9月份?
谢谢。
avatar
m*1
3
【 以下文字转载自 PhotoGear 讨论区 】
发信人: majia111 (majia111), 信区: PhotoGear
标 题: 到底应该怎样正确使用monopod?
发信站: BBS 未名空间站 (Mon Nov 15 22:00:59 2010, 美东)
为啥我用了和没用照出来的效果没两样?
你们都用不用monopod?
avatar
P*u
4
读者来信求助问:
18岁那年,我爱上李昆阳,他喜欢穿白衬衣,十分阳光,只是一眼我便被他深深的吸引
了。我们相爱两年后奉子成婚,婚后他对我呵护有加,生活无比的甜蜜而幸福。
孩子一岁时,我和他一起找了个门面做建材生意,平时公公婆婆帮我们带孩子,小叔子
那时刚上大学。我和老公负担挺重的,要供小叔子上大学,自己又要养孩子,虽然公公
在小区当保安,但他的工资刚好只够一家人开支。
可是,儿子六岁那年,老公晚上开着三轮车出去送货,迟迟没有回来,晚上11点等来的
噩耗竟然是他出了车祸,肇事者跑了,他倒在血泊中被人发现时已经离世。
我和公公婆婆悲痛欲绝,那一瞬间,家仿佛被抽空了。可是,看着年幼的儿子,我不得
不坚强起来,继续开店。孩子依旧是公公婆婆帮我带着,店里需要人手,那年小叔子毅
然辞去工作,到店里来帮忙。
我爸妈曾劝我把店面转让,回娘家住,趁着年轻找个男人结婚。可我舍不得孩子,儿子
从小到大,都没有离开过我。公婆也因为失去了儿子,对孙子更是心疼,自然舍不得让
孩子跟着我回去。为了给孩子完整的母爱,我选择了住在婆家,继续做生意赚钱。
在小叔子的帮助下,店里的生意很好,而且他也很能吃苦,什么苦力活他都往自己身上
揽,他说:以前你跟大哥一起供我读书,嫂子,我回报你是应该的……
除了勤快之外,他和我儿子的感情特别好,在孩子的世界里,他仿佛充当的是个做父亲
的角色。有时候小叔子带我儿子出去玩,别人都会误以为他就是孩子的爸爸。但他从来
都不解释什么。
就这样我和公公婆婆生活了六年,儿子上初中了。爸妈一直在为我的终身大事考虑,希
望我能尽快再嫁。可这六年的时间里,我一直尽心尽力的照顾了公公婆婆,她们也对我
就像亲闺女一样好,她们失去了儿子,如果我走了,再带走她们的孙子,她们的世界不
就垮掉了吗?
前不久,店里停了电,所以那天早早关了门回家陪孩子做作业。吃饭时,婆婆突然问我
有没有考虑过再嫁?我愣了一下,不好意思的说:孩子还小,没考虑过,再说也没碰到
合适的人选啊……
公公喝了一口酒说:你觉得梁宸怎么样?小叔子的脸,瞬间就涨得通红。端着碗,朝嘴
里迅速的扒了口饭,含糊不清的喊了一声爸,大约是要他别再说下去了。
婆婆接着说:我儿子去世,你一直不愿再嫁,还为了这个家操心,每天起早贪黑的赚钱
,我跟你爸都看在眼里,知道你是个善良的好姑娘,只要你愿意,我们同意你嫁给梁宸
(小叔子),不管你嫁不嫁给她,在我心里你都是我闺女……
在一旁吃饭的儿子,拍着手笑嘻嘻的说:妈妈,你就嫁给叔叔吧,我以后就可以喊他爸
爸了……
可我心里挺别扭的,在我心里他是小叔子,有的是亲情,没有爱情啊。我怎么能嫁给他
呢?后来我偷偷给他发过短信,叫他不要在意爸妈说的话,没想到他会说:嫂子,虽然
我比你小四岁,但是如果可以,我也想替哥照顾你一辈子,可以吗?
我爸妈一听说公婆想要我嫁给小叔子,很生气。我爸找上门来沟通这事,他觉得太丢脸
,坚决不同意我嫁给小叔子,回去时还要婆婆还我这些年赚的钱,然后一刀两断。可我
真的不想离开孩子,也舍不得放弃经营了这么多年的店面,我该怎么办?其实,我也觉
得小叔子人挺好的,至少我儿子很喜欢他,只是我一直很犹豫,他想娶我是因为爱我,
还是因为感激我?
夏莫回复:
产生爱情的方式,有很多种可能,比如一见钟情,比如日久生情。
你此时面对二婚的犹豫和纠结,一方面是因为小叔的身份,担心结婚后舆论压力和外界
的眼光,迈不过世俗的门槛。另一方面,在你的内心你其实觉得小叔还不错,是比较适
合二婚的人选。
你所谓的父母不同意这门婚事,和怀疑小叔子对你是爱还是感激之情,种种纠结都说明
你缺乏勇气,缺乏信任和自信。面对一桩婚姻,产生纠结的心理,那就不要盲目结婚。
而是应该拉长恋爱期,进一步的尝试去了解对方,唯有经历过磨合,才知道对方是否适
合你,是否是真心爱着你。
而你的父母虽然反对,但只要你和他是真心相爱,并且多和父母做思想工作,引导她们
换位思考,站在你的立场上来思考,才有可能克服世俗的偏见。
不管是否考虑嫁给小叔子,你都应该听从你内心的声音,是否爱他?先培养感情和爱的
能力,再考虑是否嫁不嫁。别为了孩子将就,也别因为他的感激之情而嫁给他。婚姻需
要爱,才能细水流长。
avatar
s*x
5
之前用的是nfsfan的最后一个touch rom
andoid真的比WM6.5好用多了
不过耗电也快多了:(
avatar
n*1
6
争论的焦点在于:
1. 车票问题究竟是不是紧耦合问题.
goodbug假设该问题是可以分割的,所以给出了当前最热门的nosql方案,本质就是
map-reduce. 而究竟如何分割,他没有答案,而是一直闪烁其词。而事实上,分割问题
才是该方案的最难点。至少铁道部那帮人做了这么多年,还是不知道怎么分。goodbug
怎么可以一笔带过
Teacherwei假设该问题无法分割,而必须用紧耦合。
2. In ram database究竟靠不靠谱
我觉得Teacherwei的writing to net其实是cheating, cz ultimately you need
to either a) store in ram in another machine, or b) writing to disk in
another machine.
但我觉得in ram没啥大不了的,没付钱的订单,丢了就丢了。毕竟停电火灾是小概
率事件,而且真没必要没付钱的单在这种情况下负全责。而且这系统比铁道部当前的还
是靠谱多了
其实魏老师的架构是可以扩展到多机并行的,不一定要上IBM大主机,只要上mpi就行了
,接口的角度上来看和单机差比不大。关于map reduce VS mpi, 已经有很多讨论了。
譬如
https://jasperpeilee.wordpress.com/2011/10/27/mpi-and-map-reduce/
我觉得虽然两方案基本假设截然不同,但是可以找到个折中点的. 但两方都没有抱着理
想的心态来讨论,而是拼命揪住别人小辫子不放。Teacherwei批goodbug代码里的错误
,goodbug抓着1W刀和10w/s不放,这就谈不下去了。
avatar
D*O
7
本人现有废纸600张,愿意与你交换!希望你快快联系我!

【在 t********u 的大作中提到】
: 本人现有AA里程6,757点,有效期到5月21日,有需要的朋友快快行动!
: 抓紧哦!

avatar
I*8
8
什马是monopod?
avatar
a*s
9
wifi什么的都好用?

【在 s**********x 的大作中提到】
: 之前用的是nfsfan的最后一个touch rom
: andoid真的比WM6.5好用多了
: 不过耗电也快多了:(

avatar
T*i
10
: 2. In ram database究竟靠不靠谱
: 我觉得Teacherwei的writing to net其实是cheating, cz ultimately you need
write to another machine wait for ACK == store in ram in another machine
It takes a few microseconds round trip.
goodbug
avatar
s*x
11
touch天生没有wifi
只有3g
avatar
g*g
12
我讨论分割的是出票系统,魏老师根本没谈这一块,打个酱油就过去了。
前端的订票系统,我没有分割,直接存到C* DB里去了。而魏老师要写的,就是这么个
系统。
本质上,魏老师要写一个NoSQL DB,还要单机,我直接拿出Cassandra把他干翻了。

goodbug

【在 n****1 的大作中提到】
: 争论的焦点在于:
: 1. 车票问题究竟是不是紧耦合问题.
: goodbug假设该问题是可以分割的,所以给出了当前最热门的nosql方案,本质就是
: map-reduce. 而究竟如何分割,他没有答案,而是一直闪烁其词。而事实上,分割问题
: 才是该方案的最难点。至少铁道部那帮人做了这么多年,还是不知道怎么分。goodbug
: 怎么可以一笔带过
: Teacherwei假设该问题无法分割,而必须用紧耦合。
: 2. In ram database究竟靠不靠谱
: 我觉得Teacherwei的writing to net其实是cheating, cz ultimately you need
: to either a) store in ram in another machine, or b) writing to disk in

avatar
a*s
13
不好意思,搞错了,一直看tp2上的android来着
上边的wifi和power managerment都没搞定

【在 s**********x 的大作中提到】
: touch天生没有wifi
: 只有3g

avatar
l*9
14
goodbug不会编程,闪烁其词是必然的
avatar
p*r
15
字体不好看,有什么补救的?

【在 s**********x 的大作中提到】
: touch天生没有wifi
: 只有3g

avatar
g*g
16
你要是技术牛逼,就在技术上驳倒我。在这里做小丑有意思吗?

【在 l*****9 的大作中提到】
: goodbug不会编程,闪烁其词是必然的
avatar
M*n
17
哪个版本的android for touch比较好啊?

【在 s**********x 的大作中提到】
: 之前用的是nfsfan的最后一个touch rom
: andoid真的比WM6.5好用多了
: 不过耗电也快多了:(

avatar
s*y
18
已经被打脸了。。。低调点好

【在 g*****g 的大作中提到】
: 你要是技术牛逼,就在技术上驳倒我。在这里做小丑有意思吗?
avatar
g*g
19
LOL,你是说那个sync的错误?我不懂我认,我没出来装逼说我是IO的专家不是。
魏老师昨天可是上下拷问,10亿银针,百万并发的要求,我的架构都撑住了,到底谁被
打脸?

【在 s******y 的大作中提到】
: 已经被打脸了。。。低调点好
avatar
s*y
21
就算对方被打了,也不能否认你被打。这种比谁被打是做技术的人的伦理准则么?

【在 g*****g 的大作中提到】
: LOL,你是说那个sync的错误?我不懂我认,我没出来装逼说我是IO的专家不是。
: 魏老师昨天可是上下拷问,10亿银针,百万并发的要求,我的架构都撑住了,到底谁被
: 打脸?

avatar
g*g
22
我有知识缺陷,这也算打脸?有人敢说自己什么都懂吗?
不懂,跟不懂还出来装逼是两回事,你不懂这个区别吗?

【在 s******y 的大作中提到】
: 就算对方被打了,也不能否认你被打。这种比谁被打是做技术的人的伦理准则么?
avatar
p*2
23
goodbug的solution跟mapreduce是啥关系呀?LZ能zkss吗?
avatar
P*l
24
同问.

【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀?LZ能zkss吗?
avatar
f*4
25
他可能是想说goodbug那个分表的思路吧
我一只没追究怎么分。我只问,分了之后怎么调整。
这部分工程的复杂度你不能不承认是实际存在的。

【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀?LZ能zkss吗?
avatar
P*l
26
我给补充了一个.
发信人: PuTTYshell (菩提壳), 信区: Programming
标 题: Re: 春运火车票2个方案比较
发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
给补充一个.有什么问题请指正.
车次和时刻表可以认为是固定的.所以这个时刻表可以每台机器可以存一份.买票的时
候根据这个时刻表计算得到该买的车次和时刻,然后下单.剩下的过程就和买直达车是
一样的了.
怎么分库不是特别要紧.

【在 f****4 的大作中提到】
: 他可能是想说goodbug那个分表的思路吧
: 我一只没追究怎么分。我只问,分了之后怎么调整。
: 这部分工程的复杂度你不能不承认是实际存在的。

avatar
a*f
27
按车次分库其实应该就足够了,分太多系统就不容易维护了。加临客不影响按车次分库
。时刻表,线路这些都要考虑到变化。

【在 P********l 的大作中提到】
: 我给补充了一个.
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个.有什么问题请指正.
: 车次和时刻表可以认为是固定的.所以这个时刻表可以每台机器可以存一份.买票的时
: 候根据这个时刻表计算得到该买的车次和时刻,然后下单.剩下的过程就和买直达车是
: 一样的了.
: 怎么分库不是特别要紧.

avatar
f*4
28
查询不是问题,问题是北京到上海,转车,上海到南京。
北京到上海在数据库1上
上海到南京在数据库2上
你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了,你从北京飞到上
海去?

【在 P********l 的大作中提到】
: 我给补充了一个.
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个.有什么问题请指正.
: 车次和时刻表可以认为是固定的.所以这个时刻表可以每台机器可以存一份.买票的时
: 候根据这个时刻表计算得到该买的车次和时刻,然后下单.剩下的过程就和买直达车是
: 一样的了.
: 怎么分库不是特别要紧.

avatar
p*2
29

这个再加一层不久行了吗?

【在 f****4 的大作中提到】
: 查询不是问题,问题是北京到上海,转车,上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了,你从北京飞到上
: 海去?

avatar
f*4
30
在补充一下,goodbug的方案,余票数据不能放在那个C*** 上面,这个他已经解释了为
什么。
那么余票数据怎么处理订票的throughput?只有分表。
然后我问分表产生的路径依赖怎么处理?他说可以让大多数有路径依赖的车次放到一个
server上去。
然后我假设我相信你能做到完美分表,但车次新增之后,怎么调整?

【在 P********l 的大作中提到】
: 我给补充了一个.
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个.有什么问题请指正.
: 车次和时刻表可以认为是固定的.所以这个时刻表可以每台机器可以存一份.买票的时
: 候根据这个时刻表计算得到该买的车次和时刻,然后下单.剩下的过程就和买直达车是
: 一样的了.
: 怎么分库不是特别要紧.

avatar
P*l
31
这就是支持同时买n张票的事了.不难吧 (至少我觉得不难:)).和分库也没关系.

【在 f****4 的大作中提到】
: 查询不是问题,问题是北京到上海,转车,上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了,你从北京飞到上
: 海去?

avatar
f*4
32
zkss

【在 p*****2 的大作中提到】
:
: 这个再加一层不久行了吗?

avatar
g*g
33
分库的是减少distributed transaction,不是杜绝distributed transaction。
DB transaction本身保证了integrity,买不下来整个rollback,你的问题是不会出现
的。
一个好的分库,纯粹在于减少跨库而已。我说了很多次,怎么分,要看历史数据去统计
。我只有
几个基本思路,没有最好的方法。但盲目地说不能分是不合适的。

【在 f****4 的大作中提到】
: 查询不是问题,问题是北京到上海,转车,上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了,你从北京飞到上
: 海去?

avatar
a*f
34
联程按车次分就是一个splitting -> reducing的模型。在合并的时候就可以解决联程
票是否成功的问题

【在 f****4 的大作中提到】
: 查询不是问题,问题是北京到上海,转车,上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了,你从北京飞到上
: 海去?

avatar
f*4
35
可以,你给一个这种分段买票,如何判断成功买到票的方案吧
顺便提供一下实现复杂度的估算,主要是能不能处理10万次/s买票请求的throughput;
顺带估计一下一个分段买票的请求,大概要等多久。
谢谢

【在 P********l 的大作中提到】
: 这就是支持同时买n张票的事了.不难吧 (至少我觉得不难:)).和分库也没关系.
avatar
f*4
36
顺便提供一下实现复杂度的估算,主要是能不能处理10万次/s买票请求的throughput;
顺带估计一下一个分段买票的请求,大概要等多久。
谢谢

【在 a*f 的大作中提到】
: 联程按车次分就是一个splitting -> reducing的模型。在合并的时候就可以解决联程
: 票是否成功的问题

avatar
w*l
37
ZKSS 啥意思?

【在 f****4 的大作中提到】
: zkss
avatar
f*4
38
你还是没想明白复杂在哪。
谁来决定买下来了没有?我买个分段票,跑到相关数据库上去查一下?
我一直假设你的分表是完美的,就是不想纠缠这个细节。但你非要说没有影响,我也没
有办法。

【在 g*****g 的大作中提到】
: 分库的是减少distributed transaction,不是杜绝distributed transaction。
: DB transaction本身保证了integrity,买不下来整个rollback,你的问题是不会出现
: 的。
: 一个好的分库,纯粹在于减少跨库而已。我说了很多次,怎么分,要看历史数据去统计
: 。我只有
: 几个基本思路,没有最好的方法。但盲目地说不能分是不合适的。

avatar
f*4
39
应该是展开说说吧?
难道我用错了???

【在 w*l 的大作中提到】
: ZKSS 啥意思?
avatar
a*f
40
如果用不加锁排号的方式出票,按车次分库,合并结果判断联程票是否成功的处理速度
很快的。瓶颈不在这里。

【在 f****4 的大作中提到】
: 可以,你给一个这种分段买票,如何判断成功买到票的方案吧
: 顺便提供一下实现复杂度的估算,主要是能不能处理10万次/s买票请求的throughput;
: 顺带估计一下一个分段买票的请求,大概要等多久。
: 谢谢

avatar
w*l
41
没,我不经常BBS。所以这词不熟。

【在 f****4 的大作中提到】
: 应该是展开说说吧?
: 难道我用错了???

avatar
g*g
42
是你没明白DB transaction怎么工作的吧。比如说50%的人一次只买一张票,他们就没
问题了,春运放票往返也没法同时买,我们暂时不考虑。另外50%的人需要买联程票,
简单点一次买两张,任意。这就是个transaction,只要是一个单子,要吗都买到,要
吗都买不到,这叫DB atomic transaction。
如果这两段票在同一个数据库里,就是一个普通的数据库transaction,如果不在,就
要distributed transaction。如果可以完美分库,那就没有distributed transaction
。所有的流量可以近乎平均的分到各个数据库里。从而降低了单个数据库压力。
至于查询,完全是cache的。不会Hit 数据库。我能做到的只能跟你说1秒以前,或者10
秒以前,数据库里还有几张票。你下单的时候看到有票,我不能保证你下单就能买到。
Transaction做的是,把两段的计数器都锁了,然后减一。如果锁不到,就等。分布式
数据库的类库有避免死锁的支持,比如都按DB ID大小同向锁。
这样说明白了没有?

【在 f****4 的大作中提到】
: 你还是没想明白复杂在哪。
: 谁来决定买下来了没有?我买个分段票,跑到相关数据库上去查一下?
: 我一直假设你的分表是完美的,就是不想纠缠这个细节。但你非要说没有影响,我也没
: 有办法。

avatar
a*f
43
我查了下数据,Google用1000台电脑排序10 billion 100-byte records (in
uncompressed text files)大概需要68秒,平均单机每秒能处理1.4 million记录文件
。对于铁道部这种不缺钱的部门来说,用几个服务器集群处理每秒10W次记录或者更多
应该没有问题。

【在 f****4 的大作中提到】
: 顺便提供一下实现复杂度的估算,主要是能不能处理10万次/s买票请求的throughput;
: 顺带估计一下一个分段买票的请求,大概要等多久。
: 谢谢

avatar
P*l
44
买一张票的复杂度度是1的话,买两张票的复杂度还是1.
买一张票的时间符合泊松分布,买两张票可能还是泊松分布.(我的排队论学得最烂了)
过程大概是:
p1 = buy ticket 1; //买票1,异步
p2 = buy ticket 2; //买票2,异步
wait(p1, p2).
then(function(result1, result2){ //两张票状态全部返回以后.
if(result1.success && result2.success){ //全买到了
check out.
}else{ //至少一张没买到
if(result1.success){
p3 = (return ticket 1); //退票,异步
}
if(result2.success){
p4 = (return ticket 2); //退票,异步
}
}
}).
always(function(){
//exception.
});
wait(p3).then()
wait(p4).then()

【在 f****4 的大作中提到】
: 可以,你给一个这种分段买票,如何判断成功买到票的方案吧
: 顺便提供一下实现复杂度的估算,主要是能不能处理10万次/s买票请求的throughput;
: 顺带估计一下一个分段买票的请求,大概要等多久。
: 谢谢

avatar
g*g
45
distributed transaction其实远比你说的这个复杂,你要考虑到买了票1,你挂了怎么
办,DB挂了怎么办。

了)

【在 P********l 的大作中提到】
: 买一张票的复杂度度是1的话,买两张票的复杂度还是1.
: 买一张票的时间符合泊松分布,买两张票可能还是泊松分布.(我的排队论学得最烂了)
: 过程大概是:
: p1 = buy ticket 1; //买票1,异步
: p2 = buy ticket 2; //买票2,异步
: wait(p1, p2).
: then(function(result1, result2){ //两张票状态全部返回以后.
: if(result1.success && result2.success){ //全买到了
: check out.
: }else{ //至少一张没买到

avatar
P*l
46
我总不能把各种情况全说一遍吧.我也说不全.
只是个大概意思.

【在 g*****g 的大作中提到】
: distributed transaction其实远比你说的这个复杂,你要考虑到买了票1,你挂了怎么
: 办,DB挂了怎么办。
:
: 了)

avatar
n*1
47
一旦采用了cassandra架构,而且还加上goodbug说的分表,方案的思路基本限定死为
map-reduce approach了

【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀?LZ能zkss吗?
avatar
f*4
48
你是想说先到2个数据库上抢票,然后把抢到没有的response发到一个server上合并?
如果有一个段没抢到整个回滚?如果抢到了做log,通知2个数据库,这2个段的票卖掉
了?

【在 a*f 的大作中提到】
: 如果用不加锁排号的方式出票,按车次分库,合并结果判断联程票是否成功的处理速度
: 很快的。瓶颈不在这里。

avatar
f*4
49
好像我的理解是正确的,你想让一个中心来裁决是否出票成功。
然后这个中心要再能够支持高throughput一遍,提供failover一遍

【在 a*f 的大作中提到】
: 我查了下数据,Google用1000台电脑排序10 billion 100-byte records (in
: uncompressed text files)大概需要68秒,平均单机每秒能处理1.4 million记录文件
: 。对于铁道部这种不缺钱的部门来说,用几个服务器集群处理每秒10W次记录或者更多
: 应该没有问题。

avatar
f*4
50
是我不好。没能理解你上的这是分布式数据库。所有的实现都是数据库提供的。
我重复一下我的理解,你看看正确不:
相当于我买一张票,先试着到这2张表不同数据库上去对每张票去上个锁?只有都上锁
了才能出票。然后有一张票上了锁,另一张票上不了锁,就等待,要么等到了,要么等
不到,释放上的锁。是这么个意思吧?
然后我终于明白了为什么zhaoc一直在提上锁,上锁
是这么个意思,没错了吧?
得确认一下,不然后面不好讨论了

transaction
10

【在 g*****g 的大作中提到】
: 是你没明白DB transaction怎么工作的吧。比如说50%的人一次只买一张票,他们就没
: 问题了,春运放票往返也没法同时买,我们暂时不考虑。另外50%的人需要买联程票,
: 简单点一次买两张,任意。这就是个transaction,只要是一个单子,要吗都买到,要
: 吗都买不到,这叫DB atomic transaction。
: 如果这两段票在同一个数据库里,就是一个普通的数据库transaction,如果不在,就
: 要distributed transaction。如果可以完美分库,那就没有distributed transaction
: 。所有的流量可以近乎平均的分到各个数据库里。从而降低了单个数据库压力。
: 至于查询,完全是cache的。不会Hit 数据库。我能做到的只能跟你说1秒以前,或者10
: 秒以前,数据库里还有几张票。你下单的时候看到有票,我不能保证你下单就能买到。
: Transaction做的是,把两段的计数器都锁了,然后减一。如果锁不到,就等。分布式

avatar
f*4
51
-_- 估算一下就好了,不需要这么学术的

了)

【在 P********l 的大作中提到】
: 买一张票的复杂度度是1的话,买两张票的复杂度还是1.
: 买一张票的时间符合泊松分布,买两张票可能还是泊松分布.(我的排队论学得最烂了)
: 过程大概是:
: p1 = buy ticket 1; //买票1,异步
: p2 = buy ticket 2; //买票2,异步
: wait(p1, p2).
: then(function(result1, result2){ //两张票状态全部返回以后.
: if(result1.success && result2.success){ //全买到了
: check out.
: }else{ //至少一张没买到

avatar
f*4
52
你这个功力还是赞的
我之前的分析是假设goodbug的4数据库分表,每个是单独的数据库。但没理解到
goodbug说的是分布式数据库,具体实现是数据库提供的。
我之前的假设,都是基于4个数据库是单独的数据库,认为这样能缩短排队时间。这样
有些case不再适用,我得再想想。
我们简单点说,排队时间。既然你要分段票买票上锁,你说实现的效率上,是分布式的
数据库快还是一个集中的主机快?更何况集中的主机上如果不上多线程的话都可以不用
上锁。这点我已经分析过了。
我之前的分析排队时间的时候举了个300人排队时间被拉长的例子,现在的情况一样糟
糕。搞不好还要糟糕。
换个话说,魏老师那个集中的出票自动机的实现,给goodbug的这个看似分布的实际概
念上集中的分布式数据库代替了。恩,就是这样。

了)

【在 P********l 的大作中提到】
: 买一张票的复杂度度是1的话,买两张票的复杂度还是1.
: 买一张票的时间符合泊松分布,买两张票可能还是泊松分布.(我的排队论学得最烂了)
: 过程大概是:
: p1 = buy ticket 1; //买票1,异步
: p2 = buy ticket 2; //买票2,异步
: wait(p1, p2).
: then(function(result1, result2){ //两张票状态全部返回以后.
: if(result1.success && result2.success){ //全买到了
: check out.
: }else{ //至少一张没买到

avatar
g*g
53
是,我一直就是这个意思。所有scalability的问题,几乎到最后都是数据库性能的问
题。如果你能完美分,像Obamacare那样,基本上架构就没有什么问题了。如果不行,
就要看你分布式交易的比例,再找妥协的办法。
我要再强调一次,订票的量很大。但是票的量并没有那么大,一千车次,一车子一万张
票,每天的票是千万张。可订票的区间一共上上亿张,这个级别的数据量,只要是异步
的,没有高并发,一台好的DB服务器就撑住了。我在那分票,纯粹是找余量和降低处理
延迟。

【在 f****4 的大作中提到】
: 是我不好。没能理解你上的这是分布式数据库。所有的实现都是数据库提供的。
: 我重复一下我的理解,你看看正确不:
: 相当于我买一张票,先试着到这2张表不同数据库上去对每张票去上个锁?只有都上锁
: 了才能出票。然后有一张票上了锁,另一张票上不了锁,就等待,要么等到了,要么等
: 不到,释放上的锁。是这么个意思吧?
: 然后我终于明白了为什么zhaoc一直在提上锁,上锁
: 是这么个意思,没错了吧?
: 得确认一下,不然后面不好讨论了
:
: transaction

avatar
a*f
54
下单的时候只是排队。不用抢。系统自动定时在后台处理所有的定单。比如定时出100
个票就是fill前100个订单,如果有多余的名额就往后选。这个进程和用户无关,不用
加锁也不用回滚,速度很快。

【在 f****4 的大作中提到】
: 你是想说先到2个数据库上抢票,然后把抢到没有的response发到一个server上合并?
: 如果有一个段没抢到整个回滚?如果抢到了做log,通知2个数据库,这2个段的票卖掉
: 了?

avatar
f*4
55
买票的排队时间。你这么搞可以直接上goodbug的大杀器,离线订单。更简单

100

【在 a*f 的大作中提到】
: 下单的时候只是排队。不用抢。系统自动定时在后台处理所有的定单。比如定时出100
: 个票就是fill前100个订单,如果有多余的名额就往后选。这个进程和用户无关,不用
: 加锁也不用回滚,速度很快。

相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。