Reactive Software Systems
7 likes1,040 views
This document discusses reactive software systems and programming paradigms like functional programming. It introduces concepts like actors, futures, and message passing from frameworks like Akka that help build responsive and resilient reactive applications. The document also covers Scala features for functional programming like immutability, pattern matching, and actors from the Akka framework in Scala.
Ad
More Related Content
What's hot (20)
Viewers also liked (13)
Ad
Similar to Reactive Software Systems (20)
Ad
Recently uploaded (20)
Reactive Software Systems
- 1. Reactive Software Systems Behrad Zari [email protected] Fall 2014
- 2. Today Software ● Cluster of multi-core machines ● Fast networks ● Lots of concurrent users ● Large data sets ● Latency in milliseconds
- 3. Our Needs ● Cope to Enterprise Software Complexity ● Scalability / Performance
- 4. Reactive Manifesto Responsive Resilient Message Driven Elastic http://www.reactivemanifesto.org/
- 6. Complexity ● Programming paradigms – Imperative → OOP, Statements, … – Functional → HOF, Immutability, Expressions,...
- 7. Programming Paradigms ● Imperative: how to solve – procedural, object-oriented, statements ● Declarative: what to solve – functional, immutability, expressions
- 8. Imperative ● Sequence of statements ● Contents of memory as state ● Statements update variables (mutation) ● Assignment, control structures
- 9. Example
- 10. OOP ● Encapsulation ● Inheritance – Reuse → Composition – Extension ● Polymorphism – Ad-hoc – Parametric – Dynamic
- 11. Functional ● Based on Lambda calculus ● Functions form programs ● Same input → same output ● Avoids mutation ● Higher order functions
- 12. Example
- 13. Side Effects ● Global Variables
- 14. Side Effects ● Function State, Object State
- 15. Side Effects Matter ● Harder to reason about program ● Harder to test ● Harder to extend, parallelize, … How to avoid them?
- 17. Functions as 1st-class Members Functions as values
- 18. Lambda Expressions ● block of code with parameters executed later
- 19. Clojures
- 20. Immutability
- 21. Statelessness ● should perform every task as if for the first time – ignorant of the past
- 22. 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!
- 23. 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
- 24. Scala :D
- 26. 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
- 27. Scala Features ● Lambda expressions, closures and currying naturally ● Pattern matching ● Multiple inheritance through Traits ● Comprehensive collections library
- 28. Collections
- 29. Immutability ● Variables – val VS var ● Collections ● Value objects (case classes)
- 30. Case classes
- 31. Pattern Matching
- 32. 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
- 33. Learn more ● http://www.scala-lang.org/old/node/8610
- 35. Thread based Model ● Shared mutable state ● Threads concurrently execute code sections – Synchronization – Locking mechanism – Not scalable – Edward A. Lee, The Problem with Threads
- 36. Always Blocking ● Latency – CPU → 1ns (=> 1 second) – RAM → 250,000ns (=> 3 days) – TCP →150,000,000ns (=> 5 years)
- 38. Future
- 39. Future
- 40. Futures in Scala
- 41. Event Loop Model ● Implemented in Node.js
- 42. Message Passing Model ● 1973, paper by Carl Hewitt ● Avoid the problems caused by threading and locking ● Implemented in Erlang, Scala
- 43. Actor Model ● Actors instead of objects ● No shared state between actors ● Asynchronous message-passing – Immutable messages ● Mailboxes
- 44. Actor Benefits ● Higher abstraction level – Easier to reason about ● Easier to avoid – Race conditions – Deadlocks – Starvation – Live locks ● Distributed computing
- 46. 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
- 47. JVM implementations ● Java – Kilim, Jetlang, ActorFoundry, Actors Guild ● Scala (FP + actor model) – Akka ● Groovy – GParallelizer
- 48. Akka :x
- 49. Akka ● Concurrency – mailboxes – dispatchers ● Scalability – Remote actors, clustering ● Fault tolerance – Actor supervision
- 50. Akka Actors ● Define messages ● Create new actors ● Send messages to others – Fire & forget – Send & receive eventually – Send & receive with future ● Become ● Supervise
- 51. Akka Actor in Java
- 52. Akka actor in Scala
- 53. Talk to Actors
- 54. Actor Hierarchies ● Name resolution: file system like
- 55. 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
- 56. Scalability & Elasticity ● Scale Up VS Scale Out – Essentially are same thing ● Minimize Contention ● Maximize Locality of Reference – Share Nothing Design
- 57. Akka Routers ● RoundRobinRoutingLogic ● RandomRoutingLogic ● SmallestMailboxRoutingLogic ● BroadcastRoutingLogic ● ScatterGatherFirstCompleted ● TailChoppingRoutingLogic ● ConsistentHashingRoutingLogic
- 58. Akka Clustering
- 61. Akka Adoption
- 62. .End() bacheHa thank { qList => qList forEach (_.answer) }