Java岗大厂面试百日冲刺 – 日积月累，每日三题【Day38】—— 实战那些事儿2

大家好，我是陈哈哈，北漂五年。相信大家和我一样，，作为一名资深Java选手，深知面试重要性，接下来我准备用100天时间，基于Java岗面试中的高频面试题，以的形式，带你过一遍热门面试题及恰如其分的解答。

一路走来，随着问题加深，发现不会的也愈来愈多。但底气着实足了不少，相信不少朋友和我一样，日积月累才是最有效的学习方式！想起高三时一个同学的座右铭：共勉（juan）。

言归正传。。

我们是如何发现慢SQL的了慢查询日志和人为发现之外，一般出现慢查询时会有如下三个特征：

• 数据库CPU负载高。一般是查询语句中有，或，导致数据库cpu负载。
• IO过高导致服务器卡住，这个一般，问题出在。
• 查询语句正常，索引正常但是还是慢。如果表面上索引都配置了，但是查询慢，那得看看。

有些SQL虽然出现在慢查询日志中，但未必是其本身的性能问题，可能是因为，等等。

需要分析SQL语句真实的执行计划，而不是看重新执行一遍SQL时，看是不是变快了（查询缓存都不带考虑的。。而是使用工具来逐步调优，了解 MySQL 在执行这条数据时的一些细节，比如等等。基于 Explain 的返回结果我们就可以根据 MySQL 的执行细节进一步优化语法，使索引能被正确使用，实现性能需求。

关于索引的创建及优化原则，美团点评技术团队的几点总结，引用一下：

1. 最左前缀匹配原则，非常重要的原则，mysql会一直向右匹配直到遇到范围查询()就停止匹配，比如a = 1 and b = 2 and c > 3 and d = 4 如果建立(a,b,c,d)顺序的索引，d是用不到索引的，如果的索引则都可以用到，a,b,d的顺序可以任意调整；

2. =和in可以乱序，比如a = 1 and b = 2 and c = 3 建立(a,b,c)索引可以任意顺序，mysql的会帮你优化成索引可以识别的形式，当然，好习惯要靠自己保持；

3. 尽量,区分度的公式是，表示字段不重复的比例，比例越大我们扫描的记录数越少，唯一键的区分度是1，而一些状态、性别字段可能在大数据面前区分度就是0，那可能有人会问，这个比例有什么经验值吗用场景不同，这个值也很难确定，一般需要join的字段我们都要求是0.1以上，即平均1条扫描10条记录；

4. 索引列不能参与计算，保持列“干净”，比如from_unixtime(create_time) = ’2014-05-29’就不能使用到索引，原因很简单，b+树中存的都是数据表中的字段值，但进行检索时，需要把所有元素都应用函数才能比较，显然成本太大。所以语句应该写成create_time = ；

5. 尽量的，不要新建索引。比如表中已经有a的索引，现在要加(a,b)的索引，那么只需要修改原来的索引即可。

当然，我们知道还有、、、等MySQL硬性问题，俗称，那我们就得基于实际情况来进行分库分表、切换检索引擎（如ES、FastDFS）等方式来处理了，术业有专攻，总不能在一棵树上吊死对吧。

目前最常见的负载均衡应用是。根据实现的原理不同，常见的web负载均衡技术包括：、、、以及等等。其中IP负载均衡可以使用硬件设备或软件方式来实现。

对于，我们常用的分布式架构、多节点集群、消息中间件（如Mycat）等来控制集群负载均衡状况，同样是横向扩展，但侧重点在于。因此，实际大多负载均衡的工作还是在Web层。

这种负载均衡方案的有点是比较简单，缺点是浏览器需要两次请求服务器才能完成一次访问，性能较差；同时，重定向服务器本身的处理能力有可能成为瓶颈，整个集群的伸缩性规模有限；使用HTTP返回码302重定向，有可能使搜索引擎判断为SEO作弊，降低搜索排名。因此实践中很少使用这种负载均衡方案来部署。

DNS负责提供，当访问某个站点时，实际上首先需要通过该站点域名的DNS服务器来，在这一过程中，DNS服务器完成了域名到IP地址的，同样，这样映射也可以是一对多的，这时候，DNS服务器便充当了，它就像http重定向转换策略一样，将用户的请求分散到多台服务器上，但是它俩的实现机制完全不同。

相比http重定向，基于DNS的负载均衡完全节省了所谓的主站点，或者说DNS服务器已经充当了主站点的职能。但不同的是，作为调度器，DNS服务器本身的性能几乎不用担心。因为DNS记录可以被用户浏览器或者互联网接入服务商的各级DNS服务器缓存，只有当缓存过期后才会重新向域名的DNS服务器请求解析。也说是DNS不存在http的吞吐率限制，理论上可以无限增加实际服务器的数量。

优势:

1. 可以根据用户IP来进行智能解析。DNS服务器可以在所有可用的A记录中寻找离用记最近的一台服务器。
2. 动态DNS：在每次IP地址变更时，及时更新DNS服务器。当然，因为缓存，一定的延迟不可避免。

不足：

1. 没有用户能直接看到DNS解析到了哪一台实际服务器，对运维人员的调试带来了不便。
2. 策略的局限性。例如你无法将HTTP请求的上下文引入到调度策略中，而在前面介绍的基于HTTP重定向的负载均衡系统中，调度器工作在HTTP层面，它可以充分理解HTTP请求后根据站点的应用逻辑来设计调度策略，比如根据请求不同的URL来进行合理的过滤和转移。

CDN（Content Delivery Network，内容分发网络）。通过发布机制将内容同步到大量的缓存节点，并在DNS服务器上进行扩展，找到里用户最近的缓存节点作为服务提供节点。

因为很难自建大量的缓存节点，所以通常使用CDN运营商的服务。目前国内的服务商很少，而且按流量计费，价格昂贵。

在客户端明确的前提下，大量访问请求（QPS）涌入。我们后台通过Nginx代理了20个服务器，高QPS打进来后先打到Nginx中，通过Nginx的负载均衡来把请求分发给这20台服务器，减轻了单台服务器负担。这种客户端 → Nginx → 服务器 的模式称为反向代理，如下图：

1. 客户端会向一个ip地址发出请求，这个ip地址是一个VIP()，这也是调度器向外公布的一个地址。
2. 请求达到调度器，调度器会根据从中选取一个负载不高的服务器，然后把请求报文的目标地址，也就是。最后，调度器会把其连接保存在一个hash表中，只要这个连接下次再发请求报文过来就会把其分发到上次选定的服务器中。
3. RealServer收到报文之后，会。
4. 调度器收到报文之后，会把源地址和源端口改为虚拟ip和端口，最后再返回给客户端。

• RealServer和调度器必须位于一个ip网络之中。
• 调度器位于RealServer和客户端之间，处理进出的通信。
• RIP通常是内部地址，仅用于集群之间通信。
• RealServer的网关必须指向调度器。
• 支持端口映射，RealServer没必要跟调度器一个端口。

响应报文一般比较大，每一次都需要NAT转换的话，大流量的时候，会导致调度器成为一个瓶颈。

来源：_陈哈哈