p*****2
发帖数: 21240 | 1 如果需要做一个distributed real time app的话 都有哪些选择 需要scalable的
solution
我知道akka storm 可以做
mq有什么好的解决方案吗
要求就是底层都做好了 可以主要力量focus在Business logic
node有成熟方案吗？
go？ |
d*******r
发帖数: 3299 | 2 二爷是要做数据分析呢，还是要做 real time, 比如 chat, online gaming 之类? |
w**z
发帖数: 8232 | 3 是啊，定义real time. 另外我们可能要重写chat. 有啥推荐的？
【在 d*******r 的大作中提到】
: 二爷是要做数据分析呢，还是要做 real time, 比如 chat, online gaming 之类?
|
p*****2
发帖数: 21240 | 4 数据分析基本就是spark了
主要是real time 发 email 但是量会很大
【在 d*******r 的大作中提到】
: 二爷是要做数据分析呢，还是要做 real time, 比如 chat, online gaming 之类?
|
p*****2
发帖数: 21240 | 5 你们现在chat用啥写的？
是不是理论上二郎最佳
【在 w**z 的大作中提到】
: 是啊，定义real time. 另外我们可能要重写chat. 有啥推荐的？
|
g*****g
发帖数: 34805 | 6 email is not realtime. More like up to 1 min latency and the requirement is
very relaxed. email bottleneck is on mail server, and it's fairly easy to
scale as there's no shared blocking.
【在 p*****2 的大作中提到】
: 数据分析基本就是spark了
: 主要是real time 发 email 但是量会很大
|
d*******r
发帖数: 3299 | 7 没具体写过，如果web的话，websocket估计不错吧
【在 w**z 的大作中提到】
: 是啊，定义real time. 另外我们可能要重写chat. 有啥推荐的？
|
P****i
发帖数: 12972 | 8 需求不明
【在 p*****2 的大作中提到】
: 如果需要做一个distributed real time app的话 都有哪些选择 需要scalable的
: solution
: 我知道akka storm 可以做
: mq有什么好的解决方案吗
: 要求就是底层都做好了 可以主要力量focus在Business logic
: node有成熟方案吗？
: go？
|
w**z
发帖数: 8232 | 9 一个open source 的烂货。Google chat， FB chat 都用二郎写的？
【在 p*****2 的大作中提到】
: 你们现在chat用啥写的？
: 是不是理论上二郎最佳
|
w**z
发帖数: 8232 | 10 那是client 端。我主要关心server 端咋整。没弄过， 不会啊。谁搞过， 说说看？
【在 d*******r 的大作中提到】
: 没具体写过，如果web的话，websocket估计不错吧
|
|
|
p*****2
发帖数: 21240 | 11 确实不是真正real time。不过batch也肯定不行。1 min latency没问题。
主要的需求是每个用户发email的时间 频率 多少 包括内容都不一样。这个需要一定的
实时计算 当然实时性要求也不高。 一旦决定什么时候发送 要尽快发送出去 有可能决
定的是几个小时之后。 user 量大 比如1 billion。每天平均每个user 2个email吧。
is
【在 g*****g 的大作中提到】
: email is not realtime. More like up to 1 min latency and the requirement is
: very relaxed. email bottleneck is on mail server, and it's fairly easy to
: scale as there's no shared blocking.
|
p*****2
发帖数: 21240 | 12 算了一下 比如每秒30k email 不考虑 server capacuty。
【在 p*****2 的大作中提到】
: 确实不是真正real time。不过batch也肯定不行。1 min latency没问题。
: 主要的需求是每个用户发email的时间 频率 多少 包括内容都不一样。这个需要一定的
: 实时计算 当然实时性要求也不高。 一旦决定什么时候发送 要尽快发送出去 有可能决
: 定的是几个小时之后。 user 量大 比如1 billion。每天平均每个user 2个email吧。
:
: is
|
p*****2
发帖数: 21240 | 13 你是关心数据库？
websocket也包括server端吧 比如node
websocket应该比较先进了
我记得fg都是单向pull的吧
【在 w**z 的大作中提到】
: 那是client 端。我主要关心server 端咋整。没弄过， 不会啊。谁搞过， 说说看？
|
p*****2
发帖数: 21240 | 14 二郎应该不烂吧
最适合写实时通信了
要不akka？
【在 w**z 的大作中提到】
: 一个open source 的烂货。Google chat， FB chat 都用二郎写的？
|
p*****2
发帖数: 21240 | |
w**z
发帖数: 8232 | |
w**z
发帖数: 8232 | 17 用node？ http://code.tutsplus.com/tutorials/using-nodejs-and-websockets-to-build-a-chat-service--net-34482
【在 p*****2 的大作中提到】
: 你是关心数据库？
: websocket也包括server端吧 比如node
: websocket应该比较先进了
: 我记得fg都是单向pull的吧
|
P****i
发帖数: 12972 | 18 不想操心的话，用sns；自己搞的话，kafka + whatever
【在 w**z 的大作中提到】
: 那是client 端。我主要关心server 端咋整。没弄过， 不会啊。谁搞过， 说说看？
|
w**z
发帖数: 8232 | 19 你这email 是做market campaign用的？
【在 p*****2 的大作中提到】
: 算了一下 比如每秒30k email 不考虑 server capacuty。
|
P****i
发帖数: 12972 | 20 或者说spam
【在 w**z 的大作中提到】
: 你这email 是做market campaign用的？
|
|
|
w**z
发帖数: 8232 | 21 你这是queue.我要的是real time chat. 不太一样。
【在 P****i 的大作中提到】
: 不想操心的话，用sns；自己搞的话，kafka + whatever
|
w**z
发帖数: 8232 | 22 一天每人两个，有点过分了。
【在 P****i 的大作中提到】
: 或者说spam
|
P****i
发帖数: 12972 | 23 哦，我还以为你说的是京二的email呢
chat就用websocket吧，socket.io的经典例子就是chat
【在 w**z 的大作中提到】
: 你这是queue.我要的是real time chat. 不太一样。
|
w**z
发帖数: 8232 | 24 好，有空看看websocket.
【在 P****i 的大作中提到】
: 哦，我还以为你说的是京二的email呢
: chat就用websocket吧，socket.io的经典例子就是chat
|
j********x
发帖数: 2330 | 25 load balancer + stateless worker
全部自己造轮子
马工就是要自己玩才有意思
玩别人的毫无乐趣
【在 p*****2 的大作中提到】
: 如果需要做一个distributed real time app的话 都有哪些选择 需要scalable的
: solution
: 我知道akka storm 可以做
: mq有什么好的解决方案吗
: 要求就是底层都做好了 可以主要力量focus在Business logic
: node有成熟方案吗？
: go？
|
p*****2
发帖数: 21240 | 26 mq只有kafka能支持这个througput吗？我kafka还算熟 其他的没用过
kafka producer这边大概怎么设计？consumer上storm就比较合适了
【在 P****i 的大作中提到】
: 不想操心的话，用sns；自己搞的话，kafka + whatever
|
p*****2
发帖数: 21240 | 27 是
【在 w**z 的大作中提到】
: 你这email 是做market campaign用的？
|
p*****2
发帖数: 21240 | 28 只是估计一个量
【在 w**z 的大作中提到】
: 一天每人两个，有点过分了。
|
p*****2
发帖数: 21240 | 29 这个用akka应该就行了
【在 j********x 的大作中提到】
: load balancer + stateless worker
: 全部自己造轮子
: 马工就是要自己玩才有意思
: 玩别人的毫无乐趣
|
g*****g
发帖数: 34805 | 30 这个既然是share nothing，很容易写的。起一堆mail server 前面有load balancer就
行。我做过。
你写的是client端的代码。可以event随时触发，batch的话速度也是你自己控制的，想
起几个线程就起几个。
【在 p*****2 的大作中提到】
: 确实不是真正real time。不过batch也肯定不行。1 min latency没问题。
: 主要的需求是每个用户发email的时间 频率 多少 包括内容都不一样。这个需要一定的
: 实时计算 当然实时性要求也不高。 一旦决定什么时候发送 要尽快发送出去 有可能决
: 定的是几个小时之后。 user 量大 比如1 billion。每天平均每个user 2个email吧。
:
: is
|
|
|
w**z
发帖数: 8232 | 31 我们用PHP搞的。开些PHP process, scan user info,就开始发了。我们发的慢，一秒
几百而已。京二那一秒几十k. 要小心，别搞爆了。
PHP
【在 g*****g 的大作中提到】
: 这个既然是share nothing，很容易写的。起一堆mail server 前面有load balancer就
: 行。我做过。
: 你写的是client端的代码。可以event随时触发，batch的话速度也是你自己控制的，想
: 起几个线程就起几个。
|
y**********u
发帖数: 6366 | 32 有考虑过用tornado吗？
就是fb以前cto搞得那个小屁公司做的
【在 w**z 的大作中提到】
: 一个open source 的烂货。Google chat， FB chat 都用二郎写的？
|
l**********n
发帖数: 8443 | 33 tornado or twisted or greenlet.
tornado is the easiest.
【在 y**********u 的大作中提到】
: 有考虑过用tornado吗？
: 就是fb以前cto搞得那个小屁公司做的
|
w**z
发帖数: 8232 | 34 Python 估计不太好sell. Java/Scala 或node based 比较容易说服高层。
【在 l**********n 的大作中提到】
: tornado or twisted or greenlet.
: tornado is the easiest.
|
p*****2
发帖数: 21240 | 35 分布式的话 threads管理起来容易吗
【在 g*****g 的大作中提到】
: 这个既然是share nothing，很容易写的。起一堆mail server 前面有load balancer就
: 行。我做过。
: 你写的是client端的代码。可以event随时触发，batch的话速度也是你自己控制的，想
: 起几个线程就起几个。
|
l**********n
发帖数: 8443 | 36 real time is all about state management |
g*****g
发帖数: 34805 | 37 这种没冲突的没啥难度。多线程难在于同步，这个没啥要同步的。
【在 p*****2 的大作中提到】
: 分布式的话 threads管理起来容易吗
|
l**********n
发帖数: 8443 | 38 用Message Queue实现异步。用WebSocket Push。 |
c*****e
发帖数: 3226 | 39 go, java, Erlang 应该都没问题， Erlang 和 go 本身已经是带 distributed
process 库了， java 用 akka.估计没问题。 你要是真的特意追求实时，特别是
audio/video process, c/c++ 是不可避免的。
【在 p*****2 的大作中提到】
: 如果需要做一个distributed real time app的话 都有哪些选择 需要scalable的
: solution
: 我知道akka storm 可以做
: mq有什么好的解决方案吗
: 要求就是底层都做好了 可以主要力量focus在Business logic
: node有成熟方案吗？
: go？
|
p*****2
发帖数: 21240 | 40 near real time足够了
go的distributed process好用吗
erlang现学肯定不成
akka做distributed不知道成熟度如何
其实我到觉得erlang可能最合适
【在 c*****e 的大作中提到】
: go, java, Erlang 应该都没问题， Erlang 和 go 本身已经是带 distributed
: process 库了， java 用 akka.估计没问题。 你要是真的特意追求实时，特别是
: audio/video process, c/c++ 是不可避免的。
|
|
|
p*****2
发帖数: 21240 | 41 比如需要多少台servers
每台server起多少threads
server down了怎么办
thread crash怎么办
也不是一定不需要同步
比如计算和发送 同一个user可能同时发生
计算好了的发送可能由于realtime event而取消 或者增加 replace 等等
【在 g*****g 的大作中提到】
: 这种没冲突的没啥难度。多线程难在于同步，这个没啥要同步的。
|
p*****2
发帖数: 21240 | 42 这个是关键
【在 l**********n 的大作中提到】
: real time is all about state management
|
q*c
发帖数: 9453 | 43 这东西没有同步，啥不行啊？上机器就好了？
【在 p*****2 的大作中提到】
: 算了一下 比如每秒30k email 不考虑 server capacuty。
|
d*******r
发帖数: 3299 | 44 大牛说说 go的distributed process 呢
【在 c*****e 的大作中提到】
: go, java, Erlang 应该都没问题， Erlang 和 go 本身已经是带 distributed
: process 库了， java 用 akka.估计没问题。 你要是真的特意追求实时，特别是
: audio/video process, c/c++ 是不可避免的。
|
g*****g
发帖数: 34805 | 45 这种最常见的做法就是zookeeper做leader election，leader做分发和监控。至于
event导致数据变化，你大可以通过锁数据库进行，反正锁的粒度只在一个用户上，不
会有啥问题。
【在 p*****2 的大作中提到】
: 比如需要多少台servers
: 每台server起多少threads
: server down了怎么办
: thread crash怎么办
: 也不是一定不需要同步
: 比如计算和发送 同一个user可能同时发生
: 计算好了的发送可能由于realtime event而取消 或者增加 replace 等等
|
p*****2
发帖数: 21240 | 46
如果1 billion user什么db比较合适？ C*做锁不是特别合适吧？
还是SQL DB加 sharding？
zookeeper这招不错。大牛知道akka怎么保证ha吗？
【在 g*****g 的大作中提到】
: 这种最常见的做法就是zookeeper做leader election，leader做分发和监控。至于
: event导致数据变化，你大可以通过锁数据库进行，反正锁的粒度只在一个用户上，不
: 会有啥问题。
|
p*****2
发帖数: 21240 | 47
F还真是二郎
Facebook (the Erlang based chat)
【在 w**z 的大作中提到】
: 好，有空看看websocket.
|
g*****g
发帖数: 34805 | 48 可以用啥数据库要看商业逻辑的具体要求，不是那么机械的。
【在 p*****2 的大作中提到】
:
: F还真是二郎
: Facebook (the Erlang based chat)
|
p*****2
发帖数: 21240 | 49 那你在说说你的方案例里thread crash怎么办？任务怎么重新分配。
【在 g*****g 的大作中提到】
: 可以用啥数据库要看商业逻辑的具体要求，不是那么机械的。
|
g*****g
发帖数: 34805 | 50 弄个标志位，活干完了回写数据库。zookeeper保证了一直会有一个 leader把没干完的
活分发下去。
【在 p*****2 的大作中提到】
: 那你在说说你的方案例里thread crash怎么办？任务怎么重新分配。
|
|
|
p*****2
发帖数: 21240 | 51 看了一下。 感觉自己要造不少东西。二郎可能更合适。java分布式还是太底层了。
http://bbs.chinaunix.net/thread-1844009-1-1.html
【在 g*****g 的大作中提到】
: 弄个标志位，活干完了回写数据库。zookeeper保证了一直会有一个 leader把没干完的
: 活分发下去。
|
g*****g
发帖数: 34805 | 52 Java的轮子是最全的，一个 zookeeper都没那么好写。
【在 p*****2 的大作中提到】
: 看了一下。 感觉自己要造不少东西。二郎可能更合适。java分布式还是太底层了。
: http://bbs.chinaunix.net/thread-1844009-1-1.html
|
p*****2
发帖数: 21240 | 53
没错。不过对于新型框架来说，还是落后了。我们这里就是全Java搞了一套，虽然有轮
子还是问题很多。
【在 g*****g 的大作中提到】
: Java的轮子是最全的，一个 zookeeper都没那么好写。
|
c*****e
发帖数: 3226 | 54 java 的轮子是多，好多都不完美，用起来不顺手，因为每个人都在造轮子，而不是合
力提高做一个最好的轮子。
【在 g*****g 的大作中提到】
: Java的轮子是最全的，一个 zookeeper都没那么好写。
|
d******e
发帖数: 2265 | 55 多real time?
【在 p*****2 的大作中提到】
: 如果需要做一个distributed real time app的话 都有哪些选择 需要scalable的
: solution
: 我知道akka storm 可以做
: mq有什么好的解决方案吗
: 要求就是底层都做好了 可以主要力量focus在Business logic
: node有成熟方案吗？
: go？
|
d******e
发帖数: 2265 | 56 不算太real time 发email，python上celery
【在 p*****2 的大作中提到】
: 数据分析基本就是spark了
: 主要是real time 发 email 但是量会很大
|
d******e
发帖数: 2265 | 57 后台发email ,celeryde最典型应用。这个根本不需要造轮子。直接配一下就用了。
【在 p*****2 的大作中提到】
: 看了一下。 感觉自己要造不少东西。二郎可能更合适。java分布式还是太底层了。
: http://bbs.chinaunix.net/thread-1844009-1-1.html
|
g*****g
发帖数: 34805 | 58 You can say this on every language.
【在 c*****e 的大作中提到】
: java 的轮子是多，好多都不完美，用起来不顺手，因为每个人都在造轮子，而不是合
: 力提高做一个最好的轮子。
|
e***m
发帖数: 92 | 59 what about Vert.x in this use case?
【在 p*****2 的大作中提到】
:
: 没错。不过对于新型框架来说，还是落后了。我们这里就是全Java搞了一套，虽然有轮
: 子还是问题很多。
|
p*****2
发帖数: 21240 | 60
应该还是合适的，起码比硬上Java会容易很多。vertx的message bus也不是persistent
吧？而且不分布式？
我觉得完成这套东西node.js+mongo＋redis应该是够了。
【在 e***m 的大作中提到】
: what about Vert.x in this use case?
|
|
|
y**********u
发帖数: 6366 | 61 大牛对mongo有什么看法？感觉在production 上不是很稳定
persistent
【在 p*****2 的大作中提到】
:
: 应该还是合适的，起码比硬上Java会容易很多。vertx的message bus也不是persistent
: 吧？而且不分布式？
: 我觉得完成这套东西node.js+mongo＋redis应该是够了。
|
c*****e
发帖数: 3226 | 62 that is not true for Erlang. its OTP 就很强大了。
【在 g*****g 的大作中提到】
: You can say this on every language.
|
p*****2
发帖数: 21240 | 63
我们这里还行。你怎么配的？
【在 y**********u 的大作中提到】
: 大牛对mongo有什么看法？感觉在production 上不是很稳定
:
: persistent
|
y**********u
发帖数: 6366 | 64 我们在我来之前用过，最后一致觉得这玩意不靠谱就扔掉了
不过好像ebay也在用
【在 p*****2 的大作中提到】
:
: 我们这里还行。你怎么配的？
|
p*****2
发帖数: 21240 | 65 优缺点都明显
有点是document nosql跟node配合无缝
功能最强大nosql 跟 sql最接近
in memory performance好
ha sharding 自动支持
缺点是太占memory scale不方便 跟其他nosql比起来显得很昂贵
但是具体用什么要看use case了
我发现一个问题就是很多人设计系统都想一个东西解决 我一般是在mongo redis
cassandra中综合考虑 很可能三个都用
【在 y**********u 的大作中提到】
: 我们在我来之前用过，最后一致觉得这玩意不靠谱就扔掉了
: 不过好像ebay也在用
|
W****n
发帖数: 141 | 66 kafka + spark streaming |
