n**x
发帖数: 606 | 1 还是那句话，我谁的臭脚也不捧，只是看到这里没有一个人愿意写几行代码测一下。
我提供数据，大家参考一下。 所以不要再说谁捧谁的臭脚了啊。
问题：
古德霸的反例但凡计算机出身的都看得懂。说白了就是在multi-threading的环境下的
顺序问题。
模拟场景：
- 我的机器12 core,我就听大家的用12个线程。
- 每个线程处理1M请求,total 12M的请求平均分布在12个线程上。
- 1000趟车，每趟20个区段，每个区段1000张票。
算法采用老魏的算法，锁区段，不锁线路。 （所谓锁区段也就是interlocked加减）
测试结果（都是平均值）
- 成功出票2M
- 无票可出10M （看完再下结论）
- 抢票过程如果失败Re-Try一次,结果又大约10个请求Re-try成功。
- 全部请求走完后，把所有失败的请求在处理一边，还是没有票。(这个很重要)
结论:
- 古德霸的a->b的反例属于re-try可以成功的例子。 如果retry不成功，那么基本就没
有满足条件的票了。
后续：
性能问题我的场景还不够真实，等我测完后在update. |
g*****g
发帖数: 34805 | 2 你使用了我abc是票贩子刷，占用了99.99%单子的反例没有？没有继续测。
【在 n**x 的大作中提到】
: 还是那句话，我谁的臭脚也不捧，只是看到这里没有一个人愿意写几行代码测一下。
: 我提供数据，大家参考一下。 所以不要再说谁捧谁的臭脚了啊。
: 问题：
: 古德霸的反例但凡计算机出身的都看得懂。说白了就是在multi-threading的环境下的
: 顺序问题。
: 模拟场景：
: - 我的机器12 core,我就听大家的用12个线程。
: - 每个线程处理1M请求,total 12M的请求平均分布在12个线程上。
: - 1000趟车，每趟20个区段，每个区段1000张票。
: 算法采用老魏的算法，锁区段，不锁线路。 （所谓锁区段也就是interlocked加减）
|
b*******s
发帖数: 5216 | |
n**x
发帖数: 606 | 4 没看懂。啥意思。
我的测试方法是：每个请求包含三张联程票。每张票区段1到20不等。12M个请求每个都
这样。
【在 g*****g 的大作中提到】
: 你使用了我abc是票贩子刷，占用了99.99%单子的反例没有？没有继续测。
|
S*A
发帖数: 7142 | 5 赞，有空可以试试那个补丁的算法，应该就不会有那 10 票漏掉了。 |
g*****g
发帖数: 34805 | 6 100张AB，10张BC， 99.99%的订单是ABC, 0.01%是AB, 刷刷看要出错多少次才能把AB的
票都卖掉。
所谓测试，就是要能处理所有的case.
【在 n**x 的大作中提到】
: 没看懂。啥意思。
: 我的测试方法是：每个请求包含三张联程票。每张票区段1到20不等。12M个请求每个都
: 这样。
|
g*****g
发帖数: 34805 | 7 你那个补丁，一仍然不能保证公平性。二大大加大了每次操作的开销。几乎是加倍，我
没乱说吧。
【在 S*A 的大作中提到】
: 赞，有空可以试试那个补丁的算法，应该就不会有那 10 票漏掉了。
|
n**x
发帖数: 606 | 8 我都一时不知道怎么简化我这个12M的模型。呵呵，明天吧。
【在 g*****g 的大作中提到】
: 100张AB，10张BC， 99.99%的订单是ABC, 0.01%是AB, 刷刷看要出错多少次才能把AB的
: 票都卖掉。
: 所谓测试，就是要能处理所有的case.
|
n**x
发帖数: 606 | 9 几百万张票几个农民工买不到票，问题我看不大啊。:)
【在 g*****g 的大作中提到】
: 你那个补丁，一仍然不能保证公平性。二大大加大了每次操作的开销。几乎是加倍，我
: 没乱说吧。
|
S*A
发帖数: 7142 | 10 公平性是比较好的保证了，如果有票没有出，是不会停止循环的。
而且落到同一 core 的是有严格先后次序的。
如果是不同 core之间，其实没法严格 measure 并发的时候的次序。
所以 memory update 次序是最接近的了。
开销肯定不是加倍，用这个实验的数据测量应该是没有很大区别。
不信可以试试，看看是不是速度减半，我打赌肯定不是。
好在这个测试我们是可以自己做的，不用牛B网卡和机器。
补充一下，不是加倍是因为那个 automic update 和程序其他的
开销来说是完全忽略不记的。到了机器码这一层我还是比较有信心
的。好在这个实验可以验证，补丁和没有补丁的性能。
【在 g*****g 的大作中提到】
: 你那个补丁，一仍然不能保证公平性。二大大加大了每次操作的开销。几乎是加倍，我
: 没乱说吧。
|
|
|
S*A
发帖数: 7142 | 11 公平性是，不是有几个民工有票买不到，
而是3 张票 5 个民工，是不是严格最先
订的三个买到。仅仅是次序问题。
有票买不到在补丁程序里已经改正了。
【在 n**x 的大作中提到】
: 几百万张票几个农民工买不到票，问题我看不大啊。:)
|
S*A
发帖数: 7142 | 12 我还想补充的是，如果你的网卡的中断处理是分在不同 core 上的，
一般APIC 都是这么处理的，那么你在串行处理的时候同样不能严格
保证先后次序的。通常的 Lock 只是保证不重入，不能保证 retry 的
先后次序。所以串行化有同样的次序不严格保证问题。除非单 core
单网卡。那样你用数据库就会有流量不够大的问题。 |
g*****g
发帖数: 34805 | 13 你是想说decrement的cost可以忽略不计？你这不是打太监的脸吗？它牛逼哄哄测了半
天的东西，数字show off了半天，原来是个可以忽略不计的东西，那还火力全开光测它
干嘛。
【在 S*A 的大作中提到】
: 公平性是比较好的保证了，如果有票没有出，是不会停止循环的。
: 而且落到同一 core 的是有严格先后次序的。
: 如果是不同 core之间，其实没法严格 measure 并发的时候的次序。
: 所以 memory update 次序是最接近的了。
: 开销肯定不是加倍，用这个实验的数据测量应该是没有很大区别。
: 不信可以试试，看看是不是速度减半，我打赌肯定不是。
: 好在这个测试我们是可以自己做的，不用牛B网卡和机器。
: 补充一下，不是加倍是因为那个 automic update 和程序其他的
: 开销来说是完全忽略不记的。到了机器码这一层我还是比较有信心
: 的。好在这个实验可以验证，补丁和没有补丁的性能。
|
g*****g
发帖数: 34805 | 14 反正异步处理，有timestamp, 单线程又如何？
【在 S*A 的大作中提到】
: 我还想补充的是，如果你的网卡的中断处理是分在不同 core 上的，
: 一般APIC 都是这么处理的，那么你在串行处理的时候同样不能严格
: 保证先后次序的。通常的 Lock 只是保证不重入，不能保证 retry 的
: 先后次序。所以串行化有同样的次序不严格保证问题。除非单 core
: 单网卡。那样你用数据库就会有流量不够大的问题。
|
g*****g
发帖数: 34805 | 15 再说一遍，这也不是什么牛逼策略。我老人家老早就提过出票策略，票10等分分到10台
服务器上，单子按始发站分多队列。当某种票低于某个threshold, 就distributed
transaction合并票继续处理。在大部分的时间里，多个数据库服务器都可以完全不相
干。太监这个单机策略实在太小儿科了。
【在 S*A 的大作中提到】
: 公平性是比较好的保证了，如果有票没有出，是不会停止循环的。
: 而且落到同一 core 的是有严格先后次序的。
: 如果是不同 core之间，其实没法严格 measure 并发的时候的次序。
: 所以 memory update 次序是最接近的了。
: 开销肯定不是加倍，用这个实验的数据测量应该是没有很大区别。
: 不信可以试试，看看是不是速度减半，我打赌肯定不是。
: 好在这个测试我们是可以自己做的，不用牛B网卡和机器。
: 补充一下，不是加倍是因为那个 automic update 和程序其他的
: 开销来说是完全忽略不记的。到了机器码这一层我还是比较有信心
: 的。好在这个实验可以验证，补丁和没有补丁的性能。
|
b*******s
发帖数: 5216 | 16 10台服务器抢票而已，而且更容易由于状态不一致导致不公平，比如某台特别慢
【在 g*****g 的大作中提到】
: 再说一遍，这也不是什么牛逼策略。我老人家老早就提过出票策略，票10等分分到10台
: 服务器上，单子按始发站分多队列。当某种票低于某个threshold, 就distributed
: transaction合并票继续处理。在大部分的时间里，多个数据库服务器都可以完全不相
: 干。太监这个单机策略实在太小儿科了。
|
b*******s
发帖数: 5216 | 17 还是老问题了，严格按timestamp来就是阻塞，如果不严格，还不如不用，按进入顺序
排队
【在 g*****g 的大作中提到】
: 反正异步处理，有timestamp, 单线程又如何？
|
g*****g
发帖数: 34805 | 18 我同样是只要有票就可以并行，最后特殊处理。
【在 b*******s 的大作中提到】
: 还是老问题了，严格按timestamp来就是阻塞，如果不严格，还不如不用，按进入顺序
: 排队
|
g*****g
发帖数: 34805 | 19 不公平个头呀，有票的时候一直出票，到最后没票了就合票。
【在 b*******s 的大作中提到】
: 10台服务器抢票而已，而且更容易由于状态不一致导致不公平，比如某台特别慢
|
b*******s
发帖数: 5216 | 20 10台机器跑单线程，我看不出相对一台机器10个核跑10个线程的优越性
【在 g*****g 的大作中提到】
: 我同样是只要有票就可以并行，最后特殊处理。
|
|
|
g*****g
发帖数: 34805 | 21 为什么要跑单线程？
【在 b*******s 的大作中提到】
: 10台机器跑单线程，我看不出相对一台机器10个核跑10个线程的优越性
|
b*******s
发帖数: 5216 | 22 我就给个例子吧，某台机器分配到1000个请求
结果这机器坏了
如果要公平，你就要先判断这1000个里面那些已经处理了
这个是必要的，避免回滚
这个不容易，因为机器状态是不正常的，不能保证从那台机器拿，简单方案是在数据库
里要存购票请求有关的信息，需要不少查询
然后把没有处理的要放到比他们迟的另外9台的请求前面，这个简单吗？我看不一定
单机要坏一起坏，反而简单了
【在 g*****g 的大作中提到】
: 不公平个头呀，有票的时候一直出票，到最后没票了就合票。
|
b*******s
发帖数: 5216 | 23 好，这个算我理解错，你如果不进行同步，怎么解决超售？
【在 g*****g 的大作中提到】
: 为什么要跑单线程？
|
d***a
发帖数: 13752 | |
g*****g
发帖数: 34805 | 25 别忘了你不要求绝对公平我也不用。票都分好了，卖到卖不下去再合票。
【在 b*******s 的大作中提到】
: 好，这个算我理解错，你如果不进行同步，怎么解决超售？
|
b*******s
发帖数: 5216 | 26 先不说实时性，你准备怎么合票？比如决定给谁，决定不给谁，短程还是长途优先，没
拿到的怎么重新排队？还有在什么时候合票，哪台机器来合票，合票时是不是阻塞所有
新请求
【在 g*****g 的大作中提到】
: 别忘了你不要求绝对公平我也不用。票都分好了，卖到卖不下去再合票。
|
S*A
发帖数: 7142 | 27 我一直说 IO 是比较可能的瓶颈。这个内存的读写还是很快的。
【在 g*****g 的大作中提到】
: 你是想说decrement的cost可以忽略不计？你这不是打太监的脸吗？它牛逼哄哄测了半
: 天的东西，数字show off了半天，原来是个可以忽略不计的东西，那还火力全开光测它
: 干嘛。
|
S*A
发帖数: 7142 | 28 你的 time stamp 是如何来的？read_tsc?
【在 g*****g 的大作中提到】
: 反正异步处理，有timestamp, 单线程又如何？
|
g*****g
发帖数: 34805 | 29 订单写入Cassandra key是 time based uuid。应用服务器集群产生的。
【在 S*A 的大作中提到】
: 你的 time stamp 是如何来的？read_tsc?
|
g*****g
发帖数: 34805 | 30 哈哈，你说的不错，单机IO 5m 我还没见过。
【在 S*A 的大作中提到】
: 我一直说 IO 是比较可能的瓶颈。这个内存的读写还是很快的。
|
|
|
h*****a
发帖数: 1718 | 31 赞
【在 n**x 的大作中提到】
: 还是那句话，我谁的臭脚也不捧，只是看到这里没有一个人愿意写几行代码测一下。
: 我提供数据，大家参考一下。 所以不要再说谁捧谁的臭脚了啊。
: 问题：
: 古德霸的反例但凡计算机出身的都看得懂。说白了就是在multi-threading的环境下的
: 顺序问题。
: 模拟场景：
: - 我的机器12 core,我就听大家的用12个线程。
: - 每个线程处理1M请求,total 12M的请求平均分布在12个线程上。
: - 1000趟车，每趟20个区段，每个区段1000张票。
: 算法采用老魏的算法，锁区段，不锁线路。 （所谓锁区段也就是interlocked加减）
|
T********i
发帖数: 2416 | 32 呵呵。俺现在改用单线程了。性能提高到50M。
还是简单好，俺喜欢简单。
【在 h*****a 的大作中提到】
: 赞
|
