由买买提看人间百态

boards

本页内容为未名空间相应帖子的节选和存档,一周内的贴子最多显示50字,超过一周显示500字 访问原贴
Programming版 - 继续,好虫这个赌约我接了
相关主题
赌约在此一个500w/s并发的计数器
老魏号称100%出票,现在的算法有碎片化问题吧。所有人拿到这个需求第一反应都是如何处理并发锁
古德霸放个带细节设计的方案吧老魏绝对是人才
100%出票还真没在赌约里。没干过大数据云计算的不用琢磨12306了
是否把好虫请来说说,我这个做出来,赌约算数不算数?大规模多核并发的系统PK大规模多机并发的系统
扯两句魏老师vs好虫好虫和魏赌局见证
目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活怎么协议里面会有length?
用计数器解决并发问题出票正确率的定义,赵,姜请进。
相关话题的讨论汇总
话题: tcp话题: 好虫话题: 并发话题: 车次话题: 12306
进入Programming版参与讨论
1 (共1页)
t**********1
发帖数: 550
1
5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
好虫又加上网络输入和输出。
这个我也同意。反正1M/s。千兆网没压力。
仅限一个TCP输入和输出。
如果我做出来,好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
benchmark,输入要严格限制在1M/s。误差正负5%以内。
虽然输入时间任意。但是为了benchmark。不应超过1小时。
t**********1
发帖数: 550
2
我一周内做出。
机器价格低于2万美金。

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 好虫又加上网络输入和输出。
: 这个我也同意。反正1M/s。千兆网没压力。
: 仅限一个TCP输入和输出。
: 如果我做出来,好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
: benchmark,输入要严格限制在1M/s。误差正负5%以内。
: 虽然输入时间任意。但是为了benchmark。不应超过1小时。

t**********1
发帖数: 550
3
还有协议我来制定。
全部代码开源。

【在 t**********1 的大作中提到】
: 我一周内做出。
: 机器价格低于2万美金。

e*******o
发帖数: 4654
4


【在 t**********1 的大作中提到】
: 还有协议我来制定。
: 全部代码开源。

t**********1
发帖数: 550
5
1微秒根本不可能准确测量。
我们可以选择1小时内1M/S请求都正确响应。总延迟不超过3秒。
好虫。等你确认。
这次再chicken out没人瞧得起你了。

【在 t**********1 的大作中提到】
: 还有协议我来制定。
: 全部代码开源。

b*******g
发帖数: 603
6
5000 * 3000 * 10 也就150M张票,单机接受1M/S的request,能3分钟正确响应,总延
迟不超过3秒即可。不能换座,不能错。给你三天时间。

【在 t**********1 的大作中提到】
: 1微秒根本不可能准确测量。
: 我们可以选择1小时内1M/S请求都正确响应。总延迟不超过3秒。
: 好虫。等你确认。
: 这次再chicken out没人瞧得起你了。

t**********1
发帖数: 550
7
行。7天内出货。干不?

【在 b*******g 的大作中提到】
: 5000 * 3000 * 10 也就150M张票,单机接受1M/S的request,能3分钟正确响应,总延
: 迟不超过3秒即可。不能换座,不能错。给你三天时间。

t**********1
发帖数: 550
8
这样吧。周末我不可能陪你玩。
咱俩折衷,5天。就是3个business day。

【在 t**********1 的大作中提到】
: 行。7天内出货。干不?
b*******g
发帖数: 603
9
行,没做出来之前,给我闭嘴就行。

【在 t**********1 的大作中提到】
: 这样吧。周末我不可能陪你玩。
: 咱俩折衷,5天。就是3个business day。

t**********1
发帖数: 550
10
说好啊。做出来了,你要滚蛋走人的。
做不出来,我滚蛋走人。

【在 b*******g 的大作中提到】
: 行,没做出来之前,给我闭嘴就行。
相关主题
扯两句魏老师vs好虫一个500w/s并发的计数器
目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活所有人拿到这个需求第一反应都是如何处理并发锁
用计数器解决并发问题老魏绝对是人才
进入Programming版参与讨论
k******n
发帖数: 184
11
没有down机测试?别的目前没看出什么问题了, betterbug可以想一下怎么起client
tests。
事情早就应该走上这个轨道, 赌局我不会接也不会走人(尽管换一个id再容易不过),
姓wei的做出来了我可以公开发帖表示服气+道歉。
b*******g
发帖数: 603
12
行,不过要公测,代码要拿出来。别忘了机器要2万以下的。大家可以找个高端服务器
验证。

【在 t**********1 的大作中提到】
: 说好啊。做出来了,你要滚蛋走人的。
: 做不出来,我滚蛋走人。

b*******g
发帖数: 603
13
起client测试简单,协议是他定的,得等他先拿出来才能写。



【在 k******n 的大作中提到】
: 没有down机测试?别的目前没看出什么问题了, betterbug可以想一下怎么起client
: tests。
: 事情早就应该走上这个轨道, 赌局我不会接也不会走人(尽管换一个id再容易不过),
: 姓wei的做出来了我可以公开发帖表示服气+道歉。

t**********1
发帖数: 550
14
谁能捐一台服务器出来?5天就好。

【在 b*******g 的大作中提到】
: 行,不过要公测,代码要拿出来。别忘了机器要2万以下的。大家可以找个高端服务器
: 验证。

s******u
发帖数: 501
15
这个似乎没那么难,每车次10站,总共差不多50种组合,bitwise的话不超过8个字节。
另外需要保存每个站点的剩余座位数,2bytesx10=20字节,也就是说一个车次顶多算64
字节好了。5000个车次1MB的数据都不到,做检索可以全部塞到cache里面,基本不存在
cache miss的问题。另外车次独立,所以线程的scalability几乎是线性的,综合起来
对这样子的简化问题每秒一百万次查询请求应该还有不少余地

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 好虫又加上网络输入和输出。
: 这个我也同意。反正1M/s。千兆网没压力。
: 仅限一个TCP输入和输出。
: 如果我做出来,好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
: benchmark,输入要严格限制在1M/s。误差正负5%以内。
: 虽然输入时间任意。但是为了benchmark。不应超过1小时。

b*******g
发帖数: 603
16
你忘了不能换座位。你忘了单机百万次的网络IO。

64

【在 s******u 的大作中提到】
: 这个似乎没那么难,每车次10站,总共差不多50种组合,bitwise的话不超过8个字节。
: 另外需要保存每个站点的剩余座位数,2bytesx10=20字节,也就是说一个车次顶多算64
: 字节好了。5000个车次1MB的数据都不到,做检索可以全部塞到cache里面,基本不存在
: cache miss的问题。另外车次独立,所以线程的scalability几乎是线性的,综合起来
: 对这样子的简化问题每秒一百万次查询请求应该还有不少余地

n****6
发帖数: 570
17
还要座位呢,座位不能换的。要把座位乘进去的

64

【在 s******u 的大作中提到】
: 这个似乎没那么难,每车次10站,总共差不多50种组合,bitwise的话不超过8个字节。
: 另外需要保存每个站点的剩余座位数,2bytesx10=20字节,也就是说一个车次顶多算64
: 字节好了。5000个车次1MB的数据都不到,做检索可以全部塞到cache里面,基本不存在
: cache miss的问题。另外车次独立,所以线程的scalability几乎是线性的,综合起来
: 对这样子的简化问题每秒一百万次查询请求应该还有不少余地

s******u
发帖数: 501
18
hmm,忘记要分配具体的座位了。不过3000个座位也不到400个字节,算上其他的开销总
共占1KB的内存不算夸张吧?5000的车次也还是不过5MB的数据量,L3 cache够了
网络io在我的knowledge之外,所以我就不去费神考虑了,呵呵

【在 b*******g 的大作中提到】
: 你忘了不能换座位。你忘了单机百万次的网络IO。
:
: 64

s******u
发帖数: 501
19
不对,每个站点都需要一个座位map,这样子总共就有400*10=4K的数据了

