进程和线程

进程线程的区别

• 进程是操作系统分配资源的最小单位，线程是操作系统调度的最小单位
• 每个进程有自己独立的上下文和代码，切换开销较大。同一个进程内的所有线程有共有的资源(虚拟内存空间，打开的文件)，但是有自己独立的寄存器和栈(上下文)，线程上下文切换的开销小。因为线程不需要切换完整的虚拟内存空间
• 进程中某个线程崩溃，可能导致整个进程崩溃。进程的子进5程崩溃不影响其他进程
• 系统会为每个进程分配内存，但不会为线程分配。线程可以使用自己所在的进程的资源

为什么要有进程和线程

进程和线程没有合二为一，是因为它们承担不同的职责。进程主要作为资源分配和隔离的单位，拥有独立的地址空间和系统资源；线程主要作为 CPU 调度和执行的单位。同一进程内的多个线程共享进程资源，可以方便地进行并发执行和数据共享，同时不同进程之间又能保持资源隔离。因此将资源管理和执行调度分离，可以兼顾隔离性和并发性能。

线程的调度过程

从一个线程切换到另一个线程的时候，首先保存旧线程的上下文资源，然后线程调度器通过调度算法决定新线程，恢复新线程的上下文，切换到新线程进行执行

进程的五种状态

创建状态，运行状态，结束状态，阻塞状态，就绪状态

上下文指什么

CPU上下文：CPU寄存器和程序计数器 进程上下文：包括虚拟内存，内核堆栈，寄存器等资源 线程上下文：线程状态，栈指针等

进程间通信的办法

管道

在管道中，数据以字节流的形式在内核缓冲区之中传输，主要有匿名管道和命名管道

• 匿名管道：没有名字，通常用于有亲缘关系的进程，生命周期随进程结束
• 命名管道：有文件系统中的名字，可以用于没有关系的进程，生命周期不依赖于创建他的进程 不管是匿名管道还是命名管道，数据都存在内核中，不支持iseek之类的文件定位操作，先进先出

消息队列

相比较于管道无格式的数据流传输，消息队列可以一个消息一个消息传输。需要用户态拷贝到内核态

共享内存

分配一个内存供所有需要的进程访问，不需要陷入内核，需要保护共享资源。这种方式大大提高了进程通信的速度 共享内存本质是两个虚拟内存映射同一块物理内存，这样就可以直接访问而不需要拷贝了

信号量

信号量可以保护共享资源，可以保证资源的互斥性。信号量其实是一个计数器，表示资源个数。信号量可分为二值信号量，计数信号量。有P操作和V操作 P 操作（wait）：信号量大于0则–，否则阻塞等待 V 操作（signal/post）：信号量++，如果有则唤起一个等待者

信号

信号是操作系统提供的一种异步通知机制，用于通知进程发生了某种事件，例如crtl+c

socket

用于网络传输，不同主机中的进程间通信

线程间通信的方法

互斥锁

读写锁

可以同时读，但是只有一个可以写。但是当读锁被占，读操作以及获取读锁操作会被阻塞，防止数据不一致的情况

条件变量

一个线程之间共享的全局变量，一个线程等待条件，另一个线程执行。条件变量总是和互斥锁结合使用

自旋锁

自旋锁在用户态执行，不会主动产生上下文切换(因为不涉及阻塞等待)。会一直检查锁的状态，然后尝试获得锁。CAS把这两个操作合并成一个硬件级原子指令。保证不可分割

信号量

进程调度的算法都有哪些

先来先

字面意思，非抢占式的先来先到，从队列中取出第一个进程执行，直到进程退出或者阻塞，从队列中取出下一个进程 这样调度会导致长任务执行太久，对短任务不公平

最短作业优先调度算法

优先选择运行时间最短的进程来运行，这样对长进程很不利

高响应比优先调度算法

先进行响应级优先比计算，把优先比最高的投入执行

时间片轮转调度算法

给每个进程分一个时间片，允许该进程在这个时间段内运行 如果时间结束这个进程还在运行，那么cpu切换进程执行，如果在时间结束前进程阻塞或结束，cpu立刻切换进程

优先级调度算法

进程的优先级可以分为

• 静态优先级：创建进程的时候就确认了，后面不会修改

• 动态优先级：在进程运行的时候动态进行修改，运行时间长的进程优先级降低，等待时间长的进程优先级升高 进程的优先级一般为-20——19，数字越小，优先级越高。初始创建的时候进程的默认级为0，root权限可以降低数字，其余权限只可以增大数字

• 非抢占式：当就绪队列中出现优先级高的进程，先执行完当前进程，再执行优先级高的进程

• 抢占式：上述情况先执行优先级高的进程，当前进程挂起等待

多级反馈队列调度算法

该算法是时间片轮转算法和优先级调度算法的结合 多级表示有多个队列，优先级从高到低，优先级约高时间片越短 反馈是指如果有新的进程加入优先级高的队伍，先执行优先级高的进程，当前进程挂起等待 收起

Reactor

