blocks|key|4424628|text|最重要的是，您的应用程序应该具有一定的可预测性。至于“如何”，如果不对需求和架构进行更深入的分析，就不可能说出这一点。缓存通常是某种形式的关键组件。根据几个因素，例如数据的波动性和变化率，可以采取不同的方法。最简单的做法是只使用本地缓存，请记住，除非添加一些缓存同步，否则对缓存数据所做的更改不会立即反映在所有节点上。在另一端，您有一个完全分布式的缓存，如Terracotta+BigMemory或其他分布式/集群缓存解决方案。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4424629|我建议您尽早建立性能测试基准。这将允许您测试正在开发的系统的可伸缩性。针对一个、两个、三个etc负载均衡节点运行基准测试，并测量吞吐量。还要确定必须在所有节点之间共享的任何资源或数据，以及如何正确地同步这些资源或数据以实现最佳可伸缩性。|4424630|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Most important is that your application should scale with some predictability. As for the "how", that is impossible to say without a more in-depth analysis of the requirements and architecture. Caching is usually a key-component in some form or other. Depending on several factors, such as the volatility of the data and the rate of change, different approaches can be taken. Simplest is to have only local caches, bearing in mind that changes made to cached data will not be immediately reflected on all nodes unless some cache synchronization is added. On the other end, you have a fully distributed caches, like Terracotta BigMemory or other distributed/clustered caching solutions.

I advice you to establish performance testing baselines as early as possible. That will allow you to test the scalability of the system you are developing. Run the benchmark against one, two, three etc load-balanced nodes and measure the throughput. Also identify any resources or data that must be shared between all the nodes and how to properly synchronize these for optimal scalability.

blocks|key|4707673|text|很难将通常通过编写和维护大规模应用程序所获得的内容压缩成论坛帖子形式的答案。通常，人们会花很多钱给其他有这种专业知识的人。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|4707674|您需要对应用程序的想法有所了解。一些陷阱在分析阶段出现，特别是关于基础设施(在哪里服务于什么？)，另一些是通过数据处理(同步如何工作？)。|4707675|其他的将在以后出现，比如“当X崩溃时我们会做什么”(插入X的基础设施的任何部分)。您可以根据这些场景反复检查您的恢复时间。|4707676|然后你写出整个想法的部分，并针对它测试失败的场景和用例。|4707677|最后，如果你认为一切都已经被考虑过了，你把它交给和你一样有经验的人，甚至更多，然后写下他们认为是问题的一切，测试他们的抱怨，并改变应用程序和/或基础设施的结构，以适应所有用例。|4707678|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

It's very difficult to condense what is usually gained by writing and maintaining large scale applications into an answer that comes in the form of a forum post. Usually, people pay alot of money to other people with this kind of expertise.

You need to get a feel for the idea of the applications. Some traps become appearant during the analysis stage, especially regarding the infrastructure (what is served where over what?), others by the data handling (how will synchronization work?).

Others will appear later, like "What will we do when X crashes" (insert any part of the infrastructure for X). You check and recheck your recovery times against these scenarios.

Then you write up the parts of the whole idea and test fail scenarios and use cases against it.

At the end, if you think everything has been thought of, you give it to someone just as experienced as yourself, maybe even more, then write down everything they see as a problem, test their complaints and alter the structure of the application and/or infrastructure to accomodate all use cases.

