【大模型推理】redis kv cache

执笔论英雄2026-07-16 9:22

SETNX 分配实例ID，这是分布式系统中一个非常经典且巧妙的用法。它解决的核心问题是：在多个服务实例同时启动或运行时，如何让每个实例获得一个全局唯一且不冲突的身份标识（ID）。

我们把这个过程拆解开来看看：

🎯 业务场景：实例ID的困境

假设你的一个微服务部署了3个副本（实例A、B、C）。它们都需要一个数字ID来标识自己（比如用于日志追踪、选主或分片）。如果在配置文件中写死ID，那么部署新实例时必须手动修改，非常容易出错。所以，我们希望实例启动时能自动向Redis申请一个"空闲"的ID。

💡 解决方案：用SETNX抢占"车位"

这个过程就像是多个司机同时抢一个带有编号的停车位。

  1. 初始化车位：运维人员在Redis里预设好一批ID，比如从1到10。每个ID都是一个Key，例如：

    • instance:id:1 -> 值暂时为空或 "AVAILABLE" (可用)
    • instance:id:2 -> 值暂时为空或 "AVAILABLE"
    • ...以此类推。

  2. 实例抢占ID（核心操作） ：

    当实例A启动时，它会用一个循环去尝试"占有"这些Key。

    • 它尝试执行：SETNX instance:id:1 实例A的UUID
    • SETNX的含义 ：这是 "SET if Not eXists" 的缩写。它的行为是：
      • 如果Key instance:id:1 不存在 ，则设置它的值为 实例A的UUID，并返回 1（表示成功）。
      • 如果Key 已经存在 （说明已被别的实例占用了），则什么也不做，并返回 0（表示失败）。

  3. 分配与记录：

    • 如果实例A对 instance:id:1 执行 SETNX 返回了 1，说明它成功抢到了 ID=1。它会把这个ID保存在自己的内存里，然后结束抢ID的流程。
    • 如果返回 0，说明ID=1被占了，实例A就会立即去试 instance:id:2，直到抢到一个为止。

  4. 释放ID（优雅停机） ：

    当实例A需要正常下线时，它会主动执行 DEL instance:id:1，把这个Key删掉。这样，下次有新实例启动时，就能重新抢到ID=1。

🛡️ 为什么用SETNX而不是SET？

这里的关键在于原子性。

  • 如果用 GET 检查 + SET 设置，在检查通过后、设置之前，可能有另一个实例也检查通过了，最终两个实例会拿到同一个ID，导致冲突。
  • SETNX 是Redis的一个原子命令 ，它把"检查是否存在"和"设置值"合并成了一个不可分割的操作，从根源上保证了在高并发下，一个ID永远只会被一个实例成功抢占。

🧩 完整的实现逻辑（伪代码）

这是一个非常典型的初始化流程：

python 复制代码 
# 假设预设的ID范围是 1 到 10
for i in range(1, 11):
    key = f"instance:id:{i}"
    # 尝试用当前实例的UUID去抢占这个Key
    if redis.setnx(key, my_uuid):
        # 抢占成功！我就用这个ID了
        self.instance_id = i
        print(f"成功获取实例ID: {i}")
        return i
    else:
        # 抢占失败，说明这个ID被占了，继续看下一个
        continue

# 如果循环结束还没抢到，说明所有ID都被占用了
raise Exception("没有可用的实例ID了！")

💡 一些关键的优化与注意事项

  1. 设置过期时间（防御性编程） ：如果某个实例抢到ID后，因为网络故障或OOM（内存溢出）突然"挂"掉了，来不及执行DEL释放Key，这个ID就会被永久占用。解决办法是，在SETNX成功后，立即用EXPIRE命令给这个Key设置一个过期时间（比如30秒），并要求实例定期续期。这样，如果实例真的挂了，Key过期后ID就能自动释放。
  2. 值的意义 ：SETNX设置的值（这里是实例的UUID）不只是为了占位。其他服务可以通过GET instance:id:1查到这个值，从而知道目前是谁占用了ID=1，方便做服务发现或问题排查。
  3. 更优的方案 ：现代的云原生环境下，更推荐使用Etcd 或Consul 这类带"租约（Lease）"机制的分布式协调服务，它们原生就支持自动续期和会话保持，比Redis手动维护过期时间更健壮。但在轻量级或已有Redis的环境下，用SETNX仍然是一个非常简洁高效的选择。

