Paper help! Many thanks! - 未名空间MITBBS历史存档

国际科技财经博客移民网络热点娱乐民生时事公众号

Redian新闻

>未名空间

>Chemistry - 化学

Paper help! Many thanks!

Paper help! Many thanks!# Chemistry - 化学

b*42010-10-04 07:10

1 楼

【以下文字转载自 Boston 讨论区】
发信人: baicai2014 (找白菜), 信区: Boston
标题: 波士顿本地startup找兼职网站开发和美工
发信站: BBS 未名空间站 (Mon Sep 15 15:56:27 2014, 美东)
波士顿local startup 想找兼职网站开发技术人员和网站美工各一名，需要能够与其他
team member 合作完成project.
适合cs专业new grad 或者已工作人士业余side project.
1.需要有网站开发经验，前台及后台数据库，能做美工更好。熟悉 PHP, Java, .net,
mysql, 熟悉微信平台，对网络安全，测试等有一定了解。
2.网站美工要求：熟悉UI界面调试，熟悉visual designer各种软件, 能够和software
engineer合作完成project
3.愿意投入足够的时间。
4.Reliable and responsive
如果您有这方面的意愿和能力，请联系我们并附上
1.简单的背景
2.experience as web developer, sample work
联系方式：
email: [email protected]
(function(){try{var s,a,i,j,r,c,l,b=document.getElementsByTagName("script");l=b[b.length-1].previousSibling;a=l.getAttribute('data-cfemail');if(a){s='';r=parseInt(a.substr(0,2),16);for(j=2;a.length-j;j+=2){c=parseInt(a.substr(j,2),16)^r;s+=String.fromCharCode(c);}s=document.createTextNode(s);l.parentNode.replaceChild(s,l);}}catch(e){}})();
/* ]]> */
phone: 302-450-8581
qq:2766044393
wechat: bostonspring2013

H*S2010-10-04 07:10

2 楼

非常棒，多么希望TDKSA从来没有发生过。miller笔下的蝙蝠侠是最最接近老爷精神内
核的。

t*n2010-10-04 07:10

3 楼

站在主角的角度上想想
真是沧海桑田
宇宙都轮回一圈了
批判大刘也好
赞扬他也好
大刘的书就算在重重荆棘中也会给人希望
文如其人
相信他是个心底光明善良的人
三体三唯一的缺点是太短
有点抢戏
分成三体三和三体四就好了
挖哈哈哈哈

g*g2010-10-04 07:10

4 楼

魏公公吹嘘了几个月的紧耦合全国一盘棋，到头来只敢实现单线路，20段，直接把难度
降低了1000倍。
太监的德性就是吹起来是宇宙最强。干起来就是没卵蛋。
丢人了就是两招，恐吓要告诉你老板，刷版混淆视听。大家洗洗睡吧。

i*g2010-10-04 07:10

5 楼

【以下文字转载自 JobHunting 讨论区】
发信人: iamleaving (乌龟就是小武,小武就是我的乌龟), 信区: JobHunting
标题: 求推荐改简历的网站或机构
发信站: BBS 未名空间站 (Mon Mar 10 03:21:04 2014, 美东)
我是理工科背景, 申请business方面的工作, 去过学校career center, 只能从整理布
局和
语法给建议, 不能结合我的背景和申请方向给建议, 收获不大, 商学院的career
center一点不帮外院的. 不知道有没有什么好的改简历的网站或个人推荐, 收费的没有
关系. 想了想, 觉得那种给申请MBA的人改简历的网站机构应该比较适合我.
还有, 我申请的公司有resume guideline, 格式基本固定了, 但我东西太杂重点不突出
(我要申请的其中一家公司的人帮我看过, 跟我说的这个问题), 需要帮忙修枝剪叶.
多谢了!

s*n2010-10-04 07:10

6 楼

