我正在尝试编写具有两种方法的批处理邮件服务:
添加(Mail mail)
:可以发送邮件,由生产者调用
flush MailService()
:刷新服务。消费者应该取一个List,然后调用另一个(昂贵的)方法。通常只有在达到批量大小后才应该调用昂贵的方法。
这有点类似于这个问题:生产者/消费者-生产者将数据添加到集合而不阻塞,消费者批量消费集合中的数据
使用具有超时的< code>poll()可以做到这一点。但是,如果生产者不想等待超时,它应该能够刷新邮件服务,但使生产者发送队列中的任何邮件。
poll(20, TimeUnit.SECONDS)
可以中断。如果中断,无论是否达到批大小,都应发送队列中的所有邮件,直到队列为空(使用 poll(),
如果队列为空,则立即返回 null
。一旦它为空,生产者发送的中断的邮件已经发送。然后,生产者应该再次调用然后阻止版本的轮询
,直到被任何其他生产者打断,依此类推。
这似乎适用于给定的实现。
我尝试将ExecutorServices与未来一起使用,但未来似乎只能中断一次,因为它们在第一次中断后被认为被取消了。因此,我求助于可以多次中断的线程。
目前我有以下似乎有效的实现(但正在使用“原始”线程)。
这是一个合理的方法吗?或者也许可以使用另一种方法?
public class BatchMailService {
private LinkedBlockingQueue<Mail> queue = new LinkedBlockingQueue<>();
private CopyOnWriteArrayList<Thread> threads = new CopyOnWriteArrayList<>();
private static Logger LOGGER = LoggerFactory.getLogger(BatchMailService.class);
public void checkMails() {
int batchSize = 100;
int timeout = 20;
int consumerCount = 5;
Runnable runnable = () -> {
boolean wasInterrupted = false;
while (true) {
List<Mail> buffer = new ArrayList<>();
while (buffer.size() < batchSize) {
try {
Mail mail;
wasInterrupted |= Thread.interrupted();
if (wasInterrupted) {
mail = queue.poll(); // non-blocking call
} else {
mail = queue.poll(timeout, TimeUnit.SECONDS); // blocking call
}
if (mail != null) { // mail found immediately, or within timeout
buffer.add(mail);
} else { // no mail in queue, or timeout reached
LOGGER.debug("{} all mails currently in queue have been processed", Thread.currentThread());
wasInterrupted = false;
break;
}
} catch (InterruptedException e) {
LOGGER.info("{} interrupted", Thread.currentThread());
wasInterrupted = true;
break;
}
}
if (!buffer.isEmpty()) {
LOGGER.info("{} sending {} mails", Thread.currentThread(), buffer.size());
mailService.sendMails(buffer);
}
}
};
LOGGER.info("starting 5 threads ");
for (int i = 0; i < 5; i++) {
Thread thread = new Thread(runnable);
threads.add(thread);
thread.start();
}
}
public void addMail(Mail mail) {
queue.add(mail);
}
public void flushMailService() {
LOGGER.info("flushing BatchMailService");
for (Thread t : threads) {
t.interrupt();
}
}
}
另一种没有中断的方法,但毒丸的变体(Mail poison_pill=new Mail()
)可能如下。当有一个用户线程时,可能效果最好。至少,对于一粒毒丸,只有一个消费者会继续服用。
Runnable runnable = () -> {
boolean flush = false;
boolean shutdown = false;
while (!shutdown) {
List<Mail> buffer = new ArrayList<>();
while (buffer.size() < batchSize && !shutdown) {
try {
Mail mail;
if (flush){
mail = queue.poll();
if (mail == null) {
LOGGER.info(Thread.currentThread() + " all mails currently in queue have been processed");
flush = false;
break;
}
}else {
mail = queue.poll(5, TimeUnit.SECONDS); // blocking call
}
if (mail == POISON_PILL){ // flush
LOGGER.info(Thread.currentThread() + " got flush");
flush = true;
}
else if (mail != null){
buffer.add(mail);
}
} catch (InterruptedException e) {
LOGGER.info(Thread.currentThread() + " interrupted");
shutdown = true;
}
}
if (!buffer.isEmpty()) {
LOGGER.info(Thread.currentThread()+"{} sending " + buffer.size()+" mails");
mailService.sendEmails(buffer);
}
}
};
public void flushMailService() {
LOGGER.info("flushing BatchMailService");
queue.add(POISON_PILL);
}
用信号和等待代替中断怎么样?
生产者在需要冲洗时放置邮件和信号。调度程序等待信号或超时,并继续在使用者线程中发送电子邮件。
import java.util.ArrayList;
import java.util.List;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;
import java.util.concurrent.LinkedBlockingQueue;
import java.util.concurrent.TimeUnit;
import java.util.concurrent.locks.Condition;
import java.util.concurrent.locks.Lock;
import java.util.concurrent.locks.ReentrantLock;
public class BatchMailService {
private LinkedBlockingQueue<Mail> queue = new LinkedBlockingQueue<>();
public static final int BATCH_SIZE = 100;
public static final int TIMEOUT = 20;
public static final int CONSUMER_COUNT = 5;
private final Lock flushLock = new ReentrantLock();
private final Condition flushCondition = flushLock.newCondition();
MailService mailService = new MailService();
public void checkMails() {
ExecutorService consumerExecutor = Executors.newFixedThreadPool(CONSUMER_COUNT);
while (true) {
try {
// wait for timeout or for signal to come
flushLock.lock();
flushCondition.await(TIMEOUT, TimeUnit.SECONDS);
// flush all present emails
final List<Mail> toFLush = new ArrayList<>();
queue.drainTo(toFLush);
if (!toFLush.isEmpty()) {
consumerExecutor.submit(() -> {
LOGGER.info("{} sending {} mails", Thread.currentThread(), toFLush.size());
mailService.sendEmails(toFLush);
});
}
} catch (InterruptedException e) {
Thread.currentThread().interrupt();
break; // terminate execution in case of external interrupt
} finally {
flushLock.unlock();
}
}
}
public void addMail(Mail mail) {
queue.add(mail);
// check batch size and flush if necessary
if (queue.size() >= BATCH_SIZE) {
try {
flushLock.lock();
if (queue.size() >= BATCH_SIZE) {
flushMailService();
}
} finally {
flushLock.unlock();
}
}
}
public void flushMailService() {
LOGGER.info("flushing BatchMailService");
try {
flushLock.lock();
flushCondition.signal();
} finally {
flushLock.unlock();
}
}
}
本教程演示了如何发送和接收来自Spring Kafka的消息。 首先创建一个能够发送消息给Kafka主题的Spring Kafka Producer。 接下来,我们创建一个Spring Kafka Consumer,它可以收听发送给Kafka主题的消息。使用适当的键/值序列化器和解串器来配置它们。 最后用一个简单的Spring Boot应用程序演示应用程序。 下载并安装Apache Kafka 要
我的应用程序由一个带有POST方法的REST控制器组成,用于提交我必须使用生产者发送到主题的数据。 这是控制器 使用Spring-Cloud-Stream版本 从3.1版开始,和注释被弃用,所以我尝试切换到新的方式来设置生产者,我就是这样工作的 最后在应用程序中。yaml我有这个 现在的问题是,当我启动应用程序时,方法被无限调用(我在主题中看到消息)。然后使用供应商似乎我被迫在供应商内部定义消息数
高级使用者 API 似乎一次读取一条消息。 如果消费者想要处理这些消息并提交给其他下游消费者(如Solr或Elastic-Search ),这可能会给他们带来很大的问题,因为他们更喜欢批量接收消息,而不是一次接收一条。 在内存中批处理这些消息也并非易事,因为只有当批处理已经提交时,Kafka中的偏移量也需要同步,否则具有未提交下游消息的崩溃的 kafka 使用者(如在Solr或ES中)将已经更新其
我正在编写一个程序,其中几个生产者生成一些应该由几个消费者处理的数据。由于每条数据的消耗大约需要100ms,而目标平台有很多处理器,所以在我看来,每个生产者和每个消费者都得到自己的线程似乎是很自然的。我的问题是:Qt信号/插槽是将数据块从生产者传递到消费者的好方法吗?还是建议更好的解决方案(强烈首选Qt)。 为了防患于未然,制作者每小时产生几十万个数据。
我想使用一个camel组件,它提供了使用和生成RESTful资源的能力。 对于这个例子,我想使用camel restlet组件。restlet组件一切正常,我已经使用REST DSL成功地实现了restlet consumer。然而,我有几个问题: 问题 1) 将restlet启用为异步是否安全?我读过restlet async可能会导致一些问题。这仍然正确吗?如何提高服务绩效?我应该改用码头吗?
生产者线程与消费者线程使用信号量同步 生产者线程与消费者线程使用信号量同步 源码/* * Copyright (c) 2006-2018, RT-Thread Development Team * * SPDX-License-Identifier: Apache-2.0 * * Change Logs: * Date Author Notes * 2018-08-24 yangjie the f