kafka分布式_带有Kafka和ZeroMQ的分布式类星体演员

最新推荐文章于 2023-12-10 16:54:42 发布
最新推荐文章于 2023-12-10 16:54:42 发布
阅读量157 收藏
点赞数
文章标签： 分布式 java kafka 网络通信 socket
原文链接：https://www.javacodegeeks.com/2016/05/distributed-quasar-actors-kafka-zeromq.html
版权

kafka分布式

因此，您已经有了使用actor的精美设计，选择了JVM和Quasar在该主题上的强大而忠实的观点。 所有明智的决定，但是在集群上进行分配时您有什么选择呢？

星系

Galaxy是一个非常酷的选择：快速的内存中数据网格，针对数据局部性进行了优化，具有复制，可选的持久性，分布式参与者注册表，甚至参与者之间的参与者迁移！ 唯一需要注意的是：要发布正式版的生产质量的银河版，还需要几个月的时间。 不建议将当前版本的Galaxy用于生产。

如果我们需要在那之前上线怎么办？

幸运的是，Quasar Actors的阻塞编程模型非常简单，以至于将其与大多数消息传递解决方案集成起来都是轻而易举的，并且为了证明让我们用两种快速，流行且截然不同的模型来做到这一点： Apache Kafka和ØMQ 。

代码和计划

可以在GitHub上找到以下所有示例，只需快速阅读简短的README ，您就可以立即运行它们。

Kafka和ØMQ分别有两个示例：

  • 快速而肮脏的人直接进行发布/投票或发送/接收演员的呼叫。
  • 详细介绍了代理角色，这些代理角色将您的代码与消息传递API隔离开。 为了证明我没有在撒谎，该程序对两种技术使用了相同的生产者和消费者参与者类 ，并且几乎使用了相同的引导程序。

卡夫卡

Apache Kafka的采用率急剧上升，这是由于其基于持久性提交日志和用于并行消息使用的使用者组的独特设计：这种结合形成了快速，可靠，灵活和可扩展的代理。

该API包括两种类型的生产者：sync和async；一种消费者（仅sync）； Comsat包括社区贡献的，对光纤友好的Kafka生产商集成 。

Kafka生产者句柄是线程安全的，在共享时表现最佳，可以像这样在actor主体（或其他任何地方）中轻松获得和使用： 

final Properties producerConfig = new Properties();
producerConfig.put("bootstrap.servers", "localhost:9092");
producerConfig.put("client.id", "DemoProducer");
producerConfig.put("key.serializer", "org.apache.kafka.common.serialization.IntegerSerializer");
producerConfig.put("value.serializer", "org.apache.kafka.common.serialization.ByteArraySerializer");

try (final FiberKafkaProducer<Integer, byte[]> producer = new FiberKafkaProducer<>(new KafkaProducer<>(producerConfig))) {
     final byte[] myBytes = getMyBytes(); // ...
     final Future<RecordMetaData> res = producer.send(new ProducerRecord<>("MyTopic", i, myBytes));
     res.get(); // Optional, blocks the fiber until the record is persisted; thre's also `producer.flush()`
}

我们用Comsat的FiberKafkaProducer包装KafkaProducer对象，以便找回光纤阻塞的未来。

但是，使用者句柄不是线程安全的1，而仅是线程阻塞的： 

final Properties producerConfig = new Properties();
consumerConfig = new Properties();
consumerConfig.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG, BOOTSTRAP);
consumerConfig.put(ConsumerConfig.GROUP_ID_CONFIG, "DemoConsumer");
consumerConfig.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG, "true");
consumerConfig.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG, "1000");
consumerConfig.put(ConsumerConfig.SESSION_TIMEOUT_MS_CONFIG, "30000");
consumerConfig.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.IntegerDeserializer");
consumerConfig.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, "org.apache.kafka.common.serialization.ByteArrayDeserializer");

try (final Consumer<Integer, byte[]> consumer = new KafkaConsumer<>(consumerConfig)) {
    consumer.subscribe(Collections.singletonList(TOPIC));
    final ConsumerRecords<Integer, byte[]> records = consumer.poll(1000L);
    for (final ConsumerRecord<Integer, byte[]> record : records) {
        final byte[] v = record.value();
        useMyBytes(v); // ...
    }
}

