公共namespace变更之后的并发请求问题

[xiaqi1210]

如果一个公共namespace被1000个应用关联了, 每个应用有10个节点, 当这个公共的namespace有配置变更后, 我理解对这10000个节点都会推送最新配置, 且这10000个节点又会几乎同时发起对于这个公共namespace的配置拉取请求, 且这10000个节点又会几乎同时发起下一次长轮询请求, 这些瞬间的并发量会对apollo server造成压力吗, 如果节点数更多是不是会有更大压力? 这个地方apollo在设计上是怎么解决这个问题的

[dosubot[bot]]

Answer generated by a 🤖

Answer

I understand your concern about the potential pressure on the Apollo server due to the simultaneous polling from a large number of nodes following a change in a common namespace. This is indeed a valid concern, especially when dealing with a large number of nodes.

In Apollo, we have implemented a mechanism to mitigate this issue. The Apollo client and server maintain a long connection, allowing the client to receive configuration updates in real-time. This is achieved through HTTP Long Polling. Specifically, the client sends an HTTP request to the server, which the server holds for 60 seconds. If there is a configuration change that the client is interested in within these 60 seconds, the held client request is immediately returned, informing the client of the namespace information where the configuration has changed. The client then pulls the latest configuration for the corresponding namespace. If there are no configuration changes within 60 seconds, the server returns an HTTP status code 304 to the client. The client, upon receiving the server's response, immediately re-establishes the connection.

This design effectively reduces the pressure on the Apollo server due to concurrent requests following a change in a common namespace. However, this is just one potential solution and there might be other ways to handle this situation depending on the specific circumstances.

If you find this explanation satisfactory and feel that it might be beneficial for other users, I encourage you to make a pull request to update the documentation. This way, other users who might have the same question can benefit from your contribution.

Sources

• docs/zh/design/apollo-introduction.md

---

This response is meant to be useful, save you time, and share context. It is not meant to be a precise solution, but rather a starting point for your own research.

Help me be more useful! Please leave a 👍 if this is helpful and 👎 if it is irrelevant.

[nobodyiam]

There is a special handling logic.

apollo/apollo-configservice/src/main/java/com/ctrip/framework/apollo/configservice/controller/NotificationControllerV2.java

Lines 287 to 305 in 99b76dc

	//do async notification if too many clients
	if (results.size() > bizConfig.releaseMessageNotificationBatch()) {
	largeNotificationBatchExecutorService.submit(() -> {
	logger.debug("Async notify {} clients for key {} with batch {}", results.size(), content,
	bizConfig.releaseMessageNotificationBatch());
	for (int i = 0; i < results.size(); i++) {
	if (i > 0 && i % bizConfig.releaseMessageNotificationBatch() == 0) {
	try {
	TimeUnit.MILLISECONDS.sleep(bizConfig.releaseMessageNotificationBatchIntervalInMilli());
	} catch (InterruptedException e) {
	//ignore
	}
	}
	logger.debug("Async notify {}", results.get(i));
	results.get(i).setResult(configNotification);
	}
	});
	return;
	}

[xiaqi1210]

我不太理解，假设releaseMessageNotificationBatch=100，results有200个，看代码逻辑似乎只有第100个和第200个result会sleep一会儿，其他198个result都是马上响应的，我比较怀疑这种1%的sleep对于整体的负载能有多大程度的减轻，还是说我代码理解的不正确

[nobodyiam]

每个批次中间会停顿一段时间，批次大小和停顿时间可配置