c******o
发帖数: 1277 | 1 今天卡看了一个slides，明白为啥我觉得akka没啥用。。。
http://www.slideshare.net/jboner/going-reactive-eventdriven-sca
Jonas Bonér TypeSafe CTO 做的， 里面讲了编写parallel时候可以用的工具（都很
流行啊）
1.先用immutability, future/data-flow 等语言直接支持的的工具,能并行够用就好
2.不够用，用Actor/Rx/Agent, 这类Async的分散式计算工具，这样可以有async的通讯。
3.不够用，必须有transaction,和share states, 就再加上STM
4.还不够用，那就只能上old Locks/显性thread 了。
我么只用到了 1/2之间，可能以后有3 |
z****e
发帖数: 54598 | 2 如果你做一个游戏的场景，需要保持长时间运作
你还用异步么？ |
c******o
发帖数: 1277 | 3 当然可以，你觉得WoW的砍人不疼的lag怎么来的，auction house的lag怎么来的，肯定
都是async啊。
异步不代表慢，代表当一部分不行的时候，其他的还能用，我这儿等的时候别的可以上。
一样的场景，同步不是一样慢。
【在 z****e 的大作中提到】
: 如果你做一个游戏的场景，需要保持长时间运作
: 你还用异步么？
|
z****e
发帖数: 54598 | 4 所以影响客户体验啊
【在 c******o 的大作中提到】
: 当然可以，你觉得WoW的砍人不疼的lag怎么来的，auction house的lag怎么来的，肯定
: 都是async啊。
: 异步不代表慢，代表当一部分不行的时候，其他的还能用，我这儿等的时候别的可以上。
: 一样的场景，同步不是一样慢。
|
c******o
发帖数: 1277 | 5 一样的场景，同步不是一样慢。
异步不代表慢，代表当一部分不行的时候，其他的还能用，我这儿等的时候别的可以上。
异步的trade off是一个难做，一个在大系统的不同部分可能有不一致，但是你的
response 快。
看看WoW的邮件系统，就很明显。
【在 z****e 的大作中提到】
: 所以影响客户体验啊
|
z****e
发帖数: 54598 | 6 可以根据场景做切割啊
不同的场景没有必要完全连成一片
保证当前场景里面所有连接的持续性
partition的方式不一样
上。
【在 c******o 的大作中提到】
: 当然可以，你觉得WoW的砍人不疼的lag怎么来的，auction house的lag怎么来的，肯定
: 都是async啊。
: 异步不代表慢，代表当一部分不行的时候，其他的还能用，我这儿等的时候别的可以上。
: 一样的场景，同步不是一样慢。
|
c******o
发帖数: 1277 | 7 那是单机吧？
MMO怎么保证？MMO你没有办法集中资源在一个视角上。
你基本上是保证数据量不到一个上限，用那个来parttition,这个也就是说你能handle
本来async就是牺牲consistency 保证 availability . 你都没有availability问题，
用什么async
Async/big data/nosql都是应为单个node/thread不行，必须parallel
所以consistency/availability不能都达到，所以才出现的，也不是什么都适合。
【在 z****e 的大作中提到】
: 可以根据场景做切割啊
: 不同的场景没有必要完全连成一片
: 保证当前场景里面所有连接的持续性
: partition的方式不一样
:
: 上。
|
z****e
发帖数: 54598 | 8 我想的就是不要把所有人都放到一个大的场景里面去
给一张大地图，地图上有很多单点城市，然后挨个城市进去
城市内部再细分，这样具体到某一个场景的人就少很多了
handle
【在 c******o 的大作中提到】
: 那是单机吧？
: MMO怎么保证？MMO你没有办法集中资源在一个视角上。
: 你基本上是保证数据量不到一个上限，用那个来parttition,这个也就是说你能handle
: 本来async就是牺牲consistency 保证 availability . 你都没有availability问题，
: 用什么async
: Async/big data/nosql都是应为单个node/thread不行，必须parallel
: 所以consistency/availability不能都达到，所以才出现的，也不是什么都适合。
|
c******o
发帖数: 1277 | 9 你这儿的假设就是场景之间的联系很少，可以近似看成独立的， 而且你也没法控制人
群（wow就碰到过很多次）。
独立的node如果能力够是可以availability/consistency(场景内一致）都有
所以不需要async/parallel
只有必须多node/thread/process才是要async
FB/twitter以前肯定也不需要考虑这个，但是数据量上去了不就必须考虑了么？
【在 z****e 的大作中提到】
: 我想的就是不要把所有人都放到一个大的场景里面去
: 给一张大地图，地图上有很多单点城市，然后挨个城市进去
: 城市内部再细分，这样具体到某一个场景的人就少很多了
:
: handle
|
z****e
发帖数: 54598 | 10 fb,t跟游戏没有太大关系
它们的东西都是独立分割的个体，比较好处理
游戏麻烦就在于联系的个体比较多
【在 c******o 的大作中提到】
: 你这儿的假设就是场景之间的联系很少，可以近似看成独立的， 而且你也没法控制人
: 群（wow就碰到过很多次）。
: 独立的node如果能力够是可以availability/consistency(场景内一致）都有
: 所以不需要async/parallel
: 只有必须多node/thread/process才是要async
: FB/twitter以前肯定也不需要考虑这个，但是数据量上去了不就必须考虑了么？
|
|
|
c******o
发帖数: 1277 | 11 这个trade off是真理，肯定在一定情况下，availability/consistency是矛盾的，
async 能最大的利用已有能力 （scalability)（会增加编程／运行时候的overhead,
所以不是什么情况都值得)。
【在 z****e 的大作中提到】
: fb,t跟游戏没有太大关系
: 它们的东西都是独立分割的个体，比较好处理
: 游戏麻烦就在于联系的个体比较多
|
b*******s
发帖数: 5216 | 12 async是解耦吧，能具体谈谈带来什么overhead吗？
【在 c******o 的大作中提到】
: 这个trade off是真理，肯定在一定情况下，availability/consistency是矛盾的，
: async 能最大的利用已有能力 （scalability)（会增加编程／运行时候的overhead,
: 所以不是什么情况都值得)。
|
c******o
发帖数: 1277 | 13 你保不保证各个async之间的message顺序？ 保证到达？ 保证互相之间执行的顺序？互
相之间通讯的那一部分。
这个解耦 可不简单，所以immutability好，要是以前的flow/algorithm不是并行的，那
么async有什么意义呢？有时候还要改flow/algorithm，这是编程的overhead
在 分散，并行系统里做到这样就会有overhead,你是fire and forget?还是guarantee
delivery? guarantee sequence?handle partial failure。 都是运行时候的overhead
.
如果在一个大的系统里，多用node会抵消这些overhead，带来好处，这就是
scalability.
要是本身一个两个node就解决了，那做这个干嘛？
【在 b*******s 的大作中提到】
: async是解耦吧，能具体谈谈带来什么overhead吗？
|
b*******s
发帖数: 5216 | 14 哦，我倒置了因果了，多谢
guarantee
overhead
【在 c******o 的大作中提到】
: 你保不保证各个async之间的message顺序？ 保证到达？ 保证互相之间执行的顺序？互
: 相之间通讯的那一部分。
: 这个解耦 可不简单，所以immutability好，要是以前的flow/algorithm不是并行的，那
: 么async有什么意义呢？有时候还要改flow/algorithm，这是编程的overhead
: 在 分散，并行系统里做到这样就会有overhead,你是fire and forget?还是guarantee
: delivery? guarantee sequence?handle partial failure。 都是运行时候的overhead
: .
: 如果在一个大的系统里，多用node会抵消这些overhead，带来好处，这就是
: scalability.
: 要是本身一个两个node就解决了，那做这个干嘛？
|
c******o
发帖数: 1277 | 15 现在都是越来越多multi core machine， core 越来越多,所以连一个node 有时候也要
考虑这个。。。
【在 b*******s 的大作中提到】
: 哦，我倒置了因果了，多谢
:
: guarantee
: overhead
|
g*****g
发帖数: 34805 | 16 ft, akka难道不就是2. 除非1够用了，否则akka怎会没用。
事实上，scala 03年就出来了，akka出来之后才火的。
讯。
【在 c******o 的大作中提到】
: 今天卡看了一个slides，明白为啥我觉得akka没啥用。。。
: http://www.slideshare.net/jboner/going-reactive-eventdriven-sca
: Jonas Bonér TypeSafe CTO 做的， 里面讲了编写parallel时候可以用的工具（都很
: 流行啊）
: 1.先用immutability, future/data-flow 等语言直接支持的的工具,能并行够用就好
: 2.不够用，用Actor/Rx/Agent, 这类Async的分散式计算工具，这样可以有async的通讯。
: 3.不够用，必须有transaction,和share states, 就再加上STM
: 4.还不够用，那就只能上old Locks/显性thread 了。
: 我么只用到了 1/2之间，可能以后有3
|
c******o
发帖数: 1277 | 17 嘿嘿，其实akka前三样都有。
我就是用不到太多2，3。。。。。所以当时有疑问。
现在觉得我的选择很自然。
【在 g*****g 的大作中提到】
: ft, akka难道不就是2. 除非1够用了，否则akka怎会没用。
: 事实上，scala 03年就出来了，akka出来之后才火的。
:
: 讯。
|
p*****2
发帖数: 21240 | |
c******o
发帖数: 1277 | 19 go 的 routine和channel和 还是比较接近old thread, 感觉上比较底层,很多东西要
explicit control.
倒也是，Go感觉是想做better c/c++
也没有什么let it die/supervisor 或者是STM之类的transaction
【在 p*****2 的大作中提到】
: goroutine怎么算？
|
p*****2
发帖数: 21240 | 20
我觉得go主要是做异步，event－driven的。而且很容易做。
【在 c******o 的大作中提到】
: go 的 routine和channel和 还是比较接近old thread, 感觉上比较底层,很多东西要
: explicit control.
: 倒也是，Go感觉是想做better c/c++
: 也没有什么let it die/supervisor 或者是STM之类的transaction
|
|
|
c******o
发帖数: 1277 | 21 这个还是做过go的说吧,我就是第一感觉。
【在 p*****2 的大作中提到】
:
: 我觉得go主要是做异步，event－driven的。而且很容易做。
|
p*****2
发帖数: 21240 | 22
clojure实现了go
【在 c******o 的大作中提到】
: 这个还是做过go的说吧,我就是第一感觉。
|
c******o
发帖数: 1277 | 23 。。。 不是说google的go么？
【在 p*****2 的大作中提到】
:
: clojure实现了go
|
p*****2
发帖数: 21240 | 24
我是说的general的concept。
【在 c******o 的大作中提到】
: 。。。 不是说google的go么？
|
c******o
发帖数: 1277 | 25 Clojure 的 go 和 go 的routine / channel 明显不一样啊。
【在 p*****2 的大作中提到】
:
: 我是说的general的concept。
|
p*****2
发帖数: 21240 | 26
什么叫明显不一样呢？Clojure的go本来就是copy golang的idea。有不一样的地方，但
是大概意思差不多把？
【在 c******o 的大作中提到】
: Clojure 的 go 和 go 的routine / channel 明显不一样啊。
|
c******o
发帖数: 1277 | 27 这个我不熟，不知道。大概错了。
我只是从https://gobyexample.com/ 上看的， 看起来是差不多 类比 future monad
【在 p*****2 的大作中提到】
:
: 什么叫明显不一样呢？Clojure的go本来就是copy golang的idea。有不一样的地方，但
: 是大概意思差不多把？
|