【在 s******u 的大作中提到】
: hmm,忘记要分配具体的座位了。不过3000个座位也不到400个字节,算上其他的开销总
: 共占1KB的内存不算夸张吧?5000的车次也还是不过5MB的数据量,L3 cache够了
: 网络io在我的knowledge之外,所以我就不去费神考虑了,呵呵

b*******g
发帖数: 603
20
每车次10段,再上一个数量级差不多了。

【在 s******u 的大作中提到】
: hmm,忘记要分配具体的座位了。不过3000个座位也不到400个字节,算上其他的开销总
: 共占1KB的内存不算夸张吧?5000的车次也还是不过5MB的数据量,L3 cache够了
: 网络io在我的knowledge之外,所以我就不去费神考虑了,呵呵

相关主题
没干过大数据云计算的不用琢磨12306了怎么协议里面会有length?
大规模多核并发的系统PK大规模多机并发的系统出票正确率的定义,赵,姜请进。
好虫和魏赌局见证每秒500万, 结论出来看了
进入Programming版参与讨论
x**r
发帖数: 2377
21
为魏老师当心啊,怎么算达到标准要制定清楚,一次搞死他,不要像上次goodbug这泼皮上
次跟我在股版打赌,本来输了要吃我老拉的屎,最后临阵脱逃,跟篮球版人越好1对1,人家
机票都买好了,他又改赌约条件...

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 好虫又加上网络输入和输出。
: 这个我也同意。反正1M/s。千兆网没压力。
: 仅限一个TCP输入和输出。
: 如果我做出来,好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
: benchmark,输入要严格限制在1M/s。误差正负5%以内。
: 虽然输入时间任意。但是为了benchmark。不应超过1小时。

s******u
发帖数: 501
22
关于网络IO,我到也改过intel ixgbe 10Gbit的网卡驱动,测试下来在10G网卡上满速
单线程可以处理到15M packets per second。CPU处理能力还有剩余,但是网卡饱和了
。当然所谓的处理只是简单的分析包头和包计数。不过对于简单数据,比方说一个
request只有几个字节的情景下,每秒一百万个包应该也是做得到的。
另外这种处理是基于串行的数据流,如果是前端有并发请求的话就不好说了。

【在 b*******g 的大作中提到】
: 你忘了不能换座位。你忘了单机百万次的网络IO。
:
: 64

f******2
发帖数: 2455
23
好虫这次要吃亏,兄弟,弄不好我老认识你,这数据听着耳熟啊。
好虫,这兄弟不懂卡三抓,也不懂卡芙卡,找个茬,忽悠忽悠他。

【在 s******u 的大作中提到】
: 关于网络IO,我到也改过intel ixgbe 10Gbit的网卡驱动,测试下来在10G网卡上满速
: 单线程可以处理到15M packets per second。CPU处理能力还有剩余,但是网卡饱和了
: 。当然所谓的处理只是简单的分析包头和包计数。不过对于简单数据,比方说一个
: request只有几个字节的情景下,每秒一百万个包应该也是做得到的。
: 另外这种处理是基于串行的数据流,如果是前端有并发请求的话就不好说了。

s******u
发帖数: 501
24
哈哈,不敢不敢,我遁了

【在 f******2 的大作中提到】
: 好虫这次要吃亏,兄弟,弄不好我老认识你,这数据听着耳熟啊。
: 好虫,这兄弟不懂卡三抓,也不懂卡芙卡,找个茬,忽悠忽悠他。

f******2
发帖数: 2455
25
赞一个

【在 t**********1 的大作中提到】
: 1微秒根本不可能准确测量。
: 我们可以选择1小时内1M/S请求都正确响应。总延迟不超过3秒。
: 好虫。等你确认。
: 这次再chicken out没人瞧得起你了。

n********d
发帖数: 7676
26
这个不容易。一个难点在于如果不能换座位,这个问题是NP-Hard的,分配位置的时候
肯定是要greedy算法,比如first available seat。Mark seat availability,linear
search太慢。第二个难点在网络上,千兆不行。不调kernel,千兆大概也就能达到6/
700mbps,一个request有TCP handshake,每个tcp包最短54字节,一兆request每秒肯
定不行。这个还是假设一个TCP连接的情况。1MTCP连接恐怕要用异步。还要调网卡和
kernel参数。5000车次是互相独立的,这个简化问题了。感觉内存IO问题不大,如果是
简单的mark seat, linear search的话。如果用更复杂的数据结构就不好说了。
x**r
发帖数: 2377
27
呵呵,有你这经验,我更放心魏老师搞死goodbug了,不过检验标准要写清楚,防止这泼皮
耍赖阿,他跟我老在股版打赌,都输得要吃屎了,还不长记性,凡是他看不懂的,都是"装B"
...

【在 f******2 的大作中提到】
: 好虫这次要吃亏,兄弟,弄不好我老认识你,这数据听着耳熟啊。
: 好虫,这兄弟不懂卡三抓,也不懂卡芙卡,找个茬,忽悠忽悠他。

q*c
发帖数: 9453
28
一个是搜索,这个 3000个座位 3000张票,每张长度不定,混乱叉在一起, 随便设计
个输入, 叫你搜索 1000 步才找到票常见。
这一个 request 就是 1000 个操作了。
还有是连票。。。上3 张票,3个不同的车次, All or none...要回滚,这写就加倍了。

linear

【在 n********d 的大作中提到】
: 这个不容易。一个难点在于如果不能换座位,这个问题是NP-Hard的,分配位置的时候
: 肯定是要greedy算法,比如first available seat。Mark seat availability,linear
: search太慢。第二个难点在网络上,千兆不行。不调kernel,千兆大概也就能达到6/
: 700mbps,一个request有TCP handshake,每个tcp包最短54字节,一兆request每秒肯
: 定不行。这个还是假设一个TCP连接的情况。1MTCP连接恐怕要用异步。还要调网卡和
: kernel参数。5000车次是互相独立的,这个简化问题了。感觉内存IO问题不大,如果是
: 简单的mark seat, linear search的话。如果用更复杂的数据结构就不好说了。

s******u
发帖数: 501
29
搜索的算法其实可以很简单。假设每一站都保存一个seat map,卖出去就把对应bit标1
。要买的车票是从站m到n,只要把seatmap[m] ... Seatmap[n]全部用或运算合并,找
第一个为0的位就可以了。这样子的搜索数据量和运算量都很有限。

了。

【在 q*c 的大作中提到】
: 一个是搜索,这个 3000个座位 3000张票,每张长度不定,混乱叉在一起, 随便设计
: 个输入, 叫你搜索 1000 步才找到票常见。
: 这一个 request 就是 1000 个操作了。
: 还有是连票。。。上3 张票,3个不同的车次, All or none...要回滚,这写就加倍了。
:
: linear

z****e
发帖数: 54598
30

标1
这就是问题,老魏把所有东西都简化了
票都简化成bit了,那搞什么
现实中怎么可能有简化成bit的票?
12306的票怎么也是身份证,姓名都放在上面的一个东西
计数器就是做了一个简单标识而已
离真正出票还有很长距离
然后就拼命证明这个标识是一个原子操作

【在 s******u 的大作中提到】
: 搜索的算法其实可以很简单。假设每一站都保存一个seat map,卖出去就把对应bit标1
: 。要买的车票是从站m到n,只要把seatmap[m] ... Seatmap[n]全部用或运算合并,找
: 第一个为0的位就可以了。这样子的搜索数据量和运算量都很有限。
:
: 了。

相关主题
魏公公,赌局我接了,你把500万/秒的订票系统做出来老魏号称100%出票,现在的算法有碎片化问题吧。
无论如何抢,最后顶多10张票会有些震荡古德霸放个带细节设计的方案吧
赌约在此100%出票还真没在赌约里。
进入Programming版参与讨论
s******u
发帖数: 501
31
Bit只是核心操作数据,具体的票的信息完全可以根据bit的位置索引另外保存
赵策你不会连这个都想不到吧

