流式计算总结

为了更好的写下一篇文章【流式计算和异构数据源的整合】，特意把自己在流式计算上的经验给总结一下，欢迎大家质疑；

网络IO工作模型，别人都用什么同步，异步XXX的，我就换个角度好了；

好吧，为了写这网络IO工作模型，我另外来一篇文章【网络IO工作模型以及在分布式中的应用】

流式计算的两种形式

图很挫，而且不严谨，凑合看一下吧，而且文章结束的时候，我会告诉大家这两种“所谓的模式“，其实没有明确界限

两种模式的优缺点

• 中心模式

  • get用阻塞方式实现（主线程收/回包，工作线程去阻塞get）
    • 优点：实现简单
    • 缺点：同一时刻并发数==线程数
      
  • get用非阻塞方式实现（只需一个线程）
    • 优点：并发数高
    • 缺点：容易出错，上一篇文章有详细说明（double-free,mem-leak，引用栈上空间）
  • 本身的优点：
    • 模块天生隔离，可重用性高

• 序列模式

  • 缺点
    • 上下游的耦合，可重用性不高
    • 上下游处理速度不匹配导致cache数据
    • 下游down机，上游处理麻烦
  • 优点
    • 只要还有任务在处理队列中，消费者都会及时从上游获得任务及时处理

• 两种模式的IO

  • 中心模式IO次数看上去要比序列模式少，但这并不是它总体比序列模式快的原因；因为还有IO大小的问题，我们看下下面的列子

    如果server-c需要使用server-a,server-b两个模块的处理结果，中心模式直接在内存里，木有网络IO；单序列模式需要两次IO才能把server-a的结果发给server-c;

  • 看上去中心模式不存在：server-a,server-b速度处理速度不匹配导致的cache；但实际上它的controller如果不控制最大并发数，那么同样会把cache堆积到内存里；
    

面对的问题

• 数据的堆积
  • 数据量大的情况下，序列模式必须要有个消息队列来堆积速度不匹配的导致的cache，这个队列可以在上游做，也可以做到下游，我认为最好的办法是在中间加一层纯粹的消息队列
• 数据的retry
  • 当server不带上下文，带定期更新的上下文，retry的问题都不大
  • 带随时更新的上下文，这才是最麻烦的，目前我做在业务里，慢慢有想法做到框架里了，但是未必对别的公司有用；

适用场景

• 对时效性要求比较高，甚至是实时的
• 基于一个请求即可，获得输出（相对于基于一批输入才能获得输出，如统计需要一批输入，不适合用这种模型），同比map-reduce模型

补充废话

• 这两种模式是可以结合起来使用的
  • 如：一个中心模式A，做完之后，发给下一个中心模式B，这样A,B就是一种序列模式了，实际上这种情况才是最常见的；
  • 同样如：一个序列模式中的serverA，它为了完成工作，需要对外请求：A1,A2,这同样又是一种中心模式
• 所以：这篇文章里的XX模式，其实都是上一篇文章中的东西，网络IO，再细看网络IO，其实它也是由更简单的东西组成的。