g*****g
发帖数: 34805 | 1 魏公公吹嘘了几个月的紧耦合全国一盘棋，到头来只敢实现单线路，20段，直接把难度
降低了1000倍。
太监的德性就是吹起来是宇宙最强。干起来就是没卵蛋。
丢人了就是两招，恐吓要告诉你老板，刷版混淆视听。大家洗洗睡吧。 |
T********i
发帖数: 2416 | 2 我说过，双程联票，每线路20段，计算时间增加一倍。linear scale。以此类推。
这个问题你搞不明白，你就不要活了。这明显是智商问题。
我觉得你老板有权知道你智商不够用。尤其是你的智商对其他人有负面影响的。
【在 g*****g 的大作中提到】
: 魏公公吹嘘了几个月的紧耦合全国一盘棋，到头来只敢实现单线路，20段，直接把难度
: 降低了1000倍。
: 太监的德性就是吹起来是宇宙最强。干起来就是没卵蛋。
: 丢人了就是两招，恐吓要告诉你老板，刷版混淆视听。大家洗洗睡吧。
|
z****e
发帖数: 54598 | 3 老魏那这样
您给估算一下最终实现全国车票上线要多少台机器吧
【在 T********i 的大作中提到】
: 我说过，双程联票，每线路20段，计算时间增加一倍。linear scale。以此类推。
: 这个问题你搞不明白，你就不要活了。这明显是智商问题。
: 我觉得你老板有权知道你智商不够用。尤其是你的智商对其他人有负面影响的。
|
L*****e
发帖数: 8347 | 4 魏老，是说1000个线路，每线路20段，可以处理5m/秒请求，然后双程联票，时间加倍
，5m请求需要2秒。。。还是说一条线路20段，可以处理5m/秒，1000线路每线路20段双
程联票需要scale到2000秒?
望明确，这个差别很大。。。
【在 T********i 的大作中提到】
: 我说过，双程联票，每线路20段，计算时间增加一倍。linear scale。以此类推。
: 这个问题你搞不明白，你就不要活了。这明显是智商问题。
: 我觉得你老板有权知道你智商不够用。尤其是你的智商对其他人有负面影响的。
|
T********i
发帖数: 2416 | 5 这个只和联程总区段数量有关。和线路数量无关。
不管多少条联程，如果票内总区段数量是20，那就是5M/s。40就是2.5M/s。以此类推。
区段数量是中间停靠站台数量 + 1。不包起点和终点/
另外，你买一趟车票，中途停靠40次中间站台，你会坐么？
【在 L*****e 的大作中提到】
: 魏老，是说1000个线路，每线路20段，可以处理5m/秒请求，然后双程联票，时间加倍
: ，5m请求需要2秒。。。还是说一条线路20段，可以处理5m/秒，1000线路每线路20段双
: 程联票需要scale到2000秒?
: 望明确，这个差别很大。。。
|
g*****g
发帖数: 34805 | 6 全国可不只是两条线，1000条线N^2就100万机器了。就不提数据耦合你不分票的话，哪
能两条线路完全没关系。就我举的例子，北京到上海A，上海出发是1-100，A1-A100都
是互相竞争A段票的。
公公当时拍胸脯牛逼单机把宇宙的票都出了，来真的就要这么夸张的堆机器。实在是极
品。
【在 z****e 的大作中提到】
: 老魏那这样
: 您给估算一下最终实现全国车票上线要多少台机器吧
|
n*****t
发帖数: 22014 | 7 假设只能转一次车，1000 x 1000 那就是构建 1M 条虚拟车次。每个车次分 8 个等级
，查票只需要计数剩余座位数，总给也就 16M 的 memory db
【在 g*****g 的大作中提到】
: 全国可不只是两条线，1000条线N^2就100万机器了。就不提数据耦合你不分票的话，哪
: 能两条线路完全没关系。就我举的例子，北京到上海A，上海出发是1-100，A1-A100都
: 是互相竞争A段票的。
: 公公当时拍胸脯牛逼单机把宇宙的票都出了，来真的就要这么夸张的堆机器。实在是极
: 品。
|
g*****g
发帖数: 34805 | 8 公公已经缩卵了，你不服气你上。需求我写得挺清楚。
【在 n*****t 的大作中提到】
: 假设只能转一次车，1000 x 1000 那就是构建 1M 条虚拟车次。每个车次分 8 个等级
: ，查票只需要计数剩余座位数，总给也就 16M 的 memory db
|
|
n*****t
发帖数: 22014 | 9 我的设计已经写出了，你先看看，别几把喷。
我先说好了，我只负责做中心节点，能 process 1M request 就完事。大宝剑我没功夫
，那是你们的活。
【在 g*****g 的大作中提到】
: 公公已经缩卵了，你不服气你上。需求我写得挺清楚。
|
c****3
发帖数: 10787 | 10 其实每个城市做一个数据库就行了。北京-济南-南京-上海，做（北京，济南，南京，
上海）四个数据库。每个城市数据库只有直达城市或中转下一站城市的票。所以北京数
据库里只有北京到上海直达票，和北京到济南的票。济南数据库因为没有直达上海，只
有到南京的票。
如果购买北京到上海的票，先算路径。有两个，一种是直达，一种是一种经过济南，南
京中转。如果直达没有票。中转的，济南，南京，一个一个数据库锁过去，济南找到南
京的票，南京找到上海的票，如果某个数据库没有票，就回退。这样就变成分布式了，
负载也分开了。 |
|
|
n*****t
发帖数: 22014 | 11 这个也不是不可以，北京经武汉转车到贵阳，你先锁一张北京局的，然后申请武汉的票
，如果失败就放弃前一张
【在 c****3 的大作中提到】
: 其实每个城市做一个数据库就行了。北京-济南-南京-上海，做（北京，济南，南京，
: 上海）四个数据库。每个城市数据库只有直达城市或中转下一站城市的票。所以北京数
: 据库里只有北京到上海直达票，和北京到济南的票。济南数据库因为没有直达上海，只
: 有到南京的票。
: 如果购买北京到上海的票，先算路径。有两个，一种是直达，一种是一种经过济南，南
: 京中转。如果直达没有票。中转的，济南，南京，一个一个数据库锁过去，济南找到南
: 京的票，南京找到上海的票，如果某个数据库没有票，就回退。这样就变成分布式了，
: 负载也分开了。
|
g*****g
发帖数: 34805 | 12 全国一盘棋的强耦合变成了一盘散沙。无敌单机出全宇宙的票，一下子尿遁成单线路。
极品就是极品。 |
c****3
发帖数: 10787 | 13 是啊，中转地，先算路径。然后只要按照车次行走方向，顺序一段一段锁相应城市的数
据库就行了。有一个城市数据库里没有到下一个城市的票，就回退。这种最简单了，而
且负载分到不同数据库里。
【在 n*****t 的大作中提到】
: 这个也不是不可以，北京经武汉转车到贵阳，你先锁一张北京局的，然后申请武汉的票
: ，如果失败就放弃前一张
|
n*****t
发帖数: 22014 | 14 你丫特么能不能少喷几句，requirements 有分歧大家做中协调，无论如何 5M 是个狠
牛叉的指标，即使单线路也不容易
【在 g*****g 的大作中提到】
: 全国一盘棋的强耦合变成了一盘散沙。无敌单机出全宇宙的票，一下子尿遁成单线路。
: 极品就是极品。
|
g*****g
发帖数: 34805 | 15 requirement就是12306，我已经给他简化了。
【在 n*****t 的大作中提到】
: 你丫特么能不能少喷几句，requirements 有分歧大家做中协调，无论如何 5M 是个狠
: 牛叉的指标，即使单线路也不容易
|
n*****t
发帖数: 22014 | 16 12306 没有每秒 5M 出票的需求，这么说下去不是又开始扯淡了吗？
现在讨论的是特定条件下系统的性能，以此论证方案的可行性，所以才要加限定条件
【在 g*****g 的大作中提到】
: requirement就是12306，我已经给他简化了。
|
g*****g
发帖数: 34805 | 17 12306怎么做有很多种办法，但5M强耦合实时是公公自己出来叫板的。做不出来他就是
个太监。
不从这里滚就是极品。
【在 n*****t 的大作中提到】
: 12306 没有每秒 5M 出票的需求，这么说下去不是又开始扯淡了吗？
: 现在讨论的是特定条件下系统的性能，以此论证方案的可行性，所以才要加限定条件
|
n*****t
发帖数: 22014 | 18 原帖有不同理解，你按你的方式，他有他的定义
【在 g*****g 的大作中提到】
: 12306怎么做有很多种办法，但5M强耦合实时是公公自己出来叫板的。做不出来他就是
: 个太监。
: 不从这里滚就是极品。
|
g*****g
发帖数: 34805 | 19 不管怎么理解，全国一盘棋有联票都是他提的，这些要求不敢满足还有啥说的。
【在 n*****t 的大作中提到】
: 原帖有不同理解，你按你的方式，他有他的定义
|
L*****e
发帖数: 8347 | 20 我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
因为是单线程
1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
个查询时间和更新时间只受所请求的路段中的站数影响。。。
2. 一个请求处理完成后，再处理下一个请求。。。
所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
线路多只是内存数据库更大，一定程度会加长查询时间。。。
【在 g*****g 的大作中提到】
: 全国可不只是两条线，1000条线N^2就100万机器了。就不提数据耦合你不分票的话，哪
: 能两条线路完全没关系。就我举的例子，北京到上海A，上海出发是1-100，A1-A100都
: 是互相竞争A段票的。
: 公公当时拍胸脯牛逼单机把宇宙的票都出了，来真的就要这么夸张的堆机器。实在是极
: 品。
|
|
|
n*****t
发帖数: 22014 | 21 我觉得单线程够呛，单节点多进程收包，查询就直接 read，锁票先 lock 再 write，
确认出票不用锁。enqueue/dequeue 开销太大
【在 L*****e 的大作中提到】
: 我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
: 因为是单线程
: 1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
: 查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
: 个查询时间和更新时间只受所请求的路段中的站数影响。。。
: 2. 一个请求处理完成后，再处理下一个请求。。。
: 所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
: 秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
: 从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
: 线路多只是内存数据库更大，一定程度会加长查询时间。。。
|
L*****e
发帖数: 8347 | 22 一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。
【在 n*****t 的大作中提到】
: 我觉得单线程够呛，单节点多进程收包，查询就直接 read，锁票先 lock 再 write，
: 确认出票不用锁。enqueue/dequeue 开销太大
|
g*****g
发帖数: 34805 | 23 不是1/5毫秒，是1/5微妙。
5m
【在 L*****e 的大作中提到】
: 我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
: 因为是单线程
: 1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
: 查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
: 个查询时间和更新时间只受所请求的路段中的站数影响。。。
: 2. 一个请求处理完成后，再处理下一个请求。。。
: 所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
: 秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
: 从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
: 线路多只是内存数据库更大，一定程度会加长查询时间。。。
|
L*****e
发帖数: 8347 | 24 我表达的不对，我是想说5百万分之一。。。
【在 g*****g 的大作中提到】
: 不是1/5毫秒，是1/5微妙。
:
: 5m
|
n*****t
发帖数: 22014 | 25 这个要实测一下。仔细想了一下，queue 其实还好，现在 memory 不值钱
【在 L*****e 的大作中提到】
: 一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
: enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。
|
n*****t
发帖数: 22014 | 26 不对，queue head/tail 也是要上锁才能写的 。。。
【在 n*****t 的大作中提到】
: 这个要实测一下。仔细想了一下，queue 其实还好，现在 memory 不值钱
|
T********i
发帖数: 2416 | 27 我都说了，queue开销基本为0。
信不信由你。
【在 n*****t 的大作中提到】
: 不对，queue head/tail 也是要上锁才能写的 。。。
|
g*****g
发帖数: 34805 | 28 我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。
【在 L*****e 的大作中提到】
: 我表达的不对，我是想说5百万分之一。。。
|
T********i
发帖数: 2416 | 29 到你这里啥都数以亿计。你丫井底之蛙而已。
还是先搞明白interlocked吧
【在 g*****g 的大作中提到】
: 我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
: 至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。
|
n*****t
发帖数: 22014 | 30 专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？
【在 g*****g 的大作中提到】
: 我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
: 至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。
|
|
|
g*****g
发帖数: 34805 | 31 我说至少，5M其实是秒2-3个数量级。即使专用数据库，做出一个数量级也不容易。
还是那句话，你做出来了，我公开代码，测试通过，没啥说的。扯嘴皮子没用。
【在 n*****t 的大作中提到】
: 专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？
|
T********i
发帖数: 2416 | 32 好像你也没提过interlocked。不知为何？
【在 n*****t 的大作中提到】
: 专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？
|
c****3
发帖数: 10787 | 33 象我说的那样，每个城市一个数据库，全部都读到内存里。
买北京到上海的票，中转的只和北京，南京，济南内存数据库有关联。买北京到西安的
，只有北京这个数据库要共享。这样需要同时锁的相关城市的数据库就大量减少。
先算路径，然后顺序锁过去。没有票就回退。这样单机也没准可以
【在 L*****e 的大作中提到】
: 一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
: enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。
|
q*c
发帖数: 9453 | 34 在高并发下，回造成巨量错误操作。
比如有 a b c 三段， 无数请求一起近来 （如果你是单线程， 那当然没问题， 但是
单线程要 5mm/second 不可能）。 req1 锁了 a, 接着锁 b, 然后锁 c 得时候失败了
， 于是取消 a,b (这里都不谈万一取消得时候出错了， a,b 得票就丢一张）。 但是
在 取消a,b 得之前， req 要求 锁 a, 失败。
这就是有票不能出。 在巨大并发下， 这种情况就会成为常态， 造成大量有票不能出
， 用户的反复试验刷票的局面，
【在 c****3 的大作中提到】
: 是啊，中转地，先算路径。然后只要按照车次行走方向，顺序一段一段锁相应城市的数
: 据库就行了。有一个城市数据库里没有到下一个城市的票，就回退。这种最简单了，而
: 且负载分到不同数据库里。
|
c****3
发帖数: 10787 | 35 不是锁了a，接着锁 b，接着锁c。
是锁了a，然后释放，然后锁b，然后释放。然后锁c，然后释放。一张票，同时只要一
个锁。
【在 q*c 的大作中提到】
: 在高并发下，回造成巨量错误操作。
: 比如有 a b c 三段， 无数请求一起近来 （如果你是单线程， 那当然没问题， 但是
: 单线程要 5mm/second 不可能）。 req1 锁了 a, 接着锁 b, 然后锁 c 得时候失败了
: ， 于是取消 a,b (这里都不谈万一取消得时候出错了， a,b 得票就丢一张）。 但是
: 在 取消a,b 得之前， req 要求 锁 a, 失败。
: 这就是有票不能出。 在巨大并发下， 这种情况就会成为常态， 造成大量有票不能出
: ， 用户的反复试验刷票的局面，
|
q*c
发帖数: 9453 | 36 一样啊，你后面 fail 前面就要 release. release 前别人就没票。
在超高并发下， 这回造成大量错误。
【在 c****3 的大作中提到】
: 不是锁了a，接着锁 b，接着锁c。
: 是锁了a，然后释放，然后锁b，然后释放。然后锁c，然后释放。一张票，同时只要一
: 个锁。
|
L*****e
发帖数: 8347 | 37 queue head/tail的锁所需时间也与路线数量无关，就是个queue的读写而已。。。
【在 n*****t 的大作中提到】
: 不对，queue head/tail 也是要上锁才能写的 。。。
|
n**x
发帖数: 606 | 38 你不是让他数据存内存吗。 这个你亏大了
【在 g*****g 的大作中提到】
: 我说至少，5M其实是秒2-3个数量级。即使专用数据库，做出一个数量级也不容易。
: 还是那句话，你做出来了，我公开代码，测试通过，没啥说的。扯嘴皮子没用。
|
T********i
发帖数: 2416 | 39 每秒500万次，lock duration都是个位微秒级别的。
【在 q*c 的大作中提到】
: 一样啊，你后面 fail 前面就要 release. release 前别人就没票。
: 在超高并发下， 这回造成大量错误。
|
g*****g
发帖数: 34805 | 40 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。
【在 T********i 的大作中提到】
: 每秒500万次，lock duration都是个位微秒级别的。
|
|
|
T********i
发帖数: 2416 | 41 AtomicInteger是java你都理解不了？
我20个段1个都不用锁。
10个线程，每线程20个段用时2us就足够了。
这个你能理解么？叫锁也不是一般意义exclusive的锁，而是锁定一张票，2us以后可能
再把这张票还回去而已。
【在 g*****g 的大作中提到】
: 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。
|
n*****t
发帖数: 22014 | 42 需要比较多的字节描述某区段有票没票，比如 1M 的 request 同时请求，我就要安排
10 bit 来表述，我的实现还要起 timer，也是存在同一个地方，这样一个区段需要 2-
3 byte，如果实时 sync to disk，开销可能太大。
用 lock 可以基本保持在 cache，具体要测试才能知道哪个方案更快
【在 T********i 的大作中提到】
: 好像你也没提过interlocked。不知为何？
|
n****6
发帖数: 570 | 43 几个人微秒不行吧，就算一个微妙，也才一个M,如果五百万至少五个线程这还只是锁
【在 g*****g 的大作中提到】
: 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。
|
T********i
发帖数: 2416 | 44 发信人: TeacherWei (TW), 信区: Programming
标 题: Re: 总结贴
发信站: BBS 未名空间站 (Tue Feb 4 17:18:04 2014, 美东)
AtomicInteger是java你都理解不了？
我20个段1个都不用锁。
10个线程，每线程20个段用时2us就足够了。
这个你能理解么？叫锁也不是一般意义exclusive的锁，而是锁定一张票，2us以后可能
再把这张票还回去而已。
【在 n****6 的大作中提到】
: 几个人微秒不行吧，就算一个微妙，也才一个M,如果五百万至少五个线程这还只是锁
|
p*u
发帖数: 2454 | 45
google "multiple-producer-multiple-consumer lockless queue"
【在 n*****t 的大作中提到】
: 不对，queue head/tail 也是要上锁才能写的 。。。
|
n****6
发帖数: 570 | 46 就算2微妙也就是每秒50万次不是500万次啊。没别的意思就是想学习下。
【在 T********i 的大作中提到】
: 发信人: TeacherWei (TW), 信区: Programming
: 标 题: Re: 总结贴
: 发信站: BBS 未名空间站 (Tue Feb 4 17:18:04 2014, 美东)
: AtomicInteger是java你都理解不了？
: 我20个段1个都不用锁。
: 10个线程，每线程20个段用时2us就足够了。
: 这个你能理解么？叫锁也不是一般意义exclusive的锁，而是锁定一张票，2us以后可能
: 再把这张票还回去而已。
|
p*u
发帖数: 2454 | 47
there r 10 threads, dude...
【在 n****6 的大作中提到】
: 就算2微妙也就是每秒50万次不是500万次啊。没别的意思就是想学习下。
|
n*****t
发帖数: 22014 | 48 要防止越界的话，底层实现还是有锁的，programmer 也许不用管
【在 p*u 的大作中提到】
:
: there r 10 threads, dude...
|
p*u
发帖数: 2454 | 49
yes but that lock is ASM instructions which is very fast.
acquiring/releasing locks r not very expensive, wait is. atomic operations
are being used to minimize wait in other threads that couldn't get the lock.
【在 n*****t 的大作中提到】
: 要防止越界的话，底层实现还是有锁的，programmer 也许不用管
|
n*****t
发帖数: 22014 | 50 进程排队还是 data 排队其实一码事，不如 producer consumer 一肩挑
lock.
【在 p*u 的大作中提到】
:
: yes but that lock is ASM instructions which is very fast.
: acquiring/releasing locks r not very expensive, wait is. atomic operations
: are being used to minimize wait in other threads that couldn't get the lock.
|
|
|
a***n
发帖数: 538 | 51 用optimistic locking， distributed transaction吧，就是最后几张票的时候才会有
真的conflict。 |
g*****g
发帖数: 34805 | 52 Without enough threads, not gonging to meet throughput requirement, enough
threads, context switch and wait is enough to kill it
lock.
【在 p*u 的大作中提到】
:
: yes but that lock is ASM instructions which is very fast.
: acquiring/releasing locks r not very expensive, wait is. atomic operations
: are being used to minimize wait in other threads that couldn't get the lock.
|
c****3
发帖数: 10787 | 53 并发也没有问题。中转城市的票本来就是抢。原来全国一个统一数据库里才变成瓶颈。
现在变成每个城市一个数据库，只包含和这个城市直达的城市的票。这是比较合乎逻辑
的划分。
中转经过多个城市，算好路径后，从始发站开始抢。但每一段的抢票，都只和所经过的
这个城市数据库有关。所以即使并发，因为大家的路径不同，大家是在不同城市的数据
库上抢票。
如果抢不到最后一段票，就把前面抢到的中转路径票release回去，这个操作瞬间就完
成了。你也可以算另一个中转路径，继续抢票。
所以这个锁就是标准的数据库写操作需要的锁而已，不会出错的。其他人又可以继续抢
这些被release的票。
【在 q*c 的大作中提到】
: 一样啊，你后面 fail 前面就要 release. release 前别人就没票。
: 在超高并发下， 这回造成大量错误。
|
q*c
发帖数: 9453 | 54 经典的 活锁， 呵呵。
a b 都要 站 z1, z2. a 抢到了z1, 准备抢 z2, b 抢到了 z2, 准备抢 z1.
然后都傻眼了， 只好都 release. 然后继续轮回 :)
而且操作不是 “瞬间” 完成的， 需要一点点时间。 虽然是一点点， 可是在 500万/
s 的条件下， 就不行了。
【在 c****3 的大作中提到】
: 并发也没有问题。中转城市的票本来就是抢。原来全国一个统一数据库里才变成瓶颈。
: 现在变成每个城市一个数据库，只包含和这个城市直达的城市的票。这是比较合乎逻辑
: 的划分。
: 中转经过多个城市，算好路径后，从始发站开始抢。但每一段的抢票，都只和所经过的
: 这个城市数据库有关。所以即使并发，因为大家的路径不同，大家是在不同城市的数据
: 库上抢票。
: 如果抢不到最后一段票，就把前面抢到的中转路径票release回去，这个操作瞬间就完
: 成了。你也可以算另一个中转路径，继续抢票。
: 所以这个锁就是标准的数据库写操作需要的锁而已，不会出错的。其他人又可以继续抢
: 这些被release的票。
|
n*****t
发帖数: 22014 | 55 不会，北京经武汉到广州，总是先抢第一段的
【在 q*c 的大作中提到】
: 经典的 活锁， 呵呵。
: a b 都要 站 z1, z2. a 抢到了z1, 准备抢 z2, b 抢到了 z2, 准备抢 z1.
: 然后都傻眼了， 只好都 release. 然后继续轮回 :)
: 而且操作不是 “瞬间” 完成的， 需要一点点时间。 虽然是一点点， 可是在 500万/
: s 的条件下， 就不行了。
|
c****3
发帖数: 10787 | 56 前面说过是按照火车行驶方向顺序抢。如果第一段抢不到，就直接另一个路径了。
除非为了数据库负载均衡，否则倒着抢意义不大，因为火车不是倒着开的。
这种崩溃都能处理，因为可以先把路径写下来。抢票在中间某个城市崩溃了，重新开始
后，看还有那些路径没有抢到。如果能抢到，就有完整中转票。抢不到，就把前面的回
退。
万/
【在 q*c 的大作中提到】
: 经典的 活锁， 呵呵。
: a b 都要 站 z1, z2. a 抢到了z1, 准备抢 z2, b 抢到了 z2, 准备抢 z1.
: 然后都傻眼了， 只好都 release. 然后继续轮回 :)
: 而且操作不是 “瞬间” 完成的， 需要一点点时间。 虽然是一点点， 可是在 500万/
: s 的条件下， 就不行了。
|