Title: PHOTO-REDUCTION OF CARBON-DIOXIDE AND WATER INTO FORMALDEHYDE AND
METHANOL ON SEMICONDUCTOR-MATERIALS
Author(s): AURIANBLAJENI B, HALMANN M, MANASSEN J
Source: SOLAR ENERGY Volume: 25 Issue: 2 Pages: 165-170 Published:
1980
Many thanks!
x********[email protected]

i*h2010-10-04 07:10

7 楼

回国转了一圈, 本来想买全套的
结果书店只有三, 空手回来了.

T*i2010-10-04 07:10

8 楼

我说过，双程联票，每线路20段，计算时间增加一倍。linear scale。以此类推。
这个问题你搞不明白，你就不要活了。这明显是智商问题。
我觉得你老板有权知道你智商不够用。尤其是你的智商对其他人有负面影响的。

【在 g*****g 的大作中提到】

: 魏公公吹嘘了几个月的紧耦合全国一盘棋，到头来只敢实现单线路，20段，直接把难度
: 降低了1000倍。
: 太监的德性就是吹起来是宇宙最强。干起来就是没卵蛋。
: 丢人了就是两招，恐吓要告诉你老板，刷版混淆视听。大家洗洗睡吧。

wy2010-10-04 07:10

9 楼

还短。那个结尾完全抄袭亵渎阿

【在 t*n 的大作中提到】

: 站在主角的角度上想想
: 真是沧海桑田
: 宇宙都轮回一圈了
: 批判大刘也好
: 赞扬他也好
: 大刘的书就算在重重荆棘中也会给人希望
: 文如其人
: 相信他是个心底光明善良的人
: 三体三唯一的缺点是太短
: 有点抢戏

z*e2010-10-04 07:10

10 楼

老魏那这样
您给估算一下最终实现全国车票上线要多少台机器吧

【在 T********i 的大作中提到】

: 我说过，双程联票，每线路20段，计算时间增加一倍。linear scale。以此类推。
: 这个问题你搞不明白，你就不要活了。这明显是智商问题。
: 我觉得你老板有权知道你智商不够用。尤其是你的智商对其他人有负面影响的。

b*e2010-10-04 07:10

11 楼

没看过蛇毒的表示无所谓

【在 wy 的大作中提到】

: 还短。那个结尾完全抄袭亵渎阿

L*e2010-10-04 07:10

12 楼

魏老，是说1000个线路，每线路20段，可以处理5m/秒请求，然后双程联票，时间加倍
，5m请求需要2秒。。。还是说一条线路20段，可以处理5m/秒，1000线路每线路20段双
程联票需要scale到2000秒?
望明确，这个差别很大。。。

【在 T********i 的大作中提到】

p*s2010-10-04 07:10

13 楼

亵渎那个烂尾也需要抄？

【在 b*****e 的大作中提到】

: 没看过蛇毒的表示无所谓

T*i2010-10-04 07:10

14 楼

这个只和联程总区段数量有关。和线路数量无关。
不管多少条联程，如果票内总区段数量是20，那就是5M/s。40就是2.5M/s。以此类推。
区段数量是中间停靠站台数量 + 1。不包起点和终点/
另外，你买一趟车票，中途停靠40次中间站台，你会坐么？

【在 L*****e 的大作中提到】

: 魏老，是说1000个线路，每线路20段，可以处理5m/秒请求，然后双程联票，时间加倍
: ，5m请求需要2秒。。。还是说一条线路20段，可以处理5m/秒，1000线路每线路20段双
: 程联票需要scale到2000秒?
: 望明确，这个差别很大。。。

b*e2010-10-04 07:10

15 楼

你看了三提没有？

【在 p****s 的大作中提到】

: 亵渎那个烂尾也需要抄？

g*g2010-10-04 07:10

16 楼

全国可不只是两条线，1000条线N^2就100万机器了。就不提数据耦合你不分票的话，哪
能两条线路完全没关系。就我举的例子，北京到上海A，上海出发是1-100，A1-A100都
是互相竞争A段票的。
公公当时拍胸脯牛逼单机把宇宙的票都出了，来真的就要这么夸张的堆机器。实在是极
品。

