Ezi*_*ore 7 rest spring load spring-boot
所以我一直在准备并进行采访。我在两次采访中被问到这个问题,但我无法给出令人满意的答案,或者可能不是他们想听到的答案。
问题是,让我们抛开负载平衡、多实例、数据库复制等各种操作技术,您可以在应用程序中进行哪些更改(即 REST API)以使其能够处理大量请求?
到目前为止我的想法是,我们可以使任何数据库或其他 API 调用异步,让它们在后台的单独线程中运行,以便处理可以继续处理其他请求。我的一位同事说使用缓存来最大限度地减少数据库调用。
也许可以增加线程池的大小,但线程很昂贵,而且您只能创建这么多线程。此外,如果池中的所有线程都忙,其他请求将被阻塞,直到有线程可用为止。所以,这似乎根本不属于解决这个问题的方法。
总的来说,我们得出的结论是,在这种情况下,除了确保 API 应该只执行轻量级操作(如果这有意义的话)之外,我们实际上无能为力。
我用谷歌搜索了相同的内容,但除了操作和线程池之外,没有真正找到任何东西。
我想知道社区是否可以对此提供意见。你是如何处理这种情况的?
为了在春季获得最佳表现,您可以做很多事情,这里列出了一些。
反应式 利用反应式非阻塞线程模型。当您的应用程序充当传递时,这非常有用,基本上,如果您收到休息请求,那么您的应用程序需要向第三方应用程序发出休息请求,利用反应式模型将允许重复使用这些线程当外部服务正在处理请求时。
无状态性 让您的服务无状态
安全性 使用 JWT 而不是每次都需要执行数据库查找的 Oauth 令牌。
缓存 尽可能缓存所有内容。尽可能使用本地缓存而不是分布式缓存
DB 使用 Hikari 等快速连接池 确保您的连接池具有最佳配置。优化查询。更快的响应时间意味着更多的线程可用于处理。
线程管理 正确配置用于执行器的线程池会对应用程序性能产生很大影响。但是,此配置必须基于系统的可用资源和应用程序的需求。
微服务架构 如果您正确使用微服务架构,每个服务只会接收与其域相关的请求,这可能会减少整个应用程序的需求。
服务器选择 使用 Undertow 或 Netty 嵌入式服务器
优化 JVM 优化应用程序或容器的 JVM 内存使用情况。
我想到的第一个问题是什么类型的请求?为了简化,我们假设有两个配置文件,读密集型或写密集型,并对两者进行详细说明。
如果应用程序是读取密集型的:
将大部分精力投入到缓存中。您可以在多个级别进行缓存,在 REST 级别完全缓存响应。还可以根据您的目标一致性级别在服务和存储库级别进行缓存。如果所有请求都是针对相同的keys,并且您的对象相当小,无法放入应用程序的内存中,您可以使用本地解决方案,否则您将需要一个缓存服务提供商来卸载缓存,例如Redis, Memcached 等。我不想特别鼓励任何一个,因为社区的偏好会不时发生变化。
这种方法背后的原因是,从 L2(甚至主内存)读取的速度比到达数据库(实际从磁盘读取时)要快几个数量级。在这里查看更多次
如果应用程序是写入密集型: 或者上述方法还不够,考虑到即使您正在缓存,有时也必须填充此缓存,那么是时候迁移到 no-sql/分布式数据库,如 MongoDB、Cassandra、ElasticSearch等等,具体取决于您的CAP要求。这里有一些例子。这些数据库专为高吞吐量而设计。您还可以在 AWS 上查看它们的等效项。可能必须对数据进行一些反规范化,以避免昂贵的(或明显不支持的)连接。
我不确定更改数据库是否在这些问题的范围内,但缓存和数据库通常是可以实现最大性能改进的地方。
祝你下次好运!
| 归档时间: |
|
| 查看次数: |
10855 次 |
| 最近记录: |