对应对高并发的一些思考

版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA 版权协议,转载请附上原文出处链接和本声明。
本文链接:https://blog.csdn.net/HEL_WOR/article/details/51246655

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

转载请注明: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数据库 数据量太大引起的性能问题
水平拆分主要是解决表的压力,垂直拆分只要是解决库的压力。
当拆分库后数据量依旧太大,则可以将之前一段时间的历史数据搬移到其他库,在查询历史数据的时候再进行二次查询。

展开阅读全文

没有更多推荐了,返回首页