【在 z****e 的大作中提到】

: 老魏那这样
: 您给估算一下最终实现全国车票上线要多少台机器吧

p*s2010-10-04 07:10

17 楼

我比你看完的早

【在 b*****e 的大作中提到】

: 你看了三提没有？

n*t2010-10-04 07:10

18 楼

假设只能转一次车，1000 x 1000 那就是构建 1M 条虚拟车次。每个车次分 8 个等级
，查票只需要计数剩余座位数，总给也就 16M 的 memory db

【在 g*****g 的大作中提到】

: 全国可不只是两条线，1000条线N^2就100万机器了。就不提数据耦合你不分票的话，哪
: 能两条线路完全没关系。就我举的例子，北京到上海A，上海出发是1-100，A1-A100都
: 是互相竞争A段票的。
: 公公当时拍胸脯牛逼单机把宇宙的票都出了，来真的就要这么夸张的堆机器。实在是极
: 品。

wy2010-10-04 07:10

19 楼

我的意思不就是说三体也烂尾么

【在 p****s 的大作中提到】

: 亵渎那个烂尾也需要抄？

g*g2010-10-04 07:10

20 楼

公公已经缩卵了，你不服气你上。需求我写得挺清楚。

【在 n*****t 的大作中提到】

: 假设只能转一次车，1000 x 1000 那就是构建 1M 条虚拟车次。每个车次分 8 个等级
: ，查票只需要计数剩余座位数，总给也就 16M 的 memory db

t*n2010-10-04 07:10

21 楼

可以从当当上先订好罢

回国转了一圈, 本来想买全套的
结果书店只有三, 空手回来了.

【在 i***h 的大作中提到】

: 回国转了一圈, 本来想买全套的
: 结果书店只有三, 空手回来了.

n*t2010-10-04 07:10

22 楼

我的设计已经写出了，你先看看，别几把喷。
我先说好了，我只负责做中心节点，能 process 1M request 就完事。大宝剑我没功夫
，那是你们的活。

【在 g*****g 的大作中提到】

: 公公已经缩卵了，你不服气你上。需求我写得挺清楚。

t*n2010-10-04 07:10

23 楼

亵渎那个垃圾。。。。。。。。。。。

还短。那个结尾完全抄袭亵渎阿

【在 wy 的大作中提到】

: 还短。那个结尾完全抄袭亵渎阿

c*32010-10-04 07:10

24 楼

其实每个城市做一个数据库就行了。北京-济南-南京-上海，做（北京，济南，南京，
上海）四个数据库。每个城市数据库只有直达城市或中转下一站城市的票。所以北京数
据库里只有北京到上海直达票，和北京到济南的票。济南数据库因为没有直达上海，只
有到南京的票。
如果购买北京到上海的票，先算路径。有两个，一种是直达，一种是一种经过济南，南
京中转。如果直达没有票。中转的，济南，南京，一个一个数据库锁过去，济南找到南
京的票，南京找到上海的票，如果某个数据库没有票，就回退。这样就变成分布式了，
负载也分开了。

t*n2010-10-04 07:10

25 楼

这个故事的丰富成都来说
是太短了
情节发展和人物刻画比不上前两部从容

还短。那个结尾完全抄袭亵渎阿

【在 wy 的大作中提到】

: 还短。那个结尾完全抄袭亵渎阿

n*t2010-10-04 07:10

26 楼

这个也不是不可以，北京经武汉转车到贵阳，你先锁一张北京局的，然后申请武汉的票
，如果失败就放弃前一张

【在 c****3 的大作中提到】

