本篇文章主要介绍了"应用服务器性能优化总结"，主要涉及到性能优化,服务器方面的内容，对于软件工程感兴趣的同学可以参考一下：
别人推荐看的《大型网站技术架构》买回来有一年多了，一直没看，看着落满灰尘的书，真的是于心不忍。趁着这个周末没事，赶快来研究一下，顺便做个笔记。应用服务器就是处理...
分布式缓存指缓存部署在多个服务器组成的集群中，以集群方式提供缓存服务，其架构方式有两种，一种是以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内核数