简单来说，这个操作就是让每个服务实例通过一个原子操作去"抢注"一个独一无二的名字，谁先SETNX成功，名字就归谁。

如果还想了解如何实现"续期"机制来防止ID被提前回收，可以随时告诉我。😊

解构用户的请求：

主题：实现"续期"机制，以防止ID（实例ID）在Redis中过早被回收（即，在实例仍处于活动状态时，由于TTL过期而被删除）。

上下文：延续之前关于使用SETNX进行分布式实例ID分配的讨论。之前提到了设置过期时间（TTL）并定期续期，以此作为实例崩溃时的防御措施。

识别核心概念：

目的：确保只要实例还活着，其对应的Redis Key（instance🆔{id}）就不会过期，但如果实例崩溃，它最终会过期并释放ID。

机制：后台周期性任务（看门狗/心跳），用于刷新Key的TTL。

关键挑战：原子性、时钟漂移、实例暂停（GC停顿）、优雅关闭。

构建回答结构：

引言：阐述目标------在实例存活时保持Key活跃，在实例死亡时让Key过期。明确"续期"通常指"看门狗"或"心跳"机制。

实现方法（分步骤）：如何实际编写代码。

核心逻辑（Lua脚本）：为什么需要原子性来续期。

综合流程（生命周期）：启动、续期循环、关闭。

关键注意事项/陷阱：GC停顿、网络分区、时钟偏移。

更优替代方案：提及Redisson的看门狗或其他协调服务（Etcd的租约），以展示对更广泛生态的了解。

起草内容（内心/草稿）：

步骤1：初始设置 -> SETNX成功，EXPIRE设为30秒。

步骤2：续期任务 -> 在后台线程中，每10秒（TTL的1/3）执行一次EXPIRE key 30。

问题：如果只用EXPIRE，过期时间会被重置，但如果我们只单纯用EXPIRE，任何实例都可以续期任何Key。我们应该续期我们自己的Key。通常，我们会检查值（UUID）是否匹配，或者直接续期（因为Key的名称包含ID，并且只有该实例知道自己的ID，但理论上其他实例也能操作）。最佳实践：使用Lua脚本检查值是否匹配，然后续期。

更好的Lua脚本：if redis.call("get", KEYS1) == ARGV1 then return redis.call("expire", KEYS1, ARGV2) else return 0 end。

生命周期：启动（获取锁，启动定时器）-> 运行（心跳）-> 关闭（删除Key，取消定时器）。

陷阱：如果实例挂起（GC），心跳停止，Key过期。这很好！这就是我们想要的。但如果网络延迟，续期可能会延迟。没关系，只要TTL足够长以容忍短暂的网络抖动。

Redisson类比：Redisson的RBucket本身就有一个"看门狗"机制，默认续期30秒。我可以提及这一点，使其更专业。

对照提示进行审查：用户特别询问"如何实现'续期'机制"。我的回答需要非常具有操作性，包含代码/逻辑示例。

起草最终回答（细化结构）：

直接回答：核心是"看门狗"后台线程，定期刷新TTL。

方案1（简单，但存在风险）：仅用EXPIRE，由自己的服务调用。（提及风险：可能误续期其他人的Key）。

方案2（推荐------原子续期）：使用Lua脚本，在续期前验证值（UUID）是否匹配。这保证了只有拥有者才能续期。

代码示例：提供清晰的Lua脚本和Java/Python伪代码，展示定时调度。

时间策略：建议续期间隔为TTL的1/3到1/2（例如，TTL=30秒，每10秒续期一次）。

优雅关闭：记得在关机时调用DEL，停止心跳。

高级/真实情况：提及JVM GC停顿可能导致心跳失败。解决方案：在捕获异常时增加重试，或增加TTL容错（例如，30秒TTL可容忍10-15秒停顿）。

加分项：提及Redisson已经为您做到了这一点（config.setLockWatchdogTimeout），这样他们就知道不必重新发明轮子，如果他们使用的是该库的话。

要实现"续期"机制，核心思路是启动一个后台心跳线程 ，在实例还活着的时候，周期性地去Redis重置Key的过期时间。这个机制在分布式系统中常被称为 "看门狗"（Watchdog）。

为了让方案足够健壮，我们需要解决一个关键问题：防止实例A误续期了实例B的Key。下面我带你从简单到完善，一步步实现。

1. 核心原理解析

  • 目标 ：在实例存活时，保持Key instance:id:1 不过期；在实例异常退出时，Key自动过期释放。
  • 手段 ：用一个后台定时任务，每隔一段时间（比如 TTL（过期时间） 的 1/3）执行一次 EXPIRE 命令，重置过期时间。

