缓存

缓存是提升应用系统能力的一大利器，可以说当察觉应用变慢的时候，优先考虑增加缓存。选用缓存虽然可以提升应用性能，但也有“一指标三场景“需要留意。一指标是缓存命中率，该值越大越好，说明缓存起作用了；三场景指的是缓存穿透、缓存击穿、缓存雪崩。

异步与消息队列

异步与消息队列的也是提升应用性能的手段之一，与缓存降低读的请求时间从而提升性能的思路不同的是，它通过异步处理的方式来降低单位方法的处理时间从而提升性能。但是殊途同归，不管是异步处理还是增加缓存，都是通过降低单位方法的响应时间来提升网站的整体处理能力。

负载均衡

通过降低单位方法的响应时间对于提升性能总是有限的，这时就可以通过增加更多的进程来并行处理，就是我们常说的集群，或者叫服务水平扩展。这种手段只要资源足够，几乎可以做到凡有性能压力就可以使用。当我们采用此种方式来应对性能压力时，一个迫在眉睫的问题就出现了——客户端要如何选择访问的服务呢？负载均衡算法就是用来解决这个问题的，而实现这个算法的组件，就是我们常说的负载均衡器。

常用的负载均衡算法

• 随机：可以通过生成一定范围的随机数来选用不同的节点

• 轮询：依次选用服务节点

• 加权轮询：根据权重依次选用节点，适用于节点新能比较一致的场景

• hash：通过HASH选用节点，请求会绑定到一个节点上

常见的负载均衡手段

• HTTP重定向负载均衡

• DNS负载均衡

• 反向代理负载均衡

• IP负载均衡

• 数据链路层负载均衡

• F5负载均衡

session同步

服务集群化+负载均衡化之后，就会出现session难以同步的问题，导致的结果就是，用户一会需要登陆，一会不需要登陆。处理这个问题的手段有四种：一种是session复制，tomcat就提供这样的能力，这样方式简单有效单，但只在集群数量小于5台以下，应用访问压力没有的情况下可靠，也就是说这种方案可扩展性不好，足以淘汰了；第二种是cookie记录的方式，这种方式安全性不好，对于禁用cookie和移动应用的场景基本已无用武之地，可以淘汰；第三种是session绑定，对于一类IP，绑定访问一台服务器，可靠性不好，绑定的服务器宕机后，session就失效了，基本不能用；最后一种，session服务器，生产中基本使用redis来做session服务，把session集中存储，服务去状态化，可以无脑水平扩展。

mySql复制

mysql的复制分主从复制、主主复制服务。

主从复制

主要是通过主库将更新日志写入到的binglog，从库的读取主库的binlong日志，写入到自己的relay log日志中，随后写入到从库中。这种模式有两种阶段，第一种阶段只做高可用，即读写都从主库走，从库只做冷备，故障恢复用；第二阶段可做读写分离，即主库只负责写操作，多个从库之间并行处理读操作。

主主复制

相较于主从，主主模式的区别在于会监听对方的binlog，将数据同步给自己。