架构师必知的11种API性能优化方法

最新推荐文章于 2024-06-26 11:06:19 发布
最新推荐文章于 2024-06-26 11:06:19 发布
阅读量981 收藏 24
点赞数 25
文章标签： 性能优化 adb android
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/2401_82584055/article/details/139933595
版权

一、索引优化

接口性能优化时，大家第一个想到的通常是：优化索引。

确实，优化索引的成本是最小的。

你可以通过查看线上日志或监控报告，发现某个接口使用的某条SQL语句耗时较长。

此时，你可能会有以下疑问：

这条SQL语句是否已经加了索引？
加的索引是否生效了？
MySQL是否选择了错误的索引？

1.1 没加索引

在SQL语句中，忘记为WHERE条件的关键字段或ORDER BY后的排序字段加索引是项目中常见的问题。

在项目初期，由于表中的数据量较小，加不加索引对SQL查询性能影响不大。

然而，随着业务的发展，表中的数据量不断增加，这时就必须加索引了。

可以通过以下命令查看/添加索引：

show index from `table_name`
CREATE INDEX index_name ON table_name (column_name);

这种方式能够显著提高查询性能，尤其是在数据量庞大的情况下。

1.2 索引没生效

通过上述命令我们已经确认索引是存在的，但它是否生效呢？

此时，你可能会有这样的疑问。

那么，如何查看索引是否生效呢？

答案是：可以使用 EXPLAIN 命令，查看 MySQL 的执行计划，它会显示索引的使用情况。

例如：

EXPLAIN SELECT * FROM `order` WHERE code='002';

结果：

图片

这个命令将显示查询的执行计划，包括使用了哪些索引。

如果索引生效，你会在输出结果中看到相关的信息。

通过这几列可以判断索引使用情况，执行计划包含列的含义如下图所示：

说实话，SQL语句没有使用索引，除去没有建索引的情况外，最大的可能性是索引失效了。

以下是索引失效的常见原因：

图片

了解这些原因，可以帮助你在查询优化时避免索引失效的问题，确保数据库查询性能保持最佳。

1.3 选错索引

此外，你是否遇到过这样一种情况：明明是同一条SQL语句，只是入参不同。

有时候使用的是索引A，有时候却使用索引B？

没错，有时候MySQL会选错索引。

必要时可以使用 FORCE INDEX 来强制查询SQL使用某个索引。

例如：

SELECT * FROM `order` FORCE INDEX (index_name) WHERE code='002';

至于为什么MySQL会选错索引，原因可能有以下几点：

图片

了解这些原因，可以帮助你更好地理解和控制MySQL的索引选择行为，确保查询性能的稳定性。

插播一条：如果你近期准备面试跳槽，建议在cxykk.com在线刷题，涵盖 1万+ 道 Java 面试题，几乎覆盖了所有主流技术面试题、简历模板、算法刷题。

二、SQL优化

如果优化了索引之后效果不明显，接下来可以尝试优化一下SQL语句，因为相对于修改Java代码来说，改造SQL语句的成本要小得多。

以下是SQL优化的15个小技巧：

三、远程调用

多时候，我们需要在一个接口中调用其他服务的接口。

例如，有这样的业务场景：

在用户信息查询接口中需要返回以下信息：用户名称、性别、等级、头像、积分和成长值。

其中，用户名称、性别、等级和头像存储在用户服务中，积分存储在积分服务中，成长值存储在成长值服务中。为了将这些数据统一返回，我们需要提供一个额外的对外接口服务。

因此，用户信息查询接口需要调用用户查询接口、积分查询接口和成长值查询接口，然后将数据汇总并统一返回。

调用过程如下图所示：

图片

调用远程接口总耗时 530ms = 200ms + 150ms + 180ms

显然这种串行调用远程接口性能是非常不好的，调用远程接口总的耗时为所有的远程接口耗时之和。

那么如何优化远程接口性能呢？

3.1 串行改并行

上面说到，既然串行调用多个远程接口性能很差，为什么不改成并行呢？