【在 z****e 的大作中提到】
:
: 标1
: 这就是问题,老魏把所有东西都简化了
: 票都简化成bit了,那搞什么
: 现实中怎么可能有简化成bit的票?
: 12306的票怎么也是身份证,姓名都放在上面的一个东西
: 计数器就是做了一个简单标识而已
: 离真正出票还有很长距离
: 然后就拼命证明这个标识是一个原子操作

b*******g
发帖数: 603
32
因为我在这个上让步了很多,没有联票,没有多票。本来也没让他写什么复杂的算法。
赌100万次做不了而已。

标1

【在 s******u 的大作中提到】
: 搜索的算法其实可以很简单。假设每一站都保存一个seat map,卖出去就把对应bit标1
: 。要买的车票是从站m到n,只要把seatmap[m] ... Seatmap[n]全部用或运算合并,找
: 第一个为0的位就可以了。这样子的搜索数据量和运算量都很有限。
:
: 了。

z****e
发帖数: 54598
33

我知道啊,但是显然如果分开的话,就不能做成txn了嘛
你要自己去实现txn,因为分布式有网络上丢包的问题
所以同时commit会有很麻烦的过程,scale就有问题了
所以其他人在说cap啊

【在 s******u 的大作中提到】
: Bit只是核心操作数据,具体的票的信息完全可以根据bit的位置索引另外保存
: 赵策你不会连这个都想不到吧

s******u
发帖数: 501
34
没错,联票和多票是真正复杂的地方,和这个简化系统比起来难度不是一个数量级的

【在 b*******g 的大作中提到】
: 因为我在这个上让步了很多,没有联票,没有多票。本来也没让他写什么复杂的算法。
: 赌100万次做不了而已。
:
: 标1

z****e
发帖数: 54598
35
因为这台机器只做一个简单的mark
其他机器需要根据这个mark作出很繁琐的动作
而且必须跟这台机器上的mark保持一致
这个一致就没那么容易保证了
任何协议都会有丢包问题
需要反复确认,比如三次握手之类的
这部分的io就会增加计数器所在机器的负担
哪怕只是确认一下,都比在内存中mark一下要复杂不少
f******2
发帖数: 2455
36
赵策能想到这个也不会成天卖vertx了。
崇拜好虫的这组人基本就是一组手熟的java programmer,虫族技术,需求量大,死不
光。咱不是说这个不好,如果真拿出老魏这种级别的项目,咱也赞,可惜的是都是嘴上
硬又没有拿出手真活的东西,还特别偏执,只要不说好就上去啐人一口。
你这个bitmap啥的对赵老师讲,需要仔细想想。

【在 s******u 的大作中提到】
: Bit只是核心操作数据,具体的票的信息完全可以根据bit的位置索引另外保存
: 赵策你不会连这个都想不到吧

z****e
发帖数: 54598
37

什么级别?5k人下载就好了?

【在 f******2 的大作中提到】
: 赵策能想到这个也不会成天卖vertx了。
: 崇拜好虫的这组人基本就是一组手熟的java programmer,虫族技术,需求量大,死不
: 光。咱不是说这个不好,如果真拿出老魏这种级别的项目,咱也赞,可惜的是都是嘴上
: 硬又没有拿出手真活的东西,还特别偏执,只要不说好就上去啐人一口。
: 你这个bitmap啥的对赵老师讲,需要仔细想想。

z****e
发帖数: 54598
38
google play,免费,5k次下载
这个标准?
t**********1
发帖数: 550
39
说实话。俺也不大厚道。能而示之不能,用而示之不用。
这个100万都不知道打了几折的能力。其实我现在严重怀疑我单核可能都不止100万。
至于2W的机器,也是狮子大张口。我先拿500刀的机器试试哈。看能不能做这个几倍?

【在 f******2 的大作中提到】
: 赵策能想到这个也不会成天卖vertx了。
: 崇拜好虫的这组人基本就是一组手熟的java programmer,虫族技术,需求量大,死不
: 光。咱不是说这个不好,如果真拿出老魏这种级别的项目,咱也赞,可惜的是都是嘴上
: 硬又没有拿出手真活的东西,还特别偏执,只要不说好就上去啐人一口。
: 你这个bitmap啥的对赵老师讲,需要仔细想想。

s*******e
发帖数: 664
40
两位大大太可爱了~不过你们谁走我都不舍得咋么办~
相关主题
100%出票还真没在赌约里。目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活
是否把好虫请来说说,我这个做出来,赌约算数不算数?用计数器解决并发问题
扯两句魏老师vs好虫一个500w/s并发的计数器
进入Programming版参与讨论
t**********1
发帖数: 550
41
还有啊,纠结什么联票多票之类的没意义。
单票百万,联票多票保证一个速度。而且保证transactional的。这个有些人看起来玄
。其实就那么回事。

【在 t**********1 的大作中提到】
: 说实话。俺也不大厚道。能而示之不能,用而示之不用。
: 这个100万都不知道打了几折的能力。其实我现在严重怀疑我单核可能都不止100万。
: 至于2W的机器,也是狮子大张口。我先拿500刀的机器试试哈。看能不能做这个几倍?

t**********1
发帖数: 550
42
还有,我即使用Java做,也能达到类似的性能。
当然,俺不会脱裤子放屁用Java啦。

【在 t**********1 的大作中提到】
: 还有啊,纠结什么联票多票之类的没意义。
: 单票百万,联票多票保证一个速度。而且保证transactional的。这个有些人看起来玄
: 。其实就那么回事。

J*******u
发帖数: 531
43
用bit不是最基本的?你和goodbug还不如说让魏老师别用电脑了,直接手出票得了...
这和goodbug在篮球版跟人打赌1对1,别人飞机票都买好了,goodbug说要加赌5000块有啥
区别?

【在 z****e 的大作中提到】
: google play,免费,5k次下载
: 这个标准?

z****e
发帖数: 54598
44

bit不叫最基本,是最节省的,因为随便一个操作,都会导致这种开销成倍增加
而现实中是不太可能用bit来标示一个票的
票的信息当然不可能是一个bit标识一下就好了
这个认识要是无法统一,就不用谈了
其实就是一个计数器,离真正出票远着呢
一张票怎么都有姓名,车次,身份证号这些
搞不好还在不同的机器上存放
越多机器卷入这个txn,越麻烦,需要反复确认,以确保网络丢包不会影响出票
这就是为啥一说单机,其他人就说,不用跟上一代人争论了
没啥意义

【在 J*******u 的大作中提到】
: 用bit不是最基本的?你和goodbug还不如说让魏老师别用电脑了,直接手出票得了...
: 这和goodbug在篮球版跟人打赌1对1,别人飞机票都买好了,goodbug说要加赌5000块有啥
: 区别?

t**********1
发帖数: 550
45
你就别在那里驴唇不对马嘴扯淡了。
不用bit也能做。其实我也没想用bit做。
你要是不服你做一个给我看看?

【在 z****e 的大作中提到】
:
: bit不叫最基本,是最节省的,因为随便一个操作,都会导致这种开销成倍增加
: 而现实中是不太可能用bit来标示一个票的
: 票的信息当然不可能是一个bit标识一下就好了
: 这个认识要是无法统一,就不用谈了
: 其实就是一个计数器,离真正出票远着呢
: 一张票怎么都有姓名,车次,身份证号这些
: 搞不好还在不同的机器上存放
: 越多机器卷入这个txn,越麻烦,需要反复确认,以确保网络丢包不会影响出票
: 这就是为啥一说单机,其他人就说,不用跟上一代人争论了

z****e
发帖数: 54598
46

我没说能做,你已经节省很多了好吧?
12306是http外加一个安全协议
我们简单点,就是https吧
你敢加上去么?tcp算什么?
这个东西放上去是等着给人偷看的么?
里面有信用卡信息哦

【在 t**********1 的大作中提到】
: 你就别在那里驴唇不对马嘴扯淡了。
: 不用bit也能做。其实我也没想用bit做。
: 你要是不服你做一个给我看看?

t**********1
发帖数: 550
47
别不要脸了。本来就是内网的。怕啥偷看?
说好了一个TCP连接。你耍赖皮也没用。
下一个会轮到你的。我不是说过了么?
哈哈哈。