2. 基础版续期（存在隐患）

最简单的写法是在实例启动一个定时器（ScheduledExecutorService），每隔10秒执行一次：

python 复制代码 
# 假设已通过 SETNX 抢到了 ID=1，且设置了过期时间30秒
def renew_key():
    # 直接重置过期时间
    redis.expire("instance:id:1", 30)

隐患 ：如果实例A挂掉了，心跳停止，30秒后Key自动删除，OK。但如果实例A因GC（垃圾回收）卡顿，导致心跳延迟了几秒，也没问题，因为30秒的缓冲。最大的问题是：如果实例A在重启后抢到了新的ID=2，但旧的ID=1的Key还未过期，而网络延迟导致旧的心跳线程又发来一条续期命令，可能会把本来已经该过期的ID=1又续上了。更糟糕的是，如果某个恶意实例知道Key名，可以直接续期别人的Key。

3. 完善版续期（原子校验 + 值匹配）

为了解决误续期问题，我们在续期时必须校验当前Key的值是否属于自己 。这必须是一个原子操作，所以要使用Lua脚本。

Lua脚本内容
lua 复制代码 
-- KEYS[1] = 要续期的Key，比如 "instance:id:1"
-- ARGV[1] = 本实例的UUID/唯一标识
-- ARGV[2] = 要重置的过期时间（秒）
if redis.call("get", KEYS[1]) == ARGV[1] then
    return redis.call("expire", KEYS[1], ARGV[2])
else
    return 0
end
服务端逻辑（Java 伪代码）
java 复制代码 
public class InstanceIdRenewal {
    private String instanceId; // 启动时生成的UUID，也是SETNX时设置的值
    private String redisKey;   // 比如 "instance:id:1"
    private ScheduledExecutorService scheduler;
    private volatile boolean running = true;

    // 启动看门狗
    public void startWatchdog() {
        // 每 10 秒执行一次（建议为 TTL 的 1/3，如 TTL=30秒）
        scheduler.scheduleAtFixedRate(() -> {
            if (!running) return;
            // 执行带校验的续期Lua脚本
            List<String> keys = Collections.singletonList(redisKey);
            List<String> args = Arrays.asList(instanceId, "30");
            Long result = (Long) redis.eval(LUA_SCRIPT, keys, args);
            
            if (result == 0) {
                // 续期失败！说明Key被删了或被其他实例占用了
                // 此时当前实例应立即停止服务，重新尝试抢占新ID，或直接自杀
                log.error("续期失败，可能Key已丢失，准备停机");
                shutdown();
            }
        }, 10, 10, TimeUnit.SECONDS);
    }

    // 优雅停机时释放
    public void shutdown() {
        running = false;
        // 显式删除自己的Key，释放ID资源
        redis.del(redisKey);
        scheduler.shutdown();
    }
}

4. 续期时间策略（TTL 与间隔）

选择合理的过期时间（TTL）和续期间隔很重要：

策略 建议值 理由
Key TTL 30 秒 足够长，能容忍网络抖动和短暂的GC暂停（Full GC通常控制在几秒内）。
续期间隔 10 秒 即 TTL 的 1/3。即使某次续期因系统负载高延迟了5秒，也依然在TTL范围内，不会导致Key提前消失。
续期失败重试 立即重试 1~2 次 如果执行Lua脚本因网络超时失败，不要直接放弃，可以立即重试一次，防止因瞬时网络波动导致Key误过期。

5. 如果续期连续失败怎么办？（防脑裂）

看门狗每次执行完Lua脚本，如果返回 0（续期失败），说明发生了以下两种情况之一：

  1. Key被人为删除了（比如运维手动操作）。
  2. Key过期被删除了，且被别的实例通过SETNX抢占了。

此时，当前实例必须认为自己的"身份证"已经失效。正确的做法是：

  1. 立即停止对外提供服务（比如从负载均衡中摘除自己）。
  2. 停止心跳线程。
  3. 尝试重新抢占 ：重新走一遍 SETNX 流程，尝试抢一个新的ID。如果抢不到，就进入"只读模式"或直接报错退出（Crash）。

6. 还有更好的选择：Redisson 的看门狗