如下图所示：

图片

调用远程接口的总耗时为200ms，这等于耗时最长的那次远程接口调用时间。

在Java 8之前，可以通过实现Callable接口来获取线程的返回结果。

在Java 8之后，可以通过CompletableFuture类来实现这一功能。

以下是一个使用CompletableFuture的示例：

public class RemoteServiceExample {
    public static void main(String[] args) throws ExecutionException, InterruptedException {
        // 调用用户服务接口
        CompletableFuture<String> userFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟远程调用
            simulateDelay(200);
            return "User Info";
        });
        // 调用积分服务接口
        CompletableFuture<String> pointsFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟远程调用
            simulateDelay(150);
            return "Points Info";
        });
        // 调用成长值服务接口
        CompletableFuture<String> growthFuture = CompletableFuture.supplyAsync(() -> {
            // 模拟远程调用
            simulateDelay(100);
            return "Growth Info";
        });
        // 汇总结果
        CompletableFuture<Void> allOf = CompletableFuture.allOf(userFuture, pointsFuture, growthFuture);
        // 等待所有异步操作完成
        allOf.join();
        // 获取结果
        String userInfo = userFuture.get();
        String pointsInfo = pointsFuture.get();
        String growthInfo = growthFuture.get();
    }
}

3.2 数据异构

为了提升接口性能，尤其在高并发场景下，可以考虑数据冗余，将用户信息、积分和成长值的数据统一存储在一个地方，比如Redis。

这样，通过用户ID可以直接从Redis中查询所需的数据，从而避免远程接口调用

图片

但需要注意的是，如果使用了数据异构方案，就可能会出现数据一致性问题。

用户信息、积分和成长值有更新的话，大部分情况下，会先更新到数据库，然后同步到redis。

但这种跨库的操作，可能会导致两边数据不一致的情况产生。

那如何解决数据一致性问题呢？

由于篇幅有限，本文就不展开详细说这块了。

四、重复调用

在我们的日常工作代码中，重复调用非常常见，但如果没有控制好，会严重影响接口的性能。

让我们一起来看看这个问题。

4.1 循环查数据库 有时候，我们需要从指定的用户集合中查询出哪些用户已经存在于数据库中。

一种实现方式如下：

public List<User> findExistingUsers(List<String> userIds) {
    List<User> existingUsers = new ArrayList<>();
    for (String userId : userIds) {
        User user = userRepository.findById(userId);
        if (user != null) {
            existingUsers.add(user);
        }
    }
    return existingUsers;
}

上述代码会对每个用户ID执行一次数据库查询，这在用户集合较大时会导致性能问题。

那么，我们如何优化呢？

我们可以通过批量查询来优化性能，减少数据库的查询次数。

public List<User> findExistingUsers(List<String> userIds) {
    // 批量查询数据库
    List<User> users = userRepository.findByIds(userIds);
    return users;
}

这里有个需要注意的地方是：id集合的大小要做限制，最好一次不要请求太多的数据。要根据实际情况而定，建议控制每次请求的记录条数在500以内。

五、异步处理

在进行接口性能优化时，有时候需要重新梳理业务逻辑，检查是否存在设计不合理的地方。

假设有一个用户请求接口，需要执行以下操作：

  1. 业务操作

  2. 发送站内通知

  3. 记录操作日志 为了实现方便，通常会将这些逻辑放在接口中同步执行，但这会对接口性能造成一定影响。

图片

这个接口表面上看起来没有问题，但如果你仔细梳理一下业务逻辑，会发现只有业务操作才是核心逻辑，其他的功能都是非核心逻辑。

在这里有个原则就是：

核心逻辑可以同步执行，同步写库。非核心逻辑，可以异步执行，异步写库。

上面这个例子中，发站内通知和用户操作日志功能，对实时性要求不高，即使晚点写库，用户无非是晚点收到站内通知，或者运营晚点看到用户操作日志，对业务影响不大，所以完全可以异步处理。

异步处理方案