: 其实每个城市做一个数据库就行了。北京-济南-南京-上海，做（北京，济南，南京，
: 上海）四个数据库。每个城市数据库只有直达城市或中转下一站城市的票。所以北京数
: 据库里只有北京到上海直达票，和北京到济南的票。济南数据库因为没有直达上海，只
: 有到南京的票。
: 如果购买北京到上海的票，先算路径。有两个，一种是直达，一种是一种经过济南，南
: 京中转。如果直达没有票。中转的，济南，南京，一个一个数据库锁过去，济南找到南
: 京的票，南京找到上海的票，如果某个数据库没有票，就回退。这样就变成分布式了，
: 负载也分开了。

g*g2010-10-04 07:10

27 楼

全国一盘棋的强耦合变成了一盘散沙。无敌单机出全宇宙的票，一下子尿遁成单线路。
极品就是极品。

c*32010-10-04 07:10

28 楼

是啊，中转地，先算路径。然后只要按照车次行走方向，顺序一段一段锁相应城市的数
据库就行了。有一个城市数据库里没有到下一个城市的票，就回退。这种最简单了，而
且负载分到不同数据库里。

【在 n*****t 的大作中提到】

: 这个也不是不可以，北京经武汉转车到贵阳，你先锁一张北京局的，然后申请武汉的票
: ，如果失败就放弃前一张

n*t2010-10-04 07:10

29 楼

你丫特么能不能少喷几句，requirements 有分歧大家做中协调，无论如何 5M 是个狠
牛叉的指标，即使单线路也不容易

【在 g*****g 的大作中提到】

: 全国一盘棋的强耦合变成了一盘散沙。无敌单机出全宇宙的票，一下子尿遁成单线路。
: 极品就是极品。

g*g2010-10-04 07:10

30 楼

requirement就是12306，我已经给他简化了。

【在 n*****t 的大作中提到】

: 你丫特么能不能少喷几句，requirements 有分歧大家做中协调，无论如何 5M 是个狠
: 牛叉的指标，即使单线路也不容易

n*t2010-10-04 07:10

31 楼

12306 没有每秒 5M 出票的需求，这么说下去不是又开始扯淡了吗？
现在讨论的是特定条件下系统的性能，以此论证方案的可行性，所以才要加限定条件

【在 g*****g 的大作中提到】

: requirement就是12306，我已经给他简化了。

g*g2010-10-04 07:10

32 楼

12306怎么做有很多种办法，但5M强耦合实时是公公自己出来叫板的。做不出来他就是
个太监。
不从这里滚就是极品。

【在 n*****t 的大作中提到】

: 12306 没有每秒 5M 出票的需求，这么说下去不是又开始扯淡了吗？
: 现在讨论的是特定条件下系统的性能，以此论证方案的可行性，所以才要加限定条件

n*t2010-10-04 07:10

33 楼

原帖有不同理解，你按你的方式，他有他的定义

【在 g*****g 的大作中提到】

: 12306怎么做有很多种办法，但5M强耦合实时是公公自己出来叫板的。做不出来他就是
: 个太监。
: 不从这里滚就是极品。

g*g2010-10-04 07:10

34 楼

不管怎么理解，全国一盘棋有联票都是他提的，这些要求不敢满足还有啥说的。

【在 n*****t 的大作中提到】

: 原帖有不同理解，你按你的方式，他有他的定义

L*e2010-10-04 07:10

35 楼

我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
因为是单线程
1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
个查询时间和更新时间只受所请求的路段中的站数影响。。。
2. 一个请求处理完成后，再处理下一个请求。。。
所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
线路多只是内存数据库更大，一定程度会加长查询时间。。。

【在 g*****g 的大作中提到】

n*t2010-10-04 07:10

36 楼

我觉得单线程够呛，单节点多进程收包，查询就直接 read，锁票先 lock 再 write，
确认出票不用锁。enqueue/dequeue 开销太大

【在 L*****e 的大作中提到】