如果你用的是 Java 的 Redisson 客户端 ，你其实不用自己写这些Lua脚本和线程池。Redisson 的 RBucket 或 RLock 内置了默认的看门狗机制。

  • 默认情况下，RBucket.set("value", 30, TimeUnit.SECONDS) 并不会启动看门狗。
  • 但如果你用 RBucket.set("value", 30, TimeUnit.SECONDS) 不带过期时间 ，Redisson 会默认给它设置 30 秒过期，并启动一个看门狗线程，每 10 秒自动续期一次 ，直到你显式调用 bucket.delete()。
  • 它的内部实现原理就是我们上面讲的 Lua 脚本校验值。

🚨 最后的提醒：对时钟和GC要宽容

  • 系统时钟回拨 ：如果你的服务器时钟突然回拨，可能会导致续期间隔计算错误。建议在续期时不依赖本地时间戳，只依赖Redis的EXPIRE命令（它是相对时间，不受时钟影响）。
  • Full GC 停顿：如果 JVM 发生长达 20 秒的 Full GC，你的看门狗线程会停止执行。但因为 TTL 设为 30 秒，这 20 秒的停顿不会导致 Key 过期。只要 GC 结束后，看门狗能恢复并续期即可。

通过这套"带身份校验的看门狗"机制，我们就能完美地防止ID被提前回收，同时又能在实例真正宕机后，让Redis自动清理残留的Key。如果你需要我画一张具体的交互时序图，或者想看 Python/Go 的具体实现，随时告诉我。😊

这个问题问得非常精准，一下子就点出了分布式锁和租约机制里最隐蔽的"幽灵续期"问题。

首先要坦白，我上一条回复里提到的"值匹配校验（Lua脚本）"其实无法解决你提出的这个场景 。因为旧Key（ID=1）里存的值，就是旧实例的UUID，延迟到达的旧续期包带着自己的UUID去校验，结果是完全匹配，所以它依然会续期成功，把本该过期的ID=1又救活了。

为了解决这个顽疾，工业界通常采用以下三种策略，其中方案一是最简洁且被广泛实践的：

🥇 方案一：新实例主动"抢占"旧 Key（强制覆盖）

这是解决该问题最直接的办法。新实例启动时，不要只盯着"空闲"的ID去抢，而是直接把旧实例的Key给"抢"过来。

  • 旧逻辑 ：新实例尝试 SETNX ID=1，发现Key存在（还没过期），于是放弃，转而去抢 ID=2。这就导致了旧Key（ID=1）无人处理，被延迟包续期。
  • 新逻辑（抢占式） ：
    1. 新实例启动，生成新的唯一标识 UUID-B。
    2. 直接执行 SET instance:id:1 UUID-B （注意，这里用 SET 而不是 SETNX，直接强行覆盖掉旧值）。
    3. 此时，Redis 中 ID=1 的 Value 变成了 UUID-B。
    4. 旧实例延迟的网络包（携带 UUID-A）终于到达，执行续期Lua脚本。
    5. Lua脚本检查：GET(instance:id:1) 现在返回的是 UUID-B，UUID-B == UUID-A 显然不成立，续期失败。
    6. 大功告成：旧心跳包被拒，ID=1 被新实例成功接管，且续期权也完全转移到了新实例手中。

⚠️ 代价与风险（脑裂） ：

这种做法的代价是，如果旧实例并没有真的死掉 （比如只是网络闪断，导致新实例误以为它死了而接管），就会发生**"脑裂"**------两个实例同时认为自己拥有 ID=1。

不过，这个窗口期非常短。旧实例的下一次心跳续期（10秒后）会因为 Value 不匹配而失败，一旦失败，旧实例会立刻"自杀"（停止提供服务），从而快速止血。

🥈 方案二：引入"生成代际（Epoch）"并覆盖

这是方案一的加强版，让"抢占"更有说服力。我们在 Value 中不仅存 UUID，还存启动时间戳 或自增的版本号。

  • 新实例启动时，用 SET key new_value 强制覆盖。
  • 续期时不仅校验 UUID，还校验版本号。
  • 如果旧包延迟到达，版本号比对失败，直接被拒。

🥉 方案三：非常规操作------主动"清理门户"

如果业务上不允许新实例抢占旧ID （即新实例必须用全新的ID，旧ID必须留给原实例），那可以在新实例启动时，主动执行 DEL instance:id:1 删掉旧Key。

  • 风险 ：如果旧实例还活着，DEL 会直接把它的"身份证"删掉，导致旧实例续期失败并自杀。这本质上和方案一一样，依然是"新实例杀死旧实例"，只是换了一种粗暴的方式。

