dejan pekter / nordeus – reactor design pattern
DESCRIPTION
Presentation on reactor design pattern should introduce you a pattern that our server’s core is based on. We will try to give away all pros and cons about it. This pattern is used to simplify development of highly concurrent servers by separating business logic from communication. This is very technical presentation, but it is designed for beginners so it should be understandable to anyone with basic software engineering skills.TRANSCRIPT
Reactor patternEvent handling pattern
Dejan PekterSoftware Development Engineer II
Nordeus and me
● Over 150 employees● Top Eleven
○ ~ 12 000 000 MAU○ ~ 5 000 000 DAU○ Cross-platform pioneer ○ Most popular online sports game
● Backend Software Development Engineer○ 250+ servers○ 10+ types○ 70.000 requests / minute○ Every fail is expected
Goal
● Share knowledge on Reactor design pattern used on our servers
● In example of server that is ○ Highly concurrent○ Highly responsive○ Well designed
● Consider different solutions○ Incrementally find solution○ Pros○ Cons
Prerequisites
● Design pattern ● Thread● Context switch● Request● Response
Easy solution
● Wait for clients to connect● For every accepted client
○ Create thread which will take responsibility over that client
Easy solution - conclusion
● Good:○ Intuitive○ Readable code○ Easy to understand
● Bad:○ 1000 users ~ 1000 threads○ Memory overhead○ Context switch overhead○ Create/kill overhead
Improved solution
● Create thread pool with N threads● Accept client
○ Pass client to thread pool ○ Thread pool assigns thread to that client
Improved solution - conclusion
● Good:○ Constrained number of threads○ Threads are reused
● Bad:○ Harder to implement○ Input/output is mixed with business logic○ Possibility of starvation
Basic nuclear reactor theory
NO! Re-act!
How would you react on good joke (event) that I can’t really tell?
FunnyThingHandler
How would you react onLOGIN_OR_REGISTER
You would not!Server would.
Event granulation
CLIENT MESSAGE
Reactor pattern
Reactor
Events
Callbacks
Event handler
EventHandler
+ handleEvent()+ getEventId()
LoginHandler
+ handleEvent()+ getEventId()
RegisterHandler
+ handleEvent()+ getEventId()
Reactor detailed design
EventHandler
+ handleEvent()+ getEventId()
LoginHandler
+ handleEvent()+ getEventId()
RegisterHandler
+ handleEvent()+ getEventId()
Server
Reactor
+ handleEvents()+ registerHandler()+ removeHandler()
dispatches 1 *
creates
Communicator
+ getEvents()
1
1
Reactor phases
● Initialize phase○ Registration of event handlers
● Event handling phase○ Gather all ready messages○ Process all messages
■ Get requests■ Identify event handler■ Execute callback
Reactor - Sequence Diagram
Main Program Event Handler Reactor
EventsregisterHandler()
instantiateHandler()
handleEvents()
handleEvent()
1) Initialize phase
2) Event handling phase
concreteHandler
event
Reactor solution - conclusion
● Good○ Logic is separated○ Easy to add new event handler○ Granulation to message level
● Bad○ Harder to debug○ Not intuitive○ Single threaded
Our improvements
● One reactor is not enough N reactors
● Separate logic even more○ Server - single thread
■ Accept clients ■ Dispatch to reactor by round robin
○ Reactor■ IO responsibility■ Build application level messages■ Find event handler■ send to dispatcher
○ Dispatcher - thread pool■ Execute callback
Our improvements - conclusion
● Good○ Responsibilities are fully separated○ 70.000 requests per minute in production○ Tested even for order of magnitude more○ Good design
● Bad○ Even harder debugging
Conclusion
● Reactor pattern○ Great maintainability○ Forget about how messages arrive, they just do○ Single threaded by definition○ Multithreaded in production
● Business○ Invest time and money in good solution○ You get new stuff almost for free
Remember...
● Don’t reinvent the wheel● Got the wheel, but you need a plane
○ think○ improve○ build it yourself
Don’t forget to...WORK AND PLAY
Thanks for your attention!Questions?