理解分布式之前，需要理解一个问题就是”事务”。

1. 本地事务

事务提供一种“ 要么什么都不做，要么做全套（All or Nothing）”机制。

Apache Kafka 是一个开源的分布式事件流平台 (Distributed Event Streaming Platform)。

忘掉 “ 消息队列 “ 这个狭隘的标签。虽然它能当消息队列用，但这好比说一台 MacBook Pro 只是个打字机。它的核心是一个分布式的、分区的、可复制的、持久化的提交日志 (Commit Log)。数据被 “ 追加 “ 到日志末尾，并且可以被多个消费者在任意时间点、以任意速度重复读取。

一句话类比: Kafka 就像一个拥有无数个频道的、永不停止的数字电视台。

• 电视台 (Kafka Cluster): 整个服务系统。
• 频道 (Topic): 数据的分类，比如 “ 订单频道 “、” 用户行为频道 “。
• 节目 (Message/Event): 一条条的数据，比如 “ 用户 A 下单 “、” 用户 B 点击了按钮 “。
• 节目制作方 (Producer): 负责制作节目并发送到指定频道。
• 电视观众 (Consumer): 订阅自己感兴趣的频道。
• 电视节目录像机 (Log & Offset): 电视台会把所有节目按顺序录下来（持久化日志）。每个观众都有自己的进度条（Offset），可以从任何时间点开始看、快进、甚至倒带重看（数据回溯），且每个观众的观看进度互不影响。

1. 自旋锁(spin lock)

1.1 背景

同一时刻只能有一个线程获取到锁。那么就面临一个问题，那么没有获取到锁的线程应该怎么办？通常有两种处理方式：

一种是没有获取到锁的线程就一直循环等待判断该资源是否已经释放锁，这种锁叫做自旋锁。

还有一种处理方式就是把自己阻塞起来，等待重新调度请求，这种叫做互斥锁。

1. 基础概念

1.1 内核态和用户态

Linux系统中分为内核态(Kernel model)和用户态(User model)，CPU会在两个model之间切换。

• 内核态代码拥有完全的底层资源控制权限，可以执行任何CPU指令，访问任何内存地址，其占有的处理机是不允许被抢占的。内核态的指令包括：启动I/O，内存清零，修改程序状态字，设置时钟，允许/终止中断和停机。内核态的程序崩溃会导致PC停机。

• 用户态是用户程序能够使用的指令，不能直接访问底层硬件和内存地址。用户态运行的程序必须委托系统调用来访问硬件和内存。用户态的指令包括：控制转移，算数运算，取数指令，访管指令（使用户程序从用户态陷入内核态）。

先抛出知乎的一个问题: https://www.zhihu.com/question/59975081

epoll技术属于IO复用，IO复用属于同步IO，所以epoll属于同步IO，这应该是没毛病的。

现在我用了一个框架，比如twisted，里面的reactor模式的实现是基于epoll或者poll的，在IO的范畴应该是属于同步IO，但是网上几乎所有的文章都说twisted是异步的。

我的问题是，异步与异步IO是不是一个东西？有没有可能异步可以由同步IO(epoll或poll)实现？

如何管理成千上万的访客（用户请求）和内部员工（服务间调用）的流动，确保一切井然有序、安全高效？这就是今天要讨论的这套“交通管理系统”要解决的问题。

1. 微服务拆分

1.1 康威法则

康威定律 (康威法则)：”设计系统的架构会与产生该系统的组织的通讯结构相匹配”。

简而言之，这意味着一个组织在设计软件系统时，系统的架构往往会反映出该组织内部的沟通和协作方式。例如，如果一个组织被划分为多个团队，每个团队负责一个独立的模块，那么最终的软件系统也可能是由多个独立的模块组成。

康威法则的实际意义在于提醒我们，组织结构和沟通方式会直接影响到软件系统的设计和质量。因此，在设计和开发软件时，优化组织结构和沟通方式是非常重要的。

1. 领域模型

RocketMQ 中消息的生命周期主要分为消息生产、消息存储、消息消费这三部分。

1. 探测机制

Kubernetes有以下三种探测容器的机制：

• HTTP GET探针

对容器的IP地址（你指定的端⼜和路径）执⾏ HTTP GET请求。如果探测器收到响应，并且响应状态码不代表错误（换句话说，如果HTTP响应状态码是2xx或3xx），则认为探测成功。如果服务器返回错误响应状态码或者根本没有响应，那么探测就被认为是失败的，容器将被重新启动。

• TCP套接字探针

尝试与容器指定端口建⽴TCP连接。如果连接成功建⽴，则探测成功。否则，容器重新启动。

• Exec探针

在容器内执⾏任意命令，并检查命令的退出状态码。如果状态码是0，则探测成功。所有其他状态码都被认为失败。

Deployment，⽀持声明式地更新应⽤程序。

1. Deployment是⼀种更⾼阶资源，⽤于部署应⽤程序并以声明的⽅式升级应⽤，⽽不是通过ReplicationController或ReplicaSet进⾏部署，它们都被认为是更底层的概念。
2. 当创建⼀个Deployment时，ReplicaSet资源也会随之创建 。
3. 在使⽤ Deployment 时 ， 实 际 的 pod 是 由Deployment 的Replicaset创建和管理的，⽽不是由Deployment直接创建和管理的。