NetTree

Topic exchange发送到 topic exchange 的消息不能有任意的 routing_key—它必须是一个用点分隔的单词列表。这些单词可以是任何内容，但通常会指定与信息相关的一些特征。 A few valid routing key examples, there can be as many words in the routing key as you like, up to the limit of 255 bytes. stock.usd.nyse、nyse.vyw、quick.orange.rabbit。路由密钥的字数不限，最多 255 字节。 binding key 的形式也必须相同。 topic exchange 背后的逻辑与直接交换类似—使用特定routing key发送的消息将被传送到所有使用匹配binding key 绑定的队列。不过，binding key 有两种重要的特殊情况： * (star) can substitute for exactly one word. # (hash) can substitute for zero o ...

Direct exchangedirect exchange路由算法 -消息会进入binding key 与消息routing key完全匹配的队列。 可以看到Direct exchange X 绑定了两个队列。第一个队列的绑定键为orange，第二个队列有两个绑定键，一个绑定键为black，另一个绑定键为green。 在此情况下，如果发布到交换机的消息routing key 为orange，则会被路由到队列 Q1。routing key 为black或green的消息将进入 Q2，其他消息都将被丢弃 Multiple bindings 用同一个binding key绑定多个队列是完全合法的。在我们的例子中，我们可以用binding key black 在 X 和 Q1 之间添加一个绑定。在这种情况下，direct exchange 将像fanout exchange 一样，向所有匹配队列广播消息，routing key为 black 的消息将同时发送到 Q1 和 Q2。 Emitting logs我们和以往一样继续使用日志Demo，不同的是将fanout换成direct。我们将 t ...

在本篇文章中，我们将向多个消费者中发送一条消息，该模式称为“publish/subscribe”。 我们将搭建简易日志系统，由发布日志信息和接收日志信息功能组成。在我们的日志系统中，接收程序的每个运行副本都会收到消息。这样，我们就能运行一个接收器，并将日志导入磁盘；同时，我们也能运行另一个接收器，并在屏幕上看到日志。发布的日志信息将广播给所有接收器。 ExchangesRabbitMQ 消息传递模型的核心思想是，生产者从不直接向队列发送任何消息。实际上，很多时候，生产者甚至不知道消息是否会被传送到任何队列。 相反，生产者只能将消息发送到 exchange 中，它的一端接收来自生产者的信息，另一端将信息推送到队列。exchange 必须清楚地知道如何处理收到的信息。 There are a few exchange types available: direct, topic, headers and fanout. 我们将使用fanout，并将其命名为logs，它只是将收到的所有消息广播到它知道的所有队列 1channel.exchangeDeclare("logs&qu ...

在本篇中，我们将创建一个 Work Queue，用于在多个 Worker 之间分配耗时的任务。 工作队列背后的主要理念是避免立即执行资源密集型任务而不得不等待其完成。将任务安排在稍后完成。我们将 task 封装为消息，并将其发送到队列。在后台运行的 Worker 进程会弹出任务并最终执行作业。当运行多个 Worker 时，任务将在它们之间共享。 准备工作将对上篇文章示例的Send.java稍作修改，以此允许使用命令行发送任意消息，该程序是将为工作队列安排任务，将其命名为NewTask.java 1234String message = String.join(" ", argv);channel.basicPublish("", "hello", null, message.getBytes());System.out.println(" [x] Sent '" + message + "'"); 对于上篇文章示例的Recv.java也稍做修改，我们令每个dot休眠 ...

基础理论 《分布式系统原理与范型》定义： “分布式系统是若干独立计算机的集合，这些计算机对于用户来说就像单个相关系统” 发展演变 单一应用架构 当网站流量很小时，只需一个应用，将所有功能都部署在一起，以减少部署节点和成本 此时，用于简化增删改查工作量的数据访问框架(ORM)是关键。 适用于小型网站，小型管理系统，将所有功能都部署到一个功能里，简单易用。 缺点： 性能扩展比较难 协同开发问题 不利于升级维护 垂直应用架构 当访问量逐渐增大，单一应用增加机器带来的加速度越来越小，将应用拆成互不相干的几个应用，以提升效率 此时，用于加速前端页面开发的Web框架(MVC)是关键 通过切分业务来实现各个模块独立部署，降低了维护和部署的难度，团队各司其职更易管理，性能扩展也更方便，更有针对性 缺点 公用模块无法重复利用，开发性的浪费 分布式服务架构 当垂直应用越来越多，应用之间交互不可避免，将核心业务抽取出来，作为独立的服务，逐渐形成稳定的服务中心，使前端应用能更快速的响应多变的市场需求 此时，用于提高业务复用及整合的分布式服务框架(RPC)是关键。 流动计算架 ...

消息队列MQ的概念基本介绍 MQ本质是个队列，FIFO 先入先出，只不过队列中存放的内容是 message 而已 是一种跨进程的通信机制，用于上下游传递消息。 在互联网架构中，MQ 是一种常见的上下游“逻辑解耦+物理解耦”的消息通信服务。 使用 MQ 之后，消息发送上游只需要依赖 MQ，不用依赖其他服务。 使用原因 流量削峰 秒杀系统： 在秒杀活动中，大量用户可能会在短时间内涌入系统，导致服务器压力剧增。使用 RabbitMQ 可以将用户的秒杀请求放入队列中，由消费者按照系统处理能力逐一处理，从而避免瞬时高峰对系统的冲击。 用户注册和激活： 在某些促销活动中，用户注册数量可能会暴增，为了避免注册请求直接访问数据库，可以通过 RabbitMQ 将注册请求异步处理，确保系统能够逐步处理用户注册和激活。 电商订单处理： 在促销活动或者特殊时期，订单量可能激增。通过将订单请求放入消息队列，可以让系统按照处理能力逐步处理订单，避免订单处理的高峰时期对数据库和其他服务的冲击。 日志处理： 在大型网站中，日志产生的速度可能非常快。通过使用消息队列，可以异步地处理日志，进行实时或离线的日志分析 ...