blocks|key|2810196|text|这是一个很大的话题，不容易回答--超大规模的应用程序通常需要针对它们期望处理的特定类型的负载进行仔细的设计。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|2810197|例如:如果您的体系结构主要处理只读页面视图(通过复制大量廉价的应用程序服务器来轻松扩展)与处理复杂的金融事务(您需要一种协调大量并发事务的方法)，那么您的体系结构将非常不同。|2810198|一些一般性的提示：|2810199|2810200|Prefer+horizontal+-尽可能的，你希望能够通过添加更多便宜的盒子来实现可伸缩性。您设计的应用程序越适合此模型，对可变状态的better.|unordered-list-item|offset|length|style|BOLD|2810201|Co-ordinated更改将最终成为可伸缩性的瓶颈，因为它是唯一不能通过廉价的盒子水平扩展到您想要的程度的东西。弄清楚这些变化是什么，并进行相应的设计。如果幸运的话，一个数据库实例就足够了。如果不是这样，您就会遇到非常昂贵的数据库群集/分层事务语义，而不是基于可以扩展territory.|2810202|Use的NoSQL+/高度自定义的数据存储经验证的库/组件。例如，用于高吞吐量communications.|2810203|Don't的Netty在没有团队专业知识的情况下尝试-将应用程序扩展到“大联盟”是困难的，并且需要专业技能。如果你做错了，你可能会遇到瓶颈，需要昂贵的重写。雇佣以前做过这件事的人。|2810204|2810205|顺便说一句，每天1000万次请求实际上并不是很大。也就是说每秒只有115个请求。通过相当紧凑的编码，一台现代服务器就可以处理这件事......|2810206|entityMap|0|LINK|mutability|MUTABLE|url|http://www.jboss.org/netty^0|0|0|0|0|0|I|0|0|41|0|0|1I|0|0|2I|6|5|0|0|0|0|1Z|0^^$0|@$1|2|3|4|5|6|7|14|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|15|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|16|8|@]|9|@]|A|$]]|$1|F|3|-4|5|6|7|17|8|@]|9|@]|A|$]]|$1|G|3|H|5|I|7|18|8|@$J|19|K|1A|L|M]]|9|@]|A|$]]|$1|N|3|O|5|I|7|1B|8|@$J|1C|K|1D|L|M]]|9|@]|A|$]]|$1|P|3|Q|5|I|7|1E|8|@$J|1F|K|1G|L|M]]|9|@]|A|$]]|$1|R|3|S|5|I|7|1H|8|@$J|1I|K|1J|L|M]]|9|@$J|1K|K|1L|1|1M]]|A|$]]|$1|T|3|-4|5|6|7|1N|8|@]|9|@]|A|$]]|$1|U|3|V|5|6|7|1O|8|@$J|1P|K|1Q|L|M]]|9|@]|A|$]]|$1|W|3|-4|5|6|7|1R|8|@]|9|@]|A|$]]]|X|$Y|$5|Z|10|11|A|$12|13]]]]

This is a huge topic and can't be easily answered - very large scale applications in general need to be carefully designed for the specific kind of load they are expected to handle. 

For example: your architecture will be very different if it is handling mostly read-only page views (easy to scale by replicating lots of cheap application servers) vs. if it is handling complex financial transactions (where you need a way of co-ordinating large numbers of simultaneous transactions).

Some general hints:

<ul>
<li>Prefer horizontal scaling - as far as possible, you want to be able to achieve your scalability by adding more cheap boxes. The more that you can design your application to fit this model, the better.</li>
<li>Co-ordinated changes to mutable state will ultimately be your bottleneck to scalability, as it's the one thing that cannot be scaled as far you as you like horizontally with cheap boxes. Work out what these changes will be, and design accordingly. If you're lucky, a single database instance will be sufficient. If not, you're into very expensive database cluster / layering transactional semantics over NoSQL / highly-custom-data-store territory.</li>
<li>Use proven libraries / components that can scale. e.g. <a href="http://www.jboss.org/netty" rel="nofollow">Netty</a> for high throughput communications.</li>
<li>Don't try this without expertise on your team - scaling applications into the "big league" is hard and requires specialist skills. If you do it wrong, you can get stuck with bottlenecks that require expensive rewrites. Hire someone who's done it before.</li>
</ul>

BTW - 10 million requests per day isn't actually that big. That's only 115 requests per second. With reasonably tight coding, one modern server can handle that......

I would like to know from highly experienced Java professionals who have worked with large scale production systems, what needs to be done to build web application to scale that can handle 10 million plus requests per day?

For example if some sort of caching needs to be done then what production quality library is used for caching?

What needs to be done to develop highly scalable web application in Java?

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我想从使用过大规模生产系统的经验丰富的Java专业人员那里了解到，需要做些什么才能构建能够处理每天1000多万个请求的规模的web应用程序？例如，如果需要进行某种缓存，那么使用什么产品质量库进行缓存？

问用Java开发高度可伸缩的web应用程序需要做些什么？
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用Java开发高度可伸缩的web应用程序需要做些什么？EN