我正在研究微服务架构。我的一个服务暴露于用于发布数据的源系统。这个微服务将数据发布到redis。我使用的是redis pub/sub，它被两个微服务进一步消费。
现在，如果另一个微服务关闭，并且无法处理redis发布/订阅的数据，那么当微服务出现时，我必须用发布的数据重试。source无法再次推送数据。由于源代码不能重新发布数据，并且无法进行手动干预，因此我选择了三种方法。
另外使用redis数据进行存储和检索。
在发布之前使用数据库进行存储。我有许多源和目标微服务使用redis pub/sub。现在如果每次使用这种方法，我必须首先在db中插入请求，而不是它的响应状态。现在我不得不使用共享数据库，这种方法本身添加了更多的异常处理案例，在我看来效率不高。
如果redis pub/sub使用kafka，因为流量很低，所以我使用redis pub/sub，无法更改。
在上述两种情况下，我必须使用调度程序，并且我必须在一个持续时间之前重试，否则后续请求将失败。有没有其他办法处理上述案件。
2条答案
按热度按时间0x6upsns1#
一开始，正如你提到的，我们似乎确实只有三种可能性
在这种情况下，您希望在推送和处理之后从服务获得握手。为了实现同样的目标，使用中间件排队系统将是一个不错的选择。
虽然要完成这个任务有点复杂，但是您可以使用kafka来流式处理这个任务。正确配置生产者和消费者组可以帮助您顺利完成工作。
考虑到“这些数据将被处理并持久化”的情况，使用db来存储将是一种过分的做法
但是，或者，将数据存储到redis并在cron作业/计划作业中读取它，会使您的作业更简单。一旦作业成功运行，您可以从缓存中删除数据，从而节省redis内存。
如果您能对体系结构和实现做进一步的评论，我可以继续并相应地更新我的答案。：）
ddarikpa2#