由于我们不想阻塞光纤的基础线程池（除了那些Kafka屏蔽的线程池之外-我们无法对它们做太多事情），因此在我们的actor的doRun我们将使用FiberAsync.runBlocking代替，以喂入固定的具有异步任务的size执行程序，该任务将阻塞光纤直到poll （将在给定的池中执行）返回之前： 

final ExecutorService e = Executors.newFixedThreadPool(2);

try (final Consumer<Integer, byte[]> consumer = new KafkaConsumer<>(consumerConfig)) {
    consumer.subscribe(Collections.singletonList(TOPIC));
    final ConsumerRecords<Integer, byte[]> records = call(e, () -> consumer.poll(1000L));
    for (final ConsumerRecord<Integer, byte[]> record : records) {
        final byte[] v = record.value();
        useMyBytes(v); // ...
    }
}

其中call是一个定义如下的实用程序方法（如果不是此Java编译器bug，则没有必要）： 

@Suspendable
public static <V> V call(ExecutorService es, Callable<V> c) throws InterruptedException, SuspendExecution {
    try {
        return runBlocking(es, (CheckedCallable<V, Exception>) c::call);
    } catch (final InterruptedException | SuspendExecution e) {
        throw e;
    } catch (final Exception e) {
        throw new RuntimeException(e);
    }
}

在第一个完整的示例中，我们将从生产者角色向消费者发送一千个序列化消息。

ØMQ

ØMQ（或ZeroMQ）不是集中的代理解决方案，而更多地是针对各种通信模式（请求/答复，发布/订阅等）的套接字的一般化。 在我们的示例中，我们将使用最简单的请求-答复模式。 这是我们的新生产者代码： 

try (final ZMQ.Context zmq = ZMQ.context(1 /* IO threads */);
     final ZMQ.Socket trgt = zmq.socket(ZMQ.REQ)) {
    trgt.connect("tcp://localhost:8000");
    final byte[] myBytes = getMyBytes(); // ...
    trgt.send(baos.toByteArray(), 0 /* flags */)
    trgt.recv(); // Reply, e.g. ACK
}

如您所见，上下文充当套接字工厂，并传递了要使用的I / O线程数：这是因为ØMQ套接字不是连接绑定的OS句柄，而是用于处理的机器的简单前端重试连接，多个连接，高效的并发I / O甚至为您排队。 这就是为什么send调用几乎从不阻塞，而recv调用不是连接上的I / O调用，而是线程与专门的I / O任务之间的同步的原因，该任务将处理来自一个或多个连接的传入字节。

但是，我们将在角色中阻塞光纤，而不是线程，因此让我们在read调用上使用FiberAsync.runBlocking ，以防万一它阻塞甚至在send时阻塞： 

final ExecutorService ep = Executors.newFixedThreadPool(2);

try (final ZMQ.Context zmq = ZMQ.context(1 /* IO threads */);
     final ZMQ.Socket trgt = zmq.socket(ZMQ.REQ)) {
    exec(e, () -> trgt.connect("tcp://localhost:8000"));
    final byte[] myBytes = getMyBytes(); // ...
    call(e, trgt.send(myBytes, 0 /* flags */));
    call(e, trgt::recv); // Reply, e.g. ACK
}

这是消费者： 

try (final ZMQ.Context zmq = ZMQ.context(1 /* IO threads */);
     final ZMQ.Socket src = zmq.socket(ZMQ.REP)) {
    exec(e, () -> src.bind("tcp://*:8000"));
    final byte[] v = call(e, src::recv);
    exec(e, () -> src.send("ACK"));
    useMyBytes(v); // ...
}

exec是另一个实用程序函数，类似于call ： 

@Suspendable
public static void exec(ExecutorService es, Runnable r) throws InterruptedException, SuspendExecution {
    try {
        runBlocking(es, (CheckedCallable<Void, Exception>) () -> { r.run(); return null; });
    } catch (final InterruptedException | SuspendExecution e) {
        throw e;
    } catch (final Exception e) {
        throw new RuntimeException(e);
    }
}

这是完整的第一个示例 。

在不改变逻辑的情况下进行分发：与救援人员的松散耦合