【在 z****e 的大作中提到】
:
: 我没说能做,你已经节省很多了好吧?
: 12306是http外加一个安全协议
: 我们简单点,就是https吧
: 你敢加上去么?tcp算什么?
: 这个东西放上去是等着给人偷看的么?
: 里面有信用卡信息哦

z****e
发帖数: 54598
48

外围机不止一个
单tcp连接因为有状态,会导致长时间连接不释放
那么请问外围机其他机器怎么联入?
你连小报告都打不了,你能耐我何?

【在 t**********1 的大作中提到】
: 别不要脸了。本来就是内网的。怕啥偷看?
: 说好了一个TCP连接。你耍赖皮也没用。
: 下一个会轮到你的。我不是说过了么?
: 哈哈哈。

t**********1
发帖数: 550
49
走着看走着看。
我这不是也走一步看一步么?

【在 z****e 的大作中提到】
:
: 外围机不止一个
: 单tcp连接因为有状态,会导致长时间连接不释放
: 那么请问外围机其他机器怎么联入?
: 你连小报告都打不了,你能耐我何?

z****e
发帖数: 54598
50

lol
也就是说你现在小报告还没发对吧?
看什么呢?血流成河你都不敢承认了现在

【在 t**********1 的大作中提到】
: 走着看走着看。
: 我这不是也走一步看一步么?

相关主题
所有人拿到这个需求第一反应都是如何处理并发锁大规模多核并发的系统PK大规模多机并发的系统
老魏绝对是人才好虫和魏赌局见证
没干过大数据云计算的不用琢磨12306了怎么协议里面会有length?
进入Programming版参与讨论
b*******g
发帖数: 603
51
哪里说了一个TCP连接?几十上百台机器总是要的,模拟前端。前端不可能一台机器撑
住的。

【在 t**********1 的大作中提到】
: 别不要脸了。本来就是内网的。怕啥偷看?
: 说好了一个TCP连接。你耍赖皮也没用。
: 下一个会轮到你的。我不是说过了么?
: 哈哈哈。

z****e
发帖数: 54598
52

太监的小伎俩
看主贴:“仅限一个TCP输入和输出。”
我早就觉得这里有问题
一个tcp socket会导致其他外围机无法接入

【在 b*******g 的大作中提到】
: 哪里说了一个TCP连接?几十上百台机器总是要的,模拟前端。前端不可能一台机器撑
: 住的。

z****e
发帖数: 54598
53
这个东西根本没有办法scale out
一个外围机用tcp联入之后,其他外围机也需要用到同样的数据
这里有资源的各种争抢
也就是n台外围机跟一台外围机是两个概念
做出来也不能代表你能模拟出12306,早着呢
所以仅限一个tcp连接肯定是不行的
这种小伎俩真是很恶心啊,已经各种简化了
连这个都要简化,我的天
z****e
发帖数: 54598
54
应该允许外围机自由接入
就是动态scale out
比如外围机可能是n = 10,也可能是n = 100
这才叫并发嘛,否则一个一个数据包发进去
叫什么并发?老魏又把排队这事推给别人去做了
y*******i
发帖数: 361
55
最后机票是怎么处理的?

,别人飞机票都买好了,

【在 J*******u 的大作中提到】
: 用bit不是最基本的?你和goodbug还不如说让魏老师别用电脑了,直接手出票得了...
: 这和goodbug在篮球版跟人打赌1对1,别人飞机票都买好了,goodbug说要加赌5000块有啥
: 区别?

n********d
发帖数: 7676
56
你这个算法有点糙了。给你个例子。假设只有两个座,A和B,一个人定了A从station 5
到 9,另一个人要定座from station 0 - 4。你是要给这个人A还是B呢?给了B,再
有人要定从station 0-4 到 5-9的票就没有了,这个就是卖票的损失啊。

标1

【在 s******u 的大作中提到】
: 搜索的算法其实可以很简单。假设每一站都保存一个seat map,卖出去就把对应bit标1
: 。要买的车票是从站m到n,只要把seatmap[m] ... Seatmap[n]全部用或运算合并,找
: 第一个为0的位就可以了。这样子的搜索数据量和运算量都很有限。
:
: 了。

t**********1
发帖数: 550
57
好虫。我赌约里面写的清楚。你也同意了。没仔细看是你的问题。
其实,你搞几十100 TCP对我的load也没啥影响。我网络都是单独core处理。带宽也够。
但是你要搞明白,几十上百台,顺序你不能保证。比如你两个连接round robin送请求
1234。连接A送13连接2送24。我的机器看到的可能是1324,也可能是2413,也可能是
1243,也可能是2134的顺序。发送接收你不能控制,我也不能控制。
最后就是扯皮。
所以我才要简化。大家都要有decency。

【在 b*******g 的大作中提到】
: 哪里说了一个TCP连接?几十上百台机器总是要的,模拟前端。前端不可能一台机器撑
: 住的。

z****e
发帖数: 54598
58

够。
所以才要txn,否则乱序都可以搞,出一半票,那还要你来做?
人家12306就能保证出完整的票,你送13过来,要么全出,要么全不出
没有出一半的道理,如果1出了,3发现 没票了,要求1也不能出
就是因为中间会有其他请求杀入,所以才使得这个需求无比复杂
否则你做什么?就是一个简单的计数器要你做?
数数很好玩么?当其他人都傻到不会数数是吧?

【在 t**********1 的大作中提到】
: 好虫。我赌约里面写的清楚。你也同意了。没仔细看是你的问题。
: 其实,你搞几十100 TCP对我的load也没啥影响。我网络都是单独core处理。带宽也够。
: 但是你要搞明白,几十上百台,顺序你不能保证。比如你两个连接round robin送请求
: 1234。连接A送13连接2送24。我的机器看到的可能是1324,也可能是2413,也可能是
: 1243,也可能是2134的顺序。发送接收你不能控制,我也不能控制。
: 最后就是扯皮。
: 所以我才要简化。大家都要有decency。

i**i
发帖数: 1500
59
卖票不能只卖明天的票。卖三个月的不算多吧?

【在 b*******g 的大作中提到】
: 5000 * 3000 * 10 也就150M张票,单机接受1M/S的request,能3分钟正确响应,总延
: 迟不超过3秒即可。不能换座,不能错。给你三天时间。

i**i
发帖数: 1500
60
还有,站1-站3,站4-站5 不能算一张票吧?
得重算共几张票。:)

【在 i**i 的大作中提到】
: 卖票不能只卖明天的票。卖三个月的不算多吧?
相关主题
出票正确率的定义,赵,姜请进。无论如何抢,最后顶多10张票会有些震荡
每秒500万, 结论出来看了赌约在此
魏公公,赌局我接了,你把500万/秒的订票系统做出来老魏号称100%出票,现在的算法有碎片化问题吧。
进入Programming版参与讨论
i**i
发帖数: 1500
61
反正这个帖子之后一个家伙得闭嘴。
吼吼
z****e
发帖数: 54598
62
老魏简化之后的想法就是
你过来一个数据包,我就处理一个,见票就出票
逗了
没那么简单,就是要打乱了并发处理
5k是并发ok?不是顺序,你自己要想办法保证顺序
就是因为请求互相之间会干扰,所以才使得整个流程无比复杂
否则要你做什么?人家12306就做到了,你做不到就别吹牛
举个简单例子,一个请求13,另外一个请求23
当一个请求出了1之后,进入3之前
被另外一个请求抢走了3的票,所以13全部都不能出
全部要求回滚,1也不能出,所以你必需先做标记
因为并发的存在,这里会有票出不了的可能性
比如一个请求13,另外一个请求31,1和3都只有一张票了
两个请求同时过来,进入队列顺序是1331
两个都会回滚,会导致这票两个人都抢不到
所以你有票必需出的要求就无法实现,这才是难点
否则做什么?计数器有什么好做的?
拜托,看看12306在做什么,人家做得可远比老魏强太多了
t****n
发帖数: 263
63
这个绝对不能接受。sever怎么做是你的事。client怎么做是client的事。别人已经让
步这么多了你还要什么decency?我有个建议,每个request你给返回个序号,以你的为
准。单个requestdelay不要太离谱就好了。

