n****1
发帖数: 1136 | 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
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不放，这就谈不下去了。 |
T********i
发帖数: 2416 | 2 : 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 |
g*****g
发帖数: 34805 | 3 我讨论分割的是出票系统，魏老师根本没谈这一块，打个酱油就过去了。
前端的订票系统，我没有分割，直接存到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
|
l*****9
发帖数: 9501 | |
g*****g
发帖数: 34805 | 5 你要是技术牛逼，就在技术上驳倒我。在这里做小丑有意思吗？
【在 l*****9 的大作中提到】
: goodbug不会编程，闪烁其词是必然的
|
s******y
发帖数: 416 | 6 已经被打脸了。。。低调点好
【在 g*****g 的大作中提到】
: 你要是技术牛逼，就在技术上驳倒我。在这里做小丑有意思吗？
|
g*****g
发帖数: 34805 | 7 LOL，你是说那个sync的错误？我不懂我认，我没出来装逼说我是IO的专家不是。
魏老师昨天可是上下拷问，10亿银针，百万并发的要求，我的架构都撑住了，到底谁被
打脸？
【在 s******y 的大作中提到】
: 已经被打脸了。。。低调点好
|
l*****9
发帖数: 9501 | 8 看看小丑被打脸
http://www.mitbbs.com/article_t0/Programming/31284509.html
【在 g*****g 的大作中提到】
: 你要是技术牛逼，就在技术上驳倒我。在这里做小丑有意思吗？
|
s******y
发帖数: 416 | 9 就算对方被打了，也不能否认你被打。这种比谁被打是做技术的人的伦理准则么？
【在 g*****g 的大作中提到】
: LOL，你是说那个sync的错误？我不懂我认，我没出来装逼说我是IO的专家不是。
: 魏老师昨天可是上下拷问，10亿银针，百万并发的要求，我的架构都撑住了，到底谁被
: 打脸？
|
g*****g
发帖数: 34805 | 10 我有知识缺陷，这也算打脸？有人敢说自己什么都懂吗？
不懂，跟不懂还出来装逼是两回事，你不懂这个区别吗？
【在 s******y 的大作中提到】
: 就算对方被打了，也不能否认你被打。这种比谁被打是做技术的人的伦理准则么？
|
|
|
p*****2
发帖数: 21240 | 11 goodbug的solution跟mapreduce是啥关系呀？LZ能zkss吗？ |
P********l
发帖数: 452 | 12 同问．
【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀？LZ能zkss吗？
|
f****4
发帖数: 1359 | 13 他可能是想说goodbug那个分表的思路吧
我一只没追究怎么分。我只问，分了之后怎么调整。
这部分工程的复杂度你不能不承认是实际存在的。
【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀？LZ能zkss吗？
|
P********l
发帖数: 452 | 14 我给补充了一个．
发信人: PuTTYshell (菩提壳), 信区: Programming
标 题: Re: 春运火车票2个方案比较
发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
给补充一个．有什么问题请指正．
车次和时刻表可以认为是固定的．所以这个时刻表可以每台机器可以存一份．买票的时
候根据这个时刻表计算得到该买的车次和时刻，然后下单．剩下的过程就和买直达车是
一样的了．
怎么分库不是特别要紧．
【在 f****4 的大作中提到】
: 他可能是想说goodbug那个分表的思路吧
: 我一只没追究怎么分。我只问，分了之后怎么调整。
: 这部分工程的复杂度你不能不承认是实际存在的。
|
a*f
发帖数: 1790 | 15 按车次分库其实应该就足够了，分太多系统就不容易维护了。加临客不影响按车次分库
。时刻表，线路这些都要考虑到变化。
【在 P********l 的大作中提到】
: 我给补充了一个．
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个．有什么问题请指正．
: 车次和时刻表可以认为是固定的．所以这个时刻表可以每台机器可以存一份．买票的时
: 候根据这个时刻表计算得到该买的车次和时刻，然后下单．剩下的过程就和买直达车是
: 一样的了．
: 怎么分库不是特别要紧．
|
f****4
发帖数: 1359 | 16 查询不是问题，问题是北京到上海，转车，上海到南京。
北京到上海在数据库1上
上海到南京在数据库2上
你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了，你从北京飞到上
海去？
【在 P********l 的大作中提到】
: 我给补充了一个．
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个．有什么问题请指正．
: 车次和时刻表可以认为是固定的．所以这个时刻表可以每台机器可以存一份．买票的时
: 候根据这个时刻表计算得到该买的车次和时刻，然后下单．剩下的过程就和买直达车是
: 一样的了．
: 怎么分库不是特别要紧．
|
p*****2
发帖数: 21240 | 17
这个再加一层不久行了吗？
【在 f****4 的大作中提到】
: 查询不是问题，问题是北京到上海，转车，上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了，你从北京飞到上
: 海去？
|
f****4
发帖数: 1359 | 18 在补充一下，goodbug的方案，余票数据不能放在那个C*** 上面，这个他已经解释了为
什么。
那么余票数据怎么处理订票的throughput？只有分表。
然后我问分表产生的路径依赖怎么处理？他说可以让大多数有路径依赖的车次放到一个
server上去。
然后我假设我相信你能做到完美分表，但车次新增之后，怎么调整？
【在 P********l 的大作中提到】
: 我给补充了一个．
: 发信人: PuTTYshell (菩提壳), 信区: Programming
: 标 题: Re: 春运火车票2个方案比较
: 发信站: BBS 未名空间站 (Mon Nov 25 14:22:04 2013, 美东)
: 给补充一个．有什么问题请指正．
: 车次和时刻表可以认为是固定的．所以这个时刻表可以每台机器可以存一份．买票的时
: 候根据这个时刻表计算得到该买的车次和时刻，然后下单．剩下的过程就和买直达车是
: 一样的了．
: 怎么分库不是特别要紧．
|
P********l
发帖数: 452 | 19 这就是支持同时买n张票的事了．不难吧 （至少我觉得不难:)）．和分库也没关系．
【在 f****4 的大作中提到】
: 查询不是问题，问题是北京到上海，转车，上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了，你从北京飞到上
: 海去？
|
f****4
发帖数: 1359 | 20 zkss
【在 p*****2 的大作中提到】
:
: 这个再加一层不久行了吗？
|
|
|
g*****g
发帖数: 34805 | 21 分库的是减少distributed transaction，不是杜绝distributed transaction。
DB transaction本身保证了integrity，买不下来整个rollback，你的问题是不会出现
的。
一个好的分库，纯粹在于减少跨库而已。我说了很多次，怎么分，要看历史数据去统计
。我只有
几个基本思路，没有最好的方法。但盲目地说不能分是不合适的。
【在 f****4 的大作中提到】
: 查询不是问题，问题是北京到上海，转车，上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了，你从北京飞到上
: 海去？
|
a*f
发帖数: 1790 | 22 联程按车次分就是一个splitting -> reducing的模型。在合并的时候就可以解决联程
票是否成功的问题
【在 f****4 的大作中提到】
: 查询不是问题，问题是北京到上海，转车，上海到南京。
: 北京到上海在数据库1上
: 上海到南京在数据库2上
: 你这张车票只有2个分段都买到才算买到了。不然上海到南京买到了，你从北京飞到上
: 海去？
|
f****4
发帖数: 1359 | 23 可以，你给一个这种分段买票，如何判断成功买到票的方案吧
顺便提供一下实现复杂度的估算，主要是能不能处理10万次/s买票请求的throughput；
顺带估计一下一个分段买票的请求，大概要等多久。
谢谢
【在 P********l 的大作中提到】
: 这就是支持同时买n张票的事了．不难吧 （至少我觉得不难:)）．和分库也没关系．
|
f****4
发帖数: 1359 | 24 顺便提供一下实现复杂度的估算，主要是能不能处理10万次/s买票请求的throughput；
顺带估计一下一个分段买票的请求，大概要等多久。
谢谢
【在 a*f 的大作中提到】
: 联程按车次分就是一个splitting -> reducing的模型。在合并的时候就可以解决联程
: 票是否成功的问题
|
w*l
发帖数: 14 | 25 ZKSS 啥意思？
【在 f****4 的大作中提到】
: zkss
|
f****4
发帖数: 1359 | 26 你还是没想明白复杂在哪。
谁来决定买下来了没有？我买个分段票，跑到相关数据库上去查一下？
我一直假设你的分表是完美的，就是不想纠缠这个细节。但你非要说没有影响，我也没
有办法。
【在 g*****g 的大作中提到】
: 分库的是减少distributed transaction，不是杜绝distributed transaction。
: DB transaction本身保证了integrity，买不下来整个rollback，你的问题是不会出现
: 的。
: 一个好的分库，纯粹在于减少跨库而已。我说了很多次，怎么分，要看历史数据去统计
: 。我只有
: 几个基本思路，没有最好的方法。但盲目地说不能分是不合适的。
|
f****4
发帖数: 1359 | 27 应该是展开说说吧？
难道我用错了？？？
【在 w*l 的大作中提到】
: ZKSS 啥意思？
|
a*f
发帖数: 1790 | 28 如果用不加锁排号的方式出票，按车次分库，合并结果判断联程票是否成功的处理速度
很快的。瓶颈不在这里。
【在 f****4 的大作中提到】
: 可以，你给一个这种分段买票，如何判断成功买到票的方案吧
: 顺便提供一下实现复杂度的估算，主要是能不能处理10万次/s买票请求的throughput；
: 顺带估计一下一个分段买票的请求，大概要等多久。
: 谢谢
|
w*l
发帖数: 14 | 29 没，我不经常BBS。所以这词不熟。
【在 f****4 的大作中提到】
: 应该是展开说说吧？
: 难道我用错了？？？
|
g*****g
发帖数: 34805 | 30 是你没明白DB transaction怎么工作的吧。比如说50%的人一次只买一张票，他们就没
问题了，春运放票往返也没法同时买，我们暂时不考虑。另外50%的人需要买联程票，
简单点一次买两张，任意。这就是个transaction，只要是一个单子，要吗都买到，要
吗都买不到，这叫DB atomic transaction。
如果这两段票在同一个数据库里，就是一个普通的数据库transaction，如果不在，就
要distributed transaction。如果可以完美分库，那就没有distributed transaction
。所有的流量可以近乎平均的分到各个数据库里。从而降低了单个数据库压力。
至于查询，完全是cache的。不会Hit 数据库。我能做到的只能跟你说1秒以前，或者10
秒以前，数据库里还有几张票。你下单的时候看到有票，我不能保证你下单就能买到。
Transaction做的是，把两段的计数器都锁了，然后减一。如果锁不到，就等。分布式
数据库的类库有避免死锁的支持，比如都按DB ID大小同向锁。
这样说明白了没有？
【在 f****4 的大作中提到】
: 你还是没想明白复杂在哪。
: 谁来决定买下来了没有？我买个分段票，跑到相关数据库上去查一下？
: 我一直假设你的分表是完美的，就是不想纠缠这个细节。但你非要说没有影响，我也没
: 有办法。
|
|
|
a*f
发帖数: 1790 | 31 我查了下数据，Google用1000台电脑排序10 billion 100-byte records (in
uncompressed text files)大概需要68秒，平均单机每秒能处理1.4 million记录文件
。对于铁道部这种不缺钱的部门来说，用几个服务器集群处理每秒10W次记录或者更多
应该没有问题。
【在 f****4 的大作中提到】
: 顺便提供一下实现复杂度的估算，主要是能不能处理10万次/s买票请求的throughput；
: 顺带估计一下一个分段买票的请求，大概要等多久。
: 谢谢
|
P********l
发帖数: 452 | 32 买一张票的复杂度度是１的话，买两张票的复杂度还是１．
买一张票的时间符合泊松分布，买两张票可能还是泊松分布．（我的排队论学得最烂了）
过程大概是：
p1 = buy ticket 1; //买票１，异步
p2 = buy ticket 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；
: 顺带估计一下一个分段买票的请求，大概要等多久。
: 谢谢
|
g*****g
发帖数: 34805 | 33 distributed transaction其实远比你说的这个复杂，你要考虑到买了票1，你挂了怎么
办，DB挂了怎么办。
了）
【在 P********l 的大作中提到】
: 买一张票的复杂度度是１的话，买两张票的复杂度还是１．
: 买一张票的时间符合泊松分布，买两张票可能还是泊松分布．（我的排队论学得最烂了）
: 过程大概是：
: p1 = buy ticket 1; //买票１，异步
: p2 = buy ticket 2; //买票２，异步
: wait(p1, p2).
: then(function(result1, result2){ ／／两张票状态全部返回以后．
: if(result1.success && result2.success){ ／／全买到了
: check out.
: }else{ ／／至少一张没买到
|
P********l
发帖数: 452 | 34 我总不能把各种情况全说一遍吧．我也说不全．
只是个大概意思．
【在 g*****g 的大作中提到】
: distributed transaction其实远比你说的这个复杂，你要考虑到买了票1，你挂了怎么
: 办，DB挂了怎么办。
:
: 了）
|
n****1
发帖数: 1136 | 35 一旦采用了cassandra架构，而且还加上goodbug说的分表，方案的思路基本限定死为
map-reduce approach了
【在 p*****2 的大作中提到】
: goodbug的solution跟mapreduce是啥关系呀？LZ能zkss吗？
|
f****4
发帖数: 1359 | 36 你是想说先到2个数据库上抢票，然后把抢到没有的response发到一个server上合并？
如果有一个段没抢到整个回滚？如果抢到了做log，通知2个数据库，这2个段的票卖掉
了？
【在 a*f 的大作中提到】
: 如果用不加锁排号的方式出票，按车次分库，合并结果判断联程票是否成功的处理速度
: 很快的。瓶颈不在这里。
|
f****4
发帖数: 1359 | 37 好像我的理解是正确的，你想让一个中心来裁决是否出票成功。
然后这个中心要再能够支持高throughput一遍，提供failover一遍
【在 a*f 的大作中提到】
: 我查了下数据，Google用1000台电脑排序10 billion 100-byte records (in
: uncompressed text files)大概需要68秒，平均单机每秒能处理1.4 million记录文件
: 。对于铁道部这种不缺钱的部门来说，用几个服务器集群处理每秒10W次记录或者更多
: 应该没有问题。
|
f****4
发帖数: 1359 | 38 是我不好。没能理解你上的这是分布式数据库。所有的实现都是数据库提供的。
我重复一下我的理解，你看看正确不：
相当于我买一张票，先试着到这2张表不同数据库上去对每张票去上个锁？只有都上锁
了才能出票。然后有一张票上了锁，另一张票上不了锁，就等待，要么等到了，要么等
不到，释放上的锁。是这么个意思吧？
然后我终于明白了为什么zhaoc一直在提上锁，上锁
是这么个意思，没错了吧？
得确认一下，不然后面不好讨论了
transaction
10
【在 g*****g 的大作中提到】
: 是你没明白DB transaction怎么工作的吧。比如说50%的人一次只买一张票，他们就没
: 问题了，春运放票往返也没法同时买，我们暂时不考虑。另外50%的人需要买联程票，
: 简单点一次买两张，任意。这就是个transaction，只要是一个单子，要吗都买到，要
: 吗都买不到，这叫DB atomic transaction。
: 如果这两段票在同一个数据库里，就是一个普通的数据库transaction，如果不在，就
: 要distributed transaction。如果可以完美分库，那就没有distributed transaction
: 。所有的流量可以近乎平均的分到各个数据库里。从而降低了单个数据库压力。
: 至于查询，完全是cache的。不会Hit 数据库。我能做到的只能跟你说1秒以前，或者10
: 秒以前，数据库里还有几张票。你下单的时候看到有票，我不能保证你下单就能买到。
: Transaction做的是，把两段的计数器都锁了，然后减一。如果锁不到，就等。分布式
|
f****4
发帖数: 1359 | 39 -_- 估算一下就好了，不需要这么学术的
了）
【在 P********l 的大作中提到】
: 买一张票的复杂度度是１的话，买两张票的复杂度还是１．
: 买一张票的时间符合泊松分布，买两张票可能还是泊松分布．（我的排队论学得最烂了）
: 过程大概是：
: p1 = buy ticket 1; //买票１，异步
: p2 = buy ticket 2; //买票２，异步
: wait(p1, p2).
: then(function(result1, result2){ ／／两张票状态全部返回以后．
: if(result1.success && result2.success){ ／／全买到了
: check out.
: }else{ ／／至少一张没买到
|
f****4
发帖数: 1359 | 40 你这个功力还是赞的
我之前的分析是假设goodbug的4数据库分表，每个是单独的数据库。但没理解到
goodbug说的是分布式数据库，具体实现是数据库提供的。
我之前的假设，都是基于4个数据库是单独的数据库，认为这样能缩短排队时间。这样
有些case不再适用，我得再想想。
我们简单点说，排队时间。既然你要分段票买票上锁，你说实现的效率上，是分布式的
数据库快还是一个集中的主机快？更何况集中的主机上如果不上多线程的话都可以不用
上锁。这点我已经分析过了。
我之前的分析排队时间的时候举了个300人排队时间被拉长的例子，现在的情况一样糟
糕。搞不好还要糟糕。
换个话说，魏老师那个集中的出票自动机的实现，给goodbug的这个看似分布的实际概
念上集中的分布式数据库代替了。恩，就是这样。
了）
【在 P********l 的大作中提到】
: 买一张票的复杂度度是１的话，买两张票的复杂度还是１．
: 买一张票的时间符合泊松分布，买两张票可能还是泊松分布．（我的排队论学得最烂了）
: 过程大概是：
: p1 = buy ticket 1; //买票１，异步
: p2 = buy ticket 2; //买票２，异步
: wait(p1, p2).
: then(function(result1, result2){ ／／两张票状态全部返回以后．
: if(result1.success && result2.success){ ／／全买到了
: check out.
: }else{ ／／至少一张没买到
|
|
|
g*****g
发帖数: 34805 | 41 是，我一直就是这个意思。所有scalability的问题，几乎到最后都是数据库性能的问
题。如果你能完美分，像Obamacare那样，基本上架构就没有什么问题了。如果不行，
就要看你分布式交易的比例，再找妥协的办法。
我要再强调一次，订票的量很大。但是票的量并没有那么大，一千车次，一车子一万张
票，每天的票是千万张。可订票的区间一共上上亿张，这个级别的数据量，只要是异步
的，没有高并发，一台好的DB服务器就撑住了。我在那分票，纯粹是找余量和降低处理
延迟。
【在 f****4 的大作中提到】
: 是我不好。没能理解你上的这是分布式数据库。所有的实现都是数据库提供的。
: 我重复一下我的理解，你看看正确不：
: 相当于我买一张票，先试着到这2张表不同数据库上去对每张票去上个锁？只有都上锁
: 了才能出票。然后有一张票上了锁，另一张票上不了锁，就等待，要么等到了，要么等
: 不到，释放上的锁。是这么个意思吧？
: 然后我终于明白了为什么zhaoc一直在提上锁，上锁
: 是这么个意思，没错了吧？
: 得确认一下，不然后面不好讨论了
:
: transaction
|
a*f
发帖数: 1790 | 42 下单的时候只是排队。不用抢。系统自动定时在后台处理所有的定单。比如定时出100
个票就是fill前100个订单，如果有多余的名额就往后选。这个进程和用户无关，不用
加锁也不用回滚，速度很快。
【在 f****4 的大作中提到】
: 你是想说先到2个数据库上抢票，然后把抢到没有的response发到一个server上合并？
: 如果有一个段没抢到整个回滚？如果抢到了做log，通知2个数据库，这2个段的票卖掉
: 了？
|
f****4
发帖数: 1359 | 43 买票的排队时间。你这么搞可以直接上goodbug的大杀器，离线订单。更简单
100
【在 a*f 的大作中提到】
: 下单的时候只是排队。不用抢。系统自动定时在后台处理所有的定单。比如定时出100
: 个票就是fill前100个订单，如果有多余的名额就往后选。这个进程和用户无关，不用
: 加锁也不用回滚，速度很快。
|
a*f
发帖数: 1790 | 44 给你看个我们年初讨论这个问题的链接：
http://www.mitbbs.com/article0/Programming/31235655_0.html
【在 f****4 的大作中提到】
: 买票的排队时间。你这么搞可以直接上goodbug的大杀器，离线订单。更简单
:
: 100
|
