前言 有些小伙伴在工作中可能遇到过这种场景：某天早上起来，监控告警响了——MQ队列里突然积压了100万条消息，整个系统卡顿如蜗牛。 你第一反应是不是“赶紧加机器，扩容消费端”？ 没错，这招能临时救火，

背景 记得有次公司搞促销活动，流量增加，但是系统一直很平稳（我们开发的系统真牛），大家很开心的去聚餐，谈笑风声，气氛融洽，突然电话响起.... 系统架构描述 我们使用rabbitmq主要是为了系统解耦

kafka的使用场景 为什么要使用 Kafka 消息队列？ 解耦、削峰：传统的方式上游发送数据下游需要实时接收，如果上游在某些业务场景：例如上午十点会流量激增至顶峰，那么下游资源可能会扛不住压力。但如

作为一名有着大量微服务系统处理经验的软件架构师，我经常遇到一个不断重复的问题：“我应该使用 RabbitMQ 还是 Kafka？”出于某种原因，许多开发人员认为这些技术是可以互换的。虽然在某些情况下确

在电商、支付等领域，往往会有这样的场景，用户下单后放弃支付了，那这笔订单会在指定的时间段后进行关闭操作，细心的你一定发现了像某宝、某东都有这样的逻辑，而且时间很准确，误差在1s内；那他们是怎么实现的呢

zookeeper是一种为分布式应用所设计的高可用、高性能且一致的开源协调服务，主要可用来实现分布式锁、配置维护、分布式消息队列、分布式通知/协调等。 zookeeper设计了一种全新的数据结构(Zn

上传并解析一个 1w 条数据的 Excel 文件，最后持久化至数据库。 在我的程序中，这个任务耗时大约 6s，对于用户来说，6s 的等待已经是个灾难了。 我们按照这个思路，借助 Celery 进行实现。 Celery 依赖一个消息后端，可选方案有 RabbitMQ, Redis…