消息队列教程

比较 Chronicle Queue 和 Apache Kafka 的一个有趣的基准测试，请注意：对于极其重视低延迟应用程序，kafka 可能不是最佳适合工具，Kafka适合高吞吐量和大数据可扩展的应用。Apache Kafka 是服务间通信的常见选择。Kafka便于消息的并行处理，

Apache Kafka、Amazon Kinesis、Microsoft Event Hubs 和 Google Pub/Sub 等分布式日志技术在过去几年中已经成熟，并且在为某些用例移动数据时添加了一些很棒的新型解决方案。据

Netflix 是一种在线视频流媒体服务，以疯狂的规模运行，2.2 亿活跃用户从多个设备访问他们的 Netflix 帐户，因此 Netflix工程师必须确保用户登录的所有不同客户端都是同步的。为所有用户在所有这些设备之间进行同步，需要 Netflix 的后端与所有各种客户端（iOS、

Facebook 有序队列服务 (FOQS)是一种完全托管的分布式优先级队列服务，用于在许多服务之间进行可靠的消息传递。FOQS 已从区域部署发展为地理分布的全球部署，以帮助确保存储在逻辑队列中的数据具有高可用性，即使在大规模灾难情况下也是如此。迁移到全局架构需要对架构进行修

由于效率低下和可扩展性的限制，使用数据库作为队列历来被认为是一种反模式，但另一方面，不将数据分布在多个数据存储上也有巨大的好处。在这篇博文中，我将讨论利弊，探讨人们对现代数据库的预期限制以及哪些优化使这些成为可能。 db-scheduler 是几年前开发的一个简单的 Java

利特尔定律（Little's law）是一个令人震惊的方程式，它非常简单，但它可以为你的分布式系统的能力带来惊人的洞察力。 举例：首先，假设我们去一个杂货店。想象一下，有一个店员，平均在四分钟内处理一个顾客。很明显，他可以提供服务：60分钟除以4-

消息传递模型是用户在选择流式消息传递系统时应该考虑的第一件事。消息传递模型应涵盖以下 3 个方面： 消息消费 - 消息是如何发送和消费的？ 消息确认 - 如何确认消息？ 邮件保

Pulsar 事务 (txn) 使事件流应用程序能够在一个原子操作中消费、处理和生成消息。开发此功能的原因可以总结如下。 随着流处理的兴起，对具有更强处理保障的流处理应用的需求也随之增长。例如，在金融行业，金融机构使用流处理引擎为用户处理借

对于经常性工作（又名 CRON 工作），我个人使用lightspeed_scheduler：

Procrastinate 是一个开源的 Python 3.7+ 分布式任务处理库，利用 PostgreSQL 来存储任务定义、管理锁和调度任务。它可以在同步和异步代码中使用。换句话说，从你的主代码中，你以一种特殊的方式调用特定的函数（任务），而不是在现场运行，它们被安排在现在或将来

Huey是： 一个任务队列（2019-04-01：2.0版本发布） 用 python (2.7+

Bunny REST Proxy 是一个构建在 RabbitMQ 之上的 HTTP 消息代理。它允许服务通过 HTTP 轻松地将消息发布到 RabbitMQ 队列，并使用拉 (HTTP GET) 和推送 (HTTP POST 到订阅者) 交付模式来使用消息。虽然 RabbitMQ 通

在构建任何分布式或非分布式系统时，您最终会处理许多数据ID标识符，从数据库行一直到生产系统版本的ID标识符。决定如何生成标识符有时非常简单；例如，您可能只是将一个自动递增ID的数字作为您的数据库中的主键。 然而，在分布式系统中，让一个数字从

Surve Mobility是一个为共享出行服务提供商提供全方位服务的车队运营，我们从客户那里接收任务，例如充电、清洁、补充耗材等。根据客户和任务，这些任务会在整个过程中一一接收在一天的过程中，在每天的批次中，或者在极少数情况下，在每月的批次中。然后，我们的代理在城市中穿行，步行，乘坐客户车

数据审计是一个跟踪表内容随时间变化的系统。PostgreSQL 具有一组强大的功能，我们可以利用这些功能在 150 行 SQL 中创建通用审计解决方案。 审计对于历史分析特别有用。为了证明这一点，设想你有一个用户表，跟踪用户何时在线。你可以

有一个表存储了所有用户的余额信息。而很大一部分select和更新查询都与一条记录有关（例如，公司账户余额/一个机构用户经常进行交易），因此这些查询需要一个接一个地执行。你能做些什么来提高这些查询的性能？ 以下是回答：利用索引加快每个查询的搜索时间