高性能、高流量Java Web站点打造的最佳实践
6. 考虑使用Oracle或者MySQL分片
当schema达到临界点，Oracle的可伸缩性将被限制，这里建议你对schema做基于功能（比如订单，产品目录，促销活动，客户等）上的分 片，同时也为高密度表做key shards。为key shards使用一致性哈希，这样当一个新的RAC被添加RAC集时，你不再需要遍历所有RAC中的键，以获悉哪些键需要被移动到键的分片中。
7. 如果你使用Oracle做RDBMS，考虑使用Data Guard及Golden Gate
使用这两种技术将大大简化甲骨文的运营周期，Data Guard允许一个近实时passive读副本（没有客户端会与之连接），而Golden Gate则允许一个近实时的active读写副本。
推荐的部署拓扑之一就是为同个数据中心的每个分片配置1个Data Guard；使用Golden Gate来备份其他数据中心的每一个分片。
注意：Golden Gate只是近实时
8. 为Oracle或者MySQL添加数据访问层
假设你有一个可以接受500个连接的Oracle RAC，而你有25个jBoss实例和这个甲骨文RAC对话，每个Jboss实例配置范围10到50的数据库连接池。
当jBoss集群开启时，连接到Oracle的数目为250（25乘10），一切运行良好。随着流量快到jBoss集群的峰值，想象一下将会发生什么。在某个点后，Oracle将开始拒绝连接。
因此建议通过一个Multiplexer层建立一个Multiplexe应用程序服务器连接。可以是一个简单的?netty应用，这个应用运行在一个每个netty节点仅能够与Oracle建立25个连接的集群上，但是对入站连接来者不拒。它会将所有的连接循环传递给Oracle，但是绝对不会超过25个，同时还使用Oracle JDBC驱动与Oracle通信。
9. 避免跨数据中心事务
当下，这已经是非常简单的事情，但是在任何地方都非常适用，包括Oracle。在两个数据不同数据中心，不要适用1个XA适配器去做跨数据中心事 务，这将导致相当长时间的应用线程阻塞，直到两个阶段的提交完成，因此将带来你的应用程序服务、服务和所有同步上传流崩溃，最终会因为线程数量增加而导致 整个应用程序崩溃，比如在类似Black Friday流量情况下。
10. 考虑分布式缓存框架
Memcached、Counbase是最常用的选择。但实际上，卸载非易失性数据到一个中心缓存集群上，确实没必要在每个JVM上做相同的拷贝。但是确实需要设置小数量的JVM堆作为分布式缓存的一个MRU缓存，这样的话，缓存集群本身将会受到非常少的网络调用。
?
在JVM上大多数分布式缓存支持本地缓存的概念，它将储存最常用的对象。JVM上，GC的pause time同样被最小化了，因为对象图中需要遍历的对象比以前更少了。Warmup过程是必不可少的，这可以帮助将数据导入分布式缓存，这个过程应该在晚上或者是用户访问量低的时候。