很简单，不是吗？ 但是，有一个令人烦恼的事情：我们在网络另一端与演员打交道的方式与本地角色截然不同。 无论他们位于何处或如何连接，这些都是我们愿意写的演员： 

public final class ProducerActor extends BasicActor<Void, Void> {
    private final ActorRef<Msg> target;

    public ProducerActor(ActorRef<Msg> target) {
        this.target = target;
    }

    @Override
    protected final Void doRun() throws InterruptedException, SuspendExecution {
        for (int i = 0; i < MSGS; i++) {
            final Msg m = new Msg(i);
            System.err.println("USER PRODUCER: " + m);
            target.send(m);
        }
        System.err.println("USER PRODUCER: " + EXIT);
        target.send(EXIT);
        return null;
    }
}
public final class ConsumerActor extends BasicActor<Msg, Void> {
    @Override
    protected final Void doRun() throws InterruptedException, SuspendExecution {
        for (;;) {
            final Msg m = receive();
            System.err.println("USER CONSUMER: " + m);
            if (EXIT.equals(m))
                return null;
        }
    }
}

幸运的是，每个演员，无论做什么，都具有相同的非常基本的接口：称为信箱的传入消息队列。 这意味着我们可以在两个通信参与者之间插入任意数量的中间参与者或代理 ，尤其是我们希望有一个发送代理，它将通过中间件将消息获取到目的地主机，并在其中接收接收代理，以捕获传入的消息。并将它们放入目标目的地的邮箱中。

因此，在我们的主程序中，我们将简单地为我们的ProducerActor提供合适的发送代理，并让我们的ConsumerActor从合适的接收代理接收： 

final ProducerActor pa = Actor.newActor(ProducerActor.class, getSendingProxy()); // ...
final ConsumerActor ca = Actor.newActor(ConsumerActor.class);
pa.spawn();
System.err.println("USER PRODUCER started");
subscribeToReceivingProxy(ca.spawn()); // ...
System.err.println("USER CONSUMER started");
pa.join();
System.err.println("USER PRODUCER finished");
ca.join();
System.err.println("USER CONSUMER finished");

让我们看看如何首先使用Kafka然后使用ØMQ来实现这些代理。

卡夫卡男演员代理

代理参与者的工厂将与特定的Kafka主题相关联：这是因为可以对主题进行分区 ，以使多个使用者可以同时读取该主题。 我们希望能够最佳地利用每个主题的最大级别或并发性： 

/* ... */ KafkaProxies implements AutoCloseable {
    /* ... */ KafkaProxies(String bootstrap, String topic) { /* ... */ }

    // ...
}

当然，我们希望对多个参与者使用一个主题，因此发送代理将指定接收者参与者ID，接收代理将仅将消息转发给绑定到该ID的用户参与者： 

/* ... */ <M> ActorRef<M> create(String actorID) { /* ... */ }
/* ... */ void drop(ActorRef ref) throws ExecutionException, InterruptedException { /* ... */ }
/* ... */ <M> void subscribe(ActorRef<? super M> consumer, String actorID) { /* ... */ }
/* ... */ void unsubscribe(ActorRef<?> consumer, String actorID) { /* ... */ }

关闭AutoClosable工厂将通知所有代理终止，并清理簿记参考： 

/* ... */ void close() throws Exception { /* ... */ }

生产者实现是非常简单且无趣的，同时给消费者带来了更多的乐趣，因为它将使用Quasar Actors的选择性接收将传入消息保留在其邮箱中，直到至少有一个订阅的用户actor可以使用它们为止： 