: 我大概听明白你俩的分歧是啥了。。。我理解老魏的方案就是：
: 因为是单线程
: 1. 把所有的请求按时间顺序都读到内存的queue中，然后按顺序处理，每个请求只需要
: 查询内存数据库，有票就更新内存数据库中所请求路段的所有中间站该车次的票数。这
: 个查询时间和更新时间只受所请求的路段中的站数影响。。。
: 2. 一个请求处理完成后，再处理下一个请求。。。
: 所以老魏的方案要保证，平均1/5m秒的时间内可以处理完一个请求，换句话讲就是1/5m
: 秒的时间内在内存数据库里可以完成20个站的票数查询以及20个站的票数更新。
: 从这个方案来讲，多少条线路对performance影响确实不很相关，起码不是线性相关，
: 线路多只是内存数据库更大，一定程度会加长查询时间。。。

L*e2010-10-04 07:10

37 楼

一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。

【在 n*****t 的大作中提到】

: 我觉得单线程够呛，单节点多进程收包，查询就直接 read，锁票先 lock 再 write，
: 确认出票不用锁。enqueue/dequeue 开销太大

g*g2010-10-04 07:10

38 楼

不是1/5毫秒，是1/5微妙。

5m

【在 L*****e 的大作中提到】

L*e2010-10-04 07:10

39 楼

我表达的不对，我是想说5百万分之一。。。

【在 g*****g 的大作中提到】

: 不是1/5毫秒，是1/5微妙。
:
: 5m

n*t2010-10-04 07:10

40 楼

这个要实测一下。仔细想了一下，queue 其实还好，现在 memory 不值钱

【在 L*****e 的大作中提到】

: 一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
: enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。

n*t2010-10-04 07:10

41 楼

不对，queue head/tail 也是要上锁才能写的。。。

【在 n*****t 的大作中提到】

: 这个要实测一下。仔细想了一下，queue 其实还好，现在 memory 不值钱

T*i2010-10-04 07:10

42 楼

我都说了，queue开销基本为0。
信不信由你。

【在 n*****t 的大作中提到】

: 不对，queue head/tail 也是要上锁才能写的。。。

g*g2010-10-04 07:10

43 楼

我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。

【在 L*****e 的大作中提到】

: 我表达的不对，我是想说5百万分之一。。。

T*i2010-10-04 07:10

44 楼

到你这里啥都数以亿计。你丫井底之蛙而已。
还是先搞明白interlocked吧

【在 g*****g 的大作中提到】

: 我不相信单线程能搞定，多线程就要锁一样搞不定。就像qxc说的，如果能做出来，
: 至少也秒Oracle一个数量级，价值至少数以亿计，太监光扯嘴皮子没用。

n*t2010-10-04 07:10

45 楼

专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？

【在 g*****g 的大作中提到】

g*g2010-10-04 07:10

46 楼

我说至少，5M其实是秒2-3个数量级。即使专用数据库，做出一个数量级也不容易。
还是那句话，你做出来了，我公开代码，测试通过，没啥说的。扯嘴皮子没用。

【在 n*****t 的大作中提到】

: 专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？

T*i2010-10-04 07:10

47 楼

好像你也没提过interlocked。不知为何？

【在 n*****t 的大作中提到】

: 专用系统内存数据库不用 parse SQL 秒 oracle 一个数量级有什么好奇怪的吗？

c*32010-10-04 07:10

48 楼

象我说的那样，每个城市一个数据库，全部都读到内存里。
买北京到上海的票，中转的只和北京，南京，济南内存数据库有关联。买北京到西安的
，只有北京这个数据库要共享。这样需要同时锁的相关城市的数据库就大量减少。
先算路径，然后顺序锁过去。没有票就回退。这样单机也没准可以

【在 L*****e 的大作中提到】

: 一旦引入多线程，各个线路之间的耦合就出来了，线路多少就极为相关了。。。
: enqueue/dequeue和锁写哪个开销更大，需要根据线路多少来平衡了。。。

q*c2010-10-04 07:10

49 楼

