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

1. 本地事务

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

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. API Gateway

1.1 定义

API 网关作为一个系统访问的切面，对外提供统一的入口供客户端访问，隐藏系统架构实现的细节，让微服务使用更为友好；并集成了一些通用特性，避免每个微服务单独开发，提升效率，使系统更加标准化。

比如鉴权、限流、熔断、监控、负载均衡、限流、降级与应用检测等功能。

如果没有 API 网关，流量的出入口则不统一，客户端就需要知道所有服务的访问信息，微服务的意义将不复存在。

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直接创建和管理的。

1. Service 基础

⽔平伸缩意味着多个pod可能会提供相同的服务——每个pod都有⾃⼰的IP地址，客户端⽆须关⼼后端提供服务pod的数量，以及各⾃对应的IP地址。它们⽆须记录每个pod的IP地址。相反，所有的pod可以通过⼀个单⼀的IP地址进⾏访问。为了解决上述问题，Kubernetes提供了⼀种资源类型——服务（service）