Reactor是干什么的： Reactor 的核心思想是把 IO 事件和业务处理解耦，通过 IO 多路复用统一监听大量连接。当大量连接处于 IO 等待状态时，并不需要为每个连接创建一个线程，而是由少量线程通过 epoll 等机制等待多个连接的事件，事件就绪后再分发给对应的处理逻辑。这样可以减少大量线程带来的栈空间、线程调度和上下文切换开销，提高高并发连接场景下的资源利用率。 收起

                         浏览器
                           │
                           │ HTTP
                           ↓
                    ┌─────────────┐
                    │    Nginx    │
                    │  80 / 8090  │
                    └──────┬──────┘
                           │
            ┌──────────────┼──────────────┐
            ↓              ↓              ↓
        user-api       event-api      order-api ×3
        :8888          :8890       :8894/:8895/:8896
            │              │              │
            │              │              │
            └──────────────┼──────────────┘
                           │
                        gRPC RPC
                           │
                     ┌─────▼─────┐
                     │   etcd    │
                     │ 服务发现   │
                     └─────┬─────┘
                           │
          ┌────────────────┼────────────────┐
          ↓                ↓                ↓
     event-rpc       inventory-rpc       order-rpc
       ×2                ×2                ×2
          │                │                │
          └────────────────┼────────────────┘
                           │
                MySQL / Redis / RabbitMQ

go-zero

go-zero是一个基于go的微服务开发框架，主要用于快速构建微服务，本项目主要使用了go-zero的api服务和rpc服务.go-zreo可以解决微服务开发中的一些重复问题，比如API定义，RPC通信，配置管理，限流，日志以及服务发现。通过.api生成和.proto生成，可以减删重复手写代码，封装基础设施

外部http请求先到达go-zero的API Gateway，Gateway根据API定义把请求转发给对应的RPC服务，服务之间主要通过gRPC通信

Gin 更偏向 HTTP Web 服务本身，主要解决路由、中间件、HTTP 请求处理这些问题。

Go-Zero 的定位更偏微服务，它除了 HTTP API 之外，还提供 RPC、服务发现、负载均衡、限流、配置管理等微服务相关能力。

etcd

etcd是一个高可用的分布式键值存储系统，在我的项目里面主要做服务发现，使用raft算法来保证数据的强一致性，可以对数据进行监视和更新

通过把rpc项目服务和地址按照key-value写进etcd里面，可以实现调用方通过etcd获取服务实例位置，同时go-zero RPC客户端负责多RPC服务的实例的负载均衡，比如轮询。 etcd会一直向实例发起续约，如果服务实例挂掉，续约失败，etcd将服务从实例中移除，同时通过watch通知客户端让客户端感知

Nginx

做api服务发现，反向代理和负载均衡

• 反向代理：Nginx 的反向代理，就是客户端把请求发给 Nginx，Nginx 再代替客户端把请求转发给后端服务器。

Lua脚本

Lua是脚本性语言

redis对Lua脚本采用单线程串行执行，一个脚本执行期间不会执行其他客户断的命令，保证操作的原子性。但是redis不是事务回滚机制

Sentinel

redis master节点崩溃之后，sentinel发送心跳长时间没回应，主观认为redis下线，半数sentinel认为节点下线，则节点真正下线。sentinel此时发起故障转移，按照slave是否正常，优先级大小和偏移量，id等决定出新master，其他slave修改为slave of新master，客户端可以通过sentinel获取master地址

Q：故障转移后，主从复制丢数据怎么办 Redis Sentinel 本身是异步主从复制，所以确实不能保证主从切换时数据零丢失。如果业务要求库存绝对不能因为故障转移而增加，不能单纯依赖 Sentinel 保证一致性。

一种方案是在故障转移期间暂停抢票，等新的 Master 选举完成后，再通过持久化数据或者 MySQL 的库存基线进行校验和修正，确认库存状态之后再恢复业务。

更严格的方案是把 MySQL 或其他强一致存储作为最终库存事实来源，Redis 只作为高并发扣库存的缓存/临时状态，并通过可靠消息和补偿机制保证最终一致。

如果 Redis 本身作为库存的最终事实来源，那么就需要接受 Sentinel 异步复制存在极端情况下的数据丢失风险，或者使用 Redis Cluster/复制增强等方案降低风险，但普通 Sentinel 本身不能提供强一致保证。

高并发和绝对一致性之间需要做权衡，不能简单地说用了 Sentinel 就能保证库存绝对安全。

30000qps

压测环境是本地 2 核 16G 机器，使用约 1 万个客户端进行并发请求，测试持续 30 秒。测试结果大约达到 3 万 QPS。这里的 3 万是请求吞吐量，不是每秒卖出 3 万张票。因为实际库存只有几十张，所以成功购票数量远小于请求数量。

MQ宕机

首先我没收到 Confirm 不代表消息一定发送失败，因为消息可能已经到达 Broker，只是 Confirm 在网络中丢失了。所以这是一个不确定状态。

订单生成全局唯一的订单号，把订单号作为业务幂等键。Confirm 超时后可以使用相同订单号进行重试，即使 Broker 实际已经收到第一条消息，重试也可能产生重复消息，但消费者侧通过订单号幂等以及 MySQL 唯一约束保证不会创建重复订单。

如果消费者处理失败，则不 ACK，让消息重试；多次失败后进入死信队列，由补偿机制处理。

另外，Redis 扣库存和 MQ 发送之间仍然存在一致性问题，比如 Redis 扣库存成功后 Producer 宕机导致消息根本没发出去。这个单靠 Confirm 解决不了，如果要进一步提高可靠性，可以引入本地消息表 Outbox 或其他可靠消息方案，再配合库存补偿机制保证最终一致。” 收起