g*****g
发帖数: 34805 | 1 大并发最大的问题永远不在于同步异步，而在于数据库。同步异步只不过多点少点机器。
x。 |
|
b*******s
发帖数: 5216 | 2 单线程应用于高并发其实要求处理的单个任务小，不具备阻塞性
否则也达不到要求 |
|
c******o
发帖数: 1277 | 3 play node的并发都是一台机上共享内存／OS的。
akka是不一样，akka 立足在 distributed computing， location neutral,你根本不
知道也不在乎call的另一个actor在哪儿 , scale/currency来说更强大,consistency
也更弱,只能自己做（刚刚deprecate STM)。 |
|
d*******r
发帖数: 3299 | 4 我觉得有很多逻辑是只有写程序那个人才知道能不能 partition, 能不能并发的吧 |
|
p*****2
发帖数: 21240 | 5
本来不就说了non－blocking了吗？无论是单线程，还是多线程，想高并发都不能阻塞
。 |
|
p*****2
发帖数: 21240 | 6
web request一般都可以并发。互相之间没什么关系。 |
|
p*****2
发帖数: 21240 | 7
大牛能不能谈谈上M的并发量一般Java是怎么解决的？ |
|
z****e
发帖数: 54598 | 8 这些东西真的是光说是不够的
还是实践最重要
这些理论就算懂，如果没有做过
人家还是不相信你会
不管怎样，最近好几个都跟这些大并发有关
要写文章，要干活，烦 |
|
z****e
发帖数: 54598 | 9 对，persistence搞定了之后
ejb都能轻松搞定这些并发
spring也可以，vert.x也可以
有的是办法，还可以针对性的优化每一个环节
最恶心的就是db那些sql script了，看了都烦
没办法，又不能不看，现在ql很多，爆发式增长
甚至还有jql，cql这些，而且没有一个统一的规范
以前sql还算比较统一，现在nosql一来，就更乱了 |
|
|
|
p*****2
发帖数: 21240 | 12 完全错误 node的并发不是多线程
through
种 |
|
p*****2
发帖数: 21240 | 13 变量的值总是最新的 有啥不确定的？ node让并发编程极其容易。 |
|
d*******r
发帖数: 3299 | 14 二爷我没有 bash Node 呀，Node 确实写并发挺方便的，特别是各种 Net/File IO，最
近用着确实挺爽的.
我只是觉得写 JS Closure 的时候，我需要注意这个 access external mutable
variables 的问题。
刚刚扫了一眼 CoffeeScript, Coffee 有个 do 关键词就是跟这个有关.
http://coffeescript.org/
When using a JavaScript loop to generate functions, it's common to insert a
closure wrapper in order to ensure that loop variables are closed over, and
all the generated functions don't just share the final values. CoffeeScript
provides the do keyword, which immediately invokes a passed function,... 阅读全帖 |
|
p*****2
发帖数: 21240 | 15
我感觉future下边是thread，actor更light weight，所以并发效果应该比future要好
。 |
|
c******o
发帖数: 1277 | 16 底下其实就是在thread pool上的callback
如果几个future互相之间没有先后等待关系 ，就是多线程并发。 |
|
p*****2
发帖数: 21240 | 17
是不是async的指得的是IO。你说的对，你这个是context switch，所以并发效果比
Node就差了。 |
|
d******e
发帖数: 2265 | 18 haskell需要并发模型马？
大牛们请教育。 |
|
|
|
c*******9
发帖数: 9032 | 21 haskell并发和并行可以很好的结合在一起。 |
|
|
j******f
发帖数: 825 | 23 Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
自己写，并发的问题其实
是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。 |
|
z****e
发帖数: 54598 | 24 多线程直接上框架，还写啥呀
没事找事，只有很少情况才会不得不去处理多线程的并发 |
|
z****e
发帖数: 54598 | 25 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异 |
|
j******f
发帖数: 825 | 26 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
concurrency问题。
对于IO来说，NODE的速度秒杀其他synchronous语言。 |
|
z****e
发帖数: 54598 | 27 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
j******f
发帖数: 825 | 28 Node callback很容易被误用，学会应用之后其实最容易效率也最高。api基本都有不要
自己写，并发的问题其实
是个ipc的问题，任何语言都需要解决这个问题。对于io来说node是不二选择。 |
|
z****e
发帖数: 54598 | 29 多线程直接上框架，还写啥呀
没事找事，只有很少情况才会不得不去处理多线程的并发 |
|
z****e
发帖数: 54598 | 30 fp涵盖了var
只是不推荐使用var
否则会在并发的时候用上大量的lock
会让你的程序变得难以维护
这一点上说，无论什么多线程的框架
其本意都是为了让用户不再使用lock
像单线程一样编程是目的
这个其实无论啥都是一样的
但是实现的手段截然不同，而且效果也很明显有差异 |
|
j******f
发帖数: 825 | 31 解决了IPC问题，NODE就解决了多机并发问题，也解决了一个线程挂掉的问题。
而对于其他语言，首先要解决IPC的问题，然后还要解决ITC问题，然后还要面临一大堆
concurrency问题。
对于IO来说，NODE的速度秒杀其他synchronous语言。 |
|
z****e
发帖数: 54598 | 32 其他框架根本不需要多process，去哪里来的ipc问题？
node的ipc放在其他框架就是itc，而且vert.x天生就有一个bus予以解决
node还要自己倒腾第三方工具予以解决，只有node需要倒腾第三方工具解决并发问题
其他都不用，哪怕是akka都是自己搞定，所谓ipc就是一个集成的问题
单机系统还需要集成的只有单线程，其他都不用，自己能搞定
这个完全是一个名词上的混淆，根本不是什么优势，是大大滴劣势
至于io快，纯粹胡说八道，vert.x vs node.js的报告到处都是
自己试试就知道node有多烂了，你还是没试过，凭想象来指责其他框架的问题 |
|
p*****2
发帖数: 21240 | 33 future heavy吧 并发不行 不过用起来简单 而且是monad |
|
m******t
发帖数: 635 | 34 Scala这么弱？ 还准备尝试下用Ｓcala写大并发呢 |
|
S*A
发帖数: 7142 | 35 channel 不是问题，每个 tcp socket 要对应一个 goroutine。
因为 go 鼓励的是 blocking 的编程模式。需要用 goroutine
来 block。感觉这个 goroutine 对应一个 socket 是不能上
大并发的。
network IO 是不可能耗尽的，就是 blocking 慢而以。
内存应该还好。
发。 |
|
w***g
发帖数: 5958 | 36 你这个情况，大并发，是go的核心竞争力。如果这都搞不定，还要go干嘛。如果只是几
千个thread, pthread就够了啊。
：
：【 在 walkrandom (walkrandom) 的大作中提到: 】 |
|
L*******k
发帖数: 42 | 37 题外话。你们这样一会儿go一会儿coroutine的搞高并发是不是在钻牛角尖走火入魔？
就算是你
们看不上的java+thread，拿台c3.2xlarge也随便处理几个K的qps啊。问题是你能有几
个K的qps？几十个K？又换句话说你都几十个K的在线业务量级了，公司起码也是若干B
的市值了吧，你拿go折腾来折腾去一年能省多少几块钱下来。
说白了就是钻技术不要太深，还是要最终outcome/impact为主导。
话说我们公司前几年就有个部门的一帮人装逼用Go写rpc server，结果问题一大堆，
跟公司其他Java为主的后端工程开发格格不入，怨声载道。 |
|
L*******k
发帖数: 42 | 38 所以说你折腾来折腾去其实跟go不go，并发大不大，没有半毛钱关系，就是想把老司机
也拉回起跑线而已。
公司上规模了，也轮不到你来决定用什么语言。 |
|
s********k
发帖数: 6180 | 39 你自己配置这个肯定更好，因为IO交互性应用，goroutine的schedule不一定会比epoll
这个更好，个人感觉你的问题不是goroutine 1：1 socket 不适合做大并发， 而是IO
密集型go不如手动好，就像开车自动车舒服省心，但是追求极致性能就需要手动档，go
的目的就是为了给大多数手动觉得麻烦人提供便利
话说你的go+epoll，现在最新的go1.9是不是也在做了？你是打算用C写底层，然后
signal去go吗？ |
|
S*A
发帖数: 7142 | 40
不知道你想如何改这个。现在问题是有 N 个 tcp 连接。
每一个发送都会有可能 block。如果你里面那个 for
loop 也是 N 个元素的话，并没有节省 goroutine。
如果里面那个 for loop service， << N 的话，那就是
发送的时候是等一个 tcp 发完了才发下一个，失去了
并发性。发送的数据包比一个Ethernet 包大多了。
一个 tcp 发玩一组才发下一个的带宽用不满。 |
|
h****n
发帖数: 596 | 41 姥爷脑栓塞和心急梗死并发，医生说无法用药。请问各位大虾，是不是这样呢？ |
|
s***d
发帖数: 15421 | 42 12306首秀被骂的狗血喷头后铁道部找来IBM、阿里巴巴等大企业要解决方案，给出的条
件是资金管够但是问题得解决。几大企业最后都拒绝了（其中阿里巴巴最后负责了排队
系统的建设）。12306开始自己尝试解决问题。他们发现市面上可以买到的成套解决方
案都不足以应付春运购票负载，所以只能自己改进已有的数据库（注：其实是改用
VMware SQLFire/GemFire，这里我之前理解错误）。以前12306用的是小型机，发现性
能严重不足，遂改用x86系统+linux平台（原平台为HP Superdome小型机，UNIX系统，
Sybase ASE数据库）。最后他们的核心系统用了十几个节点（现在应该是17节点）的多
路Xeon E7（具体几路待考），每个节点配1TB内存，数据库全部在内存中运行。2013年
春运，12306系统峰值负载11万tps，与2012年淘宝双11活动峰值负载相当，新的系统基
本经受住了考验。
补充：以上内容是我在2013年7月得知的信息，彼时没有任何公开来源提到过12306新系
统的技术细节。甚至，当时局外人没人知道12306已经在2012年开始做了技术改造。直
到数日... 阅读全帖 |
|
z***y
发帖数: 7151 | 43 原帖在ITPUB。 找不到了现在。
讨论话题：
1.如何让SQL Server支持高并发环境？
2.如何有效提升数据库性能？
3.你如何看待SQL Server未来几年的发展前景？
本期活动精彩案例分享：
【案例描述】
某零售巨头上线了一套基于微软系统的促销网站，系统本身已经稳定了，日常并发用户
数在200-300左右。大约在3个月之前的某天，销售部门老大准备举行一次全球性的促销
活动，要求把系统的并发数从目前的200-300提升10倍，达到2000-3000。
经过专业公司的压力测试，数据库在并发数达到600左右的时候，基本失去响应，由此
认定系统瓶颈存在于数据库端。一场轰轰烈烈的数据库性能调整就此展开。
【数据库环境描述】：
数据库类型： 某零售巨头促销专题网站
影响范围： 全球性
数据量： 500G
OS: Windows 2008
数据库版本： SQL Server 2008
数据库架构方式：单实例数据库
【案例进展】：
为了在有限的时间解决问题，甲方IT部门的老大亲自挂帅，组织了一支全球性的技术团
队，成员包括甲方自己的IT人员，软件供应商，系... 阅读全帖 |
|
W*******e
发帖数: 1268 | 44 学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
一，有人可能把这个东西和QQ或是网游相比。
但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据
，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就
以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
二，有人说春节期间订火车的这个事好像网站的秒杀活动。
的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个
事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次
，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，直接杀就好了。
另外，关于秒杀，完全可以做成只接受前N个用户的请求（完全不操作后端的任何数据
， 仅仅只是对用户的下单操作log），这种业务，只要把各个服务器的时间精确同步了
就可以了，无需在当时操作任何数据库。可以订单数够后，停止秒杀，然后批量写数据
库。火车票这个岂止是秒杀那么简单。能不能买到票得当时... 阅读全帖 |
|
H*******d
发帖数: 2394 | 45 【 以下文字转载自 WashingtonDC 讨论区 】
发信人: Westridge (不折腾), 信区: WashingtonDC
标 题: 学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
发信站: BBS 未名空间站 (Thu Jan 17 14:48:59 2013, 美东)
学习学习国内的IT项目-12306铁道部订票网站性能分析【转载】
业务
任何技术都离不开业务需求，所以，要说明性能问题，首先还是想先说说业务问题。
一，有人可能把这个东西和QQ或是网游相比。
但我觉得这两者是不一样的，网游和QQ在线或是登录时访问的更多的是用户自己的数据
，而订票系统访问的是中心的票量数据，这是不一样的。不要觉得网游或是QQ能行你就
以为这是一样的。网游和QQ 的后端负载相对于电子商务的系统还是简单。
二，有人说春节期间订火车的这个事好像网站的秒杀活动。
的确很相似，但是如果你的思考不在表面的话，你会发现这也有些不一样。火车票这个
事，还有很多查询操作，查时间，查座位，查铺位，一个车次不 行，又查另一个车次
，其伴随着大量的查询操作，下单的时候需要对数据库操作。而秒杀，... 阅读全帖 |
|
l******t
发帖数: 55733 | 46 人体重伤鉴定标准
（1990年3月29日司法部、最高人民法院、最高人民检察院、公安部司发［1990］070号
印发）
目 录
第一章 总 则
第二章 肢体残废
第三章 容貌毁损
第四章 丧失听觉
第五章 丧失视觉
第六章 丧失其他器官功能
第七章 其他对于人体健康的重大损伤
第一节 颅脑损伤
第二节 颈部损伤
第三节 胸部损伤
第四节 腹部损伤
第五节 骨盆部损伤
第六节 脊柱和脊髓损伤
第七节 其他损伤
第八章 附 则
第一章 总 则
第一条 本标准依照《中华人民共和国刑法》第八十五条规定，以医学和法医学的
理论和技术为基础，结合我国法医检案的实践经验，为重伤的鉴定提供科学依据和统一
标准。
第二条 重伤是指使人肢体残废、毁人容貌、丧失听觉、丧失视觉、丧失其他器官
功能或者其他对于人身健康有重大伤害的损伤。
第三条 评定损伤程度，必须坚持实事求是的原则，具体伤情，具体分析。损伤程
度包括损伤当时原发性病变... 阅读全帖 |
|
d**e
发帖数: 2420 | 47 国内过度治疗，给大家科普一下
http://blog.sina.com.cn/s/blog_71f607db0100r4wp.html
关于小儿手足口病的议论----附方舟子相关的科普佳文和某读者的回复
方舟子先生的《手足口病有那么可怕吗？》一文写得很好，对这个被无知地夸大了的区
区小病分析的很有理有据。文中的数据和结论与国际医学界的共识一致。
随后就有了“一个感染科医生” （以下简称“感染医” ）的《回复方舟子“手足
口病有那么可吗？” 》文。感觉也很值得一读。
感染医的文章一方面证实了方舟子对中国医生医院的指责，另一方面也让我更深刻
地了解到中国医生素质的低劣，医德的沦丧，政治的腐败，和医院的图财害命。
如果感染医提供的手足口病的死亡率为千分之零点五到千分之一是可靠数据的话，
那么该医院2010年死亡10个患儿就意味着他们收治了一万到两万个病例（就等于是每天
收治27－55个患儿）。这个数字是云南省去年全省一年的病例数。我怀疑任何医院能收
治如此多的病例。
假如该医院2010年只收治了一千到两千个患儿却产生了10例死亡的话，那么就等于
说有九个儿童是被你们“治死了” ！感染医，您说... 阅读全帖 |
|
p*****2
发帖数: 21240 | 48 这个话题比较大了。我随便聊聊吧。
基本上为了实现并行，我看到了三种现代的编程模式，线程，actor, 异步。
线程是现在应用最广的，也是最简单的，大概优缺点如下
优点：
1. 编程简单，并行的实现交给OS来处理，自己不用管关于线程调度的细节
2. 应用面广，几乎所有的语言，平台都支持
缺点：
1. 资源消耗大。线程虽然比进程light，但是由于现在高并发的需求不断增强，线程还
是显得太heavy了。线程需要被分配系统资源，并且context switch也是很costly的。
2. Thread safe很难保证，因此很多bug隐藏很深难于发现， 甚至有人认为不太可能写
出没有bug的多线程程序来。
3. 为了保证Thread safe, 需要同步线程，又不可避免的影响了concurrency。Java论
坛有个人挺有意思，说同步和并发是一致的，其实我认为这两个就是矛盾体。想高并发
就要少同步，或者不同步。
4. 很难调试。
因此线程的优点是上手容易，缺点主要是很难Thread safe和支持高并发。
那么为了解决这两个问题就引入了其他的并行编程模式，actor和异步。
Thread的... 阅读全帖 |
|
g*****g
发帖数: 34805 | 49 这个我老N年前就总结过了。
ORM的好处，易维护，把计算量迁移应用服务器上，容易处理高并发，缓存简单，可在不
同数据库间移植。在高并发的应用里，关系型数据库本身不能scale out，早晚是个瓶
颈，所以ORM提高了系统能支持的并发数。最近几年NoSQL DB的发展，就是单机数据库
系统在ORM下仍然是瓶颈下的必然道路。
Stored procedure的好处，在低并发，大数据量的一些应用上，如每日产生的报表有离
数据近的优势。但不易维护。近年Oracle在数据库服务器上内建对Java的支持，就是为
了提高可维护性。
SP对单个请求比ORM快几乎是必然的。但100个并发的请求，就不见得一样了，10000个
并发的请求，整一个能撑住的数据库服务器，就要比一个小数据库+一个应用服务器ORM
集群，要贵无数倍。别忘了Oracle之类的数据库是按可比CPU算钱的。
techniques
stored |
|
c*******0
发帖数: 5247 | 50
现代移动设备编程，不管是苹果还是android，有几个app是没有多线程的？你是说这些
app都是不明不白写出来的？
再说Go和多线程没啥直接关系，Go的思想是程序并发化，你单线程可以并发，多线程可
以并发，多核可以并发，多机可以并发，这有什么关系啊。你要问并发有没有用，是不
是扯淡，这里的人说了不算，你看看工业界有多少公司当年想上erlang就知道。可惜
Erlang的语法实在是令人发指，不然早就是很火的语言了。 |
|