异步处理通常有两种主要方式：多线程和消息队列（MQ）

5.1 线程池异步优化

使用线程池改造之后，接口逻辑如下

5.2 MQ异步

使用线程池有个小问题就是：如果服务器重启了，或者是需要被执行的功能出现异常了，无法重试，会丢数据。

为了避免使用线程池处理异步任务时出现数据丢失的问题，可以考虑使用更加健壮和可靠的异步处理方案，如消息队列（MQ）。消息队列不仅可以异步处理任务，还能够保证消息的持久化和可靠性，支持重试机制。

使用mq改造之后，接口逻辑如下：

插播一条：如果你近期准备面试跳槽，建议在cxykk.com在线刷题，涵盖 1万+ 道 Java 面试题，几乎覆盖了所有主流技术面试题、简历模板、算法刷题。

六、避免大事务

很多小伙伴在使用Spring框架开发项目时，为了方便，喜欢使用@Transactional注解提供事务功能。

没错，使用@Transactional注解这种声明式事务的方式提供事务功能，确实能少写很多代码，提升开发效率。

但也容易造成大事务，引发性能的问题。

图片

那么我们该如何优化大事务呢？

为了避免大事务引发的问题，可以考虑以下优化建议：

  1. 少用@Transactional注解

  2. 将查询(select)方法放到事务外

  3. 事务中避免远程调用

  4. 事务中避免一次性处理太多数据

  5. 有些功能可以非事务执行

  6. 有些功能可以异步处理

七、锁粒度

在一些业务场景中，为了避免多个线程并发修改同一共享数据而引发数据异常，通常我们会使用加锁的方式来解决这个问题。

然而，如果锁的设计不当，导致锁的粒度过粗，也会对接口性能产生显著的负面影响。

7.1 synchronized

在Java中，我们可以使用synchronized关键字来为代码加锁。

通常有两种写法：在方法上加锁和在代码块上加锁。

1. 方法上加锁

public synchronized void doSave(String fileUrl) {
    mkdir();
    uploadFile(fileUrl);
    sendMessage(fileUrl);
}

在方法上加锁的目的是为了防止并发情况下创建相同的目录，避免第二次创建失败而影响业务功能。

但这种直接在方法上加锁的方式，锁的粒度较粗。

因为doSave方法中的文件上传和消息发送并不需要加锁，只有创建目录的方法需要加锁。

我们知道，文件上传操作非常耗时，如果将整个方法加锁，那么需要等到整个方法执行完之后才能释放锁。

显然，这会导致该方法的性能下降，得不偿失。

2. 代码块上加锁我们可以将加锁改在代码块上，从而缩小锁的粒度， 如下：

public void doSave(String path, String fileUrl) {
    synchronized(this) {
        if (!exists(path)) {
            mkdir(path);
        }
    }
    uploadFile(fileUrl);
    sendMessage(fileUrl);
}

这样改造后，锁的粒度变小了，只有并发创建目录时才加锁。

创建目录是一个非常快的操作，即使加锁对接口性能的影响也不大。

最重要的是，其他的文件上传和消息发送功能仍然可以并发执行。

多节点环境中的问题 在单机版服务中，这种做法没有问题。但在生产环境中，为了保证服务的稳定性，同一个服务通常会部署在多个节点上。如果某个节点挂掉，其他节点的服务仍然可用。

多节点部署避免了某个节点挂掉导致服务不可用的情况，同时也能分摊整个系统的流量，避免系统压力过大。

但这种部署方式也带来了新的问题：synchronized只能保证一个节点加锁有效。

如果有多个节点，如何加锁呢？

7.2 Redis分布式锁

在分布式系统中，由于Redis分布式锁的实现相对简单且高效，因此它在许多实际业务场景中被广泛采用。

使用Redis分布式锁的伪代码如下：

public boolean doSave(String path, String fileUrl) {
    try {
        String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
        if ("OK".equals(result)) {
            if (!exists(path)) {
                mkdir(path);
                uploadFile(fileUrl);
                sendMessage(fileUrl);
            }
            return true;
        }
    } finally {
        unlock(lockKey, requestId);
    }
    return false;
}