够。

【在 t**********1 的大作中提到】
: 好虫。我赌约里面写的清楚。你也同意了。没仔细看是你的问题。
: 其实,你搞几十100 TCP对我的load也没啥影响。我网络都是单独core处理。带宽也够。
: 但是你要搞明白,几十上百台,顺序你不能保证。比如你两个连接round robin送请求
: 1234。连接A送13连接2送24。我的机器看到的可能是1324,也可能是2413,也可能是
: 1243,也可能是2134的顺序。发送接收你不能控制,我也不能控制。
: 最后就是扯皮。
: 所以我才要简化。大家都要有decency。

i**i
发帖数: 1500
64
"输入要严格限制在1M/s", 单位是啥?当然不管B还是b一个TCP就足够了。
t**********1
发帖数: 550
65
我写的清清楚楚。好虫答应的。再扯别的就没意思。
什么连接互相会干扰之类的都是啥也不懂的二逼。我处理所有连接都是一个单线程。肯
定是接收收完一个连接在接收下一个。你说的发送的顺序有点不一样,跟我有啥关系?
我看到的就是这样的。中间差的那几毫秒是协议栈处理的问题。是act of god。
赌约订好了,再反悔改口就没劲了。TCP你能改,还有啥不能改?这个帖子开头是我和
好虫都确认了的。白纸黑字。
z****e
发帖数: 54598
66

当然有关系,就猜到你会赖这个了
其他人给出的条件里面根本就没有这一条
你偷偷摸摸在里面夹带了这一条
纯粹就是玩点小孩子把戏
你一个单tcp连接有什么意义?
现实中谁打算用单机做12306的web server?
这不是逗嘛
你做不到就不要吹牛,人家12306比你强太多了
大概看明白了,估计是搞不定了
继续赖

【在 t**********1 的大作中提到】
: 我写的清清楚楚。好虫答应的。再扯别的就没意思。
: 什么连接互相会干扰之类的都是啥也不懂的二逼。我处理所有连接都是一个单线程。肯
: 定是接收收完一个连接在接收下一个。你说的发送的顺序有点不一样,跟我有啥关系?
: 我看到的就是这样的。中间差的那几毫秒是协议栈处理的问题。是act of god。
: 赌约订好了,再反悔改口就没劲了。TCP你能改,还有啥不能改?这个帖子开头是我和
: 好虫都确认了的。白纸黑字。

t**********1
发帖数: 550
67
好虫,条件我第一贴已经说明了。
你也答应了。
而且1个TCP和多个TCP我也说了,负载一样。但是规矩不能坏。
节外生枝,耽搁的时间算你的。
t****n
发帖数: 263
68
好虫当时说的是单一网卡。你偷偷改成单一链接的。要不要脸

【在 t**********1 的大作中提到】
: 我写的清清楚楚。好虫答应的。再扯别的就没意思。
: 什么连接互相会干扰之类的都是啥也不懂的二逼。我处理所有连接都是一个单线程。肯
: 定是接收收完一个连接在接收下一个。你说的发送的顺序有点不一样,跟我有啥关系?
: 我看到的就是这样的。中间差的那几毫秒是协议栈处理的问题。是act of god。
: 赌约订好了,再反悔改口就没劲了。TCP你能改,还有啥不能改?这个帖子开头是我和
: 好虫都确认了的。白纸黑字。

z****e
发帖数: 54598
69

二逼,说的不是你处理时候的顺序
是古德霸发时候的顺序
看不懂把我说的有票必需出的例子再看一遍
理解一下什么是acid里面的atomic
早就说了,解释这种低级概念要解释半天
tcp没啥好改的,tcp是传输协议,我们说的是应用层协议
你当然需要处理tcp数据包的拼接,否则要你干嘛?
再说一次,12306就做到了

【在 t**********1 的大作中提到】
: 我写的清清楚楚。好虫答应的。再扯别的就没意思。
: 什么连接互相会干扰之类的都是啥也不懂的二逼。我处理所有连接都是一个单线程。肯
: 定是接收收完一个连接在接收下一个。你说的发送的顺序有点不一样,跟我有啥关系?
: 我看到的就是这样的。中间差的那几毫秒是协议栈处理的问题。是act of god。
: 赌约订好了,再反悔改口就没劲了。TCP你能改,还有啥不能改?这个帖子开头是我和
: 好虫都确认了的。白纸黑字。

i**i
发帖数: 1500
70
闭嘴。

【在 z****e 的大作中提到】
:
: 二逼,说的不是你处理时候的顺序
: 是古德霸发时候的顺序
: 看不懂把我说的有票必需出的例子再看一遍
: 理解一下什么是acid里面的atomic
: 早就说了,解释这种低级概念要解释半天
: tcp没啥好改的,tcp是传输协议,我们说的是应用层协议
: 你当然需要处理tcp数据包的拼接,否则要你干嘛?
: 再说一次,12306就做到了

相关主题
老魏号称100%出票,现在的算法有碎片化问题吧。是否把好虫请来说说,我这个做出来,赌约算数不算数?
古德霸放个带细节设计的方案吧扯两句魏老师vs好虫
100%出票还真没在赌约里。目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活
进入Programming版参与讨论
z****e
发帖数: 54598
71

算谁的都改变不了你偷改协议的事实
这还在协商阶段,就是要把每一条都解释清楚了
然后双方同意才生效,否则就是各种骗
楼上给了例子了,1m/s,单位啥呀?

【在 t**********1 的大作中提到】
: 好虫,条件我第一贴已经说明了。
: 你也答应了。
: 而且1个TCP和多个TCP我也说了,负载一样。但是规矩不能坏。
: 节外生枝,耽搁的时间算你的。

z****e
发帖数: 54598
72

lol
不闭,你咬我吧

【在 i**i 的大作中提到】
: 闭嘴。
t**********1
发帖数: 550
73
协商已经结束了。
1M/s当然是请求。我这人没赖皮过。

【在 z****e 的大作中提到】
:
: lol
: 不闭,你咬我吧

z****e
发帖数: 54598
74
上一次也是讨论到txn时候老魏说搞不定了
当时古德霸就拿出12306的例子来说了
这次还是拿12306来说,人家就能实现联票联程,要么出,要么不出
绝对不会出一半,老魏就是搞不定咯
z****e
发帖数: 54598
75

哦,你的意思是单tcp连接这个不要了是吧?

【在 t**********1 的大作中提到】
: 协商已经结束了。
: 1M/s当然是请求。我这人没赖皮过。

i**i
发帖数: 1500
76
够爷们!

【在 t**********1 的大作中提到】
: 协商已经结束了。
: 1M/s当然是请求。我这人没赖皮过。

z****e
发帖数: 54598
77

你也够娘们~!

【在 i**i 的大作中提到】
: 够爷们!
i**i
发帖数: 1500
78
shut up.

【在 z****e 的大作中提到】
:
: 你也够娘们~!

z****e
发帖数: 54598
79

你没有权力让任何人shut up
记住,言论自由受宪法保护

【在 i**i 的大作中提到】
: shut up.
i**i
发帖数: 1500
80
各位给魏老师时间写程序。
稍安勿躁。
相关主题
用计数器解决并发问题老魏绝对是人才
一个500w/s并发的计数器没干过大数据云计算的不用琢磨12306了
所有人拿到这个需求第一反应都是如何处理并发锁大规模多核并发的系统PK大规模多机并发的系统
进入Programming版参与讨论
z****e
发帖数: 54598
81

写啥呀,老魏的东西远不如12306好吧
那种破烂你拿回家玩吧

【在 i**i 的大作中提到】
: 各位给魏老师时间写程序。
: 稍安勿躁。

t**********1
发帖数: 550
82
本来就回家玩的。
这是个完成赌约的程序。和12306有没有关系根本不在我的任何concern之内。