@Override
protected Void doRun() throws InterruptedException, SuspendExecution {
    //noinspection InfiniteLoopStatement
    for (;;) {
    // Try extracting from queue
    final Object msg = tryReceive((Object m) -> {
        if (EXIT.equals(m))
            return EXIT;
        if (m != null) {
            //noinspection unchecked
            final ProxiedMsg rmsg = (ProxiedMsg) m;
            final List<ActorRef> l = subscribers.get(rmsg.actorID);
            if (l != null) {
                boolean sent = false;
                for (final ActorRef r : l) {
                    //noinspection unchecked
                    r.send(rmsg.payload);
                    sent = true;
                }
                if (sent) // Someone was listening, remove from queue
                    return m;
            }
        }
        return null; // No subscribers (leave in queue) or no messages
    });
    // Something from queue
    if (msg != null) {
        if (EXIT.equals(msg)) {
            return null;
        }
        continue; // Go to next cycle -> precedence to queue
    }

    // Try receiving
    //noinspection Convert2Lambda
    final ConsumerRecords<Void, byte[]> records = call(e, () -> consumer.get().poll(100L));
    for (final ConsumerRecord<Void, byte[]> record : records) {
        final byte[] v = record.value();
        try (final ByteArrayInputStream bis = new ByteArrayInputStream(v);
             final ObjectInputStream ois = new ObjectInputStream(bis)) {

            //noinspection unchecked
            final ProxiedMsg rmsg = (ProxiedMsg) ois.readObject();
            final List<ActorRef> l = subscribers.get(rmsg.actorID);
            if (l != null && l.size() > 0) {
                for (final ActorRef r : l) {
                    //noinspection unchecked
                    r.send(rmsg.payload);
                }
            } else {
                ref().send(rmsg); // Enqueue
            }
        } catch (final IOException | ClassNotFoundException e) {
            e.printStackTrace();
            throw new RuntimeException(e);
        }
    }
}

由于我们还需要处理邮箱，因此我们以足够小的超时来轮询Kafka。 还要注意，许多参与者可以订阅相同的ID，传入消息将广播给所有参与者。 每个主题创建的接收actor代理（即光纤）的数量，以及池线程和Kafka使用者句柄（ consumer是本地线程，因为Kafka使用者不是线程安全的）的数量将等于每个主题划分分区：这使接收吞吐量达到最大。

目前，此实现使用Java序列化在字节之间来回转换消息，但是当然可以使用其他框架，例如Kryo 。

ØMQ演员代理

ØMQ模型是完全去中心化的：既没有经纪人，也没有话题，因此我们可以简单地将ØMQ地址/端点与一组参与者等同，而无需使用额外的参与者ID： 

/* ... */ ZeroMQProxies implements AutoCloseable {
    /* ... */ ZeroMQProxies(int ioThreads) { /* ... */ }
    /* ... */ <M> ActorRef<M> to(String trgtZMQAddress) { /* ... */ }
    /* ... */ void drop(String trgtZMQAddress)
    /* ... */ void subscribe(ActorRef<? super M> consumer, String srcZMQEndpoint) { /* ... */ }
    /* ... */ void unsubscribe(ActorRef<?> consumer, String srcZMQEndpoint) { /* ... */ }
    /* ... */ void close() throws Exception { /* ... */ }
}

同样，在这种情况下，并且由于与以前相同的原因，使用方有点有趣，但幸运的是，线程安全性方面的任何问题都因为ØMQ套接字在多个线程中可以正常工作： 

@Override
protected Void doRun() throws InterruptedException, SuspendExecution {
    try(final ZMQ.Socket src = zmq.socket(ZMQ.REP)) {
        System.err.printf("PROXY CONSUMER: binding %s\n", srcZMQEndpoint);
        Util.exec(e, () -> src.bind(srcZMQEndpoint));
        src.setReceiveTimeOut(100);
        //noinspection InfiniteLoopStatement
        for (;;) {
            // Try extracting from queue
            final Object m = tryReceive((Object o) -> {
                if (EXIT.equals(o))
                    return EXIT;
                if (o != null) {
                    //noinspection unchecked
                    final List<ActorRef> l = subscribers.get(srcZMQEndpoint);
                    if (l != null) {
                        boolean sent = false;
                        for (final ActorRef r : l) {
                            //noinspection unchecked
                            r.send(o);
                            sent = true;
                        }
                        if (sent) // Someone was listening, remove from queue
                            return o;
                    }
                }
                return null; // No subscribers (leave in queue) or no messages
            });
            // Something processable is there
            if (m != null) {
                if (EXIT.equals(m)) {
                    return null;
                }
                continue; // Go to next cycle -> precedence to queue
            }

            System.err.println("PROXY CONSUMER: receiving");
            final byte[] msg = Util.call(e, src::recv);
            if (msg != null) {
                System.err.println("PROXY CONSUMER: ACKing");
                Util.exec(e, () -> src.send(ACK));
                final Object o;
                try (final ByteArrayInputStream bis = new ByteArrayInputStream(msg);
                     final ObjectInputStream ois = new ObjectInputStream(bis)) {
                    o = ois.readObject();
                } catch (final IOException | ClassNotFoundException e) {
                    e.printStackTrace();
                    throw new RuntimeException(e);
                }
                System.err.printf("PROXY CONSUMER: distributing '%s' to %d subscribers\n", o, subscribers.size());
                //noinspection unchecked
                for (final ActorRef s : subscribers.getOrDefault(srcZMQEndpoint, (List<ActorRef>) Collections.EMPTY_LIST))
                    //noinspection unchecked
                    s.send(o);
            } else {
                System.err.println("PROXY CONSUMER: receive timeout");
            }
        }
    }
}

更多功能

这篇简短的文章有望使人们一眼就可以看出，由于Quasar的Actor具有顺畅的顺序流程的特性，因此可以无缝地将Quasar的Actor与消息传递解决方案进行交互。 当然，可以更进一步，例如：

  • 演员查找和发现 ：我们如何提供全球演员命名/发现服务？ 例如，Kafka使用ZooKeeper，因此可能值得利用，但是ØMQ大量押注去中心化，并且故意不提供预先打包的基础。
  • Actor故障管理 ：我们如何支持在不同节点中运行的actor之间的故障管理链接和监视？
  • 消息路由 ：如何在不更改参与者内部逻辑的情况下动态调整节点与参与者之间的消息流？
  • 角色移动性 ：我们如何将角色移动到其他节点，例如，使其更靠近消息源，以提高性能或移动到具有不同安全性的位置？
  • 可伸缩性和容错性 ：如何管理参与者节点的添加，删除，死亡和分区？ 像Galaxy这样的分布式IMDG和像Kafka这样的基于代理的解决方案通常已经做到了，但是像ØMQ这样的结构级解决方案通常不这样做。
  • 安全性 ：我们如何支持相关的信息安全性属性？
  • 测试，记录，监视 ：我们如何方便地整体测试，跟踪和监视分布式参与者集合？

这些主题尤其是分布式系统设计（尤其是分布式参与者）的“硬核”，因此要有效地解决它们，可能需要大量的精力。 Galaxy解决了所有这些问题，但是Quasar参与者提供了一个SPI ，涵盖了上述一些主题，并允许与发行技术更紧密地集成。 您可能也对Akka和Quasar + Galaxy之间的比较感兴趣，该比较涵盖了许多此类方面。

就是这样，请与您分布的Quasar演员一起玩乐，并在Quasar-Pulsar用户组中留下有关您的旅程的注释！

  1. 实际上，它也禁止除第一个线程外的任何线程使用。

翻译自: https://www.javacodegeeks.com/2016/05/distributed-quasar-actors-kafka-zeromq.html

kafka分布式

dnc8371
关注
常用MQ消息中间件Kafka、ZeroMQ和RabbitMQ对比及RabbitMQ详解
欧特GO
06-24 1543
了解常用MQ消息中间件Kafka、ZeroMQ和RabbitMQ的基础知识，对三者特性进行对比，选取合适的MQ。着重讲解RabbitMQ详解。
MQ之ZeroMQ、JZMQ、Kafka简介
风吹海洋浪的博客
07-02 1606
MQ之ZeroMQ、JZMQ、Kafka简介MQ消息队列ZeroMQ（又名ØMQ，MQ，或zmq）JZMQZeroMQ简介优缺点SocketTCP/IP协议族简介支持的通信模式 MQ消息队列 参考链接：https://blog.csdn.net/zhoujiyu123/article/details/84843068?utm_medium=distribute.pc_relevant.none-task-blog-2%7Edefault%7EBlogCommendFromMachineLearnPai2%7
RabbitMQ与Kafka
稻草人技术博客
04-03 472
导言 作为一个有丰富经验的微服务系统架构师，经常有人问我，“应该选择RabbitMQ还是Kafka？”。基于某些原因， 许多开发者会把这两种技术当做等价的来看待。的确，在一些案例场景下选择RabbitMQ还是Kafka没什么差别，但是这两种技术在底层实现方面是有许多差异的。 不同的场景需要不同的解决方案，选错一个方案能够严重的影响你对软件的设计，开发和维护的能力。 这篇文章会先介绍一下基本的异步消...
主流MQ [Kafka、RabbitMQ、ZeroMQ、RocketMQ 和 ActiveMQ]
小电玩
12-10 2200
下面是关于主流的 Kafka、RabbitMQ、ZeroMQ、RocketMQ 和 ActiveMQ 的一些介绍：Kafka 是一个分布式流处理平台，设计用于处理高吞吐量的实时数据流。它具有高可靠性、可扩展性和持久性，适用于构建实时数据管道和流式处理应用程序。Kafka 使用发布-订阅模型，消息以主题（topic）的形式进行发布和订阅。RabbitMQ 是一个功能丰富且易于使用的开源消息队列系统，实现了高级消息队列协议（AMQP）。
想了解 Kafka, RabbitMQ, ZeroMQ之间的差异？这一篇文章就够了！
zouduchen的博客
08-16 263
　　单个ActiveMQ的接收和消费消息的速度在1万笔/秒（持久化 一般为1-2万， 非持久化 2 万以上），在生产环境中部署10个Activemq就能达到10万笔/秒以上的性能，部署越多的activemq broker 在MQ上latency也就越低，系统吞吐量也就越高。...
KAFKA分布式消息系统（window）
12-17
**KAFKA分布式消息系统在Windows环境下的搭建与应用** KAFKA是一个高吞吐量的分布式消息系统，由LinkedIn开发并开源，现在是Apache软件基金会的顶级项目。它主要设计用于处理实时流数据，允许应用程序发布和订阅...
分布式_分布式_diagramfs1_源码.zip
10-25
6. **网络通信**：分布式系统中的节点间通信一般基于RPC（远程过程调用）或消息队列（如RabbitMQ、Kafka），实现高效、可靠的数据交换。 7. **一致性哈希**：解决分布式环境中的键值映射问题，使得数据能在节点之间...
最新版kafka kafka_2.13-2.6.0.tgz
08-08
对于初次使用者，安装和配置Kafka 2.13-2.6.0版本，你需要解压“kafka_2.13-2.6.0”压缩包，然后按照官方文档的步骤进行操作，包括设置环境变量、启动Zookeeper、启动Kafka服务、创建主题、发布和消费消息等。...
最新版kafka kafka_2.12-2.5.1.tgz
08-13
- 安装 Kafka 2.5.1，需要解压 `kafka_2.12-2.5.1` 压缩包，配置环境变量，并启动 Zookeeper 和 Kafka 服务。 - 配置文件 `server.properties` 包含了 Kafka 服务器的主要设置，如 broker ID、端口号、日志目录等...
【引领数据流动的未来：深度解析Kafka分布式消息系统】
最新发布
08-23
在数据洪流席卷的今天，Apache Kafka以其卓越的性能、高度的可扩展性和强大的容错机制，傲然屹立于分布式消息系统的巅峰。本资源《Kafka权威指南》，不仅是一本技术手册，更是通往高效数据处理的金钥匙。它不仅仅...
消息中间件kafka与activemq、rabbitmq、zeromq、rocketmq的比较
10-30
消息中间件kafka与activemq、rabbitmq、zeromq、rocketmq的比较
KAFKA ZMQ区别
ucgd_05的博客
11-02 925
KAFKA ZMQ区别
转：Kafka、RabbitMQ、RocketMQ等消息中间件的介绍和对比
PacosonSWJTU的博客
10-13 816
转自：https://blog.csdn.net/yunfeng482/article/details/72856762 前言 在分布式系统中,我们广泛运用消息中间件进行系统间的数据交换,便于异步解耦。现在开源的消息中间件有很多,前段时间产品 RocketMQ (MetaQ的内核) 也顺利开源,得到大家的关注。 概念 MQ简介 MQ,Message queue,消息队列，就是指保存消息的一个容器。具体的定义这里就不类似于数据库、缓存等，用来保存数据的。当然，与数据库、缓存等产品比较，也...
37 | Kafka & ZMQ：自动化交易流水线
qq_37756660的博客
11-27 1419
这节我们分析了现代化软件工程领域中的中间件系统，以及其中的主要应用——消息队列。我们讲解了最基础的消息队列的模式，包括点对点模型、发布者订阅者模型，和一些其他消息队列自己支持的模型。在真实的项目设计中，我们要根据自己的产品需求，来选择使用不同的模型；同时也要在编程实践中，加深对不同技能点的了解，对系统复杂性进行解耦，这才是设计出高质量系统的必经之路。
Kafka、RabbitMQ、RocketMQ 之间的区别是什么 ?
WangYouJin321的博客
01-24 7499
Kafka、RabbitMQ、RocketMQ 之间的区别是什么 ? - 知乎 Kafka和RabbitMQ的区别: RabbitMQ 有这么个特性，它在官方文档就声明了自己是不保证多线程消费同一个队列的消息，一定保证顺序的。而不保证的原因，是因为多线程时，当一个线程消费消息报错的时候，RabbitMQ 会把消费失败的消息再入队，此时就可能出现乱序的情况。 用 RabbitMQ，出现了三个问题： 为了实现发布订阅功能，从而使用的消息复制，会降低性能并耗费更多资源 多个消费者无法严格保证消息顺序
消息队列之六脉神剑：RabbitMQ、Kafka、ActiveMQ 、Redis、 ZeroMQ、Apache Pulsar对比和如何使用
Web3 & Basketball
08-01 9431
消息队列（Message Queue）是一种异步通信机制，它将消息发送者和接收者解耦，从而提高了应用程序的性能、可扩展性和可靠性。在分布式系统中，消息队列经常被用于处理高并发、异步处理、应用解耦等场景。本篇回答将分析比较常见的六种消息队列：RabbitMQ、Kafka、ActiveMQ 、Redis、 ZeroMQ、Apache Pulsar。我们将讨论它们的应用场景、优缺点以及如何使用。
消息中间件(RabbitMQ、RocketMQ、ActiveMQ、Kafka、ZeroMQ等)的定义、组成、特点、优缺点、应用场景&面试题
热门推荐
Allenzyg的博客
08-03 2万+
大家都参与过网上电商平台的秒杀活动吧，一般的秒杀活动辄几百万的参与人数，而“双十一”的参与人数更是已“亿”为计量单位。那么这些电商平台的系统架构是怎样的，它们是如何做到承担每秒几万、几十万的并发访问请求的，所有的请求都是直接落到数据库的吗？当然，数据库不可能承担如此高的负载请求，那这些系统架构引入了哪些“大杀器”呢？这篇文章将讲解其中的关键技术之一消息中间件，并在文章中进一步对消息中间件做详细的讲解。 1. 消息队列 1.1什么是消息队列 消息队列（Message queue，简称MQ），是指利用
ZMQ和kafka、RabbitMQ功能对比
Dark不必
07-16 4275
RabbitMQ是一个AMQP实现，传统的messaging queue系统实现，基于Erlang。老牌MQ产品了。AMQP协议更多用在企业系统内，对数据一致性、稳定性和可靠性要求很高的场景，对性能和吞吐量还在其次。 Kafka是linkedin开源的MQ系统，主要特点是基于Pull的模式来处理消息消费，追求高吞吐量，一开始的目的就是用于日志收集和传输，0.8开始支持复制，不支持事务，适合产生大量...
消息中间件（RocketMQ、RabbitMQ、ActiveMQ、Redis、kafka、ZeroMQ）以及之间的区别
m0_52165864的博客
07-27 1万+
面向消息的系统（消息中间件）是在分布式系统中完成消息的发送和接收的基础软件。消息中间件也可以称消息队列，是指用高效可靠的消息传递机制进行与平台无关的数据交流，并基于数据通信来进行分布式系统的集成。通过提供消息传递和消息队列模型，可以在分布式环境下扩展进程的通信。消息队列已经逐渐成为企业IT系统内部通信的核心手段。它具有低耦合、可靠投递、广播、流量控制、最终一致性等一系列功能；成为异步RPC的主要手段之一。......
Python库atoti_kafka-0.6.2支持Kafka分布式开发
资源摘要信息: 本资源是一个Python库的打包文件，具体名称为“atoti_kafka-0.6.2-0_b94094e-py3-none-any.whl”，它是一个与Kafka消息系统交互的Python库。Kafka是一个分布式的流处理平台，由LinkedIn公司开发，广泛...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值