微服务故障场景答案

【问题标题】：Microservice failure Scenario微服务故障场景
【发布时间】：2020-08-17 14:56:42
【问题描述】：

我正在研究微服务架构。我的一项服务暴露于用于发布数据的源系统。该微服务将数据发布到 redis。我正在使用 redis 发布/订阅。几个微服务进一步消耗了它。

现在，如果其他微服务关闭并且无法处理来自 redis pub/sub 的数据，那么当微服务启动时，我必须使用已发布的数据重试。源不能再次推送数据。由于源无法重新推送数据且无法手动干预，因此我采用了 3 种方法。

另外使用 redis 数据进行存储和检索。
在发布前使用数据库进行存储。我有许多使用 redis pub/sub 的源和目标微服务。现在，如果我每次都使用这种方法，我必须先将请求插入数据库而不是其响应状态。现在我必须使用共享数据库，这种方法本身会增加几个异常处理案例，对我来说效率不高。
如果 redis pub/sub 使用 kafka 就地。由于流量很低，所以我使用了 Redis pub/sub，并且无法更改。

在上述两种情况下，我都必须使用调度程序，并且我有一个持续时间，在此之前我必须重试，否则后续请求将失败。有没有其他方法可以处理上述情况。

【问题讨论】：

在您的第二种方法中，您似乎正在尝试实现消息代理。如果我正确理解了您的要求，那么 rabbitmq 对您来说将是简单且足够好的，因为您说流量很低。

标签： spring-boot java-8 redis architecture microservices

【解决方案1】：

 For the point 2, 
 - Store the data in DB. 
 - Create a daemon process which will process the data from the table.
 - This Daemon process can be configured well as per our needs.
 - Daemon process will poll the DB and publish the data, if any. Also, it will delete the data once published.

Not in micro service architecture, But I have seen this approach working efficiently while communicating 3rd party services.

【讨论】：

我有许多使用 redis pub/sub 的源和目标微服务。现在，如果我每次都必须先在数据库中插入请求而不是更新其响应状态时使用这种方法。我必须使用共享数据库。
是的...我知道这将是更多的开发工作。但一旦准备好，你会喜欢的。

【解决方案2】：

一开始，正如你所说，我们确实似乎只有三种可能性

这是您希望在推送和处理后与服务握手的情况之一。为了实现同样的目的，使用中间件排队系统将是一个正确的选择。

虽然完成起来有点复杂，但您可以使用 Kafka 进行流式传输。正确配置生产者和消费者组可以帮助您顺利完成工作。

考虑到“这些数据将被处理并被持久化”的情况，使用数据库来存储将是一种矫枉过正

但是，或者，将数据存储到 Redis 并在 cron-job/scheduled 作业中读取它会使您的工作更加简单。作业成功运行后，您可以从缓存中删除数据，从而节省 Redis 内存。

如果您可以进一步评论架构和实现，我可以继续并相应地更新我的答案。 :)

【讨论】：