时间APITSCTSC（Time Stamp Counter，时间戳计数器）是现代 CPU 中一个非常底层的硬件计数器，用来记录自 CPU 上电以来经过的时钟周期数。TSC 本质上是一个 64 位寄存器，通常位于 CPU 内部，每当 CPU 时钟周期推进一次，它的值就 +1（在现代 CPU 中已经不完全等价于“每个核心周期”，但概念上仍是“高精度单调计数器”）。在 x86 架构中，可以通过指令读取：RDTSC（Read Time Stamp Counter）TSC 常用于性能分析，因为它的分辨率非常高（纳秒级甚至更细）。操作系统、数据库（比如 MySQL InnoDB）、高性能网络系统都会用 TSC 做：函数耗时统计lock contention 分析cache miss 成本分析TSC ≠ wall clock timevDSO优化vDSI是linux提供的一种机制，把一部分内核提供的只读系统调用映射到用户态的空间里，让用户态直接调用，而不需要陷入内核。vDSO = “内核提前帮你准备好的用户态函数库（但数据由内核更新）”典型函数包括：gettimeofdayclock_gettimetime传统路径：用户态函数调用 → syscall 指令 → CPU 切换到内核态 → 内核处理 → 返回用户态问题在于：syscall 有 上下文切换成本需要保存/恢复寄存器可能污染 CPU cache / pipeline高频时间查询会非常昂贵比如：一个高性能服务每秒可能调用 clock_gettime 上千万次具体方式：内核在进程地址空间映射一段“只读共享代码”用户态直接调用这些函数不发生 syscall数据仍由内核更新（比如时间）Linux CLOCK_MONOTONICCLOCK_MONOTONIC是Linux 提供的一种单调递增时钟，用于测量时间间隔，而不是表示当前真实时间。他的关键特性是：时间只会向前走不会因为系统时间被修改而改变。类型含义是否受系统时间影响CLOCK_REALTIME真实世界时间（Unix time）会（NTP、手动修改会跳变）CLOCK_MONOTONIC单调时间（从某个起点开始计时）不会CLOCK_MONOTONIC 的起点是：系统启动（boot）之后的某个未定义时间点注意：不等于 Unix epoch（1970）不可预测只保证单调递增他不能跨机器比较。也不能转换成unix时间戳。它不是时间而是时间差工具。
那些底层使用了Rocksdb的项目元数据使用了RocksDB的框架kafka：的streams默认将持久化状态的中间计算结果Pulsar的底层存储，也就是Bookkeeper：的默认存储实现中，Rocksdb用来维护Ledger元数据索引rocketmq：RocketMQ 在 broker 端通过 RocksDB 来保存 消费偏移量、订阅组管理/配置、认证授权数据等元数据Ceph：使用Rocksdb来管理对象映射和磁盘分配记录。Doris在后端BE存储中使用了rocksdb保存元数据的键值对。主要状态数据使用RocksDBMySQL/MariaDB中存在innodb的另一个存储引擎选择，MyRocks，底层使用了rocksdb作为存储引擎。顺序批量写入性能更高，但是查询延迟稍高。Kvrocks，pikiwidb，Tendis他们都兼容Redis协议，并且底层使用rocksdb作为主要的持久化协议存储。tidb：底层使用的tikv的内部使用了rocksdb作为存储实现。Flink：Checkpoint可以选择，通过使用rocksdb存储到本机。ClickHouse 提供了一个叫 EmbeddedRocksDB 的表引擎，可以让用户把一个表的数据存放在一个 RocksDB 实例中，并通过 ClickHouse SQL 访问它。Nacos等这些底层依赖sofa-jraft的框架底层都采用rocksdb作为存储，不过也允许切换为其他存储实现。MongoDB提供了rocksdb存储引擎插件，优化高写入场景
LLM的有趣技术https://www.bilibili.com/video/BV1gEcmzzE4P/语言模型的进化多模态大语言模型是如何将所有的感官，对齐到语言系统中的？这本质上属于多模态对齐（multimodal alignment）与表征学习（representation learning）的交叉问题。可以从结构层面+训练机制+对齐目标三个维度来精确理解。人类的感官数据在原始形态上完全是异构的，所以核心问题变成，如何把连续的信号映射到一恶搞可以被语言模型理解的符号空间。现代多模态大模型（如 GPT-4o、Gemini、Claude 等）通常采用如下结构：不同模态编码器 → 统一 embedding 空间 → LLM（语言核心）每种感官都有专属编码器，比如图像的Vit，音频的wav2vec，视频的时空tranformer，文本的token embedding。这些编码器的目标都是抓成一个高维语义向量。那么如何对其到共享语义空间？对比学习对比学习：Contrastive learning 代表作为CLIP。训练目标：图像embedding=描述该图像的文本。即最大化：正样本（匹配图文）的相似度负样本（不匹配）的距离结果图像和语言落在同一个语义空间中跨模态生成Generative Alignment图像 → 文本（captioning）音频 → 文本（ASR）视频 → 文本（描述）训练方式输入：图像 embedding目标：生成对应文本 token让 LLM 学会“用语言解释感官”联合训练直接训练一个模型处理：[图像 tokens] + [文本 tokens] → 预测下一个 token把非语言模态“token化”（tokenization of modalities）语义一致性最终目标不是“数据形式一致”，而是：不同模态表达相同“意义”时，其内部表示接近一张猫的图片“a cat sitting on a sofa”在 embedding 空间中应接近为什么语言成为“中心模态”？语言有几个决定性优势可以表达复杂结构：时间因果抽象概念标注成本最低：图像/音频的语义通常通过语言标注获得LLM 的核心能力：chain-of-thoughtplanningabstraction都发生在语言空间。语言不是被对齐的对象，而是“语义坐标系”所有感官数据都被投影到这个坐标系中。换句话说：图像 ≠ 变成文字图像 → 映射到“可以用语言解释的语义空间”思维连chain-of+thought。本质是让模型在给出最终答案之前，显式或隐式的生成中间推理步骤，从而提升复杂任务的正确率。传统语言模型直接输出答案，COT是在输出和最终答案中增加了思考步骤。模型被引导像人一样一步步想。可以将一个复杂的问题，拆成多个简单的子问题。在训练或推理是。没有CoT只有最终loss，有CoT：每一步都有结构化的模式。本质上相当于在token级别上引入推理轨迹约束。CoT 提示过程是一种最近开发的提示方法，它鼓励大语言模型解释其推理过程。思维链的主要思想是通过向大语言模型展示一些少量的 exapmles，在样例中解释推理过程，大语言模型在回答提示时也会显示推理过程。这种推理的解释往往会引导出更准确的结果。零样本思维链（Zero Shot Chain of Thought，Zero-shot-CoT）提示过程是对 CoT prompting 的后续研究，引入了一种非常简单的零样本提示。他们发现，通过在问题的结尾附加“Let's think step by step”这几个词，大语言模型能够生成一个回答问题的思维链。从这个思维链中，他们能够提取更准确的答案。外部工具ReAct 和 Toolformer 是两种典型的“让模型使用工具/外部能力”的方法论，但它们的设计哲学和实现路径差异很大ReActReAct = 推理（Reasoning）+ 行动（Acting）交替进行模型在推理过程中，不只是“想”，还会：显式生成思考链（Thought）决定调用工具（Action）接收工具返回结果（Observation）再继续推理本质：把推理过程外显，并嵌入工具调用显式推理链（Chain-of-Thought）类似 CoT，但更进一步推理过程中可以“打断去查资料”动态工具调用工具使用是 runtime 决策不需要提前训练工具调用能力强交互性适合：多步推理（multi-hop QA）agent系统复杂决策任务ToolformerToolformer = 让模型自己学会什么时候调用工具和 ReAct 最大区别：ReAct：靠 prompt 引导Toolformer：靠训练学出来Toolformer 做了三件关键事：自监督生成工具调用数据给模型少量 seed examples，然后：模型自动：在文本中插入 API 调用（如 calculator, search）比较调用前后 loss如果调用让预测更好 → 保留自动构造训练数据！训练模型用这些数据 finetune，让模型学会：何时调用工具如何调用如何利用返回结果推理时自动调用最终模型：不需要 ReAct prompt自然生成类似：The result is [Calculator(23*45)] = 1035支持的工具类型（原论文）CalculatorSearch APITranslationQA systems既然有眼镜，草稿纸，计算器等工具了。LLM很像一个活生生的人。因此可以说小龙虾的火爆是必然的。scaling law1980s网页的增长速度鳗鱼存储系统的增长速度。我们有朝一日可以存下互联网上所有的数据。所以我们有了google。因此google的出现是必然的。人类的智能不过是算力而已。象棋中，机器每多搜一层胜率就会提高一点。每一条曲线都是一个颜色固定一个算力。随着算力的增加，就需要越来越多的数据来喂饱它。纵轴是next token的lossopenai在训练150b模型的时候，没人知道openai是否能成功，当时openai只是做了小规模的验证。一切都是历史的必然：Transformer在长上下文的能力上比LSTM的能力要好很多。所以Transformer活下来了。但是没有人知道是否存在一个模型能够用更少的参数训练出更号好模型的结构。The bitter lesson中提到心智的实际内容是极其复杂且无法简化的；我们应当停止试图寻找思考心智内容的简单方式，例如思考空间、物体、多重主体或对称性的简单方法。所有这些都是任意的、本质上复杂的外部世界的一部分。它们不应该是内建（预设）的，因为它们的复杂性是无穷无尽的；相反，我们应该只内建那些能够发现并捕捉这种任意复杂性的元方法。使用AI大模型是Transformer，prompt 工程实际上是attention工程（这就是为什么GPT刚出来的时候会有非常长的提示词。）没有合适的提示词LLM会倾向于车轱辘话（一部分是因为instruct fine-tuning/ RLHF）提示词应该分解问题。也就是要构建一个合适的抽象。如何让大语言模型更好的工作，在如今就是如何让大语言模型更接近人类的工作方式。
Epoch-Based Reclamation算法https://www.zhihu.com/question/406428296/answer/1345620324概述EBR是在无锁或低锁并发结构中常用的聂村回收机制。核心目标是解决并发环境中内存安全释放的问题。在并发数据结构中，删除节点不等于可以立即释放内存。比如在删除的时候，其他线程可能仍然持有指针，但删除线程无法知道。常见的类似方案RCU：read-copy-update。写操作不直接修改正在被读取的对象，而是创建新的副本。类似COW引用计数，开销稍大。Hazard Pointers：精确但复杂EBR的思想是：延迟释放核心Bw-Tree（B-link Tree without latches）是一种无锁的并发B+树变体。目标是实现高并发环境下实现高吞吐的索引结构。避免传统B+树锁竞争的问题。Bw-Tree主要针对内存数据库和无锁结构。每个操作在开始的时候注册到一个Epoch，可以根据物理时间，每10ms作为一个epoch操作开始时增加Epoch counter，操作结束时减少Epoch counter操作过程中，产生的垃圾都放到epoch内部的garbage list上当这个epoch的所有操作都结束了，即counter为0时，这个epoch的所有资源都可以被释放用上图举例，这是BwTree的内存垃圾回收。众所周知BwTree是一个latch-free的高性能索引，既然要latch-free那么内存分配一定不能拖后腿了。在对索引进行操作时，例如删除索引的一条数据，并不能直接释放内存，否则无锁算法很容易出现ABA问题。所以在操作过程中产生的垃圾，都放到epoch的garbage list上，当所有线程都退出这个epoch就可以安全地释放掉所有资源。（事实上，上面这个图还是Centralized，Open-BwTree里用了扩展性更好的Decentrailzed实现）EBR算法的回收是机会式回收。是许多lock-free数据结构的默认实现方式。相比RC相比RC（reference counting）引用计数法，EBR有更好的缓存局部性。引用计数每次操作都要原子写入。这会导致cpu的缓存行竞争严重。多次出发缓存行失效是严重的性能问题。EBR 也不是完美的。一个线程的sllep会导致全局epoch无法推荐。导致重试列表无限增长。内存回收也可能会不及时导致内存占用更高。特性Reference CountingEpoch Reclamation读开销高（atomic inc）极低写开销atomic dec低cache contention严重很小回收方式即时延迟内存占用低可能较高线程停顿影响无有扩展性差好EBR 的效率来自：消除 per-access 原子操作，把回收同步从“每次访问”降低到“偶尔 epoch 推进”。
MQTT学习笔记简介写给那些已经学习过消息队列的人（）或者间接连接。比如移动网络，卫星网络等。协议非常轻量header只有2字节。MQTT只有一种通信模型Publisher → Broker → Subscriber例如temperature/sensor1 temperature/sensor2设备只关心topic，topic是层级字符串，支持通配符订阅。如temperature/+ temperature/#不同于消息队列mqtt有统一的开源标准化协议。由OASIS 维护。通信模式MQTT支持多种模式如点对点：每个消息只消费一次Producer → Queue → Consumer发布订阅：每个订阅者都收到消息。流处理MQTT的Qos从高到低依次为Qos 0：至多依次（at most once1）发布者发送消息后不等确认，直接发送下一条消息。代理收到消息后直接转发给订阅者，同样不等待订阅者确认。Qos 1：至少一次（at least once）这是中等级别，确保消息至少被送达一次，但可能重复。发布者发送消息后，会等待代理返回一个 PUBACK（发布确认）包。如果超时未收到确认，发布者会重新发送消息，直到收到确认为止。代理收到消息后，会存储消息，并确保将其发送给订阅者（同样需要订阅者的确认）。消息不会丢失知道重试成功。Qos 2：恰好一次（exaclly once）最高的级别。确保消息仅有一次被送达。这个机制通过四次握手实现（four way handshake）PUBLISH：发布者发送消息。PUBREC：代理收到后回复“已接收”。PUBREL：发布者收到确认后，发送“释放”信号。PUBCOMP：代理回复“完成”，此时双方才确认消息处理完毕。Qos机制只是传输层的机制，只负责消息物理上从生产者到消费者，但无法感知消费者应用层代码是否执行成功。PUBREC/PUBCOMP 由 MQTT client library 自动发送。而不是等你业务处理完成后再发。MQTT没有类似消息队列中的DLQ（死信队列）的实现。MQTT语义是传递保证，而不是处理保证。因此broker不会感知业务是否处理成功。QoS2保证的是“协议层 exactly-once”，不是“业务 exactly-once”。这里的ack和kafka不同的是收到消息就ack，而不是完成处理才ack。MQTT 本身只是一个消息传输协议，是否把消息保存到磁盘、保存多久、是否清理，取决于具体的 MQTT Broker 实现和配置。不同 Broker（如 Eclipse Mosquitto、EMQX、HiveMQ）策略会不同。可以从几个机制来理解。如果要保证消费成功可以通过应用层ackProducer → MQTT → Consumer ↓ 处理成功 ↓ publish ack message例如topic: order/create topic: order/create/ack和消息队列的区别mqtt 出现的更早，是1999年的，kafka是2011年。并且一般kafka的生产者都是内网的机器有单独的稳定的IP。而mqtt生产者可能只有NAT的IP，并且无法固定。以EMQX距离，吞吐量能来到50w到100w。kafka在100w-1000w。由于许多应用层消费逻辑都只适配了kafka的。你甚至可以把MQTT消息桥接到kafkaIoT Device / Client │ ▼ MQTT Broker (EMQX / HiveMQ / Mosquitto) │ │ MQTT → Kafka Bridge / Connector ▼ Kafka Cluster │ ├── Stream processing (Kafka Streams / Flink / Spark) ├── Storage (Data lake / DB) └── MicroservicesMQTT为极低带宽+不稳定网络设计。最初为IOT、传感器网络设计。适用于设别算力弱。网络延迟高的场景。MQTT协议甚至不强制要求持久化。直接进行实时转发。MQTT的设计重点通常不是吞吐，而是轻量级通信。如EMQX默认所有数据都存储在内存中。通过规则引擎（Rule Engine）和数据桥接（Data Bridge），可以将消息、客户端上下线事件等数据持久化到外部数据库（如 MySQL、PostgreSQL、Redis、MongoDB 等）。这种方式通常用于业务数据归档或与外部系统集成。总的来说MQTT是无状态的。MQTT的顺序消费还要结合Qos来保证。无论是Qos1还是2都不保证严格顺序。这个顺序更像是TCP的顺序，业务层要自己控制执行顺序（毕竟ack是自动回复的，而不是业务层实现的）。
虚拟线程和协程平台线程在Java25中对虚拟线程做了非常多的优化。那么到底虚拟线程解决了什么问题呢？哪些场景下能用到呢？和GO语言的go routine有什么区别呢？我们从小学二年级就学过，在JDK21之前Java中只有平台线程。所谓平台线程就是将线程所有的调度权交给操作系统进行处理。操作系统会有时间片轮转，多级队列等机制来决定当前让哪个线程执行，这让写程序的人觉得操作系统的线程资源几乎是无限的。问题就出在了这里，操作系统的调度是有代价的，操作系统内核直接调度，导致线程切换都需要进入内核态，这涉及了完整的上下文的切换，系统需要保存和恢复寄存器，恢复上下文，进行调度决策，这部分的开销较大。当我们创建的线程数远大于实际上操作系统逻辑核心数时，操作系统为了这些线程更公平的调度就需要频繁的挂起和恢复线程，确保每个任务都能向前推进。线代的操作系统使用的都是抢占式调度，操作系统可以通过中断的方式抢占当前的CPU并进行上下文切换’这种切换是强制的称为抢占式多任务处理模式。我们这里以一个tomcat服务器为例，如果CPU有10个核心，那么这台机器如果只能同时处理10个http请求，这显然是不能接受的。但我们发现，这个http请求其实大部分的时间，并不是在使用CPU做计算，这个HTTP请求在处理过程中可能需要调用第三方的服务接口，或者是查询数据库，redis缓存等操作。在执行这些操作的时候，我们自然希望让操作系统能够挂起这些线程切换到其他线程来执行。当然同时处理过多的线程还是会出现上面提到的CPU资源被抢光，因此tomcat设置了一个默认值，也就是200作为线程池的大小。也就是说最多同时调度处理200个请求。当然具体的参数应该按照负载的类型和CPU的型号进行修改，比如CPU如果配置好，或者当前服务只是单纯的一个请求转发服务的话我们就可以将这个参数调的更高。是不是听起来非常的熟悉，没错，这就是我们经常背的八股文IO密集型和CPU密集型线程池的资源设置逻辑。虚拟线程-协作式调度所谓IO密集型的潜在含义是，这个服务不太用CPU，经常可以把CPU出让给其他线程使用。如果线程池中线程数设置的太多了，容易导致操作系统频繁的挂起程序导致性能下降，但设置的太少了也会导致在线程数被打满的情况下，处理器依旧没有满负荷运行导致性能浪费。那有没有什么方式可以解决这个问题呢？有的兄弟有的，那就是Java的虚拟线程。虚拟线程采用的解决方式十分的简单。既然操作系统的调度那么浪费时间，我把这个调度放到用户态不就好了？JVM可以自己调度线程。在Java中对虚拟线程采用的调度方式叫做协作式调度。协作式调度是当一个程序出现挂起或者阻塞，比如sleep函数时，那么当前的CPU资源就会默认被分配给另一个需要执行的线程。在这段java代码中，程序中创建了比当系统可支配调度的线程数多一个的线程。这种情况下，多的那一个线程仍然可以被运行。比如运行如下代码时，程序能够成功的输出这里的New virtual threadimport java.util.ArrayList; import java.util.List; public class Main { public static void main(String[] args) throws InterruptedException { int busyThreads = Runtime.getRuntime().availableProcessors(); int newThreadIndex = 0; List<Thread> threads = new ArrayList<>(); // 创建并启动"死循环虚拟线程" for (int i = 0; i < busyThreads; i++) { int id = i; Thread virtualThread = Thread.ofVirtual() .name("busy-virtual-thread-" + id) .start(() -> { System.out.println("Busy virtual thread " + id + " started"); while (true) { try { Thread.sleep(1); } catch (InterruptedException e) { throw new RuntimeException(e); } } }); threads.add(virtualThread); } // 等待一会儿，让死循环线程占满平台线程 Thread.sleep(1000); // 创建并启动一个新虚拟线程尝试执行 Thread newVirtualThread = Thread.ofVirtual() .name("new-virtual-thread-" + newThreadIndex) .start(() -> { System.out.println("New virtual thread " + newThreadIndex + " started"); }); threads.add(newVirtualThread); // 等待一会儿查看结果 Thread.sleep(10000); } }因为其他线程的循环中的sleep函数将会使其他虚拟线程将当前执行权让给这个新来的线程。但是如果我们稍微改一下代码把Sleep删掉，重新运行这段代码import java.util.ArrayList; import java.util.List; public class Main { public static void main(String[] args) throws InterruptedException { int busyThreads = Runtime.getRuntime().availableProcessors(); int newThreadIndex = 0; List<Thread> threads = new ArrayList<>(); // 创建并启动"死循环虚拟线程" for (int i = 0; i < busyThreads; i++) { int id = i; Thread virtualThread = Thread.ofVirtual() .name("busy-virtual-thread-" + id) .start(() -> { System.out.println("Busy virtual thread " + id + " started"); while (true) { // 纯 CPU 循环，不阻塞 } }); threads.add(virtualThread); } // 等待一会儿，让死循环线程占满平台线程 Thread.sleep(1000); // 创建并启动一个新虚拟线程尝试执行 Thread newVirtualThread = Thread.ofVirtual() .name("new-virtual-thread-" + newThreadIndex) .start(() -> { System.out.println("New virtual thread " + newThreadIndex + " started"); }); threads.add(newVirtualThread); // 等待一会儿查看结果 Thread.sleep(10000); } }我们会发现new virtual thread这段永远不会输出。无论是在JDK21还是25都是如此。这就是协作式调度，相互之间需要商量什么时候能把资源给其他线程。这种调度模式的，好处就是不需要让jvm定期中断操作，因为这会产生一定的性能开销。坏处就是如果你有11个完全不休息的任务也就是11个线程，要运行在一个10线程的CPU上，其中一个任务就会持续无法被调度运行。go混合调度go中的虚拟线程我们通常叫做go routine ，它选择了不一样的套路。我们都知道go的线程调度模型是基于GMP模型。相同的，GO也是把调度带到了用户态程序中。我们通常把Goroutine称作协程，主要这里的协就是协作的协。早期的go选择的是和现在java相似的纯协作式调度也就是说，在go1.13及之前如果你运行如下代码package main import ( "fmt" "runtime" "time" ) func main() { // 获取 CPU 核心数 numCPU := runtime.NumCPU() fmt.Println("Number of CPUs:", numCPU) busyGoroutines := numCPU + 1 // 创建比 CPU 多的 goroutine fmt.Println("Starting", busyGoroutines, "busy goroutines") // 启动大量 CPU-bound goroutine for i := 0; i < busyGoroutines; i++ { id := i go func() { fmt.Printf("Busy goroutine %d started\n", id) for { // 纯 CPU 循环 } }() } // 等待一秒，让 busy goroutine 占满 CPU time.Sleep(time.Second) // 再启动一个新 goroutine newGoroutineIndex := 0 go func() { fmt.Printf("New goroutine %d started\n", newGoroutineIndex) time.Sleep(10 * time.Second) }() fmt.Println("Submitted new goroutine, waiting 5 seconds...") time.Sleep(5 * time.Second) fmt.Println("Main function exits") }最终的会和java一样，无法输出New Goroutine，甚至会直接卡死。但是在1.14及以后版本，运行相同的代码时，New Goroutine又能够成功的输出了。go语言，很神奇吧。这是因为在后续的版本中Go语言采用了协作式加抢占式调度。如果一个goroutine在同一个逻辑处理器上连续运行10毫秒，就会被标记为可抢占。也就是说，在go中高版本有俩种可能性导致协程切换，一个是协程阻塞或者挂起，另一个是运行太久会被其他协程抢占。总结一下，我们不难得出虚拟线程的主要好处是创建和销毁线程的开销非常小，而且都是用户态的操作。因此大多数情况下，不需要和平台线程一样对虚拟线程进行池化。因此我们也不需要担心具体的线程池参数配置，这在以往，通常要根据业务属性和压测结果来进行设置。虚拟线程的切换开销也是用户态的操作，相对于系统级别的陷入才能进行的线程切换，虚拟线程在频繁需要切换线程的情况下性能会更好。在知道了这些原理后如果你觉得线程调度太麻烦，想程序员每次执行的代码都占用一个线程，所有异步操作都默认在一个线程上调度那么你就实现了python的，GIL锁。如果你想通过异步事件驱动来避免操作系统的频繁上下文切换，那你就实现了springcloud getway中的webflux。
有趣的开源项目记录分类整理1. 开发与编程工具Go-blueprint - 命令行交互式创建和初始化Go项目，支持网页端选择Pake - 用Rust开发的工具，可将网页打包成macOS、Windows、Linux支持的桌面客户端应用，封装体积比Electron小20倍manim - 3Blue1Brown作者开发的强大数学动画引擎，专为数学和科学可视化设计，推荐使用社区版manimCEDeepface - 轻量级Python人脸识别工具，支持年龄、性别、情绪、种族识别，准确率超过人类RealtimeSTT - 开源实时语音转文本库，采用流式处理技术，延迟极低，支持模型量化Amphion - 开源音频、音乐和语音生成工具包，支持TTS、SVC、TTA、VC等功能Skyvern - 基于视觉理解的网页自动化工具，摆脱传统DOM依赖，采用多智能体协作架构index-tts2 - 文本转语音工具2. 数据库与数据处理Teable - 现代化的无代码数据库与数据协作平台，基于PostgreSQL构建，类Airtable界面DiceDB - 开源高性能内存数据库，作为Redis替代品，适合高速缓存和实时系统Docling - 文档解析工具，支持导出markdown和JSON，支持OCRGitdiagram - 将GitHub仓库转换为交互式架构图3. 系统工具与操作系统PowerToys - Windows系统增强工具，包含快速启动器、图片批量处理、拾色器、文本提取器等Ventoy - 多系统启动U盘制作工具Windows via Docker - 从Docker安装Windows，在Linux中通过浏览器访问，支持Win7-11WebVM - 在网页端运行的Linux虚拟机，甚至可以运行可执行文件Jellyfinweb - 媒体服务器Web界面4. 网络与文件共享LocalSend - 本地网络安全文件共享工具，无需互联网连接FilePizza - 基于WebRTC的点对点文件传输，文件直接从发送者浏览器传到接收者浏览器File-transfer-go - Go语言实现的文件传输工具Netbird - 点对点VPN/内网穿透工具AList - 聚合网盘工具Linux Mirrors - Linux镜像源管理工具5. 监控与管理Infisical - 开源密钥管理工具，类似HashiCorp Vault，支持微服务架构Beszel - 轻量级服务器监控平台，支持Docker容器监控，资源占用低XPipe - 终端连接工具Openlist - 开源列表管理工具6. 安全与渗透测试Hacking tool - 一体化黑客工具箱，包含各类漏洞扫描和攻击工具Sherlock - 社交媒体账号搜索工具，支持400多个网站查询7. 人工智能与分布式计算EXO - 分布式AI计算集群框架，允许连接日常设备形成AI计算集群Pansou - 开源搜索引擎Weepwiki - 知识库/wiki系统项目详细记录开发与编程工具Go-blueprint通过命令行交互式的创建和初始化Go的项目。也可以在网页里直接选择。Pake一个用Rust开发的小工具，可以把网页打包成macOS、Windows、Linux三种系统支持的桌面客户端应用。Pake的封装比Electron的封装小20倍。manim3Blue1Brown的作者开发的强大动画引擎。专为数学和可视化科学设计。能生成高质量的数学动画。推荐使用manim和manimCE（社区版），因为会更稳定。DeepfaceDeepface是一个轻量级的Python人脸识别工具。支持年龄、性别、情绪、种族识别。它是混合面部识别框架，集成了多种识别模型。准确率已经超过了人类。RealtimeSTT是一个开源的实时语音转文本（Speech-to-Text，STT）库，专为低延迟应用设计。该项目由KoljaB开发，采用Python语言编写，能够将语音数据实时转换为文本，适用于语音助手、实时字幕生成、会议记录等多种场景。采用流式处理技术，在语音输入的同时实时输出转写结果，延迟极低。基础模型（tiny）运行时内存占用约400MB，大型模型（large-v2）在GPU环境下显存占用约4.2GB。通过INT8量化技术，模型内存占用可减少75%。AmphionAmphion是一个由上海人工智能实验室、香港中文大学（深圳）数据科学学院和深圳市大数据研究院联合开发的开源音频、音乐和语音生成工具包。该项目于2023年12月开源，旨在支持可重复的研究，帮助初级研究人员和工程师快速进入音频生成领域。它支持TTS、SVC、TTA、VC等功能。SkyvernSkyvern的最大突破在于摆脱了传统自动化工具对DOM结构和XPath选择器的依赖。传统工具如Selenium、Playwright需要为每个网站编写定制脚本，一旦页面布局发生变化，脚本就会失效。而Skyvern采用"视觉理解"模式：通过分析网页截图，结合视觉语言模型来理解页面内容和元素功能，像人类一样"看懂"网页并自主决策操作步骤。采用多智能体协作架构，包含规划器、执行器、验证器、视觉语言模型四个核心模块。index-tts2文本转语音工具。数据库与数据处理Teable开源项目Teable是一个现代化的无代码（no-code）数据库与数据协作平台，类似于Airtable，但基于PostgreSQL构建并且是开源的。它的目标是让技术和非技术用户都能方便地创建、管理和协作复杂的数据应用，而不必编写代码。Teable提供了一个类电子表格界面，用户可以像使用Excel或Airtable那样直接操作数据，但底层则是真正的PostgreSQL数据库，因此具备高性能、强一致性和可扩展性。DiceDBDiceDB是一个开源的高性能内存数据库（in-memory database），其设计目标是为现代实时应用和缓存场景提供极低延迟、高吞吐量的数据存储与访问能力。它最初由DiceDB团队开发，并于2024年底开源，采用BSD 3-Clause许可。DiceDB将数据全部保存在内存中（非持久化），因此适合用作高速缓存层或对性能敏感的实时系统后台。相比传统磁盘数据库，它能够显著降低读写延迟。DiceDB设计初衷之一是作为Redis的替代品，兼容部分Redis协议/命令。Docling文档解析工具，支持导出markdown和JSON格式，支持OCR功能。Gitdiagram将GitHub仓库转换为交互式的架构图。只需要输入项目地址就可以生成架构图。系统工具与操作系统PowerToys增强Windows 10和Windows 11操作系统。包含了快速启动器（快速搜索启动应用程序）、批量图片大小调整工具、拾色器、屏幕取色器、文本提取器等。Ventoy多系统启动U盘制作工具。Windows via Docker从Docker安装Windows然后从Linux中通过浏览器访问，支持Windows 7-11，默认安装Windows 11。WebVM在网页端运行的Linux虚拟机，甚至可以运行可执行文件。JellyfinwebJellyfin媒体服务器的Web界面。网络与文件共享LocalSend允许在本地网络上安全的和附近设备共享文件和消息。无需互联网连接。FilePizza基于WebRTC实现，省去了文件上传功能。文件会直接从发送者的浏览器直接发送到下载者的浏览器上。数据从未保存到中间的服务器中。传输速度更快。分享文件也支持多人下载。但是下载的时候要保证浏览器打开。File-transfer-goGo语言实现的文件传输工具。Netbird点对点VPN/内网穿透工具。AList聚合网盘的工具。Linux MirrorsLinux镜像源管理工具。监控与管理Infisical开源密钥管理工具，类似HashiCorp Vault。集中管理存储敏感信息，提供强大的安全措施来管理数据。特点包括集中管理和安全性。项目和环境分离。API和CLI支持。以微服务为例，可以给每个微服务创建一个文件夹结构。清晰的组织和管理每个微服务的密钥。BeszelBeszel是一款开源的轻量级服务器监控平台，专为简化服务器和容器监控而设计。它支持Docker容器监控、历史数据记录、智能告警等功能，拥有友好的Web界面和极低的资源占用，非常适合个人开发者和小型团队使用。轻量级设计：Beszel采用Go语言开发，资源占用极低，在1核512MB内存的主机上也能流畅运行，相比Prometheus+Grafana等传统监控方案更加轻量。Docker深度支持：能够实时监控每个容器的CPU、内存、网络使用情况，并记录历史数据，帮助用户快速定位性能瓶颈。XPipe终端连接工具。Openlist开源列表管理工具。安全与渗透测试Hacking tool一个一体化黑客工具箱。融合了各类漏洞扫描和攻击工具。包括DDos、XSS等。Sherlock社交媒体账号搜索工具，输入用户名可以查询400多个网站的社交账号。项目没有提供UI，可以通过命令行来使用。但是没有除了gitee的国内站点。人工智能与分布式计算EXO其核心理念是"在家中使用日常设备运行自己的AI集群"。该项目允许用户将家中的iPhone、iPad、Android手机、Mac、Linux电脑等日常设备连接起来，形成一个强大的分布式AI计算集群，无需昂贵的NVIDIA GPU即可运行大型AI模型。自动模型分割框架。系统会根据当前网络拓扑和各设备的可用资源，智能地将模型分割成多个部分并分配给不同设备处理。例如，两台各有8GB内存的设备可以共同运行需要16GB内存的模型，突破了单设备的内存限制。EXO实现了零配置的自动设备发现功能，无需手动配置IP地址或网络设置。只要设备连接到同一网络，系统就能自动识别并纳入计算集群，极大简化了部署流程。EXO原生支持RDMA over Thunderbolt 5技术，在支持该接口的设备之间可实现高达99%的通信延迟降低。Pansou开源搜索引擎。Weepwiki知识库/wiki系统。新增项目Follow支持在一个地方关注所有喜欢的内容，比如网站博客，社交媒体账户。是一个一体化的信息中心。支持Windows、macOS、Linux。
JEP 491虚拟线程和synchronizedJava24解决了虚拟线程同步使用问题 - 极道调度方式调度方式分为协作式调度和抢占式调度协作式调度：线程不让出执行权会导致其他线程饿死。抢占式调度：操作系统或运行时强制中断正在运行的线程，将 CPU 分配给其他线程。是否切断线程由调度器决定。即使你的 Java 代码没有调用 yield()，操作系统仍然可以在任何时刻抢占线程。在java中虚拟线程就是协作式调度，平台线程就是抢占式调度。Java 虚拟线程（Virtual Thread）只有在发生“可挂起（park）”的点时，才会与当前平台线程（carrier / platform thread）解绑，平台线程才有机会去执行其他虚拟线程。如阻塞，或者线程礼让。import java.util.concurrent.Executors; import java.util.concurrent.ExecutorService; public class Main { public static void main(String[] args) throws InterruptedException { // 使用虚拟线程创建一个固定数量的 carrier threads ExecutorService executor = Executors.newThreadPerTaskExecutor(Thread.ofVirtual().factory()); //平台线程小于50 int busyThreads = 50; int newThreadIndex = 0; // 提交“死循环虚拟线程” for (int i = 0; i < busyThreads; i++) { int id = i; executor.submit(() -> { System.out.println("Busy virtual thread " + id + " started"); while (true) { // 纯 CPU 循环，不阻塞 } }); } // 等待一会儿，让死循环线程占满平台线程 Thread.sleep(1000); // 提交一个新虚拟线程尝试执行 executor.submit(() -> { System.out.println("New virtual thread " + newThreadIndex + " started"); }); // 注意：你可能看不到 New virtual thread 的打印 // 因为所有平台线程都被占满 Thread.sleep(10000); } } 上述发生的原因是java的协程是协作式调度的go1.13之前是协作式调度为主，1.14之后支持抢占式调度。现在 Go 采用的是混合调度策略，兼具两种调度的优势：运行时向 M（OS线程）发送信号实现强制抢占，防止 goroutine 长时间占用 CPUpackage main import ( "fmt" "time" ) func main() { busyThreads := 50 newThreadIndex := 0 // 启动"死循环"goroutine for i := 0; i < busyThreads; i++ { id := i go func() { fmt.Printf("Busy goroutine %d started\n", id) // 纯 CPU 循环，不阻塞 for { } }() } // 等待一会儿，让死循环 goroutine 开始执行 time.Sleep(2 * time.Second) // 提交新 goroutine go func() { fmt.Printf("New goroutine %d started\n", newThreadIndex) }() // 等待 10 秒 time.Sleep(10 * time.Second) } 因此go就不会出现这样的问题。但在1.13中就会有问题。java21和25都存在这个问题。背景简单来说就是synchronized阻塞的时候，无法切换到其他协程，导致当前平台线程被阻塞，不能运行其他虚拟线程。理论上可以使用ReentrantLock来解决虚拟线程是Java 21通过JEP 444引入的轻量级线程，由JDK而非操作系统提供。虚拟线程显著减少了开发、维护和观察高吞吐量并发应用程序的工作量，使应用程序能够使用大量线程。线程必须被_调度_才能做有用的工作，即被分配到处理器核心上执行。对于平台线程，JDK依赖于操作系统的调度器。对于虚拟线程，JDK有自己的调度器，它将虚拟线程分配给平台线程，然后由操作系统像往常一样调度。虚拟线程在执行阻塞操作（如I/O）时会卸载，当阻塞操作准备完成时，操作将虚拟线程重新提交给JDK的调度器，调度器将虚拟线程重新安装到平台线程上以继续运行代码。为何虚拟线程被固定到平台线程在Java中，虚拟线程被固定（pinned）到平台线程的原因主要与synchronized关键字的实现机制有关。虚拟线程在synchronized方法内部运行代码时无法卸载。考虑以下synchronized从套接字读取字节的方法：synchronized byte getData() { byte buf = ...; int nread = socket.getInputStream().read(buf); // Can block here ... }期望：如果该read方法没有实际字节二阻塞，我们希望正在运行虚拟线程getData从其载体上写着。这将释放一个平台线程，以便 JDK 的调度程序可以在其上安装不同的虚拟线程。实际：不幸的是由于getData是synchronized，JVM将正在运行的虚拟线程固定getData到其载体上。固定可防止虚拟线程卸载。因此，该read方法不仅会阻塞虚拟线程，还会阻塞其载体，从而阻塞底层操作系统线程，直到有字节供读取原因java中的synchronized关键字是基于监视器实现的，每个对象都与一个监视器关联，该监视器可以被获取（锁定）、持有一段时间，然后释放（解锁）。一次只能有一个线程持有对象的监视器。在JVM中，哪个线程持有对象紧绳器的信息是基于平台线程（即操作系统线程）来跟踪的，而不是基于虚拟线程。当虚拟线程执行synchronized实例方法并获取与实例关联的监视器时，JVM是虚拟线程的载体平台线程持有监视器，而不是虚拟线程本身。如果虚拟线程在synchronized方法中卸载，JDK的调度器可能会将另一个虚拟线程安装到刚刚释放的平台线程上。由于这个新虚拟线程的载体，JVM会认为它持有与实例关联的监视器，这将破坏互斥性，因此JVM积极组织虚拟现场在synchronized方法中卸载。如果虚拟线程在执行synchronized方法时调用了Object.wait(), 它会在JVM中阻塞知道被Object.notify()唤醒，并且载体重新获取监视器。由于它在synchronized方法中执行，以及它的载体在JVM中阻塞，所以虚拟线程也被固定危害频繁的固定（尤其是长时间固定）可能会损害可扩展性，导致饥饿甚至死锁，因为没有虚拟线程可以运行，因为所有平台线程要么被虚拟线程固定，要么在JVM中被阻塞。JEP 491旨在改变JVM对synchronized关键字的实现，允许虚拟线程在synchronized方法或语句中获取、持有和释放监视器，独立于它们的载体。这将允许虚拟线程在被阻塞时卸载，释放其载体平台线程给JDK调度器，从而提高应用程序的可扩展性通过允许在synchronized方法和语句中阻塞的虚拟线程释放其底层平台线程，供其他虚拟线程使用，从而提高Java代码在使用synchronized时的可扩展性。解决了虚拟线程在synchronized方法中不能卸载的问题，这个问题限制了能够用于处理应用程序工作负载的虚拟线程数量。同时，改进了诊断工具，以识别虚拟线程未能释放平台线程的情况，通过JDK Flight Recorder (JFR)记录jdk.VirtualThreadPinned事件来识别代码中的问题区域。由于synchronized关键字不再固定虚拟线程，因此不再需要jdk.tracePinnedThreads系统属性，该属性会在虚拟线程在synchronized方法中阻塞时打印堆栈跟踪，但可能会引起性能问题。解决了开发者在选择synchronized和java.util.concurrent.locks包中的API时的困惑，现在可以根据实际需要选择，而不必因为虚拟线程固定问题而被迫使用ReentrantLock。JEP 491提议重新实现synchronized关键字，允许虚拟线程获取、持有和释放监视器，而不需要将这些操作与它们的载体线程绑定，解决了虚拟线程与监视器交互的问题。本提案涉及对Object.wait()和Object.notify()机制的更改，允许虚拟线程在等待和重新获取监视器时挂起和恢复，而不会锁定其载体平台线程。本提案识别了一些虚拟线程仍然会固定的情况，例如在类初始化器内阻塞、等待其他线程初始化类以及在类加载期间解析符号引用时阻塞。
常见音频的损失函数MSE均方误差损失$$ MSE=\frac{1}{n}\sum_{i=1}^n(y_i-\hat{y}_i)^2 $$公式n：表示样本的数量比如100张图片n就是100i：第i个样本$y_i$表示模型对滴i个样本的预测值$y_i-\hat y_i$是单个样本的预测误差$\sum$为求和1/n对总和求平均，因此也叫均方误差最小二乘损失最小二乘损失的核心思想是：通过最小化预测值与真实值之间差距的平方和，使得模型预测接近真实的情况。二乘指的是平方，我们不直接计算差距（残差），而是计算差距的平方。最小：我们的优化目标，让这个平方和达到最小。最小二乘法就是最小化平方和的方法，其对应的损失函数就是最小二乘损失函数最小二乘法是一种数学优化技术，它通过最小化误差的平方和，来找到一组数据的最佳拟合曲线（或直线）为什么二乘就是平方呢？想象一下，我们在三点图上画一条直线，试图让它尽可能地穿过靠近所有的数据点。每个数据点与直线在垂直方向上的距离，就是该点的误差（也就残差）。点在直线上方，误差为正，点在直线下方，误差为负。如果直接把所有误差相加，正负误差会相互抵消，这显然不合理。因此就将误差进行平方再相加。这个所有误差的平方之和，就是我们要最小化的目标。线性化回归就是最小二乘法的使用例子之一。对于单个样本，其损失是预测值$y_i$和真实值$\hat{y}_i$的平方$$ L(y_i,\hat{y_i})=(y_i-\hat{y_i})^2 $$数据集中，所有样本的损失的平均值，就是均方误差$$ L(y_i,\hat{y_i})=(y_i-\hat{y_i})^2 $$MAEMean absolute errorL1 loss这个名称来源于数学本质，即计算的是绝对差值的 L1范数。MAE这个名称更偏向于统计学意义，即平均绝对误差。他的目的是衡量预测值和真实值之间的误差。计算绝对值的平均值$$ \mathrm{MAE}=\frac{1}{n}\sum_{i=1}^n|y_i-\hat{y}_i| $$L1指的是L1范数，也称为曼哈顿距离。L1范数是计算向量各元素绝对值之和。由于使用的是绝对值而不是平方，当预测值与真实值相差巨大时（离群点），MAE 的惩罚增长是线性的，而 MSE 的惩罚是平方增长的。因此，MAE 比 MSE 对离群点更具鲁棒性。在反向传播计算梯度时，MAE 的导数是常数（±1），这有利于稳定的训练，但可能在接近最优解时收敛变慢。它的单位与预测目标单位一致，易于理解和解释。例如，预测房价（万元），MAE 是 5，就表示平均预测偏差了 5 万元。MSE损失的收敛目标是均值，而MAE的是中位数。STFT多分辨率损失多分辨率STFT loss通过在不同分辨率下计算短时傅里叶变换（STFT）佬捕捉音频信号的多尺度特征。核心思想是使用不同的STFT参数配置，在多个尺度上衡量生成音频与真实音频在频域上的差异。STFT将时域上的音频信号转化为时频上的表示，即频谱图幅度谱：表示了每个频率成分在特定时间点上的能量强弱。这是我们人耳感知音量的主要依据。相位谱：表示了每个频率在充分太热定时间点上的起始位置。它对于音频的清晰度和时序至关重要。I音频模型通常先生成目标的频谱图（尤其是幅度谱），然后再通过一个声码器（如Griffin-Lim或神经网络声码器）将频谱图转换回时域音频。因此，在频谱图层面设计良好的损失函数至关重要。频谱收敛损失：Magnitude-based Loss幅度损失是主要用于处理频谱图或其他时频表示，核心思想是比较生成音频与目标音频在幅度谱上的差异。在需要进度重建音频波形的任务中，它是核心的组成部分。但它不会单独使用$$ L_{sc}(x,\tilde{x})=\frac{\||STFT(x)|-|STFT(\tilde{x})|\|_F}{\||STFT(x)|\|_F} $$这个损失函数有一个更全局的视角，它关注的是生成频谱和目标频谱在形状上的一致性。SC损失将频谱图视为一个高维向量，并计算这两个向量之间的“夹角”或“方向”差异。它本质上计算的是归一化后的生成频谱与目标频谱之间的差异。你可以把它想象成：我们不直接比较两个向量的长度（那是幅度损失关心的），而是比较它们的方向是否一致。如果方向一致，说明频谱的“轮廓”或“相对能量分布”是正确的。对数幅度谱损失这个损失函数直接比较生成音频和目标音频的幅度谱。在幅度谱上计算生成结果与真实结果之间的差异。由于人耳对声音强度的感知是对数性质的（例如，声音强度增加一倍，我们感知到的响度变化不是线性的），所以通常会在对数尺度下进行比较，这更符合人耳的听觉特性。对数L1损失(更常用、更稳定):$$L_{log-stft-L1}=\mathbb{E}\left[\left\|\log(|S_{target}|+\epsilon)-\log(|S_{generated}|+\epsilon)\right\|_1\right]$$对数L2损失：$$L_{log-stft-L2}=\mathbb{E}\left[\left\|\log(|S_{target}|+\epsilon)-\log(|S_{generated}|+\epsilon)\right\|_2^2\right]$$其中$\|\cdot\|_{1\text{和}}\|\cdot\|_{2\text{分别表示 L1 范数和 L2 范数，}\mathbb{E}}$表示期望值(在批量数据上取平均)。通常这俩个函数几乎总是同时使用加权相加，构成一个复合函数。对数幅度谱复杂纹理，像一个像素级的损失。频率幅度谱负责轮廓，像一个全局结构损失，确保整个频谱大致形状是正确的。Feature Matching（FM）FM最早出现在论文 Improved GAN Training中后来被MelGAN和HIFI-GAN作为核心稳定器继承它的思想非常简单：不是值让判别器认为真和假。而是让生成器让fake的判别器中间层特征和real的判别器中间层特征尽量相同。判别器有多个子判别器，每个sub-D有多层，每层有feature map$D_k(x)$=判别器低k个字判别器的输出$f_{k,l}$=低k个子判别器的l层 feature mapFM的Loss定义为$$ L_{FM}(G, D) = \sum_k \sum_l \|f_{k,l}(x_{\text{real}}) - f_{k,l}(G(z))\|_1 $$也就是取多个判别器MPD+MSD对每个判别器每一层feature Map 做L1distance。最终加权求和。feature matching的直觉是：GAN的对抗损失值关心：生成器能不能骗过判别器判别器能不能区分真假但对抗损失不会告诉生成器怎么样更真实。Feature Matching 做的事情：判别器内部有层层抽象特征，例如：短期时域结构（similarity of waveform）周期性结构（pitch/周期）振幅动态（energy envelope）高频谐波多尺度卷积感受野捕捉的模式FM 要求“fake 的特征必须和 real 的相似”。**这本质上给生成器一个稳定的方向： 你要往真实特征靠近，而不是只要骗过判别器就行。**
分布式事务https://www.bilibili.com/video/BV1U341157BX事务ACID在分布式场景下ACID特性含义会被扩展。原子性（Atomicity）一个事务内涉及到的分布式多个节点的操作要么一起成功，要么一起失败一致性（Consistency）：跨节点场景下也不能出现中间状态。隔离性（Isolation）：一个分布式事务在一个节点哪怕完成了，在整个分布式事务完成之前，也不能被其他事务读取使用持久性（Durability）事务提交完成后的数据不仅要在当前节点保存，还应该在分布式场景下有备份高克yognxing早期分布式事务的三个方向分别是俩阶段模型，XA事务模型TCC事务模型Saga事务模型常见的方案俩阶段提交一个直接的思路就是三个系统都等到整个交易快照完成时再一起提交。根据这个思路就诞生了俩阶段提交的方法，阶段1协调器收到客户端commit命令，决定提交T。然后协调器向各节点发送prepare T消息，各节点决定该节点上T是提交还是中止并返回给协调器。第二阶段协调器收到各个节点的ready或don't commit响应，如果都是ready，那么就决定提交T，并向所有节点发送commit消息；如果收到来自一个节点或多个节点的don't commit T的消息，就决定丢弃T，并向所有节点发送abort的消息。XA事务就是把俩阶段提交标准化后形成指定的数据库接口，再由一个事务管理器作为协调者统一管理俩阶段提交，相当于标准化的俩阶段提交。很多单机数据库，如oracle、DB2、Mysql支持XA接口，应用程序实现的一个事务管理器，然后跳读下面数据库的接口实现俩阶段提交，从而实现分布式事务。XA事务允许各个系统选择不同类型的数据库，只要它们都支持XA接口。TCC事务TCC将整个业务逻辑分为三块Try、comfirm，和cancel三个操作Try就是尝试扣除用户月、尝试扣除库存；confirm就是Try的结果都成功，可以证实把订单状态状态改为已支付，通知仓库发货；而cancel则是try失败，那么就要取消教育，回复月，回复库存。TCC是业务逻辑补偿的应用层设计实现。TCC的一个关键点是，Try阶段如果完成，那么很多状态就已经保存起来，再出现故障也不会影响事务的晚餐，也就是说，哪怕confirm阶段或cancel阶段失败，也会通过不断重试完成交易，而不是回滚。TCC的过程类似于俩阶段提交，Try过程和俩阶段prepare比较相似。但TCC没有事务管理的抽象，Try、confirm、cancel和业务场景密切绑定，要考虑具体业务来实现。SATA事务模型Saga本来是为解决长事务而出现的分布式事务模型，长事务的是需要太长时间而不允许它们保持其他事务所需要的锁的事务。电商交易如果采用俩阶段提交，则订单系统的子系统要等到用户确认收货交易完成才能提交，而物流的时间一般比较长，这个时间可能需要几天。而订单系统事务可能会拖住一些资源，如用户的余额，这个锁维持几天的时间，会导致用户无法消费，这显然是不可行的。Saga是把分布式事务看做一个个单机事务的合集，对每一个单机事务A，Saga都有一个补偿事务$A^{-1}$。如果我们执行A，又执行$A^{-1}$，那么锁产生的数据库状态同A和$A^{-1}$都未执行前一样。同样都是需要业务逻辑接入，其中TCC适用于对一致性要求高、性能敏感的场景。SAGA的核心的回滚，像一个执行-如失败反向补偿的厂业务流程，适用于执行流程长，业务流程复杂的场景。体现在分布式整体上，只要我们能确认一个单机事务都执行成功，那么整个分布式事务就是成功的，可以提交。如果任意一个单机事务不成功，那么就要把它和它之前的单机事务回滚掉，但它之前的单机事务已经提交过了，无法回滚，这时候就需要执行它们的补偿事务。电商交易系统的例子可以通过设计补偿事务，把库存和用户余额加回，来实现分布式事务。分布式事务模型传奇基地交易 ：： ShardingSphere在单机数据库的基础上是心爱一个中间层（proxy），中间层基于单机事务加saga来实现分布式事务。高可用通过单机数据库的主备复制实现。如ShardingSphere-Proxy中，可以通过配置将分布式事务管理委托给Seata。当ShardingSphere-Proxy接收到一个跨多个数据库节点的事务请求时，它会将事务信息发送给Seata的全局事务协调器。全局事务协调器根据事务类型（如Base事务）和配置规则，对事务进行协调和管理。在事务执行过程中，ShardingSphere-Proxy会负责将事务操作路由到相应的数据库节点，并监控事务的执行状态。一旦事务执行完成，Seata会根据事务的执行结果，进行全局的提交或回滚操作，确保分布式事务的原子性和一致性。原生数据库：它们基于俩阶段提交实现分布式事务，不存在单机事务。比如蚂蚁的oceanbase和TIDB。SAGA生成补偿事务的思想是通用的，分布式数据库可以通过解析单机事务的SQL，从而生成逆SQL，从而生成补偿事务（比如AT模式）实现这一点要满足俩个条件要有一个标志把同一个分布式事务的所有单机事务联系起来，以便在需要执行补偿事务的时候能找到它们有的单机事务已提交，但它所在的分布式事务未提交，这时它提交的结果在分布式的角度仍处于脏数据，通常不允许其他事务对其进行读取。要单独进行处理。（通常使用分布式锁来实现）TCC的一致性比SAGA更强。SAGA是可以直接提交和直接回滚，但TCC要先try。前面介绍的俩阶段提交原型，可以看出，俩阶段提交对事物管理器的抽象天然适合封装在分布式数据库内部，这也是大部分原生数据库选择俩阶段提交的原因。俩阶段提交有一个显著的特点：事务只有在prepare阶段才会在数据行上锁，整个执行过程都是无锁的，这意味着并行的事务很有可能修改了同一行的数据。也就是说俩阶段提交是first commit win，是一种乐观事务模型（假设事务没有冲突发生）。目前一些商业的原生分布式数据库对俩阶段提交的加锁进行了改造，支持了悲观锁（即在事务执行阶段就加锁），这一步拓展原生数据库的支持能力。此外最新版本的俩阶段提交有严重的问题：协调及存在高可用问题，一旦宕机，在恢复或者新的协调器被选举出来之前，整个系统是不可用的。google的percolator事务模型对俩阶段提交问题做出了优化：把收到分布式事务请求的第一个节点作为俩阶段提交的协调者节点，一存储节点的高可用保证了协调节点的高可用，同时也不会出现些调整宕机了整个系统都不用的开启，因为任何一个节点都可以是协调者节点了。此外Percolator在事务开始时和事务提交时都会取一个时间戳并写入数据库中，这个时间戳可以很便捷的支持分布式MVCC的实现。数据库锁所是用来管理共享资源的访问的机制。在数据库中除了用户数据要上锁，还会对缓冲池中LRU列表、数据库元数据等其他资源上锁。不同数据库对锁实现差异很大。Oracle、Mysql大部分都是采用行锁设计。单机数据库的行锁会分为俩中：共享锁（S）和排它所（X），只有贡献锁之间才兼容。以mysql为例slect ... lock in share mode上的是S锁，不会阻塞后续的其他share mode。update/select... for update上的是X锁会阻塞读的操作，包括其他的share mode锁。事务中的锁还有很重要的概念，交俩阶段锁理论（2Phase lock）加锁阶段和解锁阶段是俩个独立的阶段，不能有重叠。俩阶段锁理论和事务的原子性以及隔离性关系，密切，是保证并发调度准确性的必要条件。加锁是执行阶段，解锁是提交阶段。在单机事务中大家很少考虑加锁和解锁的过程与代价。所资源默认堆所有事务是可见的，一行数据的加锁和解锁都可以看做原子操作。在分布式数据库中，数据行分布在多台机器上，因为跨节点网络传输的不可靠性，加锁和解锁不在是实时切原子的了。那么保证分布式上锁的正确性，需要在分布式事务中维持一个中心节点来记录所信息。加锁与解锁的成功和失败都以中心节点为准。在编排式SAGA中，有一个中央协调者（Saga协调器）负责管理和控制整个事务的执行流程。协调者按照预定义的顺序依次触发每个本地事务，并在事务失败后处理补偿事务。这种方式逻辑清晰、易于管理，但存在单点故障风险。而在协同式SAGA中，没有中央协调者，各个服务通过事件驱动的方式进行协调。每个服务自己决定何时开始下一个本地事务，通过订阅和发布事件来触发后续操作。这种方式去中心化、服务间耦合度低，但事务流程相对复杂，难以追踪。SAGA：独立中心节点俩阶段提交：协调者节点任何情况下出现了中心节点就要考虑高可用，通常使用共识算法来实现对于锁表和协调者的高可用性。Percolator直接把俩阶段提交的协调者放在了分布式事务的一个随机的数据节点，把协调者的高可用问题转换成了数据节点高可用问题。分布式锁通常只有X锁，因为实现分布式锁的代价本来就很大，如果还要实现分布式S锁就会增加非常多的维护和调度代价，并且S锁的使用本来就很少，因此一般没有实现分布式S锁的方案。对于select ... lock in share mode语句分布式数据库一般不支持（原生分布式数据库）或选择只在单机节点上S锁。隔离级别现在大部分关系型数据库都是基于MVCC的，要引入一个针对快照的新的隔离级别。SI（snapshot Isilation，SI）SI隔离级别会去读书屋开始时间点的数据快照，从而避免不可重复读，但又不像用锁实现的可重复读隔离级别那样要阻塞写。（如果始终读最新的快照，则相当于RC，但我们将SI，一般是事务开始的时候的快照）SI和RR的区别就是幻读和排序写。我们把点查询成为item查询，非点查询（范围聚合等），称为predicate查询因此我们可以把幻读定义为不可重复读的predicate版本。幻读和不可重复读都需要在一次事务中进行俩次读操作。不可重复读指的是俩次item查询到了不同的内容，而幻读指的是俩次predicate查询到了不同的结果。