🏆 终极建议：用专业的协调服务

其实，在真正的生产环境中，我们很少会单纯靠 Redis SETNX + 自己写看门狗来解决这类复杂的"僵尸续期"问题。因为网络延迟、GC停顿、时钟漂移会让自研逻辑变得异常复杂。

更成熟的做法是使用专业的分布式协调服务 （如 Etcd 或 ZooKeeper）：

  • 它们提供的**"租约（Lease）"机制**自带"生成号（Revision）"。
  • 当客户端重连时，Etcd 会自动生成新的 Revision，旧客户端的续期请求因为 Revision 不匹配会被后端自动拒绝。
  • 你根本不需要去手动覆盖 Key 或者写复杂的 Lua 脚本，底层协议已经帮你把"代际"隔离好了。

📝 总结你的实现策略

如果在现有 Redis 架构下修复，我推荐你采用 方案一（抢占式覆盖）：

  1. 启动时 ：用 SET key new_uuid 强制覆盖，放弃使用 SETNX。
  2. 续期时：Lua脚本严格校验 Value 是否等于自己的 UUID。
  3. 被踢时：当续期返回失败（0），实例立即触发熔断，停止所有业务处理。

这样，无论网络包延迟多久，只要新实例一启动，旧实例的"续期合法性"就被立刻剥夺了，完美解决了你提出的"僵尸续期"问题。

如果你需要我写一段包含"抢占式覆盖"逻辑的完整启动代码，随时告诉我。😊

这个问题我之前解释过，但既然你又提出来，我猜你可能想知道在代码层面具体是怎么实现和流转的，而不只是概念。我们直接从"一个请求过来，系统怎么处理"的视角，把完整链路拆开看。

用一句话先定个调：这是一种用"分片（Sharding）"代替"抢锁（Locking）"的策略，目的是让系统彻底无锁化，性能达到最高。

我们把这个过程拆成 "写数据时" 和 "处理请求时" 两个阶段来看：

1. 启动时：划分"势力范围"（Range分配）

假设你的系统有3个实例（A、B、C），需要处理1亿个用户的数据。我们预先定义好1000个"桶"（Bucket 0 ~ 999）。

  • 预设映射规则 （通常在配置中心或数据库里写好）：
    • 实例A（抢到ID=1） → 负责 Bucket 0 ~ 333
    • 实例B（抢到ID=2） → 负责 Bucket 334 ~ 666
    • 实例C（抢到ID=3） → 负责 Bucket 667 ~ 999

关键点 ：每个实例启动时，会把自己负责的起始Bucket和结束Bucket 加载到本地内存里（比如 start = 0, end = 333）。

2. 请求到达时：计算与路由（这是你关心的重点）

当一个请求（比如查询用户 user_12345 的积分）到达网关或负载均衡器时，后端系统会执行以下三段式逻辑：

第一步：计算目标 Bucket（分片路由）

系统不会随机分配，而是用请求中的关键参数（如用户ID）做哈希计算：

text 复制代码 
target_bucket = hash("user_12345") % 总桶数(1000)

假设算出来 target_bucket = 256。

第二步：查找负责人（实例路由）

系统查内存中的映射表，发现 256 落在 实例A (0~333) 的范围内。

第三步：执行消费（本地处理）

此时会有两种常见的架构实现：

  • 架构一（直连路由） ：网关层就知道映射关系，直接把请求转发给实例A。实例A收到请求后，不再校验范围，直接处理。因为网关已经保证了请求只会发给对的实例。
  • 架构二（自校验转发） ：网关随机把请求发给任意实例（比如发给了实例B）。实例B收到后，先算 target_bucket=256，发现自己 start=334，并不负责这个桶 。于是，实例B不会去抢锁，也不会处理数据，而是立刻把请求转发给实例A，或者给网关返回一个重定向响应。

3. 为什么这么做比"用SETNX抢锁"好？

我们对比一下两种处理同一个请求（user_12345）的方式：

处理方式 操作流程 性能与风险
抢锁模式（无Range） 三个实例都收到请求，都要去Redis执行 SETNX lock:user_12345 抢锁。只有1个成功，2个失败重试。 高并发下性能极差，大量网络IO浪费在抢锁上，且容易出现死锁或锁超时。
Range模式（你的问题） 请求根据算法，只有实例A会处理。B和C根本看不见这个请求。 零网络冲突，实例A直接在本地内存或本地CPU计算，没有锁竞争，延迟极低（毫秒级）。