【在 z****e 的大作中提到】
:
: 写啥呀,老魏的东西远不如12306好吧
: 那种破烂你拿回家玩吧

z****e
发帖数: 54598
83

lol
那不行,规则不是你一个人说了算
需要反复确认,否则就没有必要讨论了

【在 t**********1 的大作中提到】
: 本来就回家玩的。
: 这是个完成赌约的程序。和12306有没有关系根本不在我的任何concern之内。

i**i
发帖数: 1500
84
哪凉快哪呆着去。

【在 z****e 的大作中提到】
:
: lol
: 那不行,规则不是你一个人说了算
: 需要反复确认,否则就没有必要讨论了

z****e
发帖数: 54598
85

滚开

【在 i**i 的大作中提到】
: 哪凉快哪呆着去。
z****e
发帖数: 54598
86
老魏做的东西根本不是12306
完全是一个陷阱,玩政治
都散了吧,没啥东西,就是一个计数器
做什么?
i**i
发帖数: 1500
87
别搅和啊。好不容易两位要开练了。
z****e
发帖数: 54598
88

讨论条件,没有搅和
合同制定阶段,任何条款都应该讨论清楚

【在 i**i 的大作中提到】
: 别搅和啊。好不容易两位要开练了。
t****n
发帖数: 263
89
你先把赌咒发誓的linear scalability兑现了吧。那个在这个所谓的“赌约”前面。还
不赶快从这里滚蛋。我都替你丢人。

【在 t**********1 的大作中提到】
: 本来就回家玩的。
: 这是个完成赌约的程序。和12306有没有关系根本不在我的任何concern之内。

t****n
发帖数: 263
90
搅合个屁。他那太监计数器已经练过一次了。也就他能把拉出来的屎在嚼嚼当新屎拉

【在 i**i 的大作中提到】
: 别搅和啊。好不容易两位要开练了。
相关主题
好虫和魏赌局见证每秒500万, 结论出来看了
怎么协议里面会有length?魏公公,赌局我接了,你把500万/秒的订票系统做出来
出票正确率的定义,赵,姜请进。无论如何抢,最后顶多10张票会有些震荡
进入Programming版参与讨论
i**i
发帖数: 1500
91
“好虫又加上网络输入和输出。” 这个不是指局域网而是外网,是吧?
“1M/s +/- 5%“ 魏老师也有办法让这个成立,对吧?
t****n
发帖数: 263
92
协议是他定的。这感觉是能做到的。大不了在协议里cheating呗。又不是一次两次了

【在 i**i 的大作中提到】
: “好虫又加上网络输入和输出。” 这个不是指局域网而是外网,是吧?
: “1M/s +/- 5%“ 魏老师也有办法让这个成立,对吧?

i**i
发帖数: 1500
93
让主角说。

【在 t****n 的大作中提到】
: 协议是他定的。这感觉是能做到的。大不了在协议里cheating呗。又不是一次两次了
q*c
发帖数: 9453
94
这有啥难,就是个二维 bit array. 线性搜索。
这个计数器毛病还多,比如要动态加票,加车次,等, 远不如数据库设计,直接加票
减票,各种 txn 自动保证。

【在 t**********1 的大作中提到】
: 你就别在那里驴唇不对马嘴扯淡了。
: 不用bit也能做。其实我也没想用bit做。
: 你要是不服你做一个给我看看?

x******e
发帖数: 466
95
人家好虫都答应了没说啥,魏老白纸黑子清清楚楚,好虫又不是不懂,他也没说啥,你
参和个啥子还。你就歇歇吧。

【在 z****e 的大作中提到】
:
: 讨论条件,没有搅和
: 合同制定阶段,任何条款都应该讨论清楚

g*********e
发帖数: 14401
96
这个我也可以做。车次数量还可以翻两番
每个query 1us以内。
稍微写个不烂的cxx即可

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 好虫又加上网络输入和输出。
: 这个我也同意。反正1M/s。千兆网没压力。
: 仅限一个TCP输入和输出。
: 如果我做出来,好虫自杀所有ID, 从此滚出这个BBS。不许再注册进来。
: benchmark,输入要严格限制在1M/s。误差正负5%以内。
: 虽然输入时间任意。但是为了benchmark。不应超过1小时。

g*********e
发帖数: 14401
97
就算全cache miss也还是没问题 一个微秒够用了

64

【在 s******u 的大作中提到】
: 这个似乎没那么难,每车次10站,总共差不多50种组合,bitwise的话不超过8个字节。
: 另外需要保存每个站点的剩余座位数,2bytesx10=20字节,也就是说一个车次顶多算64
: 字节好了。5000个车次1MB的数据都不到,做检索可以全部塞到cache里面,基本不存在
: cache miss的问题。另外车次独立,所以线程的scalability几乎是线性的,综合起来
: 对这样子的简化问题每秒一百万次查询请求应该还有不少余地

b*******g
发帖数: 603
98
关键是没写盘。

【在 q*c 的大作中提到】
: 这有啥难,就是个二维 bit array. 线性搜索。
: 这个计数器毛病还多,比如要动态加票,加车次,等, 远不如数据库设计,直接加票
: 减票,各种 txn 自动保证。

t**********1
发帖数: 550
99
加上写盘丝毫不会改变任何performance number。
你是太不懂了。

【在 b*******g 的大作中提到】
: 关键是没写盘。
b*******g
发帖数: 603
100
那行,那你就把它加上去,这样大家服气。

【在 t**********1 的大作中提到】
: 加上写盘丝毫不会改变任何performance number。
: 你是太不懂了。

相关主题
赌约在此100%出票还真没在赌约里。
老魏号称100%出票,现在的算法有碎片化问题吧。是否把好虫请来说说,我这个做出来,赌约算数不算数?
古德霸放个带细节设计的方案吧扯两句魏老师vs好虫
进入Programming版参与讨论
t**********1
发帖数: 550
101
谁爱服气不服气?管我屁事?不加。
希望你自重。赌局已经开了。遵守规则。

【在 b*******g 的大作中提到】
: 那行,那你就把它加上去,这样大家服气。
f******2
发帖数: 2455
102
靠,这也行?看来前面网友说的没错,哈哈

【在 b*******g 的大作中提到】
: 那行,那你就把它加上去,这样大家服气。
k******n
发帖数: 184
103
我觉得担心姓wei的使手段玩文字有戏的多虑了。
client tests由好虫定就不怕姓wei的cheating, server side管他同步异步单机还是
云就是个black box, client tests由好虫弄就行。
b******7
发帖数: 123
104
是不是应该定义有效订票成功率啥的啊?不然1M/s收到包直接拒绝算不算测试通过啊?
还有订票算法对成功率也有影响,不定义好了是否有效订票也说不清楚,到时候又成了
各自都说自己赢了的场面了。
z****e
发帖数: 54598
105

这个应该好好讨论讨论
出错票怎么办?
比如a和b同时定
1,2和2,1座位
都只有一张票剩下
如果是a1,b2,a2,b1顺序进入
期望结果应该是a拿到票,b拿不到票
以下结果都算作失败
1)a,b各出半张票,a只拿到1,b只拿到2
2)a,b都回滚,都拿不到票,有票不出

【在 b******7 的大作中提到】
: 是不是应该定义有效订票成功率啥的啊?不然1M/s收到包直接拒绝算不算测试通过啊?
: 还有订票算法对成功率也有影响,不定义好了是否有效订票也说不清楚,到时候又成了
: 各自都说自己赢了的场面了。

b******7
发帖数: 123
106
订票算法有点像硬盘空间分配,弄得不好很多碎片,造成有效订票无效,拒绝率上升。
极端例子是上来3000张订票每张都只一站,算法不好就把3000个座位分了,以后再来全
程的订票全部失败。
b******7
发帖数: 123
107
2) 这种情况可以算为有效订票被拒绝,可以不要求0%,所以要定一个百分比。

