定位和解决线上接口性能优化或者数据库性能优化的思路是什么？
有没有遇到过一些线上性能问题？
如何定位这些问题？
解决优化性能的思路是什么？最终采用了什么方案？优化后的效果如何？请结合案例说一说。
【特别说明】此问题属于「Boss 有请·电商专场」，提问者正在招聘高薪岗位，如果你使用真实身份发布回答，BOSS 将可直接查看你的在线简历，并选择是否与你主动开聊。
回答·16
最热
最新
- 1、首先，最直接的就是优化查询语句，比如减少查询次数，在关键字段建立合适的索引，利用慢查询日志和 explain 有目的的优化查询语句等方法。 2、根据实情需要，对低变动高查询的数据进行缓存，降低数据库压力。 3、如果遇到高并发的场景，利用负载均衡分担单服务器的请求压力，有时可能还需要设计选择热点缓存的机制，甚至是限流熔断有时候也是很必要的。不过如果没有相关的场景需求，也不建议设计如此复杂的架构，否则可能得不偿失。 4、从数据架构上看性能优化，可以从分表分库上入手，对数据进行纵横切分，使其单表规模或者单条数据规模降低，达到降低查写成本的目的，提高数据库表的性能。不过对于线上数据迁移需要谨慎规划。有些关键业务接口不能停服迁移的，就需要利用中间库表，进行平滑迁移。
- 很遗憾没有具体电商项目经验。不过也回答一下。 线上接口性能排查，首先线上项目会开启 spring actuactor 这样的性能监控，zipkin 全链路服务调用追踪，可以快速发现接口调用的时间慢在哪里。是自身服务问题自身解决，非自身服务问题协调服务接口人，排查问题。 针对线上自身接口性能问题，是否是并发太多处理不过来，可以采用增加服务器数量，是否可以针对于是否可以进行常用缓存思考，是否程序自身问题，还可以在优化的空间。是否是网络问题网络延迟(多机房部署)。针对于下游处理能力薄弱或者调用链路很深，是否能够使用消息队列方式处理。 针对于数据库慢的，可以分析查询的 sql 执行计划包括子查询，大小表，不正确语句引起 sql 失效，字段索引，数据库存储选型(一般不会选错)，是否可以针对数据库做读写分离，分库分表。
- 一，线上接口问题，针对微服务架构调用复杂的情况，首先考虑从使用调用链跟踪，如 zipkin，查看每一条路线的耗时情况，甚至包括此时 CPU 性能，然后再针对性能差的服务接口进行分析；针对不是微服务而只是单实例或者简单服务调用并且接口性能不好的情况，首先压力测试掌握基本性能情况，其次从代码层面着手，看看是不是代码问题，比如查询 SQL 过慢，返回超时，或者限流不合理等情况，最后再检查硬件或者网络问题！ 二，针对数据库性能优化问题，从设计上来说，设计表之前考虑好引擎，数据量，字段格式，索引等；从 SQL 层面要利用好索引覆盖，尽量不回表，优化好 SQL（如先 explain 分析下计划）；从架构上来说，采用高可用的架构，如 MySQL 扩展的 MHA 架构；从读写上来说，做好读写代理，从而实现良好的读写分离；从业务代码层面来说，不要造成大量缓存失效，从而直接查询 DB；从大数据量来说，通常千万级别，做好分表分库！我实际工作最常遇到两种情况，第一，表索引设计不合理，等到数据量到千万级再考虑重新建索引，导致锁表，这种情况不能直接线上重建索引，简单的做法应该凌晨做好数据迁移再重建，第二代码事务中，有较长查询时间的 SQL，也就是长事务，尽可能避免！否则很大可能因为事务未提交导致锁表！
- 1. 首先要识别出是问题范围，明确是整个服务慢还是个别接口响应慢。 2. 如果是整体响应慢，需要观察内存、cpu、线程数、连接数等相关指标。如果是内存不足，可以需要观察是否有内存泄漏等问题。如果连接数较大，且是对外提供 http 接口的服务，高并发场景下可以适当调小主机 tcp time wait 参数，加快连接回收 3. 如果是单个接口响应慢，可以使用类似 zabbix 等链路监控工具识别出哪个环节响应慢。之后同过走读代码识别可能出现问题的环节，如外部接口调用，数据库操作等 4. 数据库层面响应慢需要识别出慢查询 sql，检查索引是否有效、缓存命中率等方面问题。数据量较大时可以通过热点数据与静态数据分离、表拆分、分库分表、读写分离等方式进行优化。 如上是个人理解。
- 性能问题大多数是由于 io 瓶颈，用 skw 或者 arthas 定位，数据库慢用 redis 优化,redis 慢用内存优化。链路慢，能异步的都异步处理
- 1、首先，最直接的就是优化查询语句，比如减少查询次数，在关键字段建立合适的索引，利用慢查询日志和 explain 有目的的优化查询语句等方法。 2、根据实情需要，对低变动高查询的数据进行缓存，降低数据库压力。 3、如果遇到高并发的场景，利用负载均衡分担单服务器的请求压力，有时可能还需要设计选择热点缓存的机制，甚至是限流熔断有时候也是很必要的。不过如果没有相关的场景需求，也不建议设计如此复杂的架构，否则可能得不偿失。 4、从数据架构上看性能优化，可以从分表分库上入手，对数据进行纵横切分，使其单表规模或者单条数据规模降低，达到降低查写成本的目的，提高数据库表的性能。不过对于线上数据迁移需要谨慎规划。有些关键业务接口不能停服迁移的，就需要利用中间库表，进行平滑迁移。
- 性能一般是指程序的吞吐量，它被 io，cpu，内存影响。如果性能不高，要么代码没写好，要么确实机器配置不够高 定位问题原始点就是从下游到上游依次查看日志排查，应用日志，gc 日志，系统日志。 优化思路，对于代码问题就修复 bug，资源不够就加资源（负载均衡，集群），查询多就加缓存，写频繁就加缓冲，处理不过来就熔断。对于一些耗性能的设计能少用就少用，针对业务特性对架构做针对性设计
- 定位主要在于你有什么工具，最常见的就是链路追踪，监控 metric，日志。如果你的链路关键的点都打了的话，其实可以根据 span 定位到某个点就比较容易了。如果你不知道具体是哪个接口性能慢，这个时候可以透过 metric 来找出影响性能的接口再配合链路来追踪问题。如果没有这些工具，那么就自己看日志分析吧，找出异常日志，再结合实际情况做出分析。另外注意观察系统硬件资源消耗，如果 cpu 利用率好，可以在线上采样，抓个 cpu 火焰图，看看消耗最好的点在哪里，如果不允许的话，可以做个基准测试找出消耗点，针对性的优化。如果内存消耗太高，可以 dump 一份下来分析一下内存占用。另外还可以通过观察 gc 日志来判定 jvm 参数设置是否合理，是否需要调整等等。 针对 sql 的话，我的分析也是借助工具，如果系统本身有数据库监控的话，找出耗时太多，或者高频率 sql，针对读多写少的情况可以适当使用缓存，读写分离等。针对耗时多的语句，可以开启执行计划，观察 sql 消耗，找出消耗点，针对性优化。很多数据库自身带有监控，可以开启相应的监控来抓取一定的样本，统计分析。找出问题点，关键还是两个高频率，长耗时。 至于解决问题，那就是具体问题具体方案，一般问题定位到了，解决问题的方案基本就有了，具体问题，针对性方案，没有包治百病。
- 系统的优化还是需要 1.对大的软件路径和可能的方案有基本的预判，离开粗的预判一头扎进细节是把几小时的任务量变成几个月的常见陷阱，而平时看大系统一边看一边记笔记是培养粗查问题的基础。 2.精确的监控和测量，知道每个监控变量在哪个大的系统 components 的背景下，代表了什么，测量节点的代价是什么。 3.到具体的问题，就是从粗到细把软件路径排一遍，对于偶然出现的问题，在了解具体策略的同时，有时候光靠陷入细节的追踪难以奏效，还是需要一点想象力的，可能不加班，去公园走走，打打游戏，会出来好的思路。
- 我通常，会用热备，或者负载均衡方法，加上 AOP 切片，快速定位异常点。设备超时，或者方法超时拥塞比较容易找到问题所在。大量请求，被负载去了其他服务器就说明了问题细节。 线上优化，一般代码没什么大问题，就是动态扩容。大量静态资源分区域进 CDN。路由。 如果碰到语言瓶颈的问题，例如 java 虚拟机本身内存的问题，那必须要换 C++，根据请求特征主动控制内存，跟实例化的吞吐。 还有就是大范围分布式的同步缓存。 现在会逐渐，把业务前移，android ios，实际运算能力已经非常强，存储，网速也可以。一般会把前端设备作为内容驻点，例如抖音那样，构建个小型的 bit 协议。 用户请求资源，优先地理位置范围内的广播询问。 总结一下，用类似负载均衡的机制找到异常点；静态资源类请求，就 CDN 或者前移。如果是业务请求类，就是动态扩容或者更换下技术语言。
相似问题
推荐关注
正在加载中...