p*****2
发帖数: 21240 | |
p*****2
发帖数: 21240 | 2 刚才想了一下，现在大兵法的主要解决方案就是异步，这也是为什么Node这么火的原因
，还有新兴的Go语言，老树回春的Erlang。那么Java上边情况如何呢。
我的理解基本上最下边是NIO, 然后中间有一层Netty，上边有play，reactor，vert.x。
play本身是一个模仿rails的mvc框架。现在的趋势越来越不mvc了，所以前途有限。
play下边的akka很强大，但是即使coltzhao这样的scala大牛也认为太复杂了，可见流
行程度不会很大
reactor本身是想做一个framework，并不是直接可以创建app的，并且由于很新，
production还不可用。
vert.x是zhaoce大牛最中意的，算是完全copy了node的创意，并且解决了scale和
coordination的问题。当然在web server上，goodbug大牛早说过了，request都是独立
的，所以node完全没有压力。而vert.x最大的问题是不能实现纯异步，所以还必须实用
阻碍的线程，这样就造成了瓶颈，不利于大兵法。
所以，感觉JVM上确实还没有一个比较完美的大兵法解决方案。这也是为什么Google要
用Go来代替Java的一个原因？ |
p*****w
发帖数: 429 | 3 你是做网络的吗？
你这个大并发是什么？
x。
【在 p*****2 的大作中提到】
: 刚才想了一下，现在大兵法的主要解决方案就是异步，这也是为什么Node这么火的原因
: ，还有新兴的Go语言，老树回春的Erlang。那么Java上边情况如何呢。
: 我的理解基本上最下边是NIO, 然后中间有一层Netty，上边有play，reactor，vert.x。
: play本身是一个模仿rails的mvc框架。现在的趋势越来越不mvc了，所以前途有限。
: play下边的akka很强大，但是即使coltzhao这样的scala大牛也认为太复杂了，可见流
: 行程度不会很大
: reactor本身是想做一个framework，并不是直接可以创建app的，并且由于很新，
: production还不可用。
: vert.x是zhaoce大牛最中意的，算是完全copy了node的创意，并且解决了scale和
: coordination的问题。当然在web server上，goodbug大牛早说过了，request都是独立
|
p*****2
发帖数: 21240 | 4
web的大兵法
【在 p*****w 的大作中提到】
: 你是做网络的吗？
: 你这个大并发是什么？
:
: x。
|
d*******r
发帖数: 3299 | 5 好帖，关注中。
所以看完还是觉得 vert.x 最接近 production?
"而vert.x最大的问题是不能实现纯异步，所以还必须实用阻碍的线程，这样就造成了
瓶颈，不利于大并发。"
这个我没太懂，vert.x 这种基于 messages, event, event bus, event handler 的框
架，为什么不能实现纯异步呢。
我觉得 vert.x 也提供 blocking worker thread, 只是多了一个 option，让其表现力
更强而已，可以选择不用啊。
x。
【在 p*****2 的大作中提到】
: 刚才想了一下，现在大兵法的主要解决方案就是异步，这也是为什么Node这么火的原因
: ，还有新兴的Go语言，老树回春的Erlang。那么Java上边情况如何呢。
: 我的理解基本上最下边是NIO, 然后中间有一层Netty，上边有play，reactor，vert.x。
: play本身是一个模仿rails的mvc框架。现在的趋势越来越不mvc了，所以前途有限。
: play下边的akka很强大，但是即使coltzhao这样的scala大牛也认为太复杂了，可见流
: 行程度不会很大
: reactor本身是想做一个framework，并不是直接可以创建app的，并且由于很新，
: production还不可用。
: vert.x是zhaoce大牛最中意的，算是完全copy了node的创意，并且解决了scale和
: coordination的问题。当然在web server上，goodbug大牛早说过了，request都是独立
|
p*****2
发帖数: 21240 | 6
根据好虫以前的说法，Java并没有实现所有的异步库。所以在你没有异步库的情况下不
能进入event loop，只能上线程。不上线程，event loop就阻塞了。这就跟Clojure实
现了Go的goroutine, channel一个道理。
【在 d*******r 的大作中提到】
: 好帖，关注中。
: 所以看完还是觉得 vert.x 最接近 production?
: "而vert.x最大的问题是不能实现纯异步，所以还必须实用阻碍的线程，这样就造成了
: 瓶颈，不利于大并发。"
: 这个我没太懂，vert.x 这种基于 messages, event, event bus, event handler 的框
: 架，为什么不能实现纯异步呢。
: 我觉得 vert.x 也提供 blocking worker thread, 只是多了一个 option，让其表现力
: 更强而已，可以选择不用啊。
:
: x。
|
p*****2
发帖数: 21240 | 7
目前来看JVM上的并发比较落后了，如果不想用node的话，可以上go或者erlang。当然
很多应用的并发量也并不大，Java完全没有问题。
【在 d*******r 的大作中提到】
: 好帖，关注中。
: 所以看完还是觉得 vert.x 最接近 production?
: "而vert.x最大的问题是不能实现纯异步，所以还必须实用阻碍的线程，这样就造成了
: 瓶颈，不利于大并发。"
: 这个我没太懂，vert.x 这种基于 messages, event, event bus, event handler 的框
: 架，为什么不能实现纯异步呢。
: 我觉得 vert.x 也提供 blocking worker thread, 只是多了一个 option，让其表现力
: 更强而已，可以选择不用啊。
:
: x。
|
p*****w
发帖数: 429 | 8 你把网络上的异步和java的并发相提并论就不是很恰当。java考虑更多是并发运算和他
们之间的同步。网络的异步首先是一种模块化的结果。和软件上的多线程是解决不同的
问题。很难放到一起谈。
原因
vert.
见流
独立
实用
Google要
【在 p*****w 的大作中提到】
: 你是做网络的吗？
: 你这个大并发是什么？
:
: x。
|
p*****2
发帖数: 21240 | 9
不只是网络的异步。异步是针对所有IO的。Java上的并发是多线程，但是其他语言中的
并发并不是这个样子的。现在支持高并发的主要的手段就是干掉多线程。
【在 p*****w 的大作中提到】
: 你把网络上的异步和java的并发相提并论就不是很恰当。java考虑更多是并发运算和他
: 们之间的同步。网络的异步首先是一种模块化的结果。和软件上的多线程是解决不同的
: 问题。很难放到一起谈。
:
: 原因
: vert.
: 见流
: 独立
: 实用
: Google要
|
d*******r
发帖数: 3299 | 10 哦，理解了。
那就是 vert.x 兼容 JVM 原生 lib 的问题了，任何向后兼容，都有代价的呀。
我觉得问题不大，只需要在最核心，最影响效率的地方，注意 lib 的选择就是了。
Go 或者 Erlang 这种，完全学一套自顾自玩的新东西，我觉得风险比较大。学着玩长
知识可以。
【在 p*****2 的大作中提到】
:
: 不只是网络的异步。异步是针对所有IO的。Java上的并发是多线程，但是其他语言中的
: 并发并不是这个样子的。现在支持高并发的主要的手段就是干掉多线程。
|
|
|
p*****2
发帖数: 21240 | 11
嗯。我觉得是可用的，就是到时候突然发现需要点啥没有异步库就比较麻烦了，可能架
构要相应的调整一下。不过总的来说感觉vert.x在JVM上可能已经是最好的了。感觉比
scala的akka，clojure的stm，async什么的要强一截，毕竟是走的node.js的思路吗。
【在 d*******r 的大作中提到】
: 哦，理解了。
: 那就是 vert.x 兼容 JVM 原生 lib 的问题了，任何向后兼容，都有代价的呀。
: 我觉得问题不大，只需要在最核心，最影响效率的地方，注意 lib 的选择就是了。
: Go 或者 Erlang 这种，完全学一套自顾自玩的新东西，我觉得风险比较大。学着玩长
: 知识可以。
|
d*******r
发帖数: 3299 | 12 "现在支持高并发的主要的手段就是干掉多线程。"
我觉得主要手段是不使用多线程编程，但不等于下层不用多线程。Linux底层就把线程
和进程一样对待的。
现在异步，event_loop 这些大并发效率更高，*本质* 原因我觉得是这个:
用 event_loop 和 event_handler 这些东西进一步把OS的一个执行单元(线程或者进程
) 掰开成了更小的各种执行单元 (e.g. event_handlers scheduled by event_loop).
这些执行单元 schedule 起来更轻量级，所以效率更高。
【在 p*****2 的大作中提到】
:
: 嗯。我觉得是可用的，就是到时候突然发现需要点啥没有异步库就比较麻烦了，可能架
: 构要相应的调整一下。不过总的来说感觉vert.x在JVM上可能已经是最好的了。感觉比
: scala的akka，clojure的stm，async什么的要强一截，毕竟是走的node.js的思路吗。
|
p*****2
发帖数: 21240 | 13
.
确实是这个道理。我说的干掉多线程是说编程的理念的变化。现在需要一个线程同时干
很多的事情了。线程之间的communication的方式也变化了，跟传统多线程很不同。
【在 d*******r 的大作中提到】
: "现在支持高并发的主要的手段就是干掉多线程。"
: 我觉得主要手段是不使用多线程编程，但不等于下层不用多线程。Linux底层就把线程
: 和进程一样对待的。
: 现在异步，event_loop 这些大并发效率更高，*本质* 原因我觉得是这个:
: 用 event_loop 和 event_handler 这些东西进一步把OS的一个执行单元(线程或者进程
: ) 掰开成了更小的各种执行单元 (e.g. event_handlers scheduled by event_loop).
: 这些执行单元 schedule 起来更轻量级，所以效率更高。
|
d*******r
发帖数: 3299 | 14 握手 ：）
正讨论 vert.x, play，reactor 时候，怎么不见老赵了
【在 p*****2 的大作中提到】
:
: .
: 确实是这个道理。我说的干掉多线程是说编程的理念的变化。现在需要一个线程同时干
: 很多的事情了。线程之间的communication的方式也变化了，跟传统多线程很不同。
|
p*****2
发帖数: 21240 | 15 好久不见他了 论坛冷清多了 还想看看他vertx搞啥样了
不过我也挺想看看搞erlang和golang的感受的
【在 d*******r 的大作中提到】
: 握手 ：）
: 正讨论 vert.x, play，reactor 时候，怎么不见老赵了
|
g*****g
发帖数: 34805 | 16 大并发最大的问题永远不在于同步异步，而在于数据库。同步异步只不过多点少点机器。
x。
【在 p*****2 的大作中提到】
: 刚才想了一下，现在大兵法的主要解决方案就是异步，这也是为什么Node这么火的原因
: ，还有新兴的Go语言，老树回春的Erlang。那么Java上边情况如何呢。
: 我的理解基本上最下边是NIO, 然后中间有一层Netty，上边有play，reactor，vert.x。
: play本身是一个模仿rails的mvc框架。现在的趋势越来越不mvc了，所以前途有限。
: play下边的akka很强大，但是即使coltzhao这样的scala大牛也认为太复杂了，可见流
: 行程度不会很大
: reactor本身是想做一个framework，并不是直接可以创建app的，并且由于很新，
: production还不可用。
: vert.x是zhaoce大牛最中意的，算是完全copy了node的创意，并且解决了scale和
: coordination的问题。当然在web server上，goodbug大牛早说过了，request都是独立
|
b*******s
发帖数: 5216 | 17 多线程模型的缺点是编程复杂，调试困难，但是可以利用多核，设计好throughput很高。
js等用单线程我估计是因为它部署的系统未必有多核，而且多线程支持都比较差
还有就是资源限制，将来硬件变强，系统限制放松，多线程很可能重新得势
【在 p*****2 的大作中提到】
: 好久不见他了 论坛冷清多了 还想看看他vertx搞啥样了
: 不过我也挺想看看搞erlang和golang的感受的
|
b*******s
发帖数: 5216 | 18 单线程应用于高并发其实要求处理的单个任务小，不具备阻塞性
否则也达不到要求
【在 p*****2 的大作中提到】
: 好久不见他了 论坛冷清多了 还想看看他vertx搞啥样了
: 不过我也挺想看看搞erlang和golang的感受的
|
k**********g
发帖数: 989 | 19
但也不能太小，否则抵消不了 overheda。
最好是具备 auto-partitioning 或 auto-tuning 的特性。
【在 b*******s 的大作中提到】
: 单线程应用于高并发其实要求处理的单个任务小，不具备阻塞性
: 否则也达不到要求
|
c******o
发帖数: 1277 | 20 play node的并发都是一台机上共享内存／OS的。
akka是不一样，akka 立足在 distributed computing， location neutral,你根本不
知道也不在乎call的另一个actor在哪儿 , scale/currency来说更强大,consistency
也更弱,只能自己做（刚刚deprecate STM)。 |
|
|
d*******r
发帖数: 3299 | 21 我觉得有很多逻辑是只有写程序那个人才知道能不能 partition, 能不能并发的吧
【在 k**********g 的大作中提到】
:
: 但也不能太小，否则抵消不了 overheda。
: 最好是具备 auto-partitioning 或 auto-tuning 的特性。
|
c******o
发帖数: 1277 | 22 基本上nosql就是和这些一起用的，其实哲学都不一样。
我参与了一个关于akka如何实现distributed transaction的讨论.
结论是现实中根本没有distributed transaction, "that is just an academic ivory
tower example"，包括银行，也是主要用的check ＋ audit + "roll back by give
back your money from bank itself".
器。
【在 g*****g 的大作中提到】
: 大并发最大的问题永远不在于同步异步，而在于数据库。同步异步只不过多点少点机器。
:
: x。
|
b*******s
发帖数: 5216 | 23 nosql流行就是因为关系数据库太笨拙丑陋了
ivory
【在 c******o 的大作中提到】
: 基本上nosql就是和这些一起用的，其实哲学都不一样。
: 我参与了一个关于akka如何实现distributed transaction的讨论.
: 结论是现实中根本没有distributed transaction, "that is just an academic ivory
: tower example"，包括银行，也是主要用的check ＋ audit + "roll back by give
: back your money from bank itself".
:
: 器。
|
p*****2
发帖数: 21240 | 24
器。
大牛又忘记NOSQL了。
【在 g*****g 的大作中提到】
: 大并发最大的问题永远不在于同步异步，而在于数据库。同步异步只不过多点少点机器。
:
: x。
|
p*****2
发帖数: 21240 | 25
高。
大牛这就错了。node有cluster，可以充分利用多核
【在 b*******s 的大作中提到】
: 多线程模型的缺点是编程复杂，调试困难，但是可以利用多核，设计好throughput很高。
: js等用单线程我估计是因为它部署的系统未必有多核，而且多线程支持都比较差
: 还有就是资源限制，将来硬件变强，系统限制放松，多线程很可能重新得势
|
p*****2
发帖数: 21240 | 26
本来不就说了non－blocking了吗？无论是单线程，还是多线程，想高并发都不能阻塞
。
【在 b*******s 的大作中提到】
: 单线程应用于高并发其实要求处理的单个任务小，不具备阻塞性
: 否则也达不到要求
|
p*****2
发帖数: 21240 | 27
web request都是相互独立的，要什么partitioning呢？
【在 k**********g 的大作中提到】
:
: 但也不能太小，否则抵消不了 overheda。
: 最好是具备 auto-partitioning 或 auto-tuning 的特性。
|
p*****2
发帖数: 21240 | 28
consistency
大牛说到点上了。不过对于做web server来说，不需要机器之间的通信，因此一台机器
并发就够了，然后堆机器。
akka的优势在于distributed，这个go，stm都没办法，包括node，都不是做这个的。
akka也可以做单机并发，但是对于多机来说，竞争对手就是storm等了。
【在 c******o 的大作中提到】
: play node的并发都是一台机上共享内存／OS的。
: akka是不一样，akka 立足在 distributed computing， location neutral,你根本不
: 知道也不在乎call的另一个actor在哪儿 , scale/currency来说更强大,consistency
: 也更弱,只能自己做（刚刚deprecate STM)。
|
p*****2
发帖数: 21240 | 29
web request一般都可以并发。互相之间没什么关系。
【在 d*******r 的大作中提到】
: 我觉得有很多逻辑是只有写程序那个人才知道能不能 partition, 能不能并发的吧
|
p*****2
发帖数: 21240 | 30
主要原因是SQL不能scale吧？
【在 b*******s 的大作中提到】
: nosql流行就是因为关系数据库太笨拙丑陋了
:
: ivory
|
|
|
b*******s
发帖数: 5216 | 31 怎么不能？分库分表
【在 p*****2 的大作中提到】
:
: 主要原因是SQL不能scale吧？
|
b*******s
发帖数: 5216 | 32 这个本质上就是跑几个instances，和多线程／进程就是一回事
【在 p*****2 的大作中提到】
:
: 主要原因是SQL不能scale吧？
|
c******o
发帖数: 1277 | 33 如果强关联，也是一样的。
【在 b*******s 的大作中提到】
: 怎么不能？分库分表
|
p*****2
发帖数: 21240 | 34
绝对不是一回事。
【在 b*******s 的大作中提到】
: 这个本质上就是跑几个instances，和多线程／进程就是一回事
|
b*******s
发帖数: 5216 | 35 A single instance of Node runs in a single thread. To take advantage of
multi-core systems the user will sometimes want to launch a cluster of Node
processes to handle the load.
The cluster module allows you to easily create child processes that all
share server ports.
【在 p*****2 的大作中提到】
:
: 绝对不是一回事。
|
p*****2
发帖数: 21240 | 36
Node
大牛谈谈跟multi thread为什么一样。
【在 b*******s 的大作中提到】
: A single instance of Node runs in a single thread. To take advantage of
: multi-core systems the user will sometimes want to launch a cluster of Node
: processes to handle the load.
: The cluster module allows you to easily create child processes that all
: share server ports.
|
b*******s
发帖数: 5216 | 37 我扫了一眼，说错莫怪啊
这个模型就是一个进程负责分发，其余的都是子进程，负责处理
这样实现了子进程可以共用端口，而且子进程独立，不同的进程可以跑在不同的核上充
分利用系统资源
父进程／分发进程和子进程之间通讯是ipc实现的，这是典型的多进程
没什么特别的
multi－process programming
【在 p*****2 的大作中提到】
:
: Node
: 大牛谈谈跟multi thread为什么一样。
|
p*****2
发帖数: 21240 | 38
那根multi thread有什么关系呢？我觉得编程模式很不同呀。
【在 b*******s 的大作中提到】
: 我扫了一眼，说错莫怪啊
: 这个模型就是一个进程负责分发，其余的都是子进程，负责处理
: 这样实现了子进程可以共用端口，而且子进程独立，不同的进程可以跑在不同的核上充
: 分利用系统资源
: 父进程／分发进程和子进程之间通讯是ipc实现的，这是典型的多进程
: 没什么特别的
: multi－process programming
|
b*******s
发帖数: 5216 | 39 在 brainless (n/a) 的大作中提到: 】
多进程我也提到了。这个模型本质上没什么新奇的，如何设计看需要。
异步不是万能的，这是很老的东西，是现在的需求使得它重新被重视而已了 |
b*******s
发帖数: 5216 | 40 这个模型的弱点在于那个server instance，可以设计一下比较大的需要数据参数传递
的任务，应该能让效率降低，甚至低于同步模型
【在 p*****2 的大作中提到】
:
: 那根multi thread有什么关系呢？我觉得编程模式很不同呀。
|
|
|
p*****2
发帖数: 21240 | 41
分表之后一般join，transaction啥的咋搞呀？
【在 b*******s 的大作中提到】
: 怎么不能？分库分表
|
p*****2
发帖数: 21240 | 42
这个世界没啥东西是万能的吧？一般都是根据需求选用合适的工具吧？比如需要设计一
个distributed system，可能就上akka，storm啥的了。
【在 b*******s 的大作中提到】
: 这个模型的弱点在于那个server instance，可以设计一下比较大的需要数据参数传递
: 的任务，应该能让效率降低，甚至低于同步模型
|
b*******s
发帖数: 5216 | 43 看你的具体应用了，起码在很多情况下，scale out还是能做的
其实需要用到join的，可以多表合并成一个表，不需要查询的字段都放到blob里面
【在 p*****2 的大作中提到】
:
: 这个世界没啥东西是万能的吧？一般都是根据需求选用合适的工具吧？比如需要设计一
: 个distributed system，可能就上akka，storm啥的了。
|
b*******s
发帖数: 5216 | 44 所以重点是原理性的东西明白，有做轮子的能力，才能选好合适的轮子
【在 p*****2 的大作中提到】
:
: 这个世界没啥东西是万能的吧？一般都是根据需求选用合适的工具吧？比如需要设计一
: 个distributed system，可能就上akka，storm啥的了。
|
p*****2
发帖数: 21240 | 45
这样为什么不直接上nosql算了？感觉就是sql蜕变成nosql了。
【在 b*******s 的大作中提到】
: 看你的具体应用了，起码在很多情况下，scale out还是能做的
: 其实需要用到join的，可以多表合并成一个表，不需要查询的字段都放到blob里面
|
b*******s
发帖数: 5216 | 46 我只是说明，关系数据库也不是不能scale
【在 p*****2 的大作中提到】
:
: 这样为什么不直接上nosql算了？感觉就是sql蜕变成nosql了。
|
p*****2
发帖数: 21240 | 47
这是确实呀。现在一招鲜很难呀
【在 b*******s 的大作中提到】
: 所以重点是原理性的东西明白，有做轮子的能力，才能选好合适的轮子
|
p*****2
发帖数: 21240 | 48
scale之后是不是perf还不行？
【在 b*******s 的大作中提到】
: 我只是说明，关系数据库也不是不能scale
|
b*******s
发帖数: 5216 | 49 看你多少机器咯，如果每个库／表容量都不大，应该也很快的
【在 p*****2 的大作中提到】
:
: scale之后是不是perf还不行？
|
p*****2
发帖数: 21240 | 50
那nosql跟sql分表比的优势是什么？
【在 b*******s 的大作中提到】
: 看你多少机器咯，如果每个库／表容量都不大，应该也很快的
|
|
|
b*******s
发帖数: 5216 | 51 前面说了，对开发人员友好，不是那种死蠢死蠢的东西了
【在 p*****2 的大作中提到】
:
: 那nosql跟sql分表比的优势是什么？
|
b*******s
发帖数: 5216 | 52 前面我讲的手段，会破坏一些数据库设计的原则范式
【在 p*****2 的大作中提到】
:
: 那nosql跟sql分表比的优势是什么？
|
g*****g
发帖数: 34805 | 53 不就这意思吗，重点难点不在异步上。同步做到scale out的应用多了去了。
【在 p*****2 的大作中提到】
:
: 那nosql跟sql分表比的优势是什么？
|
p*****2
发帖数: 21240 | 54
这个确实是。用了nosql，就不愿意折腾sql了。
【在 b*******s 的大作中提到】
: 前面说了，对开发人员友好，不是那种死蠢死蠢的东西了
|
p*****2
发帖数: 21240 | 55
大牛说说为什么jvm上要出现akka，play，reactor，vert.x这些异步框架？
【在 g*****g 的大作中提到】
: 不就这意思吗，重点难点不在异步上。同步做到scale out的应用多了去了。
|
g*****g
发帖数: 34805 | 56 这个不矛盾。并非解决方案现在就有，但是同样有优化的需要。异步也只是多种优化中
的一
种。特别对messaging这类应用比较合适。
【在 p*****2 的大作中提到】
:
: 大牛说说为什么jvm上要出现akka，play，reactor，vert.x这些异步框架？
|
p*****2
发帖数: 21240 | 57
大牛能不能谈谈上M的并发量一般Java是怎么解决的？
【在 g*****g 的大作中提到】
: 这个不矛盾。并非解决方案现在就有，但是同样有优化的需要。异步也只是多种优化中
: 的一
: 种。特别对messaging这类应用比较合适。
|
g*****g
发帖数: 34805 | 58 一旦搞定了数据库这块，就可以裸堆机器了。不只是java, 啥语言都是这样。
机器真没多少钱。我们前端转node, 首要的两点就是开发快速，好找人，性能提高只能
排第三。
【在 p*****2 的大作中提到】
:
: 大牛能不能谈谈上M的并发量一般Java是怎么解决的？
|
p*****2
发帖数: 21240 | 59
说是这么说，不过像L转了以后从30台机器降到3太机器。如果是在AWS上，cost节省90%
，还是挺重要的吧。不过我AWS不熟，不知道3台，30台价格的差别到底有多大。
【在 g*****g 的大作中提到】
: 一旦搞定了数据库这块，就可以裸堆机器了。不只是java, 啥语言都是这样。
: 机器真没多少钱。我们前端转node, 首要的两点就是开发快速，好找人，性能提高只能
: 排第三。
|
g*****g
发帖数: 34805 | 60 那是原来的东西写得烂。像我们跑5万台机器，前端不过1000台。哪怕真想你说10-》1
，也不过节省个2%。
L家也一样。后端机器比前端多多了。
90%
【在 p*****2 的大作中提到】
:
: 说是这么说，不过像L转了以后从30台机器降到3太机器。如果是在AWS上，cost节省90%
: ，还是挺重要的吧。不过我AWS不熟，不知道3台，30台价格的差别到底有多大。
|
|
|
p*****2
发帖数: 21240 | 61
1
你们5万台机器大概都是干嘛的？存储的话你们是自己存的还是用的S3啥的？
【在 g*****g 的大作中提到】
: 那是原来的东西写得烂。像我们跑5万台机器，前端不过1000台。哪怕真想你说10-》1
: ，也不过节省个2%。
: L家也一样。后端机器比前端多多了。
:
: 90%
|
g*****g
发帖数: 34805 | 62 这个我还真不能细说。总之后端大小服务很多。存储S3和in instance C*都用，也有一
部分是RDS.
【在 p*****2 的大作中提到】
:
: 1
: 你们5万台机器大概都是干嘛的？存储的话你们是自己存的还是用的S3啥的？
|
z****e
发帖数: 54598 | 63 怎么不能实现纯异步？
rxjava就是针对这个设计的
vert.x是兼容同步
因为以前很多东西设计时候没有设计异步的
比如jdbc，为了兼容这些，所以必需兼容同步的
让你有一个可以选择的权力
【在 d*******r 的大作中提到】
: 好帖，关注中。
: 所以看完还是觉得 vert.x 最接近 production?
: "而vert.x最大的问题是不能实现纯异步，所以还必须实用阻碍的线程，这样就造成了
: 瓶颈，不利于大并发。"
: 这个我没太懂，vert.x 这种基于 messages, event, event bus, event handler 的框
: 架，为什么不能实现纯异步呢。
: 我觉得 vert.x 也提供 blocking worker thread, 只是多了一个 option，让其表现力
: 更强而已，可以选择不用啊。
:
: x。
|
z****e
发帖数: 54598 | 64 reactor我在用啊
ui上我用得很多，最近在忙着游戏制作
哪有功夫上来搞这些
如果你对reactor异步这些感兴趣
server side可以关注一下rxjava
client side可以看看javafx，里面有binding，这就是reactor
【在 d*******r 的大作中提到】
: 握手 ：）
: 正讨论 vert.x, play，reactor 时候，怎么不见老赵了
|
z****e
发帖数: 54598 | 65 这些东西真的是光说是不够的
还是实践最重要
这些理论就算懂，如果没有做过
人家还是不相信你会
不管怎样，最近好几个都跟这些大并发有关
要写文章，要干活，烦 |
z****e
发帖数: 54598 | 66 而且关键是一旦做大了
解决方案其实可以有很多
其实选择很多，各种方式都可以
就是不要吃饱了重复造轮子
轮子造了之后，维护是个大问题
自己劈里啪啦写了一堆，最后回过头来看
自己都有可能看不懂，很正常，更不要说别人了
别人看晕过去是常事，轮子的好处就是
你用了，至少维护你省心了，要不然，一旦有人不懂
半夜都把你叫起来，杀人的心都有了 |
z****e
发帖数: 54598 | 67 一般java压根就是硬上
后面维护成了超级大问题
现在绝大多数core java的legacy code都是这样
谁看了谁头疼
前面的人出了无数问题，但是都被修补了
但是这个修补的过程，是不规范的
也就是a家和b家是不一样的
所以b家的人跳槽到了a家，几个月内无法上手
虽然都是java，但就是看不懂
因为写得乱七八糟
这种代码谁见谁头疼，但是以前没有轮子，所以没有办法
只能自己搞，所以还是要堆轮子，否则一旦做大了
维护成本是一个非常大的问题
j2ee原本设计就是用来对付这些问题的
后来被证明，中间件本身问题不大，甚至还有优化的余地
ejb都很好地解决了大多数这种问题，但是主要瓶颈在db这一层上
而且db要换，很麻烦，transaction和join不是那么容易丢掉的
web容易，但是一般商业机构，还是要db，所以oracle的基本盘就在这里
ibm的基本盘也在这里
【在 p*****2 的大作中提到】
:
: 1
: 你们5万台机器大概都是干嘛的？存储的话你们是自己存的还是用的S3啥的？
|
z****e
发帖数: 54598 | 68 对，persistence搞定了之后
ejb都能轻松搞定这些并发
spring也可以，vert.x也可以
有的是办法，还可以针对性的优化每一个环节
最恶心的就是db那些sql script了，看了都烦
没办法，又不能不看，现在ql很多，爆发式增长
甚至还有jql，cql这些，而且没有一个统一的规范
以前sql还算比较统一，现在nosql一来，就更乱了
【在 g*****g 的大作中提到】
: 一旦搞定了数据库这块，就可以裸堆机器了。不只是java, 啥语言都是这样。
: 机器真没多少钱。我们前端转node, 首要的两点就是开发快速，好找人，性能提高只能
: 排第三。
|
z****e
发帖数: 54598 | 69 最近在大学里面发现了一个宝贝
某个教授是做分布式算法的
其主要应用是游戏行业，最近在跟他好好搞这些
然后还有另外两个是做数据的
研究兴趣是数据仓库以及高级数据库
说白了就是大数据相关的东西
所以也在好好从这两个那里偷偷弄点东西来
一个感觉就是，很多国家的人的英语，其实不怎样
发音极其恶劣，但就是敢说，搞得我对自己英语越发地有信心起来
现在大数据经过几年得实践
多少都开始有些经验了，那么现在如何规范总结这些经验
才是以后的重点，这个东西接近高潮尾巴了，一旦形成一个套路
被市场采纳之后，予以推广，这一块基本上暴利的部分就结束了
是时候寻找下一个热点了
国内现在做手游超级热，建议想创业发财的，好好看一看 |
d*******r
发帖数: 3299 | 70 所以你现在是在搞 reactor?
跟 vert.x 比主要优势劣势是什么呢？
【在 z****e 的大作中提到】
: reactor我在用啊
: ui上我用得很多，最近在忙着游戏制作
: 哪有功夫上来搞这些
: 如果你对reactor异步这些感兴趣
: server side可以关注一下rxjava
: client side可以看看javafx，里面有binding，这就是reactor
|
|
|
d*******r
发帖数: 3299 | 71 老赵你讲讲游戏 server 如何做吧，
MMORPG 或者 傻傻的卡牌游戏 的 server，
感觉 MMORPG 那个是真考技术的。
【在 z****e 的大作中提到】
: 最近在大学里面发现了一个宝贝
: 某个教授是做分布式算法的
: 其主要应用是游戏行业，最近在跟他好好搞这些
: 然后还有另外两个是做数据的
: 研究兴趣是数据仓库以及高级数据库
: 说白了就是大数据相关的东西
: 所以也在好好从这两个那里偷偷弄点东西来
: 一个感觉就是，很多国家的人的英语，其实不怎样
: 发音极其恶劣，但就是敢说，搞得我对自己英语越发地有信心起来
: 现在大数据经过几年得实践
|
t*d
发帖数: 1290 | 72 给别人干，这种不愿维护、撇清关系的态度，也许是明哲保身的方法。
如果是给自己干，你要半夜起来把别人叫起来，一则不可可能，二则那个会起杀人心。
总之你的事坑定得黄。
【在 z****e 的大作中提到】
: 而且关键是一旦做大了
: 解决方案其实可以有很多
: 其实选择很多，各种方式都可以
: 就是不要吃饱了重复造轮子
: 轮子造了之后，维护是个大问题
: 自己劈里啪啦写了一堆，最后回过头来看
: 自己都有可能看不懂，很正常，更不要说别人了
: 别人看晕过去是常事，轮子的好处就是
: 你用了，至少维护你省心了，要不然，一旦有人不懂
: 半夜都把你叫起来，杀人的心都有了
|