4. 如果请求里的参数没法直接 Hash 呢？

有时候业务参数不是数字ID，比如是一个"手机号"。没关系，哈希算法支持字符串：

text 复制代码 
target_bucket = abs(hash("13800138000")) % 1000

只要保证相同的手机号永远算出相同的 Bucket，那么同一个用户的所有请求就永远只落在一个实例上，天然保证了数据一致性。

5. 如果实例A突然挂了，Range 怎么处理？（故障转移）

这就涉及到你上一个问题里提到的**"续期失败"**后的动作了：

  1. 实例A续期失败，主动自杀（停止服务）。
  2. 协调器（比如ZooKeeper或Redis自身）发现实例A的心跳Key instance:id:1 过期消失了。
  3. 触发重平衡（Rebalance） ：系统把实例A的 0~333 范围临时划给实例B （比如实例B的新范围变成 0~666）。
  4. 实例B更新本地内存中的 start = 0, end = 666。
  5. 此后，user_12345（Bucket 256）的请求就会被实例B正常处理，整个过程对上游调用方完全无感知。

📝 总结这句原话的落地含义

"每个 instance 只消费自己 bucket range 内的请求"

翻译成开发代码中的逻辑就是：

java 复制代码 
public void handleRequest(UserRequest request) {
    // 1. 计算请求属于哪个桶
    int bucket = Math.abs(request.getUserId().hashCode()) % 1000;
    
    // 2. 判断这个桶是否在我的本地范围内 (假设本地变量 localStart=0, localEnd=333)
    if (bucket < localStart || bucket > localEnd) {
        // 3. 不是我的活，转发给对应的实例，或者直接抛出异常
        forwardToCorrectInstance(bucket, request);
        return;
    }
    
    // 4. 在我的范围内，直接处理业务（操作本地缓存或数据库），无需任何Redis锁！
    doActualBusiness(request);
}

如果还想了解"重平衡（Rebalance）"过程中如何避免数据丢失或重复处理，可以随时告诉我，我们接着往下聊。😊

相关推荐
渣渣灰飞1 小时前
MySQL 系统学习 第六阶段：Redis + 缓存 + 高并发设计 第八章：Redis 高级应用
学习·mysql·缓存
tiancaijiben1 小时前
阿里云SAE应用引擎弹性扩缩容完全指南：从手动调控到智能自动化
java·网络·数据库
倔强的石头_2 小时前
8000 条 SQL 里，180 条外连接语义跑偏——Oracle 迁 KES 那些藏得最深的坑
数据库
渣渣灰飞2 小时前
MySQL 系统学习 第六阶段：Redis + 缓存 + 高并发设计 第十章：Redis 综合企业项目实战
学习·mysql·缓存
Alluxio2 小时前
重卡自动驾驶数据引擎升级，智加科技凭借Alluxio实现训练吞吐10倍跃迁
分布式·科技·机器学习·缓存·ai·自动驾驶·汽车
逆境不可逃2 小时前
RAG 不只是向量数据库：讲透 Chunk、混合检索、重排、引用与权限治理
数据库·oracle
全堆鸿蒙2 小时前
鸿蒙应用开发实战【36】— 数据查询优化：predicates 链式调用
数据库·harmonyos·鸿蒙系统
91刘仁德2 小时前
MySQL 数据库基础操作知识点整理
数据库·mysql·oracle
IvorySQL10 小时前
PG 日报｜新增 VACUUM 全维度统计信息补丁迭代
数据库·人工智能·postgresql·ivorysql
热门推荐
012026年7月AI圈大地震：GPT-5.6被政府限制、Claude入驻Slack、Anthropic自研芯片02GitHub 镜像站点03AI科技热点日报 | 2026年07月01日04幻兽帕鲁 - 服务器管理员权限与 GM 命令完全指南05AI 编程 IDE 全景解析 2026：Agent 全面接管开发链路062026 国产 AI 大模型横评：DeepSeek、通义千问、Kimi、文心一言、星火、豆包谁更能打？07GPT-5.5 对比 GPT-5.6 Sol、Terra、Luna：官方性能数据与选型分析08国内可直接用、免费额度/永久免费的大模型API清单（含 SiliconFlow、火山、阿里、智谱、百度、Kimi、DeepSeek、DMXAPI 等）09Codex 下载安装指南：Windows 和 macOS 官方版下载102026 年 AI 大模型 & AI 编程工具实战全总结