n**x
发帖数: 606 | 1 本人纯凑绕闹，不倾向任何一方。
系统主要特点：
- 多线程。(老魏没有给出具体多少个线程，假定100个吧。我的12 core intel xeon轻
轻松松100 thread）
- 无锁。
- 单机。
数据结构：
1. 全国1000条线 (X1, X2, X... , X1000)， 每条20个区段 (S1, S2, S3... S20)。
2. 每条线的每个区段的票的总数计为:T[X1,S1], T[X1, S2]....... T[X1000, S20]
抢票程序（注意举得例子是联票）
1. 100个thread处理收到的请求
2. 每个请求包括三个参数（线路， 起始站，结束战). 比如（234次列车, 济南， 上
海）。 （注意， 234次列车是从沈阳出发，到上海的, 济南是第5个区的开始，上海最
后一个区段的结束）
3. 计算过程就是把234次列车从济南到上海的每个区段的票数做interlocked.
decrement, 如下：
- Interlocked.Decrement( T[X234，S5] )
- Interlocked.Decrement( T[X234，S6] )
- Interlocked.Decrement( T[X234，S7] )
.......
- Interlocked.Decrement( T[X234，S20] )
4. 如果每个interlocked.decrement后的结果还大于0,表示可以出票。 如果有任何一
个环节计算后<0,那么抢票失败,并且要对前面decrement的全部做increment.
5. 北京->上海。 用户选择： 北京-〉济南， 济南-〉上海。 每一张票都可重复step
#3.
方案的本质：
- 就是对一个巨大的内存空间做interlocked加减法。
- 系统的性能由 hardware决定。 100线程，每个需要每秒处理50000个请求。
- 这个方案人人都写得出来。
大家说说目前的硬件可行吗？
缺点：
- 单点失败整个系统失败。 老魏说是100不遇的情况，不考虑。
- 只interlock区段，不interlock整个路线。中途失败需要increment之前所有
decrement过的。 会导致本来有票结果出现没票的结果。 |
g*****g
发帖数: 34805 | 2 你就2万个数，随机取20个锁更新，看看能有多快就知道了。别忘了这还不能保证座位
。处理输入输出都有开销。 |
n**x
发帖数: 606 | 3 我其实也很想知道。interlock要霸占总线，多出好几个cpu cycle. 不过老魏说没问题
呀。呵呵。
【在 g*****g 的大作中提到】
: 你就2万个数，随机取20个锁更新，看看能有多快就知道了。别忘了这还不能保证座位
: 。处理输入输出都有开销。
|
q*c
发帖数: 9453 | 4 不行啊， 联票咋办？
每个请求里面有 1-2 个票
。
【在 n**x 的大作中提到】
: 本人纯凑绕闹，不倾向任何一方。
: 系统主要特点：
: - 多线程。(老魏没有给出具体多少个线程，假定100个吧。我的12 core intel xeon轻
: 轻松松100 thread）
: - 无锁。
: - 单机。
: 数据结构：
: 1. 全国1000条线 (X1, X2, X... , X1000)， 每条20个区段 (S1, S2, S3... S20)。
: 2. 每条线的每个区段的票的总数计为:T[X1,S1], T[X1, S2]....... T[X1000, S20]
: 抢票程序（注意举得例子是联票）
|
n**x
发帖数: 606 | 5 按照老魏的说法，这已经有联票了：
北京到上海：北京-〉济南， 济南-〉上海。 每一段重复step #3
【在 q*c 的大作中提到】
: 不行啊， 联票咋办？
: 每个请求里面有 1-2 个票
:
: 。
|
n*****t
发帖数: 22014 | 6 锁 20 个干啥？每个车次一个锁不行吗？
【在 g*****g 的大作中提到】
: 你就2万个数，随机取20个锁更新，看看能有多快就知道了。别忘了这还不能保证座位
: 。处理输入输出都有开销。
|
g*****g
发帖数: 34805 | 7 一个车次20段。每段都得锁。
【在 n*****t 的大作中提到】
: 锁 20 个干啥？每个车次一个锁不行吗？
|
n*****t
发帖数: 22014 | 8 靠，我把整个车次一起锁了不行啊，大不了同时请求这个车次的等一下，1000 个车次
，冲突概率只有 0.1%，何必浪费那么多锁。
或者某车次某等级设一个锁，冲突概率更低了。
【在 g*****g 的大作中提到】
: 一个车次20段。每段都得锁。
|
q*c
发帖数: 9453 | 9 ou. 你是把票搞成 global, 跨区段都是一张票。
这样也行
【在 n**x 的大作中提到】
: 按照老魏的说法，这已经有联票了：
: 北京到上海：北京-〉济南， 济南-〉上海。 每一段重复step #3
|
i**i
发帖数: 1500 | 10 (s1 to s20) as a whole piece has to be locked before manipulation.
lock / atom operation on a part cannot guarantee the overall operation is
correct.
cs 102.
。
【在 n**x 的大作中提到】
: 本人纯凑绕闹，不倾向任何一方。
: 系统主要特点：
: - 多线程。(老魏没有给出具体多少个线程，假定100个吧。我的12 core intel xeon轻
: 轻松松100 thread）
: - 无锁。
: - 单机。
: 数据结构：
: 1. 全国1000条线 (X1, X2, X... , X1000)， 每条20个区段 (S1, S2, S3... S20)。
: 2. 每条线的每个区段的票的总数计为:T[X1,S1], T[X1, S2]....... T[X1000, S20]
: 抢票程序（注意举得例子是联票）
|
|
|
q*c
发帖数: 9453 | 11 就两个 thread? 还是单线程？
而且很多热门车次 block 其他大量车次。
【在 n*****t 的大作中提到】
: 靠，我把整个车次一起锁了不行啊，大不了同时请求这个车次的等一下，1000 个车次
: ，冲突概率只有 0.1%，何必浪费那么多锁。
: 或者某车次某等级设一个锁，冲突概率更低了。
|
g*****g
发帖数: 34805 | 12 And if you decrement at will and rollback when hitting a zero counter.
Lots of requests will fail although there are actually tickets left, just
temporarily booked and released shortly after. No fairness.
【在 i**i 的大作中提到】
: (s1 to s20) as a whole piece has to be locked before manipulation.
: lock / atom operation on a part cannot guarantee the overall operation is
: correct.
: cs 102.
:
: 。
|
g*****g
发帖数: 34805 | 13 锁的粒度大不见得有利，北京到上海过天津和南京，本来北京到天津和南京到上海的不
相干，一下子就得等。
【在 n*****t 的大作中提到】
: 靠，我把整个车次一起锁了不行啊，大不了同时请求这个车次的等一下，1000 个车次
: ，冲突概率只有 0.1%，何必浪费那么多锁。
: 或者某车次某等级设一个锁，冲突概率更低了。
|
n*****t
发帖数: 22014 | 14 1/1000 不严谨，16 个 core 抢 1000 个车次，重复的概率多大？如果按 5 个等级，
那冲突更低了。无论如何，没必要 20 个锁。
【在 q*c 的大作中提到】
: 就两个 thread? 还是单线程？
: 而且很多热门车次 block 其他大量车次。
|
N*n
发帖数: 456 | 15 应该每个车次一个锁。。
否则按老魏的算法到后来有可能整票（从头到尾的）有票卖不出去，区间
票倒先卖掉了
【在 n*****t 的大作中提到】
: 锁 20 个干啥？每个车次一个锁不行吗？
|
g*****g
发帖数: 34805 | 16 锁少了，每个等锁的队列就长，光等的时间就没戏了。没有holy grail。
【在 n*****t 的大作中提到】
: 1/1000 不严谨，16 个 core 抢 1000 个车次，重复的概率多大？如果按 5 个等级，
: 那冲突更低了。无论如何，没必要 20 个锁。
|
n**x
发帖数: 606 | 17 you are right. 老魏的方案里没有说如何解决这个问题。
老魏？
【在 g*****g 的大作中提到】
: And if you decrement at will and rollback when hitting a zero counter.
: Lots of requests will fail although there are actually tickets left, just
: temporarily booked and released shortly after. No fairness.
|
N*n
发帖数: 456 | 18 2nd this
【在 i**i 的大作中提到】
: (s1 to s20) as a whole piece has to be locked before manipulation.
: lock / atom operation on a part cannot guarantee the overall operation is
: correct.
: cs 102.
:
: 。
|
n*****t
发帖数: 22014 | 19 等也比上 20 个锁划算多了。
或者 try lock failed，我把这个请求扔 queue 里，先处理其他 request，完了再
try，没必要 block
【在 g*****g 的大作中提到】
: 锁的粒度大不见得有利，北京到上海过天津和南京，本来北京到天津和南京到上海的不
: 相干，一下子就得等。
|
g*****g
发帖数: 34805 | 20 整个东西不就是个速度的问题，你要说1万个，我当然信，500万我不信而已。
还是那句话，你自己试试就知道了。按你说的，1000个车次，随机取两个锁住，
然后更新20个计数器，开锁。
【在 n*****t 的大作中提到】
: 等也比上 20 个锁划算多了。
: 或者 try lock failed，我把这个请求扔 queue 里，先处理其他 request，完了再
: try，没必要 block
|
|
|
n*****t
发帖数: 22014 | 21 Kernel lock 大概 50 cpu cycles，如果我没记错的话。写计数器 20 个，sync to
disk 再加几十个吧，没测过，你算算够不够。
1M/s 我觉得狠靠谱
【在 g*****g 的大作中提到】
: 整个东西不就是个速度的问题，你要说1万个，我当然信，500万我不信而已。
: 还是那句话，你自己试试就知道了。按你说的，1000个车次，随机取两个锁住，
: 然后更新20个计数器，开锁。
|
n**x
发帖数: 606 | 22 加了锁老魏的系统就完蛋了。 不枷锁就会出现你前面提到的本来有票结果出现没票的
结果。
老魏人去哪里了？
【在 g*****g 的大作中提到】
: 整个东西不就是个速度的问题，你要说1万个，我当然信，500万我不信而已。
: 还是那句话，你自己试试就知道了。按你说的，1000个车次，随机取两个锁住，
: 然后更新20个计数器，开锁。
|
n*****t
发帖数: 22014 | 23 其实少量的有票出现没票狠正常，计划跟不上变化，现在看到没票继续刷的太多了，最
终这张票还是会卖出去的。只要严格防止重票就可以了。
【在 n**x 的大作中提到】
: 加了锁老魏的系统就完蛋了。 不枷锁就会出现你前面提到的本来有票结果出现没票的
: 结果。
: 老魏人去哪里了？
|
n**x
发帖数: 606 | 24 我同意。 不过古德霸的需求不允许这个。
【在 n*****t 的大作中提到】
: 其实少量的有票出现没票狠正常，计划跟不上变化，现在看到没票继续刷的太多了，最
: 终这张票还是会卖出去的。只要严格防止重票就可以了。
|
n*****t
发帖数: 22014 | 25 他也没法验证，哈哈，谁知道哪个 request 先到的？
【在 n**x 的大作中提到】
: 我同意。 不过古德霸的需求不允许这个。
|
g*****g
发帖数: 34805 | 26 峰值请求高，500万。热门票数少3000，你看到的会反过来。
【在 n**x 的大作中提到】
: 我同意。 不过古德霸的需求不允许这个。
|
i**i
发帖数: 1500 | 27 一个车次（K1,6:00pm)只能由同一个线程写，不需要锁．
可以有只读拷贝，供其他线程调度参考．
【在 n*****t 的大作中提到】
: 其实少量的有票出现没票狠正常，计划跟不上变化，现在看到没票继续刷的太多了，最
: 终这张票还是会卖出去的。只要严格防止重票就可以了。
|
n*****t
发帖数: 22014 | 28 那是按车次调度 thread 了？我赶脚比 lock 的开销大啊，尤其是都放在 kernel
space 里的话，还不如 lock 糙快猛
【在 i**i 的大作中提到】
: 一个车次（K1,6:00pm)只能由同一个线程写，不需要锁．
: 可以有只读拷贝，供其他线程调度参考．
|
i**i
发帖数: 1500 | 29 我觉得要快，因为没有无用功． 并且内存里设计个20标志不在话下．开锁解锁就麻烦
了．
【在 n*****t 的大作中提到】
: 那是按车次调度 thread 了？我赶脚比 lock 的开销大啊，尤其是都放在 kernel
: space 里的话，还不如 lock 糙快猛
|
i**i
发帖数: 1500 | 30 按照一定规则，把对于（车次，时间）映射到12个thread上，每个thread对应一个核．
【在 n*****t 的大作中提到】
: 那是按车次调度 thread 了？我赶脚比 lock 的开销大啊，尤其是都放在 kernel
: space 里的话，还不如 lock 糙快猛
|
|
|
n*****t
发帖数: 22014 | 31 先卖完的 core 先下班吗？当然加班帮别人卖也行，这个调度好的话其实也行，唯一的
麻烦是联程，比如跨 thread 出 2 张票，这个怎么协同？
【在 i**i 的大作中提到】
: 按照一定规则，把对于（车次，时间）映射到12个thread上，每个thread对应一个核．
|
b*******s
发帖数: 5216 | 32 在前端做判断，有一个失败就提交撤销请求
【在 n*****t 的大作中提到】
: 先卖完的 core 先下班吗？当然加班帮别人卖也行，这个调度好的话其实也行，唯一的
: 麻烦是联程，比如跨 thread 出 2 张票，这个怎么协同？
|
n*****t
发帖数: 22014 | 33 这俩线头要唠嗑，你那嘎达有内啥票没？好像稍微复杂了点。具体看情况
【在 b*******s 的大作中提到】
: 在前端做判断，有一个失败就提交撤销请求
|
b*******s
发帖数: 5216 | 34 其实就是事务不在后端做，在某个中间服务器甚至前端里面，把联票拆解成2个请求
反正都毫秒级内得到反馈的，可以单独为联票的准备一个小集群
【在 n*****t 的大作中提到】
: 这俩线头要唠嗑，你那嘎达有内啥票没？好像稍微复杂了点。具体看情况
|
n*****t
发帖数: 22014 | 35 哦，那也行，拿不到就 request release locked
【在 b*******s 的大作中提到】
: 其实就是事务不在后端做，在某个中间服务器甚至前端里面，把联票拆解成2个请求
: 反正都毫秒级内得到反馈的，可以单独为联票的准备一个小集群
|
b*******s
发帖数: 5216 | 36 嗯，就是这个意思
【在 n*****t 的大作中提到】
: 哦，那也行，拿不到就 request release locked
|
