Pulsar客户端如何控制内存使用

摘要

本文围绕一个常见的使用场景深入分析在高吞吐场景下，使用Pulsar客户端收发消息可能会遇到的若干问题。并以此为切入点，梳理一下Pulsar客户端在内存控制上所做的优化改进。

使用场景

假设这样一个常见的场景，一个搜索类业务需要记录用户搜索请求，以便后续分析搜索热点，以及有针对性的优化搜索效果等。于是，我们有下面这段逻辑，简化后如下：

	PulsarClient pulsarClient = PulsarClient.builder()
	.serviceUrl("pulsar://localhost:6650")
	.build();
	Producer<byte[]> producer = pulsarClient.newProducer()
	.topic("search-activities")
	.create();
	try {
	MessageId messageId = producer.send(/* message payload here */);
	log.debug("Search activity messageId={}", messageId);
	} catch (Exception e) {
	log.error("Failed to record search activity", e);
	}

注意pulsarClient和producer均支持复用，并且推荐这么做，这里只是为了演示写到了一起。

producer.send是阻塞方式发送消息，换句话说就是线程会卡在这里等待发送结果返回。在现实中可以根据消息在实际业务中的需要选择阻塞和非阻塞两种方式，例如这里我们的业务是在用户发起一次搜索请求时记录搜索请求和上下文信息，业务上对搜索请求事件并无强依赖，因此这里使用阻塞方式发消息就不太适合了，从性能上考虑会加长整体的搜索延迟，从稳定性上考虑会增加搜索执行过程中的不确定性，总的来说，要区分支线流程和主线流程，不应该把支线流程全部嵌套在主线流程中。

于是，我们可以优化一下，调整为非阻塞方式，将记录搜索事件放到其它线程中完成：

	producer.sendAsync(/* message payload here */).whenComplete((msgId, ex) -> {
	if (ex != null) {
	log.error("Failed to record search activity", ex);
	} else {
	log.debug("Search activity messageId={}", msgId);
	}
	});

在现实中，若用户搜索的TPS较高，例如在单实例上可以超过1000QPS（高和低都是相对而言的，这里只是举个例子）。若恰好记录的搜索事件内容较多（例如包含了搜索请求的完整上下文和搜索结果等），序列化之后大小能达到100KB甚至1MB，那么上面代码在运行时你可以会遇到MemoryBufferIsFullError异常：

org.apache.pulsar.client.api.PulsarClientException$MemoryBufferIsFullError: Client memory buffer is full