与之前使用synchronized关键字加锁时一样，这里的锁的范围也太大了，换句话说，锁的粒度太粗。这会导致整个方法的执行效率很低。

实际上，只有在创建目录时才需要加分布式锁，其余代码不需要加锁。

于是，我们需要优化代码：

public void doSave(String path, String fileUrl) {
    if (tryLock()) {
        try {
            if (!exists(path)) {
                mkdir(path);
            }
        } finally {
            unlock(lockKey, requestId);
        }
    }
    uploadFile(fileUrl);
    sendMessage(fileUrl);
}

private boolean tryLock() {
    String result = jedis.set(lockKey, requestId, "NX", "PX", expireTime);
    return "OK".equals(result);
}

private void unlock(String lockKey, String requestId) {
    // 解锁逻辑
}

上面的代码将加锁的范围缩小了，只有在创建目录时才加锁。这样的简单优化后，接口性能可以得到显著提升。

7.3 数据库锁

MySQL数据库中的三种锁

  1. 表锁：

    • 优点：加锁快，不会出现死锁。

    • 缺点：锁定粒度大，锁冲突的概率高，并发度最低。

  2. 行锁：

    • 优点：锁定粒度最小，锁冲突的概率低，并发度最高。

    • 缺点：加锁慢，会出现死锁。

  3. 间隙锁：

    • 优点：锁定粒度介于表锁和行锁之间。

    • 缺点：开销和加锁时间介于表锁和行锁之间，并发度一般，也会出现死锁。

锁与并发度

并发度越高，接口性能越好。因此，数据库锁的优化方向是：

  1. 优先使用行锁

  2. 其次使用间隙锁

  3. 最后使用表锁

八、分页处理

有时候，我需要调用某个接口来批量查询数据，例如，通过用户ID批量查询用户信息，然后为这些用户赠送积分。

但是，如果一次性查询的用户数量太多，例如一次查询2000个用户的数据，传入2000个用户的ID进行远程调用时，用户查询接口经常会出现超时的情况。

调用代码如下：

List<User> users = remoteCallUser(ids);

众所周知，调用接口从数据库获取数据需要经过网络传输。如果数据量过大，无论是数据获取速度还是网络传输速度都会受到带宽限制，从而导致耗时较长。

那么，这种情况下该如何优化呢？

答案是：分页处理。

将一次性获取所有数据的请求，改为分多次获取，每次只获取一部分用户的数据，最后进行合并和汇总。

其实，处理这个问题可以分为两种场景：同步调用和异步调用。

8.1 同步调用

如果在job中需要获取2000个用户的信息，它要求只要能正确获取到数据即可，对获取数据的总耗时要求不高。

但对每一次远程接口调用的耗时有要求，不能大于500ms，否则会有邮件预警。

这时，我们可以同步分页调用批量查询用户信息接口。

具体示例代码如下：

List<List<Long>> allIds = Lists.partition(ids, 200);

for (List<Long> batchIds : allIds) {
    List<User> users = remoteCallUser(batchIds);
}

代码中我使用了Google Guava工具中的Lists.partition方法，用它来做分页简直太好用了，不然要写一大堆分页的代码。 8.2 异步调用 如果是在某个接口中需要获取2000个用户的信息，需要考虑的因素更多。

除了远程调用接口的耗时，还需要考虑该接口本身的总耗时，也不能超过500ms。

这时，使用上面的同步分页请求远程接口的方法肯定是行不通的。

那么，只能使用异步调用了。

代码如下：

List<List<Long>> allIds = Lists.partition(ids, 200);

final List<User> result = Lists.newArrayList();
allIds.stream().forEach(batchIds -> {
    CompletableFuture.supplyAsync(() -> {
        result.addAll(remoteCallUser(batchIds));
        return Boolean.TRUE;
    }, executor);
});

