体系结构是这样的,有几个应用程序访问一组关系数据库。但是有些应用程序需要大量的连接,这会增加查询时间。为了解决这个问题,我们制作了关系数据库的elasticsearch副本。但是,即使是从数据库中对es中的数据进行实时索引也需要很多时间。这就是kafka的由来,我们引入了一个kafka管道,将应用程序直接连接到es。es的logstash是消费者,而应用程序是kafka的生产者。除了更新数据库的正常流之外,这种体系结构是一个好主意吗(因此,如果es索引崩溃或es集群以任何方式丢失数据,我们都可以从数据库中更新回来)?
1条答案
按热度按时间vi4fp9gy1#
这是个好主意,是的,因为你提到你自己的原因。事实上,我也有一个设置,文档通过Kafka输入es,真的无法想象回到我介绍Kafka之前的设置。
如果你需要对Kafka的消费过程进行更精细的控制,请看这里。这是最近的一个项目,不幸的是,在我实现了自己的低级使用者之后,它变得可用了:)