我是织物技术的新手。我读了一些关于基于Kafka的订购服务及其优势的文章。一些文章说，基于Kafka的多订单服务适合容错。现在我只应用3个基于Kafka的订购服务(orderer0、orderer1、orderer2(。然后我使用以下命令停止了2名订购者
docker stop orderer1.example.com
docker stop orderer2.example.com
现在Rest api正常工作。然后我停止了使用的订单0
docker stop orderer0.example.com
现在我的Rest api不工作了。它面临着网络连接问题。然后，我使用以下命令启动了orderer1和orderer2
docker start orderer1.example.com
docker start orderer2.example.com
但是我的Rest api不起作用。。。。。。。。。。。它也面临着同样的网络连接问题。
最后我开始使用订购0
docker start orderer0.example.com
现在网络运行良好。
我的问题是
基于Kafka的订购服务的实际用途是什么。。？？
我们如何实现基于Kafka的订购服务来防止订购者宕机问题。。。？？
结构：1.1.0
作曲：0.19.16
节点：8.11.3
操作系统：Ubuntu 16.04
当我想设置几个订购者时，我遇到了和您一样的问题。为了解决这个问题，我有两个解决方案：
- 我更改了SDK，当前您的SDK尝试联系订购者0，如果失败则返回错误，有必要对此进行更改，以便请求在订购者列表上循环，如果无效则返回错误
- 更简单：在订购者的上游设置一个负载均衡器
回答您的问题。建立基于Kafka的排序服务的优势在于，所提出的块的数据分布在多个服务器上。存在容错，因为如果订购者崩溃并重新连接到kafka集群，它将能够重新同步。性能更好(理论上我没有测试这一点(
根据Kafka订购服务
在Kafka 中，每个通道都映射到一个单独的单个分区主题
这意味着主题中的所有消息都按照发送顺序完全排序。
和
至少，[代理数量]应设置为4。(正如我们将在下面的步骤4中解释的那样，这是显示崩溃容错所需的最小节点数，即有4个代理时，您可以有1个代理关闭，所有通道将继续是可写和可读的，并且可以创建新的通道。(
以上假设Kafka复制因子为3，并且生产客户端将min.insync.replicas理想地设置为2，以确保所有写入都复制到至少两个服务器。
根据您的网络问题，在我看来，您实际上并没有正确配置所有三个代理(需要查看您的整个Docker设置以及Dockerfile实际在做什么(。但是，假设您为这个"RESTneneneba API"配置了所有三个代理，并且有一个带有3个副本的单分区Kafka主题(默认复制为1，主题是用它自动创建的(。因此，我建议您清理所有内容，然后启动三个代理，然后手动创建带有1个分区、3个副本的主题，然后启动Hyperledger。
如果REST API是真正的问题，而不是Kafka连接，那么我猜需要一个负载平衡