使用CompletableFuture类，通过多个线程异步调用远程接口，最后汇总结果统一返回。

九、加缓存

通常情况下，我们最常用的缓存是：Redis和Memcached。

但对于Java应用来说，绝大多数情况下使用的是Redis，所以接下来我们以Redis为例。

在关系型数据库（例如：MySQL）中，菜单通常有上下级关系。某个四级分类是某个三级分类的子分类，三级分类是某个二级分类的子分类，而二级分类又是某个一级分类的子分类。

这种存储结构决定了，想一次性查出整个分类树并非易事。这需要使用程序递归查询，而如果分类很多，这个递归操作会非常耗时。

因此，如果每次都直接从数据库中查询分类树的数据，会是一个非常耗时的操作。

这时我们可以使用缓存。在大多数情况下，接口直接从缓存中获取数据。操作Redis可以使用成熟的框架，比如：Jedis和Redisson等。 使用Jedis的伪代码如下：

String json = jedis.get(key);
if (StringUtils.isNotEmpty(json)) {
    CategoryTree categoryTree = JsonUtil.toObject(json);
    return categoryTree;
}
return queryCategoryTreeFromDb();

注意引入缓存之后，我们的系统复杂度就上升了，这时候就会存在数据不一致的问题

十、分库分表

有时候，接口性能受限的并不是其他方面，而是数据库。

当系统发展到一定阶段，用户并发量增加，会有大量的数据库请求，这不仅需要占用大量的数据库连接，还会带来磁盘IO的性能瓶颈问题。

此外，随着用户数量的不断增加，产生的数据量也越来越大，一张表可能无法存储所有数据。由于数据量太大，即使SQL语句使用了索引，查询数据时也会非常耗时。

那么，这种情况下该怎么办呢？

答案是：需要进行分库分表。

如下图所示：

图片

图中将用户库拆分成了三个库，每个库都包含了四张用户表。

如果有用户请求过来，先根据用户ID路由到其中一个用户库，然后再定位到某张表。

路由的算法有很多：

  1. 根据ID取模：

    • 例如：ID=7，有4张表，则7%4=3，模为3，路由到用户表3。

  2. 给ID指定一个区间范围：

    • 例如：ID的值是0-10万，则数据存在用户表0；ID的值是10-20万，则数据存在用户表1。

  3. 一致性Hash算法。 分库分表主要有两个方向：垂直和水平。

1. 垂直分库分表
垂直分库分表（即业务方向）更简单，将不同的业务数据存储在不同的库或表中。

例如，将用户数据和订单数据存储在不同的库中。

2. 水平分库分表
水平分库分表（即数据方向）上，分库和分表的作用有区别，不能混为一谈。

分库

  • 目的：解决数据库连接资源不足问题和磁盘IO的性能瓶颈问题。

分表

  • 目的：解决单表数据量太大，SQL语句查询数据时，即使走了索引也非常耗时的问题。此外，还可以解决消耗CPU资源的问题。

分库分表

  • 目的：综合解决数据库连接资源不足、磁盘IO性能瓶颈、数据检索耗时和CPU资源消耗等问题。

业务场景中的应用

  1. 只分库：

    • 用户并发量大，但需要保存的数据量很少。

  2. 只分表：

    • 用户并发量不大，但需要保存的数据量很多。

  3. 分库分表：

    • 用户并发量大，并且需要保存的数据量也很多。

十一、监控功能

优化接口性能问题，除了上面提到的这些常用方法之外，还需要配合使用一些辅助功能，因为它们真的可以帮我们提升查找问题的效率。

11.1 开启慢查询日志

通常情况下，为了定位SQL的性能瓶颈，我们需要开启MySQL的慢查询日志。把超过指定时间的SQL语句单独记录下来，方便以后分析和定位问题。

开启慢查询日志需要重点关注三个参数：

  • slow_query_log：慢查询开关

  • slow_query_log_file：慢查询日志存放的路径

  • long_query_time：超过多少秒才会记录日志

