Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Today Software
● Cluster of multi-core machines● Fast networks● Lots of concurrent users● Large data sets● Latency in milliseconds
Our Needs
● Cope to Enterprise Software Complexity
● Scalability / Performance
Reactive Manifesto
Responsive
Resilient
Message Driven
Elastic
http://www.reactivemanifesto.org/
Code Complexity
Complexity
● Programming paradigms
– Imperative → OOP, Statements, …
– Functional → HOF, Immutability, Expressions,...
Programming Paradigms
● Imperative: how to solve– procedural, object-oriented, statements
● Declarative: what to solve– functional, immutability, expressions
Imperative
● Sequence of statements● Contents of memory as state● Statements update variables (mutation)● Assignment, control structures
Example
OOP
● Encapsulation
● Inheritance– Reuse → Composition
– Extension
● Polymorphism– Ad-hoc
– Parametric
– Dynamic
Functional
● Based on Lambda calculus● Functions form programs● Same input → same output● Avoids mutation● Higher order functions
Example
Side Effects
● Global Variables
Side Effects
● Function State, Object State
Side Effects Matter
● Harder to reason about program● Harder to test● Harder to extend, parallelize, …
How to avoid them?
Statements vs Expressions
→
Functions as 1st-class Members
Functions as values
Lambda Expressions
● block of code with parameters executed later
Clojures
Immutability
Statelessness
● should perform every task as if for the first time– ignorant of the past
Thinking in Functions
● All of your functions must accept at least one argument
● All of your functions must return data or another function
● No loops!
Multi paradigm Implementations
● Imperative with functional features– Java, C#, Python, Ruby
● Functional with OO features– Scala
– Ocaml, f#
What makes difference?– Higher order functions
– Immutable data structures
– Recommended functional style idioms
Scala :D
www.toptal.com
www.toptal.comwww.toptal.comwww.toptal.com
Why Scala
● Nice functional support– Basically functional + immutable data structures + ...
● Type inference system– Less program code, more type checks
● Designed for scalability
● Stick with JVM echo system
Scala Features
● Lambda expressions, closures and currying naturally
● Pattern matching
● Multiple inheritance through Traits
● Comprehensive collections library
Collections
Immutability
● Variables– val VS var
● Collections
● Value objects (case classes)
Case classes
Pattern Matching
Functional Programing Issues
● Input/output difficult to deal with– Monadic operations
● Requires garbage collection
● Sometimes slower (but usually not by much)
● Stateful operations are cumbersome
Learn more
● http://www.scala-lang.org/old/node/8610
Concurrency Models
Thread based Model
● Shared mutable state● Threads concurrently execute code sections
– Synchronization
– Locking mechanism– Not scalable
– Edward A. Lee, The Problem with Threads
Always Blocking
● Latency– CPU → 1ns (=> 1 second)
– RAM → 250,000ns (=> 3 days)
– TCP →150,000,000ns (=> 5 years)
Non blocking Code
Future
Future
Futures in Scala
Event Loop Model
● Implemented in Node.js
Message Passing Model
● 1973, paper by Carl Hewitt● Avoid the problems caused by threading and
locking ● Implemented in Erlang, Scala
Actor Model
● Actors instead of objects
● No shared state between actors
● Asynchronous message-passing
– Immutable messages
● Mailboxes
Actor Benefits
● Higher abstraction level– Easier to reason about
● Easier to avoid– Race conditions– Deadlocks– Starvation– Live locks
● Distributed computing
Example in Erlang
Erlang Actors in Real
● Ericson AXD 301 switch– millions of calls per ,99.9999999 percent uptime
● Facebook chat application– 70 million concurrent users
● RabbitMQ– high-performance AMQP, 400,000 messages per second.
● Apache CouchDB– distributed, fault-tolerant document-oriented database
● Ejabberd XMPP server – jabber.org
JVM implementations
● Java– Kilim, Jetlang, ActorFoundry, Actors Guild
● Scala (FP + actor model)– Akka
● Groovy– GParallelizer
Akka :x
Akka
● Concurrency– mailboxes
– dispatchers
● Scalability– Remote actors, clustering
● Fault tolerance– Actor supervision
Akka Actors
● Define messages● Create new actors● Send messages to others
– Fire & forget
– Send & receive eventually
– Send & receive with future
● Become● Supervise
Akka Actor in Java
Akka actor in Scala
Talk to Actors
Actor Hierarchies
● Name resolution: file system like
Supervision & Resilience
● OneForOneStrategy VS AllForOneStrategy
● Monitor through Death Watch
● Every single actor has a default supervisor strategy. Which is usually sufficient. But it can be overridden
Scalability & Elasticity
● Scale Up VS Scale Out– Essentially are same thing
● Minimize Contention● Maximize Locality of Reference
– Share Nothing Design
Akka Routers
● RoundRobinRoutingLogic
● RandomRoutingLogic
● SmallestMailboxRoutingLogic
● BroadcastRoutingLogic
● ScatterGatherFirstCompleted
● TailChoppingRoutingLogic
● ConsistentHashingRoutingLogic
Akka Clustering
Simple Bulk Aggregator
Better Bulk Aggregator
Akka Adoption
.End()
bacheHa thank { qList => qList forEach (_.answer)}
Related Documents
