This document contains the slides from a talk given by Konrad Malawski on the "Tao/Zen of Programming" using Akka. Some of the key points discussed include:
- Actors are meant to work together and each actor should focus on a single responsibility. Having only one actor limits its capabilities.
- Actors should be structured in a hierarchy with parent-child relationships to allow for supervision. Actors should also be named meaningfully based on their purpose.
- Blocking operations can starve other actors by monopolizing shared resources. Blocking code needs to be isolated on dedicated dispatchers.
- Messages should be processed asynchronously using for/flatMap instead of awaiting futures to avoid blocking
Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Ac...Jonas Bonér
Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM
We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction.
Akka is here to change that.
Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provides a better platform to build correct concurrent and scalable applications.
For fault-tolerance we adopt the "Let it crash" / "Embrace failure" model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop.
Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.
Akka is Open Source and available under the Apache 2 License.
Akka: Simpler Scalability, Fault-Tolerance, Concurrency & Remoting through Ac...Jonas Bonér
Akka is the platform for the next generation event-driven, scalable and fault-tolerant architectures on the JVM
We believe that writing correct concurrent, fault-tolerant and scalable applications is too hard. Most of the time it's because we are using the wrong tools and the wrong level of abstraction.
Akka is here to change that.
Using the Actor Model together with Software Transactional Memory we raise the abstraction level and provides a better platform to build correct concurrent and scalable applications.
For fault-tolerance we adopt the "Let it crash" / "Embrace failure" model which have been used with great success in the telecom industry to build applications that self-heals, systems that never stop.
Actors also provides the abstraction for transparent distribution and the basis for truly scalable and fault-tolerant applications.
Akka is Open Source and available under the Apache 2 License.
Introduction to Akka 2. Explains what Akka's actors are all about and how to utilize them to write scalable and fault-tolerant systems.
Talk given at JavaZone 2012.
Everyone in the Scala world is using or looking into using Akka for low-latency, scalable, distributed or concurrent systems. I'd like to share my story of developing and productionizing multiple Akka apps, including low-latency ingestion and real-time processing systems, and Spark-based applications.
When does one use actors vs futures?
Can we use Akka with, or in place of, Storm?
How did we set up instrumentation and monitoring in production?
How does one use VisualVM to debug Akka apps in production?
What happens if the mailbox gets full?
What is our Akka stack like?
I will share best practices for building Akka and Scala apps, pitfalls and things we'd like to avoid, and a vision of where we would like to go for ideal Akka monitoring, instrumentation, and debugging facilities. Plus backpressure and at-least-once processing.
Akka and the Zen of Reactive System DesignLightbend
In order to be successful with asynchronous programming, when coming from synchronous execution models you need to change your mindset and look at things from a slightly different perspective. In order to use Akka at it's best, you will have to change the way you think about application design (loosen coupling in space and time between components), and re-think what you've maybe learned in the past.
In this talk we uncover a number of rules that serve as a guide in designing concurrent distributed applications, how those apply to Akka, and how they can help you in daily app development.
Aimed at developers through architects, Akka team happy hAkker, Konrad Malawski, bends your parameters with regards to application design and asynchronous execution models.
Most Rails users are familiar with ActiveRecord. But what does that mean? What is ActiveRecord's approach to object relational mapping? And what are the alternatives?
This presentation is by Doug Crockford, I'm reposting it here from this Google Blog post: http://googlecode.blogspot.com/2009/03/doug-crockford-javascript-good-parts.html
A talk about the current state of java enterprise development, evaluation of the available alternatives to conventional enterprise solutions, tools and languages for the JVM, and possibly beyond.
JUG-Roma meeting 16 Sept 2014
The things we don't see – stories of Software, Scala and AkkaKonrad Malawski
Opening keynote for Scalapeno, Tel Aviv 2016.
The talk focuses and explains the things we don't often see explicitly and/or don't notice when doing our daily work, yet make up a large part of the ecosystem and maturity of the ecoststem as a whole. We also dive into some of the more confusing bits around using the same word about different things in software
Networks and Types - the Future of Akka @ ScalaDays NYC 2018Konrad Malawski
A look into the upcoming soon-to-be-stable typed Actor APIs in Akka. Shown at Scala Days NYC 2018, while Akka 2.5.13 was out. Looking at what will become the stable Akka Typed.
In this talk we explain the basics of Typed Actors as they are to land in Akka as a stable module in 2018. Typed Actors ("Akka Typed") re-introduce typesafety to concurrency and distributed systems thanks to the abstraction of a typed actor reference.
ScalaSwarm 2017 Keynote: Tough this be madness yet theres method in'tKonrad Malawski
A talk about the implications and context around API design. How APIs come to be and how to understand them. This talk was delivered as opening keynote, setting the tone, for the ScalaSwarm conference in Porto, Portugal in 2017.
Building a Reactive System with Akka - Workshop @ O'Reilly SAConf NYCKonrad Malawski
Intense 3 hour workshop covering Akka Actors, Cluster, Streams, HTTP and more. Including very advanced patterns.
Presented with Henrik Engstrom at O'Reilly Software Architecture Conference in New York City in 2017
Akka-chan's Survival Guide for the Streaming WorldKonrad Malawski
In this talk we dive into the various kinds of "Streaming", what it actually means, where to use which technology and specifically take a look at Akka Streams and their specific use case and strengths.
Reactive Streams are a cross-company initiative first ignited by Lightbend in 2013, soon to be joined by RxJava and other implementations focused on solving a very similar problem: asynchronous non-blocking stream processing, with guaranteed over-flow protection. Fast forward to 2016 and now these interfaces are part of JSR-266 and proposed for JDK9.
In this talk we'll first disambiguate what the word Stream means in this context (as it's been overloaded recently by various different meanings), then look at how its protocol works and how one might use it in the real world showing examples using existing implementations.
We'll also have a peek into the future, to see what the next steps for such collaborative protocols and the JDK ecosystem are in general.
End to End Akka Streams / Reactive Streams - from Business to SocketKonrad Malawski
The Reactive Streams specification, along with its TCK and various implementations such as Akka Streams, is coming closer and closer with the inclusion of the RS types in JDK 9. Using an example Twitter-like streaming service implementation, this session shows why this is a game changer in terms of how you can design reactive streaming applications by connecting pipelines of back-pressured asynchronous processing stages. The presentation looks at the example from two perspectives: a raw implementation and an implementation addressing a high-level business need.
[Japanese] How Reactive Streams and Akka Streams change the JVM Ecosystem @ R...Konrad Malawski
Japanese subtitles by Yugo Maede-san, thank you very much. Japanese subtitled version of the "How Reactive Streams and Akka Streams change the JVM Ecosystem". http://www.slideshare.net/ktoso/how-reactive-streams-akka-streams-change-the-jvm-ecosystem
This 7-second Brain Wave Ritual Attracts Money To You.!nirahealhty
Discover the power of a simple 7-second brain wave ritual that can attract wealth and abundance into your life. By tapping into specific brain frequencies, this technique helps you manifest financial success effortlessly. Ready to transform your financial future? Try this powerful ritual and start attracting money today!
ER(Entity Relationship) Diagram for online shopping - TAEHimani415946
https://bit.ly/3KACoyV
The ER diagram for the project is the foundation for the building of the database of the project. The properties, datatypes, and attributes are defined by the ER diagram.
Multi-cluster Kubernetes Networking- Patterns, Projects and GuidelinesSanjeev Rampal
Talk presented at Kubernetes Community Day, New York, May 2024.
Technical summary of Multi-Cluster Kubernetes Networking architectures with focus on 4 key topics.
1) Key patterns for Multi-cluster architectures
2) Architectural comparison of several OSS/ CNCF projects to address these patterns
3) Evolution trends for the APIs of these projects
4) Some design recommendations & guidelines for adopting/ deploying these solutions.
1.Wireless Communication System_Wireless communication is a broad term that i...JeyaPerumal1
Wireless communication involves the transmission of information over a distance without the help of wires, cables or any other forms of electrical conductors.
Wireless communication is a broad term that incorporates all procedures and forms of connecting and communicating between two or more devices using a wireless signal through wireless communication technologies and devices.
Features of Wireless Communication
The evolution of wireless technology has brought many advancements with its effective features.
The transmitted distance can be anywhere between a few meters (for example, a television's remote control) and thousands of kilometers (for example, radio communication).
Wireless communication can be used for cellular telephony, wireless access to the internet, wireless home networking, and so on.
6. Why such talk?
1番: One actor is no Actor
2番: Structure your Actors
3番: Name your Actors
4番: ”Matrix of mutability (Pain)”
5番: Blocking needs careful management
6番: Never Await, for/flatMap instead!
7番: Avoid Java Serialization
7.5番: Trust no-one, benchmark everything!
Agenda
8番: Let it Crash!
9番: Backoff Supervision
10番: Design using State Machines
11番: Cluster Convergence and Joining
12番: Cluster Partitions and “Down”
13番: Akka is a Toolkit.
14番: Happy Hakking, Community!
Questions?
7. “The Tao / Zen of Programming”
Talk title loosely based on
the “Tao of Programming” book
by Goeffrey James (1987).
「プログラミングの Tao (道)」
8. “The Tao / Zen of Programming”
And the follow-up book
“Zen of Programming”.
「プログラミングの Zen (禅)」の 2冊に影響を受けたトーク
9. “The Tao / Zen of Programming”
Available here: http://www.mit.edu/~xela/tao.html
Series of nine “books”,
stories about an apprentice programmer and his sensei.
Thus spake the Master Programmer:
“Without the wind, the grass does not move.
Without software hardware is useless.”
師が弟子に語る形式の 9冊シリーズの一部
「風無くば草は揺れず。ソフト無くばハードは無用の長物。」
13. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
14. 1番: One actor is no Actor
If you have only one actor then it can only…
1. Reply
2. Drop the message (“ignore”
3. Schedule another message to self
So we’re not really making any use of its
parallelism or concurrency capabilities.
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
15. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
16. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
17. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
18. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
19. 1番: One actor is no Actor
アクターは他のアクターと協調するためにある
アクターは一つの責務に特化するべき
20. 1番: One actor is no Actor
- Actors are meant to work together.
- An Actor should do one thing and do it very well
- then talk to other Actors to do other things for it.
- Child Actors usually used for workers or “tasks” etc.
- Avoid using `actorSelection`,
introduce Actors to each other.
アクターはエンティティーを表す
それぞれが「一貫性の島」であるべき
26. 3番: Name your Actors
// default
context.actorOf(childProps) // "$a", "$b", "$c"
Default names are: BASE64(sequence_nr++)
Here’s why:
- cheap to generate
- guarantees uniqueness
- less chars than plain numbers
27. 3番: Name your Actors
// default: naming is BASE64(sequential numbers)
context.actorOf(childProps) // "$a", "$b", "$c"
// better: but not very informative...
context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2"
private var _fetchWorkers: Int = 0
private def nextFetchWorkerName: String = {
_fetchWorkers += 1
s”fetch-worker-${_fetchWorkers}”
}
Sequential names are a bit better sometimes.
28. 3番: Name your Actors
// default: naming is BASE64(sequential numbers)
context.actorOf(childProps) // "$a", "$b", "$c"
// better: but not much informative...
context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2"
private var _fetchWorkers: Int = 0
private def nextFetchWorkerName: String = {
_fetchWorkers += 1
s”fetch-worker-${_fetchWorkers}”
}
abstract class SeqActorName {
def next(): String
def copy(name: String): SeqActorName
}
object SeqActorName {
def apply(prefix: String) = new SeqActorNameImpl(prefix, new AtomicLong(0))
}
final class SeqActorNameImpl(val prefix: String, counter: AtomicLong)
extends SeqActorName {
def next(): String = prefix + '-' + counter.getAndIncrement()
def copy(newPrefix: String): SeqActorName = new SeqActorNameImpl(newPrefix, counter)
}
If you use this pattern a lot, here’s a simple encapsulation of it:
29. 3番: Name your Actors
// default: naming is BASE64(sequential numbers)
context.actorOf(childProps) // "$a", "$b", "$c"
// better: but not much informative...
context.actorOf(childProps, nextFetchWorkerName) // "fetch-worker-1", "fetch-worker-2"
private var fetchWorkers: Int = 0
private def nextFetchWorkerName: String = {
fetchWorkers += 1
s"fetch-worker-$fetchWorkers"
}
// BEST: proper names, based on useful information
context.actorOf(childProps, fetcherName(videoUrl)) // "fetch-yt-MRCWy2E_Ts", ...
def fetcherName(link: Link) = link match {
case YoutubeLink(id, metadata) => s"fetch-yt-$id"
case DailyMotionLink(id, metadata) => s"fetch-dm-$id"
case VimeoLink(id, metadata) => s"fetch-vim-$id"
}
Meaningful names are the best!
アクターが適切に命名すべき
アクターの名前は一意で、内容と構造を表す
30. 3番: Name your Actors
Meaningful names are the best!
import akka.actor.OneForOneStrategy
import akka.actor.SupervisorStrategy._
import scala.concurrent.duration._
// ... extends Actor with ActorLogging {
override def supervisorStrategy: SupervisorStrategy =
OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1.minute) {
case ex: Exception ⇒
log.warning("Child {} failed with {}, attempting restart...",
sender().path.name,
ex.getMessage)
Restart
}
The name of the failed child Actor!
31. 3番: Name your Actors
Meaningful names are the best!
import akka.actor.OneForOneStrategy
import akka.actor.SupervisorStrategy._
import scala.concurrent.duration._
// ... extends Actor with ActorLogging {
override def supervisorStrategy: SupervisorStrategy =
OneForOneStrategy(maxNrOfRetries = 10, withinTimeRange = 1.minute) {
case ex: Exception ⇒
log.warning("Child {} failed with {}, attempting restart...",
sender().path.name,
ex.getMessage)
Restart
}
The name of the failed child Actor!
// BAD –– String ALWAYS built
log.debug(s"Something heavy $generateId from $physicalAddress")
// GOOD! –– String built only when DEBUG level is ON
log.debug("Something heavy {} from {}", generateId, physicalAddress)
Side note: always use {} log formatting (or macros), not s””
40. 5番: Blocking needs careful management
Blocking operations are really bad.
Actors are all about resource sharing, and if someone is “behaving
badly” it hurts everyone.
Here is an example how blocking can grind an app to a halt.
Next we’ll see how to avoid that… even if we have to live with the
blocking code.
ブロック操作を使ってはいけない
アクター同士が共有するリソースを独り占めすると皆が困る
41. 5番: Blocking needs careful management
In simple terms:
Blocking is bad because instead of doing something else,
we just wait and do nothing (wasting CPU time)…
ブロック操作を使ってはいけない
アクター同士が共有するリソースを独り占めすると皆が困る
43. 5番: Blocking needs careful management
Having that said, it’s not a bad question. Let’s investigate.
Future でブロックしている悪い例
デフォルトのディスパッチャーが枯渇する
44. 5番: Blocking needs careful management
// BAD! (due to the blocking in Future):
implicit val defaultDispatcher = system.dispatcher
val routes: Route = post {
complete {
Future { // uses defaultDispatcher
Thread.sleep(5000) // will block on the default dispatcher,
System.currentTimeMillis().toString // starving the routing infra
}
}
}
Future でブロックしている悪い例
デフォルトのディスパッチャーが枯渇する
45. 5番: Blocking needs careful management
// BAD! (due to the blocking in Future):
implicit val defaultDispatcher = system.dispatcher
val routes: Route = post {
complete {
Future { // uses defaultDispatcher
Thread.sleep(5000) // will block on the default dispatcher,
System.currentTimeMillis().toString // starving the routing infra
}
}
}
Future でブロックしている悪い例
デフォルトのディスパッチャーが枯渇する
46. 5番: Blocking needs careful management
// application.conf
my-blocking-dispatcher {
type = Dispatcher
executor = “thread-pool-executor"
thread-pool-executor {
// in Akka previous to 2.4.2:
core-pool-size-min = 16
core-pool-size-max = 16
max-pool-size-min = 16
max-pool-size-max = 16
// or in Akka 2.4.2+
fixed-pool-size = 16
}
throughput = 100
}
47. 5番: Blocking needs careful management
// GOOD (due to the blocking on a dedicated dispatcher):
implicit val blockingDispatcher = system.dispatchers.lookup("my-blocking-dispatcher")
val routes: Route = post {
complete {
Future { // uses the good "blocking dispatcher" that we configured,
// instead of the default dispatcher – the blocking is isolated.
Thread.sleep(5000)
System.currentTimeMillis().toString
}
}
}
Future でブロックしている良い例
別のディスパッチャーに隔離
48. 5番: Blocking needs careful management
The “Never block!” mantra sounds cool,
but actually what we mean by it is “blocking needs careful management”.
We use the “bulkhead” pattern separate out potentially blocking
behaviours to their independent dispatchers (and should always do so).
http://stackoverflow.com/questions/34641861/akka-http-blocking-in-a-future-blocks-the-server/34645097#34645097
54. 7番: Avoid Java Serialization
Java Serialization is the default one in Akka, since it’s easy to
get started with it – no configuration needed.
If you need performance and are running on multiple nodes,
you must change the serialization.
Popular formats are ProtoBuf or Kryo.
Kryo is easier, but harder to evolve schema with.
ProtoBuf is harder to maintain but great schema evolution.
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
55. 7番: Avoid Java Serialization
Benchmarking serialization impact on “ping pong” case.
(Two actors sending a message between them.)
in-process messaging, super fast.
no serialization overhead.
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
56. 7番: Avoid Java Serialization
more work => increased latency => decreased throughput.
over-the-network messaging,
slower due to network and serialization.
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
57. 7番: Avoid Java Serialization
Java Serialization is known to be:
very slow & footprint heavy
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
58. 7番: Avoid Java Serialization
It is on by default in Akka… Why?
a) zero setup => simple to “play around”
b) historical reasons - hard to remove the default
Since 2.4 a warning is logged:
WARNING: Using the default Java serializer for class [{}] which is not recommended
because of performance implications. Use another serializer or disable this warning
using the setting 'akka.actor.warn-about-java-serializer-usage'
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
59. 7番: Avoid Java Serialization
sbt> jmh:run
-f 1
-tu us
-wi 20
-i 10
-jvm /home/ktoso/opt/jdk1.8.0_65/bin/java
-jvmArgsAppend -XX:+PreserveFramePointer
-bm avgt
.*pingPong.*
[info] # JMH 1.10.3 (released 184 days ago, please consider updating!)
[info] # VM version: JDK 1.8.0_65, VM 25.65-b01
[info] # VM invoker: /home/ktoso/opt/jdk1.8.0_65/bin/java
[info] # VM options: -XX:+PreserveFramePointer
[info] # Warmup: 20 iterations, 5 s each
[info] # Measurement: 10 iterations, 1 s each
[info] # Timeout: 10 min per iteration
[info] # Threads: 1 thread, will synchronize iterations
[info] # Benchmark mode: Average time, time/op
[info] # Benchmark: akka.actor.ForkJoinActorBenchmark.pingPong
[info] # Parameters: (serializer = java)
github.com/ktoso/sbt-jmh
openjdk.java.net/projects/code-tools/jmh/
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
62. 7番: Avoid Java Serialization
----sr--model.Order----h#-----J--idL--customert--Lmodel/Customer;L--descriptiont--Ljava/lang/String;L--
orderLinest--Ljava/util/List;L--totalCostt--Ljava/math/BigDecimal;xp--------ppsr--java.util.ArrayListx-----
a----I--sizexp----w-----sr--model.OrderLine--&-1-S----I--lineNumberL--costq-~--L--descriptionq-~--L--ordert--
Lmodel/Order;xp----sr--java.math.BigDecimalT--W--(O---I--scaleL--intValt--Ljava/math/BigInteger;xr--
java.lang.Number-----------xp----sr--java.math.BigInteger-----;-----I--bitCountI--bitLengthI--
firstNonzeroByteNumI--lowestSetBitI--signum[--magnitudet--[Bxq-~----------------------ur--[B------T----xp----
xxpq-~--xq-~--
Java Serialization
final case class Order(id: Long, description: String, totalCost: BigDecimal,
orderLines: ArrayList[OrderLines], customer: Customer)
<order id="0" totalCost="0"><orderLines lineNumber="1" cost="0"><order>0</order></orderLines></order>XML…!
{"order":{"id":0,"totalCost":0,"orderLines":[{"lineNumber":1,"cost":0,"order":0}]}}JSON…!
------java-util-ArrayLis-----model-OrderLin----java-math-BigDecima---------model-Orde-----Kryo…!
Excellent post by James Sutherland @
http://java-persistence-performance.blogspot.com/2013/08/optimizing-java-serialization-java-vs.html
Java Serialization は遅い
性能を出したければ、ProtoBuf か Kryo
63. 7番: Avoid Java Serialization for Persistence!!!
Java Serialization is a horrible idea if you’re going to store the
messages for a long time.
For example, with Akka Persistence we store events “forever”.
Use a serialization format that can evolve over time in a
compatible way. It can be JSON or ProtocolBuffers (or Thrift
etc).
Java Serialization を永続化に使わない
スキーマの変更しやすいフォーマットを選ぶべき
64. 7.5番: Trust no-one, benchmark everything!
Always measure and benchmark properly
before judging performance of a tool / library.
Benchmarking is often very hard,
use the right tools:
- JMH (for Scala via: ktoso/sbt-jmh)
-YourKit / JProfiler / …
- Linux perf_events
7.5番
推測するな、計測せよ
ベンチマークを書いてプロファイラでスレッドの挙動を診断
65. 8番: Let it Crash! Supervision, Failures & Errors
66. http://www.reactivemanifesto.org/
8番: Let it Crash! Supervision, Failures & Errors
Error
… which is an expected and coded-for condition—for
example an error discovered during input validation, that
will be communicated to the client …
Failure
… is an unexpected event within a service that
prevents it from continuing to function normally.
A failure will generally prevent responses to the current,
and possibly all following, client requests.
75. 9番: Backoff Supervision
Our goal is to “let things crash”
and “recover gracefully”
Not to hammer the DB while it tries to recover!
クラッシュさせた上で、しなやかな回復を目指す
78. 9番: Backoff Supervision
IF we allowed immediate restarts…
we could end up in “infinite replay+fail hell”.
(we don’t. since Persistence went stable in 2.4.x)
クラスタでは BackoffSupervisor
全アクターが同時に再起動し DB に殺到するのを防ぐ
85. 10番: Design using State Machines
def receive = {
case Thingy() =>
// ...
case AnotherThingy() =>
// ...
case DoOtherThings() =>
// ...
case PleaseGoAway() =>
// ...
case CarryOn() =>
// ...
case MakeSomething() =>
// ...
// ...
}
有限状態機械を作る
FSM トレイトか become メソッドを使う
86. 10番: Design using State Machines
def receive = {
case Thingy() =>
// ...
case AnotherThingy() =>
// ...
case DoOtherThings() =>
// ...
case PleaseGoAway() =>
// ...
case CarryOn() =>
// ...
case MakeSomething() =>
// ...
// ...
}
Good:
Actors avoid the “pyramid of doom”.
Pyramid of doom in some
async programming styles.
有限状態機械を作る
FSM トレイトか become メソッドを使う
87. 10番: Design using State Machines
def receive = {
case Thingy() =>
// ...
case AnotherThingy() =>
// ...
case DoOtherThings() =>
// ...
case PleaseGoAway() =>
// ...
case CarryOn() =>
// ...
case MakeSomething() =>
// ...
// ...
}
That well works because
“everything is a message”:
有限状態機械を作る
FSM トレイトか become メソッドを使う
88. 10番: Design using State Machines
def receive = awaitingInstructions
def awaitingInstructions: Receive =
terminationHandling orElse {
case CarryOn() =>
// ...
case MakeSomething(metadata) =>
// ...
context become makeThings(meta)
}
def makeThings(metadata: Metadata): Receive =
terminationHandling orElse {
case Thingy() =>
// make a thingy ...
case AnotherThingy() =>
// make another thingy ...
case DoOtherThings(meta) =>
// ...
context become awaitingInstructions
}
def terminationHandling: Receive = {
case PleaseGoAway() =>
// ...
context stop self
}
有限状態機械を作る
FSM トレイトか become メソッドを使う
DoOtherThings
MakeSomething
89. 10番: Design using State Machines
We also provide an FSM (Finite State Machine) helper trait.
You may enjoy it sometimes, give it a look.
DoOtherThings
MakeSomething
http://doc.akka.io/docs/akka/2.4.1/scala/fsm.html
class Buncher extends FSM[State, Data] {
startWith(Idle, Uninitialized)
when(Idle) {
case Event(SetTarget(ref), Uninitialized) =>
stay using Todo(ref, Vector.empty)
}
// transition elided ...
when(Active, stateTimeout = 1 second) {
case Event(Flush | StateTimeout, t: Todo) =>
goto(Idle) using t.copy(queue = Vector.empty)
}
// unhandled elided ...
initialize()
}
有限状態機械を作る
FSM トレイトか become メソッドを使う
91. 11番: Cluster Convergence and Joining
http://doc.akka.io/docs/akka/2.4.1/common/cluster.html
Cluster Gossip Convergence
When a node can prove that the cluster state it is observing
has been observed by all other nodes in the cluster.
92. 11番: Cluster Convergence and Joining
http://doc.akka.io/docs/akka/2.4.1/common/cluster.html
Cluster Gossip Convergence
When a node can prove that the cluster state it is observing
has been observed by all other nodes in the cluster.
Convergence is required for “Leader actions”,
which include Join-ing and Remove-ing a node.
Down-ing can happen without convergence.
109. 12番: Cluster Partitions and “Down”
Make sure the others have heard you say goodbye before you leave.
Vanishes immediately.
110. 12番: Cluster Partitions and “Down”
Make sure the others have heard you say goodbye before you leave.
“Where’s Bill?
I did not hear him say Goodbye!”
“Failure Detector” used to determine UNREACHABLE.
111. 12番: Cluster Partitions and “Down”
Failure detection only triggers “UNREACHABLE”.
Nodes can come back from that state.
112. 12番: Cluster Partitions and “Down”
Declaring DOWN is done by either timeouts (which is rather unsafe) [auto-downing].
Or by “voting” or “majority” among the members of the cluster [split-brain-resolver].
116. 12番: Cluster Partitions and “Down”
お
前
は
も
う
死
ん
で
い
る
.
.
.
.
Why do we do that?
In order to guarantee consistency via
“single writer principle”.
Note:
Akka Distributed Data has no need for
“single writer”, it’s CRDT based. But it’s harder to
model things as CRDT, so it’s a trade off.
117. 12番: Cluster Partitions and “Down”
Notice that we do not mention “Quarantined”.
That is a state in Akka Remoting, not Cluster.
It’s a terminal state from which one can never recover.
TL;DR;
use Akka Cluster instead of Remoting.
it’s pretty much always the thing you need (better than remoting).
119. 13番: A fishing rod is a Tool. Akka is a Toolkit.
Akka strives is Toolkit,
not a Framework.
“Give a man a fish and you feed him for a day
teach a man to fish and you feed him for a lifetime.”
120. 13番: Akka is a Toolkit, pick the right tools for the job.
“Constraints Liberate,
Liberties Constrain”
Runar Bjarnason
Runar’s excellent talk @ Scala.World 2015
121. 13番: Akka is a Toolkit, pick the right tools for the job.
Runar’s excellent talk @ Scala.World 2015
The less powerful abstraction
must be built on top of
more powerful abstractions.
122. 13番: Akka is a Toolkit, pick the right tools for the job.
Runar’s excellent talk @ Scala.World 2015
Asynchronous processing toolbox:
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
123. 13番: Akka is a Toolkit, pick the right tools for the job.
Runar’s excellent talk @ Scala.World 2015
Asynchronous processing toolbox:
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
124. 13番: Akka is a Toolkit, pick the right tools for the job.
Asynchronous processing toolbox:
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
125. 13番: Akka is a Toolkit, pick the right tools for the job.
Single value, no streaming by definition.
Local abstraction.
Execution contexts.
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
126. 13番: Akka is a Toolkit, pick the right tools for the job.
Mostly static processing layouts.
Well typed and Back-pressured!
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
127. 13番: Akka is a Toolkit, pick the right tools for the job.
Plain Actor’s younger brother, experimental.
Location transparent, well typed.
Technically unconstrained in actions performed
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
128. 13番: Akka is a Toolkit, pick the right tools for the job.
Runar’s excellent talk @ Scala.World 2015
Location transparent.
Various resilience mechanisms.
(watching, persistent recovering, migration, pools)
Untyped and unconstrained in actions performed.
Akka は道具箱。正しい道具を選ぶべし。
レゴを組み合わせるようにしてアプリを作れる
129. 13番: Akka is a Toolkit, pick the right tools for the job.
Akka it a Toolkit. Not a Framework.
Another example is persisting data.
Akka Persistence is specifically geared towards Event Sourcing.
If you know you you want a raw Key-Value Store and do not need
Event Sourcing’s capabilities, don’t use Akka Persistence –
it would be the wrong tool for the job.
If you use it for Event Sourcing though… it’ll work very well for you.
There it is the right tool for the job.
用途に合わない道具は使うべきではない
例えば CQRS が適切でない時は生 DB アクセスを使えば済む
131. 14番: Happy hAkking, Community!
akka.io – website
github.com/akka/akka/issues – help out!
“community-contrib” or “small” for starters
groups.google.com/group/akka-user – mailing list
gitter.im/akka/akka – chat about using Akka
gitter.im/akka/dev – chat about developing Akka
134. ありがとう!
ktoso @ typesafe.com
twitter: ktosopl
github: ktoso
team blog: letitcrash.com
home: akka.io
Thus spake the Master Programmer:
“After three days without programming,
life becomes meaningless.”
135. Q/A
(Now’s the time to ask things!)
ktoso @ typesafe.com
twitter: ktosopl
github: ktoso
team blog: letitcrash.com
home: akka.io