Building High Scalability Apps With Terracotta

Building High Scalability Apps with Terracotta

David ReinesSenior Architect

Object Partners Inc.

david.reines@objectpartners.comtwitter: dhreines

Agenda

Terracotta OverviewProductsDistributed Shared Objects (DSO)

ArchitectureDistributed Shared Objects

Roots and Instrumented ClassesLocksData StructuresObject Identity

Designing to ScaleDemo

Terracotta Overview

Terracotta is an open source software solution that provides JVM-level clustering.

Plugs into the Java Memory ModelUtilizes bytecode manipulation

ConsistentCreates a virtual heap across multiple nodesProvides highly optimized cluster-wide locking

AvailableTerracotta active/standby servers provide high-availabilityData persisted to disk to survive certain disaster scenarios

Terracotta Server Array provides "linear" scalability

Terracotta Products

Terracotta ProductsDistributed Ehcache

cache eviction algorithmswrite-through/write-behindJTA support (XA compliant)monitoring

Distributed Ehcache for HibernateJob Store for QuartzWeb Session ClusteringSpring Framework Clustering

Distributed Shared Objectsthe foundation of Terracotta Products

Terracotta Architecture

Client JVM(s) (L1)Application logicCommunicates with active Terracotta server(s)Supports numerous standard containersUtilize Terracotta Integration Modules (TIMs)

Terracotta Server(s) (L2) Data management

data storage (memory and disk)full-fill L1 data requests/change broadcastsdistributed garbage collection

Lock managementActive server(s) replicate data to standby server(s) in real-time

Deployment Options

Permanent StorageRecommended for high-availability modeStores data to disk (Berkeley-DB)Disk speed will impact performance

Active/StandbyAllows for high availabilityActive server "elected" at start-upAutomatic failover if active fails

Terracotta Server Array (Enterprise Only)Provides "linear" scalabilityMultiple active/standby "mirror groups"Transparent to the application tier

Terracotta Cluster

Open Source vs. Enterprise

Open Source VersionProduction readyHigh availabilityVery high throughput and performanceDeveloper consoleLimited to a single active server

Enterprise VersionTerracotta Server Array (Terracotta FX)Additional Enterprise Operations and Management ToolsProduction back-up and restore Certified Patches, Support

Simple upgrade from open source to enterprise version.

Distributed Shared Objects (DSO)

As a developer, you may never need to work directly with Terracotta DSOs.

Terracotta products such as Ehcache hide the complexity of DSOs from developers.

The concepts are still important because DSOs provide the foundation for Terracotta's products.

If needed, developers can still utilize DSOs directly.

RootRoot

Applications define root(s)A root and it's references are clusteredA root cannot be changed

/** * Singleton CustomerService. */private class CustomerService {@Rootprivate ConcurrentDistributedMap<Long, Customer> customers;}

Instrumented Classes

Instrumented ClassShared objects must be instrumentedSerializable not requiredRoot container is automatically instrumented

/** * Shared Customer. */@InstrumentedClasspublic class Customer {...}

Locks

Terracotta LocksProvide cluster-wide synchronizationProvide a means for terracotta "transactions"Modifications to clustered objects must occur within a clustered lock.Utilizes standard Java synchronization syntax

Lock Supportread/writesynchronous-writeReentrantReadWriteLock

Lock OptimizationGreedy locks - once obtained, no need to contact server

Object Identity

Objects are assigned a cluster-wide ObjectId

Object identity is maintained cluster-wide!

Multiple objects can reference the same object instance cluster-wide

Only data changes are broadcast

Not completely true when using ehcache serialization mode.Good reasons for either option. Ehcache provides the flexibility to choose per cache.

Designing to Scale

Partial Loading and Locality of Reference

To properly scale an application can utilize partial loading to maintain a good locality of reference .

Partial Loading

Consider the following example:

Map<String, ReallyBigObject>

Loading all elements into each node limits scalability.

Partial Loading a MapTerracotta faults the keys into each node in the clusterValues are faulted into node(s) as needed

Data Structures Supporting Partial LoadingDSO Data Structures Guide(i.e. LinkedBlockingQueue)

Locality of Reference

Always access and update the same data on the same node.

For example, CustomerId 100 is always accessed on Client JVM #1

BenefitsUses partial loading Minimizes lock recalls - greedy locksMinimizes fault ratesMinimizes flush ratesMinimizes change broadcastsReduces L1 garbage collection cycles

Locality of Reference (cont)

Potential Routing OptionsLoad-balancers (i.e. session, url or header properties)Custom Client Libraries

Potential Routing KeysHttpSession IdCustomerIdUserIdetc...

FailoverIf a node fails, route requests to another serverObjects transparently fault into memory

Designing to Scale

* Transparent Failover

Demo

Referenceshttp://www.terracotta.org/documentation/ga/product-documentation-1page

http://www.terracotta.org/confluence/display/docs/Concept+and+Architecture+Guide

http://blog.terracottatech.com/archive/2005/08/object_identity.html

http://www.terracotta.org/confluence/display/docs/DSO+Data+Structures+Guide

Data Structures (via terracotta.org)