网络编程框架Socket编程接口NIO编程接口Leader Follower 原理SEDA原理Netty编程框架Mina编程框架Web编程框架分布式应用∙负载均衡器/Load Balancer Session Stickiness∙内存状态复制/Replication Sysch-replicationAsych-replication∙Local CacheConcurrentHashMapFastMapLocal QueueQueuesQueues类似于沟通“生产者”和“消费者”的管道。
组件从管道的一端放入，然后从另一端取出：“先进先出”(FIFO)的顺序。
Queue接口在JavaSE5新添加到java.util中的，能够被用于单线程访问的场景中，主要适用于多个生产者、一个或多个消费者的情景，所有的读写操作都是基于同一个队列。
java.util.concurrent包中的BlockingQueue接口是Queue的子接口，而且还添加了新的特性处理如下场景：队列满（此时刚好有一个生产者要加入一个新的组件）、队列空（此时刚好有一个消费者读取或者删除一个组件）。
BlockingQueue提供如下方案解决这些情况：一直阻塞等待直到其他线程修改队列的数据状态;阻塞一段时间之后返回，如果在这段时间内有其他线程修改队列数据，那么也会返回。
Deque在JavaSE6中新增加了两端都可以添加和删除的队列-Deque (发音"deck",not "dick"). Deques不仅可以从一端添加元素，从另一端移除，而且两端都可以添加和删除元素。
如同BlockingQueue，BlockingDeque接口也为阻塞等待和超时等待的特殊情况提供了解决方法。
因为Deque继承Queue、BlockingDeque继Deque的一个特殊应用场景是只在一个端口进行添加、删除、检查操作--堆栈（first-in-last-out顺序)。
Deque接口提供了stack相同的方法：push(), pop()和peek()，这方法和addFirst(), removeFirst(), peekFirst()一一对应，可以把Deque的任何一个实现类当做堆栈使用。
表6中是JDK中Deque和BlockingDeque的实现。
注意Deque继承Queue，BlockingDeque继承自BlockingQueue。
分布式缓存CoherenceJboss CacheMem Cache分布式数据存储数据库的垂直划分和水平划分数据库的读写分离分布式事务分布式事务处理是指一个事务可能涉及多个数据库操作，分布式事务处理的关键是必须有一种方法可以知道事务在任何地方所做的所有动作，提交或回滚事务的决定必须产生统一的结果（全部提交或全部回滚）。
X/Open DTP 模型简介X/Open组织（即现在的Open Group）定义了分布式事务处理模型。
X/Open DTP模型（1994）包括应用程序（AP）、事务管理器（TM）、资源管理器（RM）、通信资源管理器（CRM）四部分。
一般，常见的事务管理器（TM）是交易中间件，常见的资源管理器（RM）是数据库，常见的通信资源管理器（CRM）是消息中间件。
The X/Open DTP model is a model for software architecture that allows multiple application programs to share resources provided by multiple resource managers, and allows their work to be coordinated into global transactions.The X/Open DTP model identifies the key entities in a distributed transaction processing environment and standardizes their roles and interactions. The entities are: The transaction processing monitor (TM)∙The resource manager (RM)∙The application program (AP)This section discusses the X/Open DTP functional model, including its major components and their interfaces. The following figure shows the X/Open DTP model.A conceptual view of the X/Open DTP model通常把一个数据库内部的事务处理，如对多个表的操作，作为本地事务看待。
数据库的事务处理对象是本地事务，而分布式事务处理的对象是全局事务。
所谓全局事务，是指分布式事务处理环境中，多个数据库可能需要共同完成一个工作，这个工作即是一个全局事务，例如，一个事务中可能更新几个不同的数据库。
对数据库的操作发生在系统的各处但必须全部被提交或回滚。
此时一个数据库对自己内部所做操作的提交不仅依赖本身操作是否成功，还要依赖与全局事务相关的其它数据库的操作是否成功，如果任一数据库的任一操作失败，则参与此事务的所有数据库所做的所有操作都必须回滚。
一般情况下，某一数据库无法知道其它数据库在做什么，因此，在一个DTP环境中，交易中间件是必需的，由它通知和协调相关数据库的提交或回滚。
而一个数据库只将其自己所做的操作（可恢复）影射到全局事务中。
XA就是X/Open DTP定义的交易中间件与数据库之间的接口规范（即接口函数），交易中间件用它来通知数据库事务的开始、结束以及提交、回滚等。
XA接口函数由数据库厂商提供。
XA 与两阶段提交协议Basic algorithmCommit request phase/voting phase1.The coordinator sends a query to commit message to all cohorts and waits until ithas received a reply from all cohorts.2.The cohorts execute the transaction up to the point where they will be asked tocommit. They each write an entry to their undo log and an entry to their redo log.3.Each cohort replies with an agreement message (cohort votes Yes to commit), ifthe cohort's actions succeeded, or an abort message (cohort votes No, not tocommit), if the cohort experiences a failure that will make it impossible to commit.Commit phase/Completion phaseSuccessIf the coordinator received an agreement message from all cohorts during the commit-request phase:1.The coordinator sends a commit message to all the cohorts.2.Each cohort completes the operation, and releases all the locks and resources heldduring the transaction.3.Each cohort sends an acknowledgment to the coordinator.4.The coordinator completes the transaction when acknowledgments have beenreceived.FailureIf any cohort votes No during the commit-request phase (coordinator will send an abort message):1.The coordinator sends a rollback message to all the cohorts.2.Each cohort undoes the transaction using the undo log, and releases the resourcesand locks held during the transaction.3.Each cohort sends an acknowledgement to the coordinator.4.The coordinator undoes the transaction when all acknowledgements have beenreceived.通常情况下，交易中间件与数据库通过XA 接口规范，使用两阶段提交来完成一个全局事务，XA规范的基础是两阶段提交协议。
在第一阶段，交易中间件请求所有相关数据库准备提交（预提交）各自的事务分支，以确认是否所有相关数据库都可以提交各自的事务分支。
当某一数据库收到预提交后，如果可以提交属于自己的事务分支，则将自己在该事务分支中所做的操作固定记录下来，并给交易中间件一个同意提交的应答，此时数据库将不能再在该事务分支中加入任何操作，但此时数据库并没有真正提交该事务，数据库对共享资源的操作还未释放（处于上锁状态）。
如果由于某种原因数据库无法提交属于自己的事务分支，它将回滚自己的所有操作，释放对共享资源上的锁，并返回给交易中间件失败应答。
在第二阶段，交易中间件审查所有数据库返回的预提交结果，如所有数据库都可以提交，交易中间件将要求所有数据库做正式提交，这样该全局事务被提交。
而如果有任一数据库预提交返回失败，交易中间件将要求所有其它数据库回滚其操作，这样该全局事务被回滚。
以一个全局事务为例，AP首先通知交易中间件开始一个全局事务，交易中间件通过XA接口函数通知数据库开始事务，然后AP可以对数据库管理的资源进行操作，数据库系统记录事务对本地资源的所有操作。