通过MySQL的SET命令可以设置：

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL slow_query_log_file = '/usr/local/mysql/data/slow.log';
SET GLOBAL long_query_time = 2;

设置完之后，如果某条SQL的执行时间超过了2秒，会被自动记录到slow.log文件中。

当然，也可以直接修改配置文件my.cnf：

[mysqld]
slow_query_log = ON
slow_query_log_file = /usr/local/mysql/data/slow.log
long_query_time = 2

但这种方式需要重启MySQL服务。

很多公司每天早上都会发一封慢查询日志的邮件，开发人员根据这些信息优化SQL。

11.2 加监控

为了在出现SQL问题时能够及时发现，我们需要对系统做监控。

目前业界使用比较多的开源监控系统是：Prometheus。

它提供了监控和预警的功能。

架构图如下：

我们可以用它监控如下信息：

  • 接口响应时间

  • 调用第三方服务耗时

  • 慢查询sql耗时

  • cpu使用情况

  • 内存使用情况

  • 磁盘使用情况

  • 数据库使用情况

  • 等等。。。

它的界面大概长这样子：

图片

可以看到MySQL的当前QPS、活跃线程数、连接数、缓存池的大小等信息。

如果发现连接池占用的数据量太多，肯定会对接口性能造成影响。

这时可能是由于代码中开启了连接却忘记关闭，或者并发量太大导致的，需要进一步排查和系统优化

链路跟踪

有时候，一个接口涉及的逻辑非常复杂，例如查询数据库、查询Redis、远程调用接口、发送MQ消息以及执行业务代码等等。

这种情况下，接口的一次请求会涉及到非常长的调用链路。如果逐一排查这些问题，会耗费大量时间，此时我们已经无法用传统的方法来定位问题。

有没有办法解决这个问题呢？

答案是使用分布式链路跟踪系统：SkyWalking。

SkyWalking的架构图如下：

图片

图片

在SkyWalking中，可以通过traceId（全局唯一的ID）来串联一个接口请求的完整链路。你可以看到整个接口的耗时、调用的远程服务的耗时、访问数据库或者Redis的耗时等，功能非常强大。

之前没有这个功能时，为了定位线上接口性能问题，我们需要在代码中加日志，手动打印出链路中各个环节的耗时情况，然后再逐一排查。这种方法不仅费时费力，而且容易遗漏细节。

