加入缓存
热点数据放在缓存里，项目上线前让热点数据在缓存里跑一遍，让数据进到缓存里，避免在大压力上来以后缓存里没有数据，从后台取数据是很可怕的，数据库优化的成本远高于缓存，缓存的部署很简单，加入一定的规则就OK了，接下来看缓存的命中率和使用情况，它要比动数据库来的更直接一些和更便宜，往往要动数据库时是性能优化做不了了，必须要动最底层东西从根本上优化它
负载均衡
---说白了就是通过一定的规则去把压力分摊或分流一下
---负载均衡的规则要以实际系统为准，可能是轮询，可能是按比例分配，也可能是其他
集群
以team为例，集群对于外部来说就是一个整体，他们只知道这个team叫牛逼组，但对于内部来说是由多少个人组成的(多个机器)
好处：
---避免单点故障
---方便管理，可将工作负载转移给集群中的其他服务器
---可扩展
集群测试的关注点：
---数据的一致性(增删改查)
---机器的失效切换与恢复(与负载均衡有关)
分布式：一个业务拆分多个子业务部署在不同的服务器上
集群：同一个业务部署在多个服务器上
可用性测试也是性能测试的一种，负载均衡不是加的机器越多越好
CDN的全称是Content Delivery Network，即内容分发网络，其目的是使用户可就近取得所需内容，解决Internet网络拥挤的状况，提高用户访问网站的响应速度
反向代理：有两方面的作用，一是相当于一层缓存，另一方面是更安全一些
完整的请求流程：
在浏览器输入www.besttest.cn，点击回车，首先走本地缓存，如果本地缓存有直接拿出来，如果本地缓存没有不走缓存，直接往后流转，流转到DNS服务器，DNS服务器对域名进行解析，域名对应IP服务器，域名解析定位到哪台服务器上，在向后流转，流转到应用服务器上，又经过一层缓存，如果缓存里有直接拿出来，往前端返，如果没有继续往后流转，流转到数据库，流转到数据库后进行操作，操作完成之后，把取出来的数据扔到缓存，同时把取出来的数据往前端返，返回到浏览器，浏览器在接到数据后进行前端页面的解析，最终解析出来看到的页面，完成之后并把这次的数据缓存到本地，下次再访问时直接从本地取
响应时间的计算：
在整个过程中要经过网络，到Web服务器，到中间件，到线程，通过线程传到应用程序，进行逻辑处理或运算操作，再把请求传到线程，线程池在接受到这个请求之后往后端进行传，进行JDBC操作，这时候通过网络传到数据库，数据库接收到请求进行dml操作，通过网络传到应用服务器，服务器通过中间件，线程在拿到这个请求后进行处理，在应用程序这进行计算或逻辑处理，计算完了通过中间件线程池把这个请求拿到，通过网络返回到客户端，这是整个响应时间的计算
数据库读操作的流程：
select 查询过程，是一个读的过程，首先查询语句发送到sql这，sql进行接收，第一步看其是否命中querycache，如果命中数据结果集直接返回，不进行其他操作，如果没有命中querycache，会进行语法分析，语义解析，看sql写的对不对，看select是不是写的不对，判断有没有执行权限等等，把这些数据完成之后生成sql的执行计划，在拿到这个执行计划之后再去数据库进行查询，查询时看sql的数据是否在内存里面，内存没有的话去磁盘里拿，这个过程涉及到内存和querycache，这就是要进行sql优化的原因，所有sql优化的原因都要从querycache里进行，其实就是从sql的执行过程来分析为什么进行优化
第一步：内存
为什么说数据库的一切问题在IO呢，如果内存无限大，可以把所有数据全都加载在内存里，叫热数据，这样查询不需要进行磁盘交互，查询速度就会快很多，设置数据库会设置多大内存，内存设置越大会往内存放的热数据会越多，那么和磁盘交互的时间和次数会越少，这就是内存的重要性
第二步：querycache
查询时会进行语法分析，语义解析，这些步骤是需要耗时的，如果执行计划在querycache里面，直接拿到，直接去查找数据就完了，尽可能的命中数据库的缓存，就是这个原因，没索引加索引，什么样的语句走索引
数据库写操作的流程：
写操作其实不是写到内存、写到磁盘就结束了，是写到缓存区里就结束了，对于sql来说写到缓存区里就返回了，剩下的写从缓存区同步到内存，从内存同步到磁盘里面，后面还有这么多过程，对应用程序或sql语句来说就不计算了，它觉得就已经返回了，其实后面还有两句，从缓存区到内存，从内存到磁盘，最终数据要写到磁盘里，这两步没计算