筆記：Akka Streams: Streaming Data Transformation à la Carte

http://www.infoq.com/presentations/akka-streams?utm_source=infoq

心得

這位Viktor Klang講話方式與外型都很像我前同事XD，現在Akka除了可以提供不用管Thread的執行模型之外，還有Akka Stream可以提供處理資料的模型。其實我對Akka沒很熟啦，不過因為後來都是在寫Backend的關係，所以對Backend處理架構有興趣。看起來Akka Stream除了提供原本基於Actor的好處之外，還提供了對資料流更高階更有效率的抽象化架構，像是Source, Flow, Sink這樣的概念，以前在做M$的DirectShow就有接觸了，不過那個只是單機視訊播放。這個是處理數千數萬的資料流，應用的等級差很大。最後帶到Reactive Stream的概念，那個Dynamic Push-Pull Model看來真的是蠻屌，但應該還在發展中。話說現在typesafe也要改名成lightblend了，看來他們公司搞的技術都頗有看頭，希望他們Live long and Prosper！

筆記

簡介Akka

• Akka: Simple message-oriented programming model for build reactive applications.
• 會用Scala demo因為可以顯示比較完整(!)
• 不需要考慮Share state, memory visibility, threads, locks, concurrent collections, thread notifications.
• 高CPU使用率, 低延遲, 高輸出, 有彈性
• Supervisor hierarchy可以讓application有彈性
  • 有個root actor當supervisor，管控其下的child actor，有問題就換掉，做得慢supervisor就找其他actor幫忙。

    這種是製造業思維，被敏捷洗腦的我聽了有點OOXX，不過Akka處理message就是製造業沒錯啦…

• Akka的計算單位稱為Actor
• Actor有address, mailbox, current behavior, local storage
• Actor週期性的送出message
• 每個Actor有一個Parent，由Parent處理該Actor失敗的情境
• 每個Actor有1..N個child Actor
• 沒做事的Actor不會佔用CPU時間
• 一個Actor一次只處理一個message，避免Concurrent issue
• 一個Actor佔用450 byte，所以一台機器可以有百萬個Actor(!)
• Akka Cluster可以有2500個node，所以如果都是10G RAM以上的機器，可以有到兆等級的Actor(!)

  Akka Stream

• 有誰敢說自己Multi Thread的實作100%正確呢？就算有Test，Multi Thread這件事本質上就是容易錯，我們有一定要用這個作業系統特性嗎？
• 如果有更簡單的方式，是否可以不用Thread
• Akka Stream特性：
  • immutable，Actor處理方式讓各個資料流不互相干擾
  • reuseable，有Immutable就很容易可以做到
  • composable，既然可以reuse，就可以很容易組合
  • coordinated，Actor的Supvisor架構
  • asynchronus，Actor是message driven，可以做到非同步
  • transformations，提供各種不同的Transformation方式來處理Flow
• Linear transformation
  • Source
  • Sink
• Non-linear transformation
  • Fan in
  • Fan out
• Non-linear transformation：可以建構Graph，拿來做Protocol
• 擴展
  • Akka TCP stream
  • Akka Http
  • Reactive Stream Inter op
  • …其他
• Materialization具體化
  • Akka Stream把what與how分離
  • Source/Flow/Sink的DSL可以建立藍圖
  • ActorFlowMaterializer把藍圖用Actor執行
• Demo: 定義Source, Flow, Sink形成資料流處理的管道
• Klang’s Conjecture: “If you cannot solve a problem without programming; you cannot solve a problem with programming.”

  本日學到的名言

• 比較Push與Pull的特性，主要就是Push沒辦法處理Drop，Pull會有多的Overhead
• 比較Push&Pull與Supply＆Demand
• 2-way在Publisher與Subscriber
• 如果我們的Data Flow可以同時有Push與Pull?
  • 當Subscriber比較快就用Push
  • 當Publisher比較快就用Pull
  • 自動切換Push與Pull->Dynamic push-pull
  • 當可以有批次的Demand，就可以有批次的動作，設計者決定要累積多少的Demand才發出信號進行動作。
• 帶出Reactive Stream，可以完成以上的model
• 推廣時間：
  • https://github.com/typesafehub/activator-akka-stream-scala
  • https://github.com/reactive-streams/reactive-streams-jvm

​