About me • Call me Azrul • Solu'on Architect at Experian Decision
Analy'cs • In charge of Experian’s stuff:
– BI – Business Ac'vity Monitoring – Integra'on
• OSGi stuff • Love to read • Black belt in Aikido • No concurrency expert,
– just a wild enthusiast!!
Menu of the day
• Why concurrency? • Concurrency is hard • Producer consumer • Using disruptor • PaUerns
Why concurrency?
• Cloud • Mul'-‐core • Mul'-‐channel • Complex business process
Concurrency is hard! Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Concurrency is hard! Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Concurrency is hard! Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Stuck here!
Concurrency is hard!
• Random decisions in different places influence each other
• Influence each other BADLY!
Solving concurrency with locking Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Wait for resource A to be available
Wait for resource B to be available
Reserve resource B
Reserve resource A
Use A and B
Release A and B
Monitor
Solving concurrency with locking
• Locking is done through ‘monitors’
• OS or VM level • Like a toilet – If someone is using it, everyone else has to wait
– Acquiring a lock is generally SLOW!
CAS to the rescue
• CAS = Compare-‐And-‐Swap • ‘Hardware’ level locking • Atomic opera'ons • Crazy fast – mul'-‐core friendly
CAS to the rescue – incremen'ng a value
Get ‘input’
Increment
Compare
Input = 21
Input = 21
21
Shared memory
result = 22
Set
Input = 21
Same
Different
result = 22
Changed by another thread
CAS to the rescue
• Java example
AtomicInteger counter = new AtomicInteger(1); … int currentValue = counter.getAndIncrement();
PRODUCER -‐ CONSUMER
Producer -‐ consumer Producers
Producer -‐ consumer Producers
Mess
Producer -‐ consumer Consumer (cleaner) Producers
Mess
Producer -‐ consumer
• Other examples Industry Producer Consumer
Banking Credit card applica'on
User “credit worthiness” verifica'on
Insurance Insurance applica'on
Underwri'ng process
Manufacturing Raw material delivery
Factory worker
Producer -‐ consumer
• Problems – Producer is producing faster than consumer can consumer
Solu'on 1: Array blocking queue
• Classic solu'on: Using array blocking queue – Producer would queue things if consumer is slow – Consumer can consume at its own pace – If queue is full, producer will be blocked
Solu'on 1: Array blocking queue
• Classic solu'on: Using array blocking queue – Advantage: Scalability = many consumers
Solu'on 1: Array blocking queue
• Main problem: – Queue need to be locked
• For consumer to read • For producer to write
– Producer is blocked if queue is full – Lock => Slow
Solu'on 2: Using ring buffer & CAS
• Producer will never be blocked – we just “wrap around” the circular queue (write over older entry)
• Elements of ring buffer are set using CAS • => Ring buffer is very very fast
Solu'on 2: Using ring buffer & CAS
• Ring buffer + CAS = Disruptor • Create by LMAX – Doing High frequency trading
• “100 k TPS at 1 ms latency” • Disruptor also includes a few other op'miza'ons
USING DISRUPTOR
Loan applica'on processing
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Loan applica'on processing
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Loan applica'on processing
X 100 every second
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Loan applica'on processing
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Loan applica'on processing
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Tedious in your typical applica'on
server (resort to JMS)
Loan applica'on processing – with Disruptor
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Disruptor
Loan applica'on processing – with Disruptor
Applica'on by user
Pre-‐bureau processing
Call credit bureau
Approved / refer / reject
Save data
Disruptor
Handle ‘forking’ Handle parallel users Handle ‘workflow’
Loan applica'on processing – with Disruptor
Disruptor<MyEvent> disruptor = new Disruptor<MyEvent>(…); //read data disruptor.handleEventsWith(preBureauProcessing). //first do this then(callBureau). //next do this then( approvedReferReject, saveData); //arer that, do these in parallel //run disruptor RingBuffer<ValueEvent> ringBuffer = disruptor.start(); //write (applica'on by user) long sequence = ringBuffer.next(); MyEvent event = ringBuffer.get(sequence); event.setValue(x); ringBuffer.publish(sequence);
Batch reading
Write
Write
Write
Batch reading
Read
USEFUL PATTERNS
Useful paUerns
• PaUerns I’ve experimented with – Not ‘in produc'on yet’ – Try it out on your own before commisng – Don’t sue me if it blows J
Topic replacement
Topic replacement AND
Topic replacement AND
Topic replacement
• Just use disruptor’s ‘default sesng’
Queue replacement OR
Queue replacement
• Use WorkerPool WorkerPool<ValueEvent> workerPool = new WorkerPool<ValueEvent>(…); workerPool.start(…) ;
Actors
• A unit of concurrent computa'on • From wikipedia: – “… in response to a message that it receives, an actor can make local decisions, create more actors, send more messages, and determine how to respond to the next message received”
Actors
Actors Actor = Worker Pool (Queue)
Actors Actor = Worker Pool (Queue)
Replica'on
‘Topic’ layout
Replica'on
‘Topic’ layout
JMS
Listener
JMS messaging over network
Replica'on
‘Topic’ layout
JMS
Listener
JMS messaging over network
Guaranteed delivery
Conclusion
• Disruptor – interes'ng and ‘disrup've’ framework
• Revenge of the “object oriented programming” model J
• Do your own experiments • Check out: – hUp://code.google.com/p/disruptor/ – hUp://mar'nfowler.com/ar'cles/lmax.html – hUp://mechani's.blogspot.com/2011/07/dissec'ng-‐disruptor-‐wiring-‐up.html
Top Related