Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à Building High Scalability Apps With Terracotta
Similaire à Building High Scalability Apps With Terracotta (20)
Dernier
Dernier (20)
Building High Scalability Apps With Terracotta
- 1. Building High Scalability Apps with Terracotta David Reines Senior Architect Object Partners Inc. david.reines@objectpartners.com twitter: dhreines
- 2. Agenda Terracotta Overview Products Distributed Shared Objects (DSO) Architecture Distributed Shared Objects Roots and Instrumented Classes Locks Data Structures Object Identity Designing to Scale Demo
- 3. Terracotta Overview Terracotta is an open source software solution that provides JVM-level clustering. Plugs into the Java Memory Model Utilizes bytecode manipulation Consistent Creates a virtual heap across multiple nodes Provides highly optimized cluster-wide locking Available Terracotta active/standby servers provide high-availability Data persisted to disk to survive certain disaster scenarios Terracotta Server Array provides "linear" scalability
- 4. Terracotta Products Terracotta Products Distributed Ehcache cache eviction algorithms write-through/write-behind JTA support (XA compliant) monitoring Distributed Ehcache for Hibernate Job Store for Quartz Web Session Clustering Spring Framework Clustering Distributed Shared Objects the foundation of Terracotta Products
- 5. Terracotta Architecture Client JVM(s) (L1) Application logic Communicates with active Terracotta server(s) Supports numerous standard containers Utilize Terracotta Integration Modules (TIMs) Terracotta Server(s) (L2) Data management data storage (memory and disk) full-fill L1 data requests/change broadcasts distributed garbage collection Lock management Active server(s) replicate data to standby server(s) in real- time
- 6. Deployment Options Permanent Storage Recommended for high-availability mode Stores data to disk (Berkeley-DB) Disk speed will impact performance Active/Standby Allows for high availability Active server "elected" at start-up Automatic failover if active fails Terracotta Server Array (Enterprise Only) Provides "linear" scalability Multiple active/standby "mirror groups" Transparent to the application tier
- 8. Open Source vs. Enterprise Open Source Version Production ready High availability Very high throughput and performance Developer console Limited to a single active server Enterprise Version Terracotta Server Array (Terracotta FX) Additional Enterprise Operations and Management Tools Production back-up and restore Certified Patches, Support Simple upgrade from open source to enterprise version.
- 9. 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.
- 10. Root Root Applications define root(s) A root and it's references are clustered A root cannot be changed /** * Singleton CustomerService. */ private class CustomerService { @Root private ConcurrentDistributedMap<Long, Customer> customers; }
- 11. Instrumented Classes Instrumented Class Shared objects must be instrumented Serializable not required Root container is automatically instrumented /** * Shared Customer. */ @InstrumentedClass public class Customer { ... }
- 12. Locks Terracotta Locks Provide cluster-wide synchronization Provide a means for terracotta "transactions" Modifications to clustered objects must occur within a clustered lock. Utilizes standard Java synchronization syntax Lock Support read/write synchronous-write ReentrantReadWriteLock Lock Optimization Greedy locks - once obtained, no need to contact server
- 13. 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.
- 14. 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 .
- 15. Partial Loading Consider the following example: Map<String, ReallyBigObject> Loading all elements into each node limits scalability. Partial Loading a Map Terracotta faults the keys into each node in the cluster Values are faulted into node(s) as needed Data Structures Supporting Partial Loading DSO Data Structures Guide (i.e. LinkedBlockingQueue)
- 16. 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 Benefits Uses partial loading Minimizes lock recalls - greedy locks Minimizes fault rates Minimizes flush rates Minimizes change broadcasts Reduces L1 garbage collection cycles
- 17. Locality of Reference (cont) Potential Routing Options Load-balancers (i.e. session, url or header properties) Custom Client Libraries Potential Routing Keys HttpSession Id CustomerId UserId etc... Failover If a node fails, route requests to another server Objects transparently fault into memory
- 18. Designing to Scale * Transparent Failover
- 19. Demo
- 21. Data Structures (via terracotta.org) http://www.terracotta.org/confluence/display/docs/DSO+Data+Structures+Guide