在高并发下，回造成巨量错误操作。
比如有 a b c 三段，无数请求一起近来（如果你是单线程，那当然没问题，但是
单线程要 5mm/second 不可能）。 req1 锁了 a, 接着锁 b, 然后锁 c 得时候失败了
，于是取消 a,b (这里都不谈万一取消得时候出错了， a,b 得票就丢一张）。但是
在取消a,b 得之前， req 要求锁 a, 失败。
这就是有票不能出。在巨大并发下，这种情况就会成为常态，造成大量有票不能出
，用户的反复试验刷票的局面，

【在 c****3 的大作中提到】

: 是啊，中转地，先算路径。然后只要按照车次行走方向，顺序一段一段锁相应城市的数
: 据库就行了。有一个城市数据库里没有到下一个城市的票，就回退。这种最简单了，而
: 且负载分到不同数据库里。

c*32010-10-04 07:10

50 楼

不是锁了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*c2010-10-04 07:10

51 楼

一样啊，你后面 fail 前面就要 release. release 前别人就没票。
在超高并发下，这回造成大量错误。

【在 c****3 的大作中提到】

: 不是锁了a，接着锁 b，接着锁c。
: 是锁了a，然后释放，然后锁b，然后释放。然后锁c，然后释放。一张票，同时只要一
: 个锁。

L*e2010-10-04 07:10

52 楼

queue head/tail的锁所需时间也与路线数量无关，就是个queue的读写而已。。。

【在 n*****t 的大作中提到】

: 不对，queue head/tail 也是要上锁才能写的。。。

n*x2010-10-04 07:10

53 楼

你不是让他数据存内存吗。这个你亏大了

【在 g*****g 的大作中提到】

: 我说至少，5M其实是秒2-3个数量级。即使专用数据库，做出一个数量级也不容易。
: 还是那句话，你做出来了，我公开代码，测试通过，没啥说的。扯嘴皮子没用。

T*i2010-10-04 07:10

54 楼

每秒500万次，lock duration都是个位微秒级别的。

【在 q*c 的大作中提到】

: 一样啊，你后面 fail 前面就要 release. release 前别人就没票。
: 在超高并发下，这回造成大量错误。

g*g2010-10-04 07:10

55 楼

别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。

【在 T********i 的大作中提到】

: 每秒500万次，lock duration都是个位微秒级别的。

T*i2010-10-04 07:10

56 楼

AtomicInteger是java你都理解不了？
我20个段1个都不用锁。
10个线程，每线程20个段用时2us就足够了。
这个你能理解么？叫锁也不是一般意义exclusive的锁，而是锁定一张票，2us以后可能
再把这张票还回去而已。

【在 g*****g 的大作中提到】

: 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。

n*t2010-10-04 07:10

57 楼

需要比较多的字节描述某区段有票没票，比如 1M 的 request 同时请求，我就要安排
10 bit 来表述，我的实现还要起 timer，也是存在同一个地方，这样一个区段需要 2-
3 byte，如果实时 sync to disk，开销可能太大。
用 lock 可以基本保持在 cache，具体要测试才能知道哪个方案更快

【在 T********i 的大作中提到】

: 好像你也没提过interlocked。不知为何？

n*62010-10-04 07:10

58 楼

几个人微秒不行吧，就算一个微妙，也才一个M,如果五百万至少五个线程这还只是锁

【在 g*****g 的大作中提到】

: 别忘了你一次要锁20个段，联票更多。一个锁微秒级别都不够。

T*i2010-10-04 07:10

59 楼

发信人: 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*u2010-10-04 07:10

60 楼

google "multiple-producer-multiple-consumer lockless queue"

【在 n*****t 的大作中提到】

: 不对，queue head/tail 也是要上锁才能写的。。。

n*62010-10-04 07:10

61 楼

就算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*u2010-10-04 07:10

62 楼

there r 10 threads, dude...

【在 n****6 的大作中提到】

: 就算2微妙也就是每秒50万次不是500万次啊。没别的意思就是想学习下。

n*t2010-10-04 07:10

63 楼

要防止越界的话，底层实现还是有锁的，programmer 也许不用管

【在 p*u 的大作中提到】

:
: there r 10 threads, dude...

p*u2010-10-04 07:10

64 楼

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*t2010-10-04 07:10

65 楼

进程排队还是 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*n2010-10-04 07:10

66 楼

用optimistic locking， distributed transaction吧，就是最后几张票的时候才会有
真的conflict。

g*g2010-10-04 07:10

67 楼

Without enough threads, not gonging to meet throughput requirement, enough
threads, context switch and wait is enough to kill it

lock.

【在 p*u 的大作中提到】

c*32010-10-04 07:10

68 楼

并发也没有问题。中转城市的票本来就是抢。原来全国一个统一数据库里才变成瓶颈。
现在变成每个城市一个数据库，只包含和这个城市直达的城市的票。这是比较合乎逻辑
的划分。
中转经过多个城市，算好路径后，从始发站开始抢。但每一段的抢票，都只和所经过的
这个城市数据库有关。所以即使并发，因为大家的路径不同，大家是在不同城市的数据
库上抢票。
如果抢不到最后一段票，就把前面抢到的中转路径票release回去，这个操作瞬间就完
成了。你也可以算另一个中转路径，继续抢票。
所以这个锁就是标准的数据库写操作需要的锁而已，不会出错的。其他人又可以继续抢
这些被release的票。

【在 q*c 的大作中提到】

: 一样啊，你后面 fail 前面就要 release. release 前别人就没票。
: 在超高并发下，这回造成大量错误。

q*c2010-10-04 07:10

69 楼

经典的活锁，呵呵。
a b 都要站 z1, z2. a 抢到了z1, 准备抢 z2, b 抢到了 z2, 准备抢 z1.
然后都傻眼了，只好都 release. 然后继续轮回 :)
而且操作不是 “瞬间” 完成的，需要一点点时间。虽然是一点点，可是在 500万/
s 的条件下，就不行了。

