一、分布式缓存
在整个网站应用中，缓存几乎无处不在，既存在于浏览器也存在于应用服务器和数据库服务器；既可以对数据缓存，也可以对文件缓存，还可以对页面片段缓存。合理使用缓存，对网站性能优化意义重大。
网站性能优化第一定律：优先考虑使用缓存。
1、缓存的基本原理
缓存是指将数据存储在相对较高访问速度的存储介质中。
（1）访问速度快，减少数据访问时间；
（2）如果缓存的数据进过计算处理得到的，那么被缓存的数据无需重复计算即可直接使用，因此缓存还起到减少计算时间的作用。
缓存的本质是一个内存Hash表，以一对Key、Value的形式存储在内存Hash表中，读写时间复杂度为O(1)。
缓存主要用来存放那些读写比很高、很少变化的数据，如商品的类目信息，热门词的搜索列表信息，热门商品信息等。应用程序读取数据时，先到缓存中读取，如果读取不到或数据已失效，再访问数据库，并将数据写入缓存。
网站数据访问通常遵循二八定律，即80%的访问落在20%的数据上，因此利用Hash表和内存的高速访问特性，将这20%的数据缓存起来，可很好地改善系统性能，提高数据存取速度，降低存储访问压力。
2、合理使用缓存
不合理使用缓存非但不能提高系统的性能，还会成为系统的累赘，甚至风险。
频繁修改的数据
如果缓存中保存的是频繁修改的数据，就会出现数据写入缓存后，应用还来不及读取缓存，数据就已经失效，徒增系统负担。一般来说，数据的读写比在2：1（写入一次缓存，在数据更新前至少读取两次）以上，缓存才有意义。
没有热点的访问
如果应用系统访问数据没有热点，不遵循二八定律，那么缓存就没有意义。
数据不一致与脏读
一般会对缓存的数据设置失效时间，一旦超过失效时间，就要从数据库中重新加载。因此要容忍一定时间的数据不一致，如卖家已经编辑了商品属性，但是需要过一段时间才能被买家看到。还有一种策略是数据更新立即更新缓存，不过这也会带来更多系统开销和事务一致性问题。
缓存可用性
缓存会承担大部分数据库访问压力，数据库已经习惯了有缓存的日子，所以当缓存服务崩溃时，数据库会因为完全不能承受如此大压力而宕机，导致网站不可用。这种情况被称作缓存雪崩，发生这种故障，甚至不能简单地重启缓存服务器和数据库服务器来恢复。
实践中，有的网站通过缓存热备份等手段提高缓存可用性：当某台缓存服务器宕机时，将缓存访问切换到热备服务器上。但这种设计有违缓存的初衷，缓存根本就不应该当做一个可靠的数据源来使用。
通过分布式缓存服务器集群，将缓存数据分布到集群多台服务器上可在一定程度上改善缓存的可用性。当一台缓存服务器宕机时，只有部分缓存数据丢失，重新从数据库加载这部分数据不会产生很大的影响。
缓存预热（warm up）
缓存中存放的是热点数据，热点数据又是缓存系统利用LRU（最近最久未用算法）对不断访问的数据筛选淘汰出来，这个过程需要花费较长的时间。新系统的缓存系统如果没有任何数据，在重建缓存数据的过程中，系统的性能和数据库负载都不太好，那么最好在缓存系统启动时就把热点数据加载好，这个缓存预加载手段叫缓存预热。对于一些元数据如城市地名列表、类目信息，可以在启动时加载数据库中全部数据到缓存进行预热。
缓存穿透
如果因为不恰当的业务、或者恶意攻击持续高并发地请求某个不存在的数据，由于缓存没有保存该数据，所有的请求都会落到数据库上，会对数据库造成压力，甚至崩溃。一个简单的对策是将不存在的数据也缓存起来(其value为null)。
3、分布式缓存架构
分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其架构方式有两种，一种是以JBoss Cache为代表的需要更新同步的分布式缓存，一种是以Memcached为代表的不互相通信的分布式缓存。
JBoss Cache在集群中所有服务器中保存相同的缓存数据，当某台服务器有缓存数据更新，就会通知其他机器更新或清除缓存数据。 它通常将应用程序和缓存部署在同一台服务器上，但受限于单一服务器的内存空间；当集群规模较大的时候，缓存更新需要同步到所有机器，代价惊人。因此这种方案多见于企业应用系统中。
Memcached采用一种集中式的缓存集群管理（互不通信的分布式架构方式）。缓存与应用分离部署，缓存系统部署在一组专门的服务器上，应用程序通过一致性Hash等路由算法选择缓存服务器远程访问数据，缓存服务器之间不通信，集群规模可以很容易地实现扩容，具有良好的伸缩性。详细请看LZ其他文章。
Memcached有以下几个特性：
（1）简单的通信协议。Memcached使用TCP协议(UDP也支持)通信；
（2）丰富的客户端程序。
（3）高性能的网络通信。Memcached服务端通信模块基于Libevent，一个支持事件触发的网络通信程序库，具有稳定的长连接。
（4）高效的内存管理。
（5）互不通信的服务器集群架构。
二、异步操作
使用消息队列将调用异步化（生产者–消费者模式），可改善网站的扩展性，还可以改善系统的性能。
在不使用消息队列的情况下，用户的请求数据直接写入数据库，在高并发的情况下，会对数据库造成巨大压力，使得响应延迟加剧。在使用消息队列后，用户请求的数据发送给消息队列后立即返回，再由消息队列的消费者进程（通常情况下，该进程独立部署在专门的服务器集群上）从消息队列中获取数据，异步写入数据库。由于消息队列服务器处理速度远快于服务器（消息队列服务器也比数据库具有更好的伸缩性）。
消息队列具有很好的削峰作用–通过异步处理，将短时间高并发产生的事务消息存储在消息队列中，从而削平高峰期的并发事务。
需要注意的是，由于数据写入消息队列后立即返回给用户，数据在后续的业务校验、写数据库等操作可能失败，因此在使用消息队列进行业务异步处理后，需要适当修改业务流程进行配合，如订单提交后，订单数据写入消息队列，不能立即返回用户订单提交成功，需要在消息队列的订单消费者进程真正处理完后，甚至商品出库后，再通过电子邮件或SMS消息通知用户订单成功，以免交易纠纷。有关消息队列的详细信息请参看LZ的其他博客。
任何可以晚点做的事情都应该晚点再做。
三、使用集群
在网站高并发访问的场景下，使用负载均衡技术为一个应用构建一个由多台服务器组成的服务器集群，将并发访问请求分发到多台服务器上处理，避免单一服务器因负载压力过大而响应缓慢，使用户请求具有更好的响应延迟特性。
四、代码优化
多线程
从资源利用的角度看，使用多线程的原因主要有两个：IO阻塞与多CPU。当前线程进行IO处理的时候，会被阻塞释放CPU以等待IO操作完成，由于IO操作（不管是磁盘IO还是网络IO）通常都需要较长的时间，这时CPU可以调度其他的线程进行处理。 理想的系统Load是既没有进程（线程）等待也没有CPU空闲，利用多线程IO阻塞与执行交替进行，可最大限度利用CPU资源。 使用多线程的另一个原因是服务器有多个CPU。
简化启动线程估算公式：
启动线程数 = [任务执行时间 / (任务执行时间 - IO等待时间)]*CPU内核数
多线程编程一个需要注意的问题是线程安全问题，即多线程并发对某个资源进行修改，导致数据混乱。所有的资源—对象、内存、文件、数据库，乃至另一个线程都可能被多线程并发访问。
编程上，解决线程安全的主要手段有：
（1）将对象设计为无状态对象。所谓无状态对象是指对象本身不存储状态信息（对象无成员变量，或者成员变量也是无状态对象），不过从面向对象设计的角度看，无状态对象是一种不良设计。
（2）使用局部对象。即在方法内部创建对象，这些对象会被每个进入该方法的线程创建，除非程序有意识地将这些对象传递给其他线程，否则不会出现对象被多线程并发访问的情形。
（3）并发访问资源时使用锁。即多线程访问资源的时候，通过锁的方式使多线程并发操作转化为顺序操作，从而避免资源被并发修改。
资源复用
系统运行时，要尽量减少那些开销很大的系统资源的创建和销毁，比如数据库连接、网络通信连接、线程、复杂对象等。从编程角度，资源复用主要有两种模式：单例(Singleton)和对象池(Object Pool)。
单例虽然是GoF经典设计模式中较多被诟病的一个模式，但由于目前Web开发中主要使用贫血模式，从Service到Dao都是些无状态对象，无需重复创建，使用单例模式也就自然而然了。
对象池模式通过复用对象实例，减少对象创建和资源消耗。对于数据库连接对象，每次创建连接，数据库服务端都需要创建专门的资源以应对，因此频繁创建关闭数据库连接，对数据库服务器是灾难性的，同时频繁创建关闭连接也需要花费较长的时间。因此实践中，应用程序的数据库连接基本都使用连接池（Connection Pool）的方式，数据库连接对象创建好以后，将连接对象放入对象池容器中，应用程序要连接的时候，就从对象池中获取一个空闲的连接使用，使用完毕再将该对象归还到对象池中即可，不需要创建新的连接。
数据结构
早期关于程序的一个定义是，程序就是数据结构+算法，数据结构对于编程的重要性不言而喻。在不同场景中合理使用数据结构，灵活组合各种数据结构改善数据读写和计算特性可极大优化程序的性能。
垃圾回收
理解垃圾回收机制有助于程序优化和参数调优，以及编写内存安全的代码。