对应对高并发的一些思考

这个话题很大，以我目前的经验写得可能比较呛，会持续更新，如果您有好的提议，意见，场景，请留言告知，先谢过。

转载请注明：http://blog.csdn.net/HEL_WOR/article/details/51246655

请求量的增加，导致服务器CPU消耗上升，直至满负荷运转，当请求量继续上升，如果不提升硬件性能，结果就是请求被处理的速度跟不上请求到达的速度，CPU过热，用户发出的请求丢失。

接下来便是增加服务器，让相同的服务同时配置在两台服务器上，分担用户访问的压力，但这同时存在的两台服务器，对于正在到来的这个请求，它该怎么选，选哪台服务器，如果这个请求的响应被返回到了客户端，下次同一用户的后续操作到来，其请求又该分配给哪台服务器，为了保证前后两次操作的服务连贯，这两次请求是不是该分配到同一服务器上？

对到达请求的分配，由负载均衡完成，客户端发出请求的目的地址是服务器地址，但在DNS解析后这个地址变成了负载均衡的地址，即这个请求最终会先到达负载均衡上，根据具体的负载均衡策略，这个请求会按策略发被送至其后的服务器上，但如果客户端发出请求的目的地址是服务地址额IP形式呢？这样就不需要经过DNS进行域名解析而直接到达服务器，那么就不会经过负载均衡，就这个问题我问了下我们老大，他的答复是即使是以IP地址发出请求，后端还是可以通过策略做负载。

负载均衡可用软件完成也可由硬件完成，硬件一劳永逸，但贵，软件便宜，但需要时时调整维护，基本的负载均衡方式，有重定向，4层负载，7层负载。
对于一个请求具体应该怎么分，由负载均衡策略决定。
而这两台服务器，即我们平时描述的集群，虽然服务器数量很小。

对于类似图片这样的大文件，现在通常通过CDN服务器保存。
js，css等文件，可以同一放在资源服务器上。
对于一次页面点击，请求参数被发往服务器，在处理之后被返回客户端，其主要携带处理信息，再响应完成之后，去资源服务器上获取资源文件，再到就近的CDN服务器上获取图片信息，这样可以降低后端服务器的压力以及响应时间。

有时为了提升用户的体验，构造的请求会被放入消息队列中，而前端页面直接打印成功信息，类似于京东上下单成功，携程订票成功后，直接返回成功页面，其实订单正在被处理，这是异步的方式，消息队列中消息会由线程池循环处理，对于线程池的线程数，应该是可变的，即监视队列中的等待项，可以动态的增加或者降低线程数。消息队列也可是，放在服务器端监听消息的到来，缓存到来的消息，并等待处理。消息队列的存在和负载均衡并不对立。

使用内存数据库缓存数据提高处理速度，降低数据库访问量，那么如何保证内存的命中率，如何解决热点key问题。对于基础数据且不常变动的数据，放入内存数据库，设定较长的更新间隔时间，对于常变动的数据，记录访问次数，将最常用数据保存到内存数据库，频繁变动的数据，那么在设置值时优先更新到内存数据库，再同步到数据库中，对内存数据库中数据打上访问次数，定期扫描，对于访问次数太低的数据remove掉，对于访问次数高的数据将其提升，每次去数据库中获取的数据，根据局部性原理，需将其保存到内存数据库。

对于最后的数据库操作，除了使用explain检查sql语句的性能，添加索引加快查询速度外，接下来最常使用的就是分库分表，对应我们常说的垂直拆分和水平拆分。
数据库的压力会来自于数据量，访问量。
当一个库体积过大，会造成查询，新增，删除等等操作耗时增加。这有一个例子：关于SQL数据库 数据量太大引起的性能问题。
水平拆分主要是解决表的压力，垂直拆分只要是解决库的压力。
当拆分库后数据量依旧太大，则可以将之前一段时间的历史数据搬移到其他库，在查询历史数据的时候再进行二次查询。