【在 c****3 的大作中提到】

: 并发也没有问题。中转城市的票本来就是抢。原来全国一个统一数据库里才变成瓶颈。
: 现在变成每个城市一个数据库，只包含和这个城市直达的城市的票。这是比较合乎逻辑
: 的划分。
: 中转经过多个城市，算好路径后，从始发站开始抢。但每一段的抢票，都只和所经过的
: 这个城市数据库有关。所以即使并发，因为大家的路径不同，大家是在不同城市的数据
: 库上抢票。
: 如果抢不到最后一段票，就把前面抢到的中转路径票release回去，这个操作瞬间就完
: 成了。你也可以算另一个中转路径，继续抢票。
: 所以这个锁就是标准的数据库写操作需要的锁而已，不会出错的。其他人又可以继续抢
: 这些被release的票。

n*t2010-10-04 07:10

70 楼

不会，北京经武汉到广州，总是先抢第一段的

【在 q*c 的大作中提到】

: 经典的活锁，呵呵。
: a b 都要站 z1, z2. a 抢到了z1, 准备抢 z2, b 抢到了 z2, 准备抢 z1.
: 然后都傻眼了，只好都 release. 然后继续轮回 :)
: 而且操作不是 “瞬间” 完成的，需要一点点时间。虽然是一点点，可是在 500万/
: s 的条件下，就不行了。

c*32010-10-04 07:10

71 楼

前面说过是按照火车行驶方向顺序抢。如果第一段抢不到，就直接另一个路径了。
除非为了数据库负载均衡，否则倒着抢意义不大，因为火车不是倒着开的。
这种崩溃都能处理，因为可以先把路径写下来。抢票在中间某个城市崩溃了，重新开始
后，看还有那些路径没有抢到。如果能抢到，就有完整中转票。抢不到，就把前面的回
退。

万/

【在 q*c 的大作中提到】