码农浩克
关注
【系统架构设计师】论文：论Web应用系统性能优化技术与应用
数据知道的博客
09-03 3473
我单位联合某高校研发了。系统以程序代码在线提交自动评测功能为核心，主要分为题库模块、测评机、实验作业模块、考试模块、比赛模块、抄袭判定模块、用户管理模块等，支持对接教务平台。在项目中我担任系统架构师，主要负责架构设计工作。本文以该平台为例，主要论述了Web系统性能优化技术在本项目中的具体应用，着重介绍了负载均衡技术、缓存技术、数据库主从部署三种技术。通过负载均衡技术结合服务器集群，提高网站的并发能力。
架构师必知必会系列：服务导向架构与API设计
AI天才研究院
09-24 1687
服务导向架构（SOA）是一种新型的企业级应用架构模式，它将复杂的业务功能从应用程序中分离出来，通过服务提供者和消费者模型实现业务功能的可复用、独立开发和部署，进而提高系统的可扩展性、弹性、可靠性和可管理性。SOA旨在帮助组织解决以下四个主要难题：1.技术异构性业务部门通常有多种类型的软件和硬件平台，包括各种编程语言、数据库、中间件等等。要开发跨平台兼容的应用程序或服务，就需要考虑到这些异构性，并且针对不同平台进行定制优化。服务导向架构可以很好地解决这个问题。2.性能和可伸缩性瓶颈。
各种API性能_性能优化技巧
06-12
各种API性能_性能优化技巧！！！
工作实践：11种API性能优化方法
BUG指挥课堂
06-21 1310
上面这个例子中，发站内通知和用户操作日志功能，对实时性要求不高，即使晚点写库，用户无非是晚点收到站内通知，或者运营晚点看到用户操作日志，对业务影响不大，所以完全可以异步处理。但是，如果一次性查询的用户数量太多，例如一次查询2000个用户的数据，传入2000个用户的ID进行远程调用时，用户查询接口经常会出现超时的情况。这种情况下，接口的一次请求会涉及到非常长的调用链路。当系统发展到一定阶段，用户并发量增加，会有大量的数据库请求，这不仅需要占用大量的数据库连接，还会带来磁盘IO的性能瓶颈问题。
聊聊Api接口优化的几个方法
959
04-26 1138
文章目录1.哪些问题会引起接口性能问题2.问题解决2.1 慢查询（基于mysql）2.2 业务逻辑复杂2.3 线程池设计不合理2.4 锁设计不合理2.5 机器问题（fullGC，机器重启，线程打满）2.6 万金油解决方式 1.哪些问题会引起接口性能问题 数据库慢查询 深度分页问题 未加索引 索引失效 join过多 子查询过多 in中的值太多 单纯的数据量过大 业务逻辑复杂 循环调用 顺序调用 线程池设计不合理 锁设计不合理 机器问题（fullGC，机器重启，线程打满） 2.问题解决 2.1 慢查询（基于
聊聊接口性能优化的11个小技巧
m0_67322837的博客
04-26 3695
前言 接口性能优化对于从事后端开发的同学来说，肯定再熟悉不过了，因为它是一个跟开发语言无关的公共问题。 该问题说简单也简单，说复杂也复杂。 有时候，只需加个索引就能解决问题。 有时候，需要做代码重构。 有时候，需要增加缓存。 有时候，需要引入一些中间件，比如mq。 有时候，需要需要分库分表。 有时候，需要拆分服务。 等等。。。 导致接口性能问题的原因千奇百怪，不同的项目不同的接口，原因可能也不一样。 本文我总结了一些行之有效的，优化接口性能的办法，给有需要的朋友一个参考。 1.索引
架构师必备技能指南：SaaS(软件即服务)架构设计
01-27
- **性能优化**：确保高并发下的服务响应速度和稳定性。 - **集成能力**：与其他系统和API的无缝连接。 - **管理工具**：方便租户管理和监控服务使用情况。 7. **实施注意事项** 在设计SaaS架构时，需考虑以下...
Java架构师API设计
赵广陆
10-12 419
目录 1 导学 2 架构师的角度来审视API 2.1 API狭隘理解 2.2 API广义理解 2.3 API的用途不同定义 2.4 面向抽象编程的Java开发 2.5 API在提高系统的可维护性和可扩展性方面的作用 3 架构师必备的API设计原则 3.1 标准化原则 3.2 易用性原则 3.3 扩展性原则 3.4 兼容性原则 3.5 抽象性原则 3.6 职责单一性原则 4 API设计法则 4.1 用力驱动的API设计 4.2 初步设计的API进行综合权衡和调整 4.3 API设计时需要考虑的问题
API接口性能优化总结
xulong5000的专栏
06-17 1112
在调用WCF ，API ， Core2.1或者其他接口时，总会遇到性能瓶颈，在订单量不断的新增的情况下，产生高并发。 出现服务器CPU 100% 或者是内存100% 其根本原因 可能是 API接口调用频率太高。无法释放内存产生的。 在这种情况下，如何找到并发的原因： 一：检查sql数据查询或者是非查询功能的性能。查看sql语句的执行时间是否超时，优化sql语句 二：查看接口中是否...
api接口的简单见解与优化
qq_40876291的博客
04-16 4137
初级：基础接口  如注册登陆，文章内容的增删改查（一般将增和改放一起写），邮件发送中级：中级接口   主要是一些借助第三方接口文档，如短信，push消息，微信支付高级： 项目工程化及性能调优   主要包括自测脚本，lib公共代码的抽离，第三方composer管理，异常处理，DAO数据操作层抽离和基类增删改查的实现（框架自带），统一的api接口数据返回，统一的接受数据高级优化-详情：公共代码抽离：将...
优化API性能：实用策略提升响应速度
最新发布
ze_mingmingge123的博客
06-26 737
在今天快节奏的数字世界中，API的速度可能是用户体验的决定因素。在本文中，我们将探讨优化API性能的实用策略。例如，当有连续的数据输入时（如我们之前文章中提到使用MQTT的场景），在内存中聚合数据，然后使用定时器每2分钟执行一次批量插入。通过实施这些策略，您可以显著提升API的性能，为用户提供更快速和更可靠的体验。线程池管理一个线程池，它会重用线程，从而减少了创建和销毁线程的开销。通过异步编程和并行处理，可以更有效地利用系统资源，显著提升API的性能。方法提供了一种方便的方式来并行处理集合中的元素。
接口性能优化技巧，干掉慢代码！
好好学java
12-21 601
今日推荐推荐 20 款 IDEA 主题！ 开源困境：Log4j2 维护者发声：没有工资，还要挨骂！！ RedisJson 横空出世，性能碾压ES和Mongo！ 还在发愁写API文档？...
如何优化API？8个实用技巧【eolink翻译】
API
04-01 1263
使用 API 可以让公司利用现代连接的力量来帮助他们扩大全球影响力、传输数据和改进集成。由于 API 使企业能够简化流程并增强可用性，所以企业会使用一些优化策略，不断优化流程，比如接下来要说到的8个技巧，这可以帮助企业获得更好的性能、更好的用户体验以及更少的错误结果和延迟实例。
聊聊Api接口优化的几个方法！
2401_83396023的博客
03-09 915
我负责的系统到2021年初完成了功能上的建设，开始进入到推广阶段。随着推广的逐步深入，收到了很多好评的同时也收到了很多对性能的吐槽。刚刚收到吐槽的时候，我们的心情是这样的：当越来越多对性能的吐槽反馈到我们这里的时候，我们意识到，接口性能的问题的优先级必须提高了。然后我们就跟踪了1周的接口性能监控，这个时候我们的心情是这样的：有20多个慢接口，5个接口响应时间超过5s，1个超过10s，其余的都在2s以上，稳定性不足99.8%。作为一个优秀的后端，这个数据肯定是不能忍的，我们马上就进入了漫长的接口优化之路。
每个 Java 工程师都必须知道的五个 API 性能优化技巧
m0_72885838的博客
08-19 1176
为什么你的 API 响应这么慢？也许你需要解决这些问题。作为后端开发人员，我们总是在编写各种 API，无论是为前端 Web 提供数据支持的HTTP REST API ，还是提供内部使用的 RPC API。这些 API 在服务初期可能表现不错，但随着用户数量的增长，一开始响应很快的API变得越来越慢，直到用户抱怨：“你的系统太糟糕了。我只是浏览一个网页。怎么这么慢？” 这时，您需要考虑如何优化您的 API 性能。要提高你的API的性能，我们首先要知道什么问题会导致接口响应慢。API设计需要考虑很多方面。
API接口优化总结
myroncham的博客
04-23 494
1、一定要绝对避免循环查数据库和缓存（PS：循环里面就不能有查询缓存，更不能有查询数据库的操作，因为循环的次数没法控制） 2、对于API接口的话，一般都是直接查缓存的，没有查数据库的 3、多用批量查询，少用单条查询，尽量一次查出来 4、对于使用阿里云，要留意一下相应产品的配置，该花的钱还是得花，同时，千万要记得正式环境中使用相应产品的内网地址 5、注意连接池大小（包括数据库连接池、Redis缓存连...
蚂蚁架构师：并发编程与分布式性能优化教程
"蚂蚁架构师第3期并发编程设计模式分布式性能优化视频教程" 本视频教程聚焦于Java并发编程设计模式和分布式系统的性能优化，旨在帮助Java开发者提升在大规模并发环境下的编程能力以及优化分布式系统性能的技巧。...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值