高性能、高流量Java Web站点打造的最佳实践

高性能、高流量Java Web站点打造的最佳实践

博客分类：

• Web性能

weboraclemysqljvm 

从2005年-2013年，Ashwanth Fernando曾供职于Best Buy、Pearson VUE、Walgreens、Walmart eCommerce等多家知名公司，现在Apple从事高级工程师、平台工程师一职，拥有丰富的高流量Web应用程序打造及架构经验，近日 Ashwanth撰文分享了他的高流量Web软件打造经验。

下为译文

受Joshua Bloch写的《Effective Java》启发，我想分享自己关于建立高流量Web软件的整体建议。这些术语中的一些可能不仅仅关于软件设计也关于工程组织、文化等相关领域。

免责声明

• 只代表个人观点
• 如发现与现实情况相违背的原则，请谨慎对待，或使用一般认识

1. 考虑使用不止一个数据中心

在商务领域，一直存在许多恐怖的道听途说，而这些恐慌都因为他们只使用了单一的数据中心。如果你想在自然灾害或者电力供应故障中幸免，那么请使用多 于1个的数据中心，使用active-active模式来配置你所有的数据中心。虽然在开销上可能会有所增加，但是比只使用单active的配置要值得多 ——因为在passive和active副本上，总会发现有些数据片不一致。

2. 考虑使用稀疏数据中心部署

不管是通过PaaS，还是运营团队进行，当软件集群被部署到同一个数据中心的机架上时，确保这些机架使用不同的电力供应。你不可能保证机架供电的万无一失，一旦失败将会导致整个机架上服务器的丢失，这个时候你绝对不会希望整个数据中心都只连在一个电路上。

3. 考虑使用私有云来组织资源

IaaS开源解决方案Openstack等其他的软件至今尚未成熟，需要庞大的团队来运营，在运行期间会产生各种各样的问题，除非你有足够的预算， 否则别考虑建立一个私有的云服务。然而，私有云可以提供众多优势。首先在部署方面就可以进行众多的定制化，这远比AWS或者是Rackspace货架上的 选择要多。其次它允许你做许多的硬件定制化，就好比在硬件层次的Oracle就比准虚拟化环境快得多。

4. 考虑使用PaaS做解决方案

为软件释放投入巨量人力进行部署的日子已接近尽头，各个机构在敏捷及快速市场投放上绞尽脑汁，而PaaS无疑会加速这个部署过程。它允许特性尽可能 快的发布，同时也能让开发者得到极大的满足。这是个非常好的开始，给予开发者部署集维护自己软件的工具，这将给工作积极性带来很大的提高。同时，越来越多 的开发者甚至不愿意加入没有自动化软件部署系统的公司。更少的领导，更简化的环节，将给你带来无与伦比的效率。

5. 如果使用Oracle或者MySQL，只做基于主键的查询

只有在RAC中存在很少的Artifacts时，Oracle才能在流量高峰时获得最佳性能。尽可能避免使用Referential Integrity、Triggers、Materialized Views、Views、Stored Procedures和其他的Oracle Artifacts。Triggers可以在从数据访问层实现。Stored Procedures可以完全转移到应用层。数据库只用来存储数据，基于字段进行存储而不是主键，使用类似Lucene的索引器做表的索引，使用一个允许 在结果集上做基于其他字段的查询，这将会返回这个记录的主键，而这个主关键字可以进一步被用来拿取记录。<="" p=""></ARTIFACTS时，ORACLE才能在流量高峰时获得最佳性能。尽可能避免使用REFERENTIAL>

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过程是必不可少的，这可以帮助将数据导入分布式缓存，这个过程应该在晚上或者是用户访问量低的时候。