b*******g
发帖数: 603 | 1 我不明白我提的数据库分票策略有啥不行的。你们要质疑也要质疑个明白。
如果没有联票，那可以完美分库，这个没有疑问。现在有10%的联票，我把所有票的10%
预留到一台数据库上，所有联票的request发到这台机器上。剩下的就可以轻松一个车
次一个数据库，实际上用不了那么多，比如弄10台机器组合一下就可以基本达到负载平
衡。
很显然，每个车次只有两个数据库有票。初值其实是按照历史数据的比例分的。而运行
到一个数据库用完了之后，可以重新平衡数据库。比如预估10%，其实是20%，单车次刚
开始预分900张，联票预分100张，联票服务器用完了之后，订票发现没票了，就可以看
到另外一个数据库还有500张，然后把这500张按4:1重新分配。当低于一定阈值还一边
用完了，比如总数100，就可以把所有票合到联票数据库上。
distributed transaction 很多数据库都支持，这种策略不是为了避免，而是为了减少
而已。从上面的例子可以看到，一个线路，正常不过2-3次调整足够了。2-3次
distributed transaction, 假定比单数据库慢10倍，相比1000张票，仍然只是3%的额
外开销而已。对于10%的联票，仍然可以达到5-10倍的加速。如果余票比例低，效率更
好。 |
L*****e
发帖数: 8347 | 2 10%的联票发生概率，和你预留所有票的10%给联票数据库是两个概念。联票不是在各个
车次上平均发生的，你怎么预留啊? 留多少北京到上海再从上海转广州的? 又预留多少
北京到株洲，株洲转贵阳的?
10%
【在 b*******g 的大作中提到】
: 我不明白我提的数据库分票策略有啥不行的。你们要质疑也要质疑个明白。
: 如果没有联票，那可以完美分库，这个没有疑问。现在有10%的联票，我把所有票的10%
: 预留到一台数据库上，所有联票的request发到这台机器上。剩下的就可以轻松一个车
: 次一个数据库，实际上用不了那么多，比如弄10台机器组合一下就可以基本达到负载平
: 衡。
: 很显然，每个车次只有两个数据库有票。初值其实是按照历史数据的比例分的。而运行
: 到一个数据库用完了之后，可以重新平衡数据库。比如预估10%，其实是20%，单车次刚
: 开始预分900张，联票预分100张，联票服务器用完了之后，订票发现没票了，就可以看
: 到另外一个数据库还有500张，然后把这500张按4:1重新分配。当低于一定阈值还一边
: 用完了，比如总数100，就可以把所有票合到联票数据库上。
|
b*******g
发帖数: 603 | 3 这有什么难理解的，去年同时候所有的票，每车次百分之多少是联票的形式，你就留多
少给那
台服务器。
【在 L*****e 的大作中提到】
: 10%的联票发生概率，和你预留所有票的10%给联票数据库是两个概念。联票不是在各个
: 车次上平均发生的，你怎么预留啊? 留多少北京到上海再从上海转广州的? 又预留多少
: 北京到株洲，株洲转贵阳的?
:
: 10%
|
w**z
发帖数: 8232 | 4 联票10%是假设？实际情况应该没有那么多联票。如果是联票请求，就只能
distributed transaction, 那些慢点就慢点。保证大多数用户的请求是最重要的。
10%
【在 b*******g 的大作中提到】
: 我不明白我提的数据库分票策略有啥不行的。你们要质疑也要质疑个明白。
: 如果没有联票，那可以完美分库，这个没有疑问。现在有10%的联票，我把所有票的10%
: 预留到一台数据库上，所有联票的request发到这台机器上。剩下的就可以轻松一个车
: 次一个数据库，实际上用不了那么多，比如弄10台机器组合一下就可以基本达到负载平
: 衡。
: 很显然，每个车次只有两个数据库有票。初值其实是按照历史数据的比例分的。而运行
: 到一个数据库用完了之后，可以重新平衡数据库。比如预估10%，其实是20%，单车次刚
: 开始预分900张，联票预分100张，联票服务器用完了之后，订票发现没票了，就可以看
: 到另外一个数据库还有500张，然后把这500张按4:1重新分配。当低于一定阈值还一边
: 用完了，比如总数100，就可以把所有票合到联票数据库上。
|
L*****e
发帖数: 8347 | 5 得，这又扯到我最早就提过的要根据以往数据来制定出票策略的事了，但是迄今为止没
有多少讨论是从现实情况历史出发的。
另外就是，这个10%的联票分票方案一点也不比你不分票的出错率低。因为不是你这10%
的联票都没了，你才去别的分车次数据库调用票的。这10%的联票数据库里任何一个车
次都可能先没票而要去调票，如果联票数据库里有1000个车次，就可能调1000次票。。。
【在 b*******g 的大作中提到】
: 这有什么难理解的，去年同时候所有的票，每车次百分之多少是联票的形式，你就留多
: 少给那
: 台服务器。
|
L*****e
发帖数: 8347 | 6 如果根据以往数据，更靠谱的是中间站预留少数票，大大简化分座方案。。。
anyway，耦合数据分布处理要达到你们说的100%无错原则，不敢说将来是不是一定能做
到，
起码今天的技术做不到。。。
【在 b*******g 的大作中提到】
: 这有什么难理解的，去年同时候所有的票，每车次百分之多少是联票的形式，你就留多
: 少给那
: 台服务器。
|
b*******g
发帖数: 603 | 7 So? 不妨量化，1000个车次，1000张票，单机数据库做要1M transaction。
我的联票数据库出其中的10%，两张票一个transaction, 是50K transaction, 每车次
平衡3次，产生3k个
distributed transaction, DT比较慢，相当于30k transaction的速度。一共加起来是
80K transaction. 其余单车次随便组合不是瓶颈。
所以我从1M 直接加速到80K， 加速了12倍。
10%
。。
【在 L*****e 的大作中提到】
: 得，这又扯到我最早就提过的要根据以往数据来制定出票策略的事了，但是迄今为止没
: 有多少讨论是从现实情况历史出发的。
: 另外就是，这个10%的联票分票方案一点也不比你不分票的出错率低。因为不是你这10%
: 的联票都没了，你才去别的分车次数据库调用票的。这10%的联票数据库里任何一个车
: 次都可能先没票而要去调票，如果联票数据库里有1000个车次，就可能调1000次票。。。
|
b*******g
发帖数: 603 | 8 什么100% 原则？ 总共俩数据库，单线程处理，单车次一边，联票去另一边，还有啥不
合理的问题？
你要觉得我这个分票数据库不工作，好歹来个反例。
【在 L*****e 的大作中提到】
: 如果根据以往数据，更靠谱的是中间站预留少数票，大大简化分座方案。。。
: anyway，耦合数据分布处理要达到你们说的100%无错原则，不敢说将来是不是一定能做
: 到，
: 起码今天的技术做不到。。。
|
L*****e
发帖数: 8347 | 9 我没说你这个速度问题，我是说你弄这个联票分数据库的出错率一点不比你只有分车次
数据库的出错率低。你不信你就用同一组测试数据给两种不同方案跑跑比较比较。。。
【在 b*******g 的大作中提到】
: So? 不妨量化，1000个车次，1000张票，单机数据库做要1M transaction。
: 我的联票数据库出其中的10%，两张票一个transaction, 是50K transaction, 每车次
: 平衡3次，产生3k个
: distributed transaction, DT比较慢，相当于30k transaction的速度。一共加起来是
: 80K transaction. 其余单车次随便组合不是瓶颈。
: 所以我从1M 直接加速到80K， 加速了12倍。
:
: 10%
: 。。
|
L*****e
发帖数: 8347 | 10 你俩前两天说的: 说有票100%有票，说没票100%没票。
换句话说就是，不能有一例对前一个说了没票，后来的买上了。。。
你只要出现一次需要两个数据库互相调票的情况，就算违背这个原则了。你不能向用户
说: 我说没票，保证这个数据库里没票，另一个数据库里有没有我不管，你等我调完票
再说。。。
【在 b*******g 的大作中提到】
: 什么100% 原则？ 总共俩数据库，单线程处理，单车次一边，联票去另一边，还有啥不
: 合理的问题？
: 你要觉得我这个分票数据库不工作，好歹来个反例。
|
|
|
d***a
发帖数: 13752 | 11 考虑有20个区间的线路S。联票服务器最开始有100张票，买掉100张票，都是S1-S19。
最多还可以卖100张S20段的票。这里算有票还是无票呢？这些可卖的票，是放在联票数
据库，还是放在局部数据库呢？
如果你不提碎片最小化和区间最小化倒还好。提了这两个要求，你如何在联票数据库上
，不访问局部数据库，就做到最优化呢？如果对联票不做最优化，那他人的算法早就可
以做到了。
以后高铁形成网络，联票的比例会很大，你也不能假设只有10%的联票。
10%
【在 b*******g 的大作中提到】
: 我不明白我提的数据库分票策略有啥不行的。你们要质疑也要质疑个明白。
: 如果没有联票，那可以完美分库，这个没有疑问。现在有10%的联票，我把所有票的10%
: 预留到一台数据库上，所有联票的request发到这台机器上。剩下的就可以轻松一个车
: 次一个数据库，实际上用不了那么多，比如弄10台机器组合一下就可以基本达到负载平
: 衡。
: 很显然，每个车次只有两个数据库有票。初值其实是按照历史数据的比例分的。而运行
: 到一个数据库用完了之后，可以重新平衡数据库。比如预估10%，其实是20%，单车次刚
: 开始预分900张，联票预分100张，联票服务器用完了之后，订票发现没票了，就可以看
: 到另外一个数据库还有500张，然后把这500张按4:1重新分配。当低于一定阈值还一边
: 用完了，比如总数100，就可以把所有票合到联票数据库上。
|
b*******g
发帖数: 603 | 12 废话，单线程的，如果需要调票，就等在调票上。你有1000个线路，等的是一个线路，
能有啥问题。
你问的问题实在不合理。
【在 L*****e 的大作中提到】
: 你俩前两天说的: 说有票100%有票，说没票100%没票。
: 换句话说就是，不能有一例对前一个说了没票，后来的买上了。。。
: 你只要出现一次需要两个数据库互相调票的情况，就算违背这个原则了。你不能向用户
: 说: 我说没票，保证这个数据库里没票，另一个数据库里有没有我不管，你等我调完票
: 再说。。。
|
L*****e
发帖数: 8347 | 13 你是说联票数据库一旦需要调票，所有联票的请求hold等待？你联票请求的时间队列和
非联票请求的队列分别对待？如果等同对待，联票请求等待必然造成其它非联票请求等
待。如果分别排队，算不算一种“不公平”啊？买联票的低买非联票的一等？买联票的
明明早排队却要等调票结果，而他需要的其中一张票被比他后排队的买非联票的买走了
。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 废话，单线程的，如果需要调票，就等在调票上。你有1000个线路，等的是一个线路，
: 能有啥问题。
: 你问的问题实在不合理。
|
L*****e
发帖数: 8347 | 14 本来以为你只是把买联票的和买非联票的分到不同的数据库上去处理，他们起码还是排
的同一个队。。。你现在是有让他们分别排两队的节奏啊。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 废话，单线程的，如果需要调票，就等在调票上。你有1000个线路，等的是一个线路，
: 能有啥问题。
: 你问的问题实在不合理。
|
b*******g
发帖数: 603 | 15 是排的同一个队呀。只不过没票了，不是挨个数据库查。而是调整余票直接出。
【在 L*****e 的大作中提到】
: 本来以为你只是把买联票的和买非联票的分到不同的数据库上去处理，他们起码还是排
: 的同一个队。。。你现在是有让他们分别排两队的节奏啊。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t
发帖数: 22014 | 16 不是说时间优先吗？低优先的单票到了 A 出票了，高优先联程本机无票，到 A 一查没了
【在 b*******g 的大作中提到】
: 是排的同一个队呀。只不过没票了，不是挨个数据库查。而是调整余票直接出。
|
b*******g
发帖数: 603 | 17 这个从技术上说，就是保证90%的最优分配，提高12倍速度。3分钟延迟变成15秒，这样
就可以做成简单的在线应用。
我从来没说过能做到实时最优分配，太监也做不到不是。所以，接下来就是看那些
tradeoff可以接受了。现实中线路上本来就有很多预留票。这个无非说我预留10%的票
给联程，而且那样连distributed transaction都不用了。
【在 d***a 的大作中提到】
: 考虑有20个区间的线路S。联票服务器最开始有100张票，买掉100张票，都是S1-S19。
: 最多还可以卖100张S20段的票。这里算有票还是无票呢？这些可卖的票，是放在联票数
: 据库，还是放在局部数据库呢？
: 如果你不提碎片最小化和区间最小化倒还好。提了这两个要求，你如何在联票数据库上
: ，不访问局部数据库，就做到最优化呢？如果对联票不做最优化，那他人的算法早就可
: 以做到了。
: 以后高铁形成网络，联票的比例会很大，你也不能假设只有10%的联票。
:
: 10%
|
b*******g
发帖数: 603 | 18 每线路单线程，一个单子处理完再处理下一个。有问题吗？你直接能出就出，不能出调
票再出。
没了
【在 n*****t 的大作中提到】
: 不是说时间优先吗？低优先的单票到了 A 出票了，高优先联程本机无票，到 A 一查没了
|
n*****t
发帖数: 22014 | 19 订单 1 联程送 B 处理，订单 2 单票送 A，B 发现缺一张到 A 调票，订单 2 已经处
理完了
出。
【在 b*******g 的大作中提到】
: 每线路单线程，一个单子处理完再处理下一个。有问题吗？你直接能出就出，不能出调
: 票再出。
:
: 没了
|
b*******g
发帖数: 603 | 20 你是不懂数据库怎么工作的吗？一条线路，两个数据库各一条记录，一个调票就是调整
这两条纪录就行，当然实际上是每边20条。需要等待的只是锁在这两条纪录上的单子而
已。
【在 L*****e 的大作中提到】
: 你是说联票数据库一旦需要调票，所有联票的请求hold等待？你联票请求的时间队列和
: 非联票请求的队列分别对待？如果等同对待，联票请求等待必然造成其它非联票请求等
: 待。如果分别排队，算不算一种“不公平”啊？买联票的低买非联票的一等？买联票的
: 明明早排队却要等调票结果，而他需要的其中一张票被比他后排队的买非联票的买走了
: 。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
|
|
L*****e
发帖数: 8347 | 21 你调整余票需要在你的联票数据库和某车次数据库之间进行吧？调整余票的时候，你所
有的比当前等候调整结果的请求排队时间晚的请求都得停止等候吧？
如果有500个车次出现一次这种调整余票，就得这样等500次。
不单是你上面的计算时间要调整，那些在调整余票时，时间戳比那个等待的联票晚，但
又已经被分布到3000个单车次数据库上处理的请求怎么办？怎么通知它们停止？怎么
rollback？
老霸，你该休息休息了，大脑缺氧想问题是糊涂的。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 是排的同一个队呀。只不过没票了，不是挨个数据库查。而是调整余票直接出。
|
b*******g
发帖数: 603 | 22 我老早就说了分布式算法没有绝对的公平。这种级别的公平本来就是不管的。但是震荡
就不会。换座之类的问题统统没有。
【在 n*****t 的大作中提到】
: 订单 1 联程送 B 处理，订单 2 单票送 A，B 发现缺一张到 A 调票，订单 2 已经处
: 理完了
:
: 出。
|
n*****t
发帖数: 22014 | 23 什么？我只不过把你给老魏的要求稍微演化了一下，就这么宽于律己了？
【在 b*******g 的大作中提到】
: 我老早就说了分布式算法没有绝对的公平。这种级别的公平本来就是不管的。但是震荡
: 就不会。换座之类的问题统统没有。
|
b*******g
发帖数: 603 | 24 我对你缺乏数据库常识感到震惊，数据库并发本来就是一锁纪录，等着锁那些纪录的请
求都排队。
1000条线路，有的是能够继续出票的请求。不会说一个 hold up, 所有request都等着。
【在 L*****e 的大作中提到】
: 你调整余票需要在你的联票数据库和某车次数据库之间进行吧？调整余票的时候，你所
: 有的比当前等候调整结果的请求排队时间晚的请求都得停止等候吧？
: 如果有500个车次出现一次这种调整余票，就得这样等500次。
: 不单是你上面的计算时间要调整，那些在调整余票时，时间戳比那个等待的联票晚，但
: 又已经被分布到3000个单车次数据库上处理的请求怎么办？怎么通知它们停止？怎么
: rollback？
: 老霸，你该休息休息了，大脑缺氧想问题是糊涂的。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
n*****t
发帖数: 22014 | 25 热门车次呢？
btw，数据库常识不提也罢
着。
【在 b*******g 的大作中提到】
: 我对你缺乏数据库常识感到震惊，数据库并发本来就是一锁纪录，等着锁那些纪录的请
: 求都排队。
: 1000条线路，有的是能够继续出票的请求。不会说一个 hold up, 所有request都等着。
|
L*****e
发帖数: 8347 | 26 不是只有这两个数据库的一条row受影响啊，联票请求排第二的在等候，如果它也刚好
要从另外一个单车次数据库调票，那么那个单车次数据库上的请求也受影响，依次下去
。。。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 你是不懂数据库怎么工作的吗？一条线路，两个数据库各一条记录，一个调票就是调整
: 这两条纪录就行，当然实际上是每边20条。需要等待的只是锁在这两条纪录上的单子而
: 已。
|
b*******g
发帖数: 603 | 27 你这就是给自己弄一个完成不了的任务。你前段来两个一样的request, 一个早到web
server1ms, 但web server发给你的分票服务器网络延迟比另一个多2ms, 导致后处理，
你公平了吗？
扯蛋不是这样的。
【在 n*****t 的大作中提到】
: 什么？我只不过把你给老魏的要求稍微演化了一下，就这么宽于律己了？
|
L*****e
发帖数: 8347 | 28 先不说你都无法做到完全同时在两个数据库上锁一条row，也不说你判断需要调票时，
时间戳晚的有冲突非联票请求都可能已经完成了。只说我上面已经给你解释了，这个冲
突不是等待调票的第一个联票请求和非联票请求才有，排第二第三的联票请求和相应的
单票请求都可能有冲突，你都锁？
btw，我基本上没啥数据库知识，也就是在坛子上看大牛们扯，就照猫画虎，一知半解
地胡诌，别介意哈。。。
着。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 我对你缺乏数据库常识感到震惊，数据库并发本来就是一锁纪录，等着锁那些纪录的请
: 求都排队。
: 1000条线路，有的是能够继续出票的请求。不会说一个 hold up, 所有request都等着。
|
b*******g
发帖数: 603 | 29 你能不能算一算。让你3000次调整的时候联票数据库完全停止运转可以了吧？那不就是
3万次transaction的时间。
加上联票本身5万次transaction时间，8万次。
【在 L*****e 的大作中提到】
: 不是只有这两个数据库的一条row受影响啊，联票请求排第二的在等候，如果它也刚好
: 要从另外一个单车次数据库调票，那么那个单车次数据库上的请求也受影响，依次下去
: 。。。
:
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
b*******g
发帖数: 603 | 30 你说的非联票要求先完成了可能呀，我早就说了达不到完全的公平。但是基本上前一秒
的比后一秒的先出就不会有问题。
严格的公平本来就不可能，除非整个系统就一个机器一个线程，不服你来公平一下这个。
前段来两个一样的request, 一个早到web
server1ms, 但web server发给你的分票服务器网络延迟比另一个多2ms, 导致后处理，
你公平了吗？
扯蛋不是这样的。
【在 L*****e 的大作中提到】
: 先不说你都无法做到完全同时在两个数据库上锁一条row，也不说你判断需要调票时，
: 时间戳晚的有冲突非联票请求都可能已经完成了。只说我上面已经给你解释了，这个冲
: 突不是等待调票的第一个联票请求和非联票请求才有，排第二第三的联票请求和相应的
: 单票请求都可能有冲突，你都锁？
: btw，我基本上没啥数据库知识，也就是在坛子上看大牛们扯，就照猫画虎，一知半解
: 地胡诌，别介意哈。。。
:
: 着。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
|
|
L*****e
发帖数: 8347 | 31 靠！这个说有票100%有票，说没票100%没票的要求不是你给老魏提的要求么？怎么成我
扯淡了？哦，还忘了问你这个分联票数据库方案怎么做实时座位优化呢？这也是你提出
来的吧？还是我记错了？如果是我记错了，就当我扯淡吧？
个。
★ 发自iPhone App: ChineseWeb 8.2.2
【在 b*******g 的大作中提到】
: 你说的非联票要求先完成了可能呀，我早就说了达不到完全的公平。但是基本上前一秒
: 的比后一秒的先出就不会有问题。
: 严格的公平本来就不可能，除非整个系统就一个机器一个线程，不服你来公平一下这个。
: 前段来两个一样的request, 一个早到web
: server1ms, 但web server发给你的分票服务器网络延迟比另一个多2ms, 导致后处理，
: 你公平了吗？
: 扯蛋不是这样的。
|
b*******g
发帖数: 603 | 32 这个topic本来我就是谈不达到全局最优怎么可以降低90%的延迟。你非要全局最优毫无
疑问做不到实时呀。
啥东西都是先说清楚了前提。而不是像太监那样动不动就宇宙第一，到头来八十老妪抗
大包。
【在 L*****e 的大作中提到】
: 靠！这个说有票100%有票，说没票100%没票的要求不是你给老魏提的要求么？怎么成我
: 扯淡了？哦，还忘了问你这个分联票数据库方案怎么做实时座位优化呢？这也是你提出
: 来的吧？还是我记错了？如果是我记错了，就当我扯淡吧？
:
: 个。
: ★ 发自iPhone App: ChineseWeb 8.2.2
|
g****t
发帖数: 31659 | 33 按去年的情况留票，可能会落到最差情况的。因为去年和今年的人流在某些线路上完全
有可能差别极大。
【在 b*******g 的大作中提到】
: 这有什么难理解的，去年同时候所有的票，每车次百分之多少是联票的形式，你就留多
: 少给那
: 台服务器。
|
g****t
发帖数: 31659 | 34 问题是你降低不了90%的延迟阿。除非你假设今年联票的发生情况和去年情况一样。但
这个显然是不对的。GDP每年还增长8%呢。
按你的分票方案，结果可能会很差。正确的办法是业
务人员开会定下来考虑哪个中间站怎么弄好。
全局优化也好，90%的延迟也好。都是没道理的。
【在 b*******g 的大作中提到】
: 这个topic本来我就是谈不达到全局最优怎么可以降低90%的延迟。你非要全局最优毫无
: 疑问做不到实时呀。
: 啥东西都是先说清楚了前提。而不是像太监那样动不动就宇宙第一，到头来八十老妪抗
: 大包。
|
b*******g
发帖数: 603 | 35 你都没弄懂我说啥，历史数据就是个初值而已，又不是不能调整。
【在 g****t 的大作中提到】
: 问题是你降低不了90%的延迟阿。除非你假设今年联票的发生情况和去年情况一样。但
: 这个显然是不对的。GDP每年还增长8%呢。
: 按你的分票方案，结果可能会很差。正确的办法是业
: 务人员开会定下来考虑哪个中间站怎么弄好。
: 全局优化也好，90%的延迟也好。都是没道理的。
|
g****t
发帖数: 31659 | 36 那你这90%延迟提高怎么算出来的？
你预留在服务器上的分布如果和实际情况不match,你就得不到90%这个数字吧。
【在 b*******g 的大作中提到】
: 你都没弄懂我说啥，历史数据就是个初值而已，又不是不能调整。
|
