- 同步 && 异步

同步异步思想

同步： 目前一些项目的API 就是同步的思想，同步操作是指调用方发起请求后必须等待响应返回才能继续执行后续代码

代码顺序执行，符合人类直觉
线程等待I/O操作
阻塞执行

异步： 异步操作是指调用方发起请求后不等待响应，通过回调、事件或消息等方式在操作完成后获得通知。

基于事件驱动或消息队列
执行线程不会被I/O操作阻塞
非阻塞式执行（Non-blocking）

这里涉及到了一个回调，怎么才算是回调呢？

回调函数（Callback Function）是作为参数传递给其他函数的函数，目的是在特定事件发生时被调用。这是一种**"你完成后通知我"**的编程模式。


// 你定义的通知方式（回调函数）
func myCallback(food string) {
    fmt.Println("【电话响起】您点的", food, "已到门口！")
}

// 美团的外卖API（接收回调的函数）
func placeOrder(menuItem string, callback func(string)) {
    fmt.Println("系统：已接收", menuItem, "订单")
    
    // 骑手去取餐（异步操作）
    go func() {
        time.Sleep(30 * time.Minute) // 模拟送餐时间
        callback(menuItem)           // 餐到后调用你的回调函数
    }()
}

func main() {
    // 下单操作（传递回调函数）
    placeOrder("麻辣香锅", myCallback)
    
    fmt.Println("我可以继续刷手机...") // 不必等待外卖
}

好形象的一个例子！！

Go的goruntine

局限性！

持久化缺口

场景：订单支付处理中突然断电
- goroutine方案：支付状态丢失 → 资金不一致
- 任务队列方案：Redis中保留任务 → 恢复后可继续处理

分布式问题

// 假设有三个服务实例
[Server A] --正在处理Task X--> 崩溃
[Server B] 无法知道X的状态
[Server C] 可能重复处理X

最大的问题就是：

状态同步延迟
缺乏原子操作：多个服务器同时检查/修改同一任务状态时，操作不是不可分割的单元，导致竞态条件（Race Condition）。
心跳检测局限：如果任务在某一个服务间崩溃，想要别人处理必须等待超时时间过去之后才能获取！

在分布式中存在的一些经典的问题！

分布式系统没有"瞬间"：所有状态变更都需要时间传播

网络是不可靠的信使：任何消息都可能延迟或丢失

时间同步是幻觉：不同服务器的时间永远存在微小差异

后续需要跟进的

[todo]

任何可能改变系统状态的业务操作，都必须假定进程随时会崩溃

Contents

同步异步思想

Go的goruntine