【在 z****e 的大作中提到】
:
: 这个应该好好讨论讨论
: 出错票怎么办?
: 比如a和b同时定
: 1,2和2,1座位
: 都只有一张票剩下
: 如果是a1,b2,a2,b1顺序进入
: 期望结果应该是a拿到票,b拿不到票
: 以下结果都算作失败
: 1)a,b各出半张票,a只拿到1,b只拿到2

b******7
发帖数: 123
108
2) 这种情况可以算为有效订票被拒绝,可以不要求0%,所以要定一个百分比。

【在 z****e 的大作中提到】
:
: 这个应该好好讨论讨论
: 出错票怎么办?
: 比如a和b同时定
: 1,2和2,1座位
: 都只有一张票剩下
: 如果是a1,b2,a2,b1顺序进入
: 期望结果应该是a拿到票,b拿不到票
: 以下结果都算作失败
: 1)a,b各出半张票,a只拿到1,b只拿到2

n********d
发帖数: 7676
109
呵呵。这个时候就看出PhD训练的重要性了。正经的项目,应该要求blocking rate,测
试的时候一次出票数目从1到N符合一定概率分布,票的source and destination,
number of stations符合一定分布,response time depends on request arrival
distribution. 假设request是匀速的,大大降低了要求。在同样average的情况下,越
bursty越难搞。

【在 b******7 的大作中提到】
: 2) 这种情况可以算为有效订票被拒绝,可以不要求0%,所以要定一个百分比。
i**i
发帖数: 1500
110
两位得把这个约定好了。成功率99%行不行?

【在 z****e 的大作中提到】
:
: 这个应该好好讨论讨论
: 出错票怎么办?
: 比如a和b同时定
: 1,2和2,1座位
: 都只有一张票剩下
: 如果是a1,b2,a2,b1顺序进入
: 期望结果应该是a拿到票,b拿不到票
: 以下结果都算作失败
: 1)a,b各出半张票,a只拿到1,b只拿到2

相关主题
扯两句魏老师vs好虫一个500w/s并发的计数器
目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活所有人拿到这个需求第一反应都是如何处理并发锁
用计数器解决并发问题老魏绝对是人才
进入Programming版参与讨论
i**i
发帖数: 1500
111
大赞,有气魄!
就是一次申请的票数不限,all or none, 并且有票必出。成功率100%.

【在 t**********1 的大作中提到】
: 谁爱服气不服气?管我屁事?不加。
: 希望你自重。赌局已经开了。遵守规则。

t**********1
发帖数: 550
112
赌约规定,一次一张,同一个TCP的请求要尊重先后次序。并且有票必出。成功率100%.

【在 i**i 的大作中提到】
: 大赞,有气魄!
: 就是一次申请的票数不限,all or none, 并且有票必出。成功率100%.

i**i
发帖数: 1500
113
赌约没说一次仅限一张。
两位需要商量一下。

%.

【在 t**********1 的大作中提到】
: 赌约规定,一次一张,同一个TCP的请求要尊重先后次序。并且有票必出。成功率100%.
t**********1
发帖数: 550
114
协议我来制定。规定的。

【在 i**i 的大作中提到】
: 赌约没说一次仅限一张。
: 两位需要商量一下。
:
: %.

i**i
发帖数: 1500
115
要是写合同,作者得允许按照不利自己的方式解读。
也就是说,合同没写仅限一次一张,那么就是可以一次多张。

【在 i**i 的大作中提到】
: 赌约没说一次仅限一张。
: 两位需要商量一下。
:
: %.

i**i
发帖数: 1500
116
“协议”指的是网络传输协议,这次打赌的规则叫"赌约"。

【在 t**********1 的大作中提到】
: 协议我来制定。规定的。
g****u
发帖数: 252
117
笑死我了

【在 i**i 的大作中提到】
: “协议”指的是网络传输协议,这次打赌的规则叫"赌约"。
t**********1
发帖数: 550
118
5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
仔细阅读,输入和输出。这是好虫的要求。
这就是赌约。
你想其他输入,那是另外的合同了。

【在 i**i 的大作中提到】
: “协议”指的是网络传输协议,这次打赌的规则叫"赌约"。
i**i
发帖数: 1500
119
你的意思是提供的API一次只能申请一张?这样的话有违约之嫌。

【在 t**********1 的大作中提到】
: 协议我来制定。规定的。
z****e
发帖数: 54598
120

够。
才几十个?并发上万,也就是几千个connections几乎同时到才对
否则叫并发上万?那叫并发上几十,不叫并发上万好吧?

【在 t**********1 的大作中提到】
: 好虫。我赌约里面写的清楚。你也同意了。没仔细看是你的问题。
: 其实,你搞几十100 TCP对我的load也没啥影响。我网络都是单独core处理。带宽也够。
: 但是你要搞明白,几十上百台,顺序你不能保证。比如你两个连接round robin送请求
: 1234。连接A送13连接2送24。我的机器看到的可能是1324,也可能是2413,也可能是
: 1243,也可能是2134的顺序。发送接收你不能控制,我也不能控制。
: 最后就是扯皮。
: 所以我才要简化。大家都要有decency。

相关主题
没干过大数据云计算的不用琢磨12306了怎么协议里面会有length?
大规模多核并发的系统PK大规模多机并发的系统出票正确率的定义,赵,姜请进。
好虫和魏赌局见证每秒500万, 结论出来看了
进入Programming版参与讨论
i**i
发帖数: 1500
121
我是中立态度,我什么也不想。
输入车次没说仅输入一个车次,并且买票也确实是几张一起买的。所以一次多张的解读
没问题。

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 仔细阅读,输入和输出。这是好虫的要求。
: 这就是赌约。
: 你想其他输入,那是另外的合同了。

z****e
发帖数: 54598
122
这次几乎必然是一次多张好吧?
如果一次一张,一个tcp连接在同一个时间点内只能处理一张票
那几十个连接哪里够啊?
并发上五千,那就是五千个连接才行好吧?
这次必然是5000/n,n是你外围机的数量
而且因为http,安全验证以及各种html的处理,web server几乎必然不可能一台顶住
所以肯定是n要大于某一个数值才可成立
所以应该是n>=100,然后每次至少是5000/100=50张票好吧?
你一次一张票,才开几十个连接,你这叫并发上万?
哈?好意思,这叫并发上几十好吧?
t**********1
发帖数: 550
123
买票还要web前端,支付,capcha,是不是都要做?
赵策和古德霸说着个根本不是12036。我觉得这个理解也可以。这就是一个赌局。

【在 i**i 的大作中提到】
: 我是中立态度,我什么也不想。
: 输入车次没说仅输入一个车次,并且买票也确实是几张一起买的。所以一次多张的解读
: 没问题。

z****e
发帖数: 54598
124

你可以不做啊,但是并发上五千是目标
这点并发都实现不了,那就不用谈了
并发上万什么意思?

【在 t**********1 的大作中提到】
: 买票还要web前端,支付,capcha,是不是都要做?
: 赵策和古德霸说着个根本不是12036。我觉得这个理解也可以。这就是一个赌局。

t**********1
发帖数: 550
125
已经订好最多500了。正常200了。
200个前端机啥概念?照我现在这个核心及的性能,
前端机是二级cache机的话,
最少也能服务每秒2亿请求。
这还是按照1M/s请求算的。
如果我的性能是10M/s的话,那是每秒20亿请求。呵呵。

【在 z****e 的大作中提到】
:
: 你可以不做啊,但是并发上五千是目标
: 这点并发都实现不了,那就不用谈了
: 并发上万什么意思?

z****e
发帖数: 54598
126

对啊,并发数要谈好
你一个连接只准一张票的话
这里并发不过几百
这点并发有什么意义?
就是因为你连接数量只有200-500
所以每次必然是多张票
要不然怎么模拟?
总共并发不过200-500的话,这种数量级随便一个东西都能做
要你干嘛?

【在 t**********1 的大作中提到】
: 已经订好最多500了。正常200了。
: 200个前端机啥概念?照我现在这个核心及的性能,
: 前端机是二级cache机的话,
: 最少也能服务每秒2亿请求。
: 这还是按照1M/s请求算的。
: 如果我的性能是10M/s的话,那是每秒20亿请求。呵呵。

