分布式

通用的微服务架构应包含哪些组件 相对于单体式架构的简单粗暴，微服务架构将应用打散，形成多个微服务进行独立开发、测试、部署与运维。虽然从管理与逻辑上更符合业务需要，但微服务架构也带来了诸多急需解决的核心

Homebrew Homebrew是Mac系统上的一款非常便利的软件安装工具，可以帮你安装大部分开发工作所需的各种工具软件。这节课中的很多工具，我们也可以使用它来安装。你可以在Homebrew的官网查

随着微服务架构的兴起，越来越多的公司会在实际场景中遇到分布式事务的问题。几个跨进程的应用共同完成一个任务，就更离不开分布式事务的参与。而对于分布式事务而言，2PC、TCC也是经常被提到了，不过在面对长

本地消息表 核心思路是将分布式事务拆分成本地事务进行处理。 在库存服务和订单服务之间引入mq后，此时又引入了新的问题。大概列举如下： 若库存服务完成支付逻辑后，在投递消息到mq中间件的过程中由于网络抖

架构风格 传统单体架构 所有的功能都在同一个线程中 不过传统单体架构的是可以水平伸缩的，这个样子就不在同一个线程中，伸缩架构如图 这个样子所有的压力都来到了数据库层面，根据木桶原理。数据库成为了整个系

1. 分布式系统的定义 分布式系统指的是由一组通过网络进行通信，为了完成共同的任务而协调工作的计算机节点组成的系统。 2. "通过网络进行通信"的隐含语义 网络却是架构分布式系统的根基。网络的复杂性会

分布式系统是计算机程序的集合，这些程序利用跨多个独立计算节点的计算资源来实现共同的目标。分布式系统旨在消除系统的瓶颈或中心故障点。 您将应用构建成一个可部署的单元，尽管运行良好，但规模和复杂性随着时间

> 翻译自 [Martin Fowler](https://martinfowler.com/) 网站 [Microservices](https://martinfowler.com/article

状态一致性 之前讲到检查点又叫作“一致性检查点”，是 Flink 容错机制的核心。接下来我们就对状态一致性的概念进行展开，结合理论和实际应用场景，讨论一下 Flink 流式处理架构中的应对机制。 一致

在实际环境中，经常会出现，因为网络原因，数据有可能会延迟一会才到达Flink实时处理系统。 Flink 中的时间概念类型 在 Flink 的流式处理中，会涉及到时间的不同概念， 如下图所示： 对于流式

流式数据连续不断地到来，无休无止;所以流处理程序也是持续运行的，并没有一个明确的结束退出时间。机器运行程序，996 起来当然比人要容易得多，不过希望“永远运行”也是不切实际的。因为各种硬件软件的原因，

解压并重命名 配置环境变量/etc/profile 修改 broker 的配置文件 $KAFKA_HOME/conf/server.properties。主要关注以下几个配置参数即可： 说明：如果是单

什么是分布式系统 在《分布式系统概念与设计》一书中,对分布式系统做了如下定义: 上面这个简单的定义涵盖了几乎所有有效地部署了网络化计算机的系统。严格地讲,同一个分布式系统中的计算机在空间部署上是可以随

准备工作 准备3台虚拟机 jdk检测 防火墙检测 创建用户 修改主机名和IP的映射关系 上传 上传用工具。 解压 重命名**** 修改环境变量 切换用户到root)并修改配置文件profile 重新编

在当今世界，应用现代化通常意味着迁移到以微服务形式构建的云原生应用。然后使用 Docker 和 Kubernetes 等容器技术进行部署。随着 Netflix 和 Atlassian 完成此部署，其他

12-Factory的作用 12-Factor（twelve-factor）的概念出现很久了，一般叫"12要素"，衡量一个后端服务是否适合搬到云上，描述了云端应用服务应当遵循的一些最佳实践。 12-F

现在有很多大型互联网应用系统，其用户是面向全球的普通大众，用户体量动辄十几亿。这些用户即使只有万分之一同时访问系统，也会产生十几万的并发访问量。 因此，高并发是现在的大型互联网系统必须面对的挑战，当同

Paxos 是用来解决分布式的系统中存在故障（crash fault），但不存在恶意（corrupt）节点的场景（即可能消息丢失或重复，但无错误消息）下如何达成共识。这也是分布式共识领域最为常见的问题

在最终一致性的解决方案中，使用MQ保证各个系统之间的数据一致性。如果使用MQ则面临着消息的可靠性。 要保障MQ消息的可靠性，需要从三个维度解决：生产者100%投递、MQ持久化、消费者100%消费。 R

世界上解决一个计算机问题最简单的方法：“恰好”不需要解决它！—— 沈询 一些可以绕过分布式事务的场景