z****e
发帖数: 54598
127
如果n = 200 ~ 500的话
那每次必然是
10000/500 = 20 ~ 10000/200 = 50
也就是每次大概是20~50张票
这个才是真实的12306的模拟好吧?
一次一张票,区区上百的并发谁做不出来?
z****e
发帖数: 54598
128
拜托老魏专业点
不要老弄点外行的拙劣表演
一次一张票并发数量不过几百
人家12306并发数量可是上万的
你这点东西能说明什么?
一次几十张票完全是考虑到了你的外围机的存在之后的简化
如果连外围机都考虑进去,你这里根本就是上万个https协议同时进行
已经给你简化很多了,连并发数都要简化,就没法谈了
i**i
发帖数: 1500
129
我尽量中立地解读。有什么有争议的地方你们二位各让一步。
显然你不用做前端,只提供对外的接口。古德霸仅限于调用你的接口完成订票、退票和
查询,但是你要保证这个接口符合赌局的约定。

【在 t**********1 的大作中提到】
: 买票还要web前端,支付,capcha,是不是都要做?
: 赵策和古德霸说着个根本不是12036。我觉得这个理解也可以。这就是一个赌局。

i**i
发帖数: 1500
130
少说了一个支付,支付本身由外围机完成。
订完票去支付到支付完成,魏老师得有一个合理的接口来支持。没问题吧?

【在 i**i 的大作中提到】
: 我尽量中立地解读。有什么有争议的地方你们二位各让一步。
: 显然你不用做前端,只提供对外的接口。古德霸仅限于调用你的接口完成订票、退票和
: 查询,但是你要保证这个接口符合赌局的约定。

相关主题
魏公公,赌局我接了,你把500万/秒的订票系统做出来老魏号称100%出票,现在的算法有碎片化问题吧。
无论如何抢,最后顶多10张票会有些震荡古德霸放个带细节设计的方案吧
赌约在此100%出票还真没在赌约里。
进入Programming版参与讨论
i**i
发帖数: 1500
131
不是12306没问题。但是这个赌局是一个订票系统,这个是有共识的。

【在 t**********1 的大作中提到】
: 买票还要web前端,支付,capcha,是不是都要做?
: 赵策和古德霸说着个根本不是12036。我觉得这个理解也可以。这就是一个赌局。

d****r
发帖数: 300
132
我来帮着算一下,一个http roundtrip 要2 ms, 老魏的机器处理1000 request per ms
, 这样需要2000个connection同时转,才能产生期待的load. 如果有更快的http
roundtrip, 再算。

【在 i**i 的大作中提到】
: 我尽量中立地解读。有什么有争议的地方你们二位各让一步。
: 显然你不用做前端,只提供对外的接口。古德霸仅限于调用你的接口完成订票、退票和
: 查询,但是你要保证这个接口符合赌局的约定。

i**i
发帖数: 1500
133
各位,不讨论技术实现问题,只关注这个赌约条款。
有争议的地方可以拿出来,供二位参考。
m***i
发帖数: 2480
134
为什么不在同台机器看谁的throughput 在cpu 50%高呢。

【在 t**********1 的大作中提到】
: 5000车次,每车次10站,3000票。输入车次,上车下车站,给回有 票没票信 息,有票
: 要占住,中途不换座,要1微秒完成。我不管你单线程多线程。
: 仔细阅读,输入和输出。这是好虫的要求。
: 这就是赌约。
: 你想其他输入,那是另外的合同了。

y****w
发帖数: 3747
135
不能假定前端把Request打包?比如每1/10s或1000个request? 对买盘来说可接受。他
们赌的还是server端算法吧

linear

【在 n********d 的大作中提到】
: 这个不容易。一个难点在于如果不能换座位,这个问题是NP-Hard的,分配位置的时候
: 肯定是要greedy算法,比如first available seat。Mark seat availability,linear
: search太慢。第二个难点在网络上,千兆不行。不调kernel,千兆大概也就能达到6/
: 700mbps,一个request有TCP handshake,每个tcp包最短54字节,一兆request每秒肯
: 定不行。这个还是假设一个TCP连接的情况。1MTCP连接恐怕要用异步。还要调网卡和
: kernel参数。5000车次是互相独立的,这个简化问题了。感觉内存IO问题不大,如果是
: 简单的mark seat, linear search的话。如果用更复杂的数据结构就不好说了。

s*******m
发帖数: 58
136
很高兴有一个观摩学习的机会。不过想插一句,这个问题的的难度和铁路网的拓扑结构
有很大关系。最简单的结构,全是直线,和最复杂的结构,一个全联通的网的差别,可
是好几个数量级的。举个例子,站A到站B的path,在最极端的情况下,可能有e^N条,
没有办法事先cache下来,只能实时计算。
所以,这个问题是一个heavy computing 的问题,需要用很多的资源来算。
现在两位的赌约实际上是把它简化成了一个怎样优化IO和system来做简单计算的问题。
相信两位不管谁胜谁负,围观者都可以学到不少东西。不过,这只是一个被简化过不知
道多少的问题。
不管结果怎样,我希望大家对12306的设计者还是保留一些敬意。我做的工作和他们很
像,我知道有多难。我们不care IO和system的优化,我们care 算法,我们的CPU大部
分时候都在算。
z****e
发帖数: 54598
137
很高兴滴看到群众们的眼睛是雪亮的
老魏的各种小伎俩已经被识破了
老魏要做的已经是一个简化得不能再简单的东西了
其实到现在也不过是一个并发上百的单机服务器而已
还没有txn,没有支付,没有html render,没有security,没有联票套票
可以说是什么都没有
离真正的12306可谓是十万八千里远
讨论到这里基本上做的是什么群众们心里都有数了
在此应该特别感谢计数器这个说法提出者
区区三个字把老魏所有伎俩全部秒杀
w********2
发帖数: 16371
138
看了一眼,感觉好虫输面大呀。
n****6
发帖数: 570
139
一个core 负责连接200个session,并且数据量不大情况下问题不大。一个core负责计算
。如果计算没啥问题的话,感觉好虫压力比较大。

【在 w********2 的大作中提到】
: 看了一眼,感觉好虫输面大呀。
t**********1
发帖数: 550
140
你认为2000个session压力会大么?

【在 n****6 的大作中提到】
: 一个core 负责连接200个session,并且数据量不大情况下问题不大。一个core负责计算
: 。如果计算没啥问题的话,感觉好虫压力比较大。

相关主题
100%出票还真没在赌约里。目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活
是否把好虫请来说说,我这个做出来,赌约算数不算数?用计数器解决并发问题
扯两句魏老师vs好虫一个500w/s并发的计数器
进入Programming版参与讨论
n****6
发帖数: 570
141
实话实说没啥问题。但是如果好虫不停的发新连接那就是另外问题了。

【在 t**********1 的大作中提到】
: 你认为2000个session压力会大么?
t**********1
发帖数: 550
142
所以我已经把他那条路堵死了。

【在 n****6 的大作中提到】
: 实话实说没啥问题。但是如果好虫不停的发新连接那就是另外问题了。
1 (共1页)
进入Programming版参与讨论
相关主题
出票正确率的定义,赵,姜请进。是否把好虫请来说说,我这个做出来,赌约算数不算数?
每秒500万, 结论出来看了扯两句魏老师vs好虫
魏公公,赌局我接了,你把500万/秒的订票系统做出来目前来看,魏老师是真刷子,好虫没亮招,权且判断是花活
无论如何抢,最后顶多10张票会有些震荡用计数器解决并发问题
赌约在此一个500w/s并发的计数器
老魏号称100%出票,现在的算法有碎片化问题吧。所有人拿到这个需求第一反应都是如何处理并发锁
古德霸放个带细节设计的方案吧老魏绝对是人才
100%出票还真没在赌约里。没干过大数据云计算的不用琢磨12306了
相关话题的讨论汇总
话题: tcp话题: 好虫话题: 并发话题: 车次话题: 12306