Ximou Zhao’s Blog https://ximouzhao.com/ \(^o^)/~ Thu, 20 Aug 2026 05:15:04 GMT https://validator.w3.org/feed/docs/rss2.html https://github.com/jpmonette/feed en-US All rights reserved 2026, Ximou Zhao <![CDATA[内存触顶之后，Redis 会删谁的数据？]]> https://ximouzhao.com/article/redis-maxmemory-eviction https://ximouzhao.com/article/redis-maxmemory-eviction Sat, 15 Aug 2026 00:00:00 GMT
🛒
购物车、session 和商品缓存还在一台 Redis 上膨胀。监控开始报警：used_memory 逼近上限。本篇只回答：触顶后谁有资格被删、副本为何常常「看起来没在淘汰」，以及为什么淘汰解决不了单机容量上限。落盘见 持久化，主从与自动切主见 复制 / Sentinel，装不下再水平切开见 Cluster 哈希槽。整张地图见从单机到分片。缓存穿透 / 击穿 / 雪崩与 Cache-Aside 不在本篇范围。
系列压力阶梯（全系列同一张图；本篇钉住「淘汰(A4)」）。整图说明见从单机到分片。

内存报警时，是 OOM 崩掉还是开始丢 key？

App 持续 SET / HSET，Redis 进程的已用内存往上爬。你配置了 maxmemory（服务端允许数据占用的内存上限）之后，触顶时会发生什么，并不取决于「机器还剩多少物理 RAM」，而取决于 maxmemory-policy（触顶后的内存淘汰策略）。
两条分叉很清楚：
  1. 拒写：策略是 noeviction（或不淘汰候选集为空）时，新的写命令失败，已有 key 尽量留下。
  1. 删 key：策略允许淘汰时，Redis 按规则挑出受害者删掉，腾出空间后再接受写。
还有一个运维边界：复制积压、持久化等缓冲区占用不计入与 maxmemory 的比较。因此上限要留余量——把 maxmemory 顶满整机可用内存，仍可能被缓冲区推到真实 OOM。
触顶不是「机器必崩」，而是「按你设的策略：拒写，或删谁」。

allkeys 和 volatile 差在「谁有资格被删」

policy
谁有资格被删
触顶行为
noeviction
无人
拒写；不主动删 key
allkeys-lru
全部 key
近似 LRU：优先删「最久没被访问」的
allkeys-lfu
全部 key
LFU：优先删「访问最不频繁」的
allkeys-random
全部 key
在全部 key 里随机删
volatile-lru
仅带 expire 的 key
在带过期时间的集合里做近似 LRU
volatile-lfu
仅带 expire 的 key
在带过期时间的集合里做 LFU
volatile-random
仅带 expire 的 key
在带过期时间的集合里随机删
volatile-ttl
仅带 expire 的 key
优先删「更接近过期」的
本地定义两句就够用：
  • allkeys 系策略：候选集是整库 key；购物车、无 TTL 的 session、商品缓存都可能被删。
  • volatile 系策略：候选集只含设置了过期时间（expire）的 key。若库里没有任何带 expire 的 key，volatile-* 的行为会接近 noeviction——你以为会淘汰，实际却在拒写。
近似 LRU（Least Recently Used，最近最少使用）不会扫全库，而是用采样（maxmemory-samples）估「谁更冷」。LFU（Least Frequently Used，最不经常使用）从 Redis 4.0 起可用，可用 lfu-log-factor / lfu-decay-time 调「多热才算热」。官方把 allkeys-lru 当作多数「访问服从帕累托分布」缓存场景的合理默认：少数热 key 留下，长尾冷 key 先让路。
Redis 8.6+ 的 LRM，以及怎么用命中率调策略？（非主结论）
从 Redis 8.6 起还有 allkeys-lrm / volatile-lrm（Least Recently Modified，按写侧时间戳偏向更久未改的 key）。版本不够就不要当通用建议。调策略时看 INFO 的 keyspace_hits / keyspace_misses 与 evicted_keys：命中率差、淘汰猛，说明候选集或算法与访问形态不匹配。也可用 redis-cli --hotkeys 抽样看热点（本身不是容量扩容方案）。

副本为什么常常「看起来没在淘汰」？

你在 master 上看到 evicted_keys 在涨，副本上却「安静」——这往往不是监控坏了。
⚠️
默认情况下，副本会忽略自己的 maxmemory，不在本地独立跑淘汰。主节点按策略删 key 后，会把合成的 DEL 复制给副本，副本跟着删。若把 replica-ignore-maxmemory 设为 no，副本才会按自己的 maxmemory 参与淘汰——这通常只适合可写副本或你明确接受主从可能短暂不一致、且写入幂等的场景，改之前要搞清楚后果。即便配置了 maxmemory，副本仍可能用掉比该上限更多的内存——要盯副本真实占用，避免物理机 OOM，而不能只看「策略名」。
因果链是：App 写 master → master 触顶并淘汰 → 复制流带上删除 → 副本数据集跟随。副本自己不「另起一套 LRU」，所以仪表盘上常常「主在淘汰、从在跟」。

淘汰解决不了单机容量上限

淘汰回答的是：这一台内存顶满时，拒写还是丢谁。它不把键空间摊到多机，也不提高「整库还能装多少不相关的热数据」。
若工作集已经稳定大于单机可承载（扣掉缓冲区余量之后），换 allkeys-lru 只会更频繁地删仍可能被访问的 key，换来更高的后端穿透与抖动——工作集并没有变小。要水平切开键空间，走到 Cluster 的 16384 哈希槽，而不是继续在单进程里赌淘汰算法。
淘汰是单机泄压阀；分片才是容量扩容。

清单：触顶前确认的配置

因果收束：App 写入撑大内存 → 碰到 maxmemory → maxmemory-policy 决定拒写或在「全库 / 仅带 TTL」候选集里删 key → 默认由 master 淘汰并复制 DEL，副本不独自淘汰且可能超过 maxmemory → 淘汰管不了「数据集已经装不进一台」——那是分片问题。
上线前自检：
已设置 maxmemory，并为复制 / 持久化等缓冲区留出主机余量
maxmemory-policy 与业务一致：缓存可丢用 allkeys；必须保住无 TTL 键时慎用 volatile 或改用拒写
若选 volatile-*，确认关键键确实带 expire；否则行为接近 noeviction
监控 used_memory、evicted_keys、keyspace_hits / keyspace_misses，以及副本真实内存，防物理 OOM
默认副本忽略 maxmemory 已理解；仅在明确需要时改 replica-ignore-maxmemory
工作集长期大于单机上限时，转向分片（见 Cluster 篇），而不是只换淘汰策略
Sources
  • Evidence rechecked: 2026-08-15
  • Key eviction — maxmemory / maxmemory-policy；volatile-* 在无 expire key 时接近 noeviction；allkeys-lru 与帕累托场景；缓冲区不计入 maxmemory 比较并需留 RAM；近似 LRU 与 maxmemory-samples；LFU（≥4.0）与 lfu-log-factor / lfu-decay-time；LRM（≥8.6，仅扩展阅读）；INFO 的 hits/misses / evicted_keys
]]> <![CDATA[进程被 kill 之后，Redis 里还剩什么？]]> https://ximouzhao.com/article/redis-persistence-rdb-aof https://ximouzhao.com/article/redis-persistence-rdb-aof Fri, 14 Aug 2026 00:00:00 GMT
🛒
单机 Redis 扛着购物车、登录 session 和商品缓存。运维重启机器，或进程被 kill 之后，有人发现购物车「没了」，有人发现「差点没了」。本文只回答一件事：进程没了之后，磁盘上还能剩什么、丢多少取决于什么配置。缓存怎么写穿、穿透击穿雪崩是另一类问题——同站另有一篇讲缓存策略的文章；这里不重复那一套。整张压力地图见从单机到分片。
系列压力阶梯（全系列同一张图；本篇钉住「落盘(A1)」）。整图说明见从单机到分片。

重启之后，购物车为什么「没了」？

事故现场通常很像这样：App 一直在写 Redis，监控里命令都成功了；进程一没，再连上来，键空间却空了一截，甚至整库空了。
先分清三个角色，后面整篇文章都围着它们转：
  • 你 / App：发出 SET、HSET 等写命令，等 Redis 回成功。
  • Redis 进程内存：真正对外服务的那份数据；进程没了，这份就没了。
  • 磁盘上的持久化文件：可选的 RDB / AOF；只有它们在，重启才有机会「把库装回来」。
「写成功了」往往只表示：内存里已经改完，并且客户端拿到了应答。它不等于「磁盘上已经安全留下了同一笔写」。若当时没开持久化，或持久化的丢失窗口刚好盖住了事故时段，你就会看到购物车「没了」或「差点没了」。

数据先在内存里，落盘是第二件事

Redis 默认是内存数据库：读、写、过期、淘汰都先在内存里完成。持久化（Persistence，把内存状态落到磁盘以便崩溃后恢复）是可选能力，不是「每条写命令自动双写到盘」的隐含承诺。
官方可选组合很直接：只开 RDB、只开 AOF、都不开，或 RDB + AOF 一起开。都不开时，进程被 kill 或机器重启后，内存数据就没了——磁盘上没有可加载的恢复源。
一次普通写入的因果链是：
读这张图时抓住一点：ACK 发生在内存侧。磁盘侧是否跟上、跟上多少，由你有没有开持久化、以及 appendfsync / 快照节奏决定。持久化不把 Redis 变成「每次写都强同步到盘才回包」的引擎——除非你显式选了最严的 AOF 刷盘策略，且仍要接受性能代价。

RDB 快照能救什么、救不了什么？

RDB（Redis Database，点时间快照） 是把某一时刻的内存数据集写成一个紧凑的二进制文件。它适合备份、适合较快地从快照恢复；官方也强调它用 fork() 拉起子进程去做落盘，父进程继续对外服务。
它能救的是：最后一次成功快照那一刻的全库样子。进程被 kill 后，若磁盘上还有这份文件，重启可以把库装回快照点。
它救不了的是：两次成功快照之间发生的全部写入。若你依赖「每隔一段时间存一次」，崩溃刚好落在两次保存中间，那几分钟（或你配置的间隔）里的购物车变更就会丢。RDB 不承诺「刚 ACK 的那一笔一定进盘」；它只承诺「有一份可用的历史切片」。
另外，fork() 会带来短暂的资源压力（父子共享页、写时复制），高写入负载下可能抖一下——这是机制成本，不是「开了 RDB 就零代价」。

AOF 是在记「做过的写」，还是保证「永不丢」？

AOF（Append Only File，仅追加文件） 把写命令追加进日志；恢复时重放这些命令，重建数据集。AOF 还会做 rewrite（重写）：在合适时机生成一份更短、但仍等价的命令集，避免日志无限膨胀。
AOF 记的是「做过的写」，不是口头上的「永不丢」。真正决定丢失窗口的，是配置项 appendfsync（把 AOF 刷到磁盘的策略）：
appendfsync
大致做什么
崩溃时可能丢什么
代价直觉
always
每条写都 fsync
官方称最安全；仍受盘/系统故障边界约束
最慢
everysec
大约每秒 fsync
官方说明：可能丢掉约 1 秒的数据
常用折中
no
交给操作系统决定何时刷盘
窗口依赖内核与负载；勿写成「固定总是 N 秒」
通常更快、更不可控
所以：AOF 缩小了相对纯 RDB 间隔的丢失窗口，尤其是 everysec / always；它不等于分布式强一致，也不等于「App 收到 ACK 后，副本 / 别的机器上也一定有这份写」（那是复制话题）。
appendfsync no 为什么不能写死「Linux 总是 30 秒」？
官方文档会提到：在 appendfsync no 时，刷盘时机由操作系统决定，并举例 Linux 上常见量级可能到约 30 秒量级。那是说明「窗口可以很大、且不由 Redis 精确保证」，不是给你一张「永远 30 秒」的 SLA。选型时请写成：依赖 OS / 内核刷新行为，丢失窗口不可用固定秒数硬编码进事故预案。

为什么常建议 RDB+AOF 一起开？

当 RDB 与 AOF 同时启用 时，官方重启加载规则是：优先用 AOF，因为它通常更完整（覆盖到更近的写入）。决策可以画成：
耐久性真的重要时，官方更倾向 两者一起开：AOF 负责更细的恢复粒度，RDB 仍适合备份与某些重启/运维路径。文档也会提醒：在部分备份与重启相关考量上，不宜把「只开 AOF」当成唯一习惯——具体取舍以当前版本文档为准，但主结论可以收成一句：要尽量剩数据，优先 RDB+AOF，而不是赌单一机制。
双开不消灭丢失窗口：AOF 仍受 appendfsync 约束；RDB 仍只保证快照点。它改善的是「恢复用哪份更完整、备份与日常落盘怎么分工」，不是「从此零丢失」。
⚠️
还有一个比「本机丢几秒」更狠的坑：若 master 没开持久化，又被自动拉起成空实例，副本可能跟着同步这份「空主」，把原来还在的数据冲掉。单机持久化解决不了复制拓扑里的这个问题；系列下一篇会专门讲复制与 Sentinel。现在只要记住：无持久化 + 自动重启，危险面比「本机购物车丢了」更大。

Redis 7 之后 AOF 文件长什么样？

若你的 Redis ≥ 7.0，AOF 不再只是「一个越写越长的 append 文件」这一种心智：官方采用 multi-part AOF（多文件 AOF）——通常包括 base、增量（incremental）以及 manifest（清单） 来描述如何组装恢复。运维时要按版本文档看待目录与文件集合，而不是只盯一个 .aof 文件名。
多文件 AOF 对你运维意味着什么？
恢复时 Redis 按 manifest 把 base 与增量部分拼成完整重放输入。备份、拷贝实例目录、做磁盘容量规划时，要按「一组相关文件」处理，避免只复制了其中一部分却以为「AOF 齐了」。版本低于 7 时，不要把「multipart」当成你环境里的默认事实；升级前后对照官方 Persistence 文档。
（非通用）Redis ≥ 8.10 的 BACKUP 命令族
官方 Persistence 文档提到 BACKUP 相关能力出现在较新版本（≥ 8.10.0）。它不是「所有线上 Redis 都已具备」的默认工具，也不应写进「你今天必须怎么选 RDB/AOF」的主结论。若你的版本够新，再单独对照该版本文档评估是否纳入备份流程。

你该怎么选：缓存可丢 vs 必须尽量剩

回到购物车场景：先问数据丢了能不能从别处重建，再选持久化强度。
商品缓存、可回源的读模型：丢了能打回数据库重建 → 可以接受较弱持久化，甚至（在充分理解风险后）不为「缓存层」追求最强耐久；但仍要警惕上一节的「空主拖死副本」。
购物车 / session 等不好立刻重建、丢了直接伤体验或登录态：至少认真评估 AOF，常用折中是 appendfsync everysec（官方：可能丢约 1 秒）；更不能丢再评估 always 与性能。
耐久性重要：优先 RDB + AOF；重启时按官方规则偏向加载更完整的 AOF，RDB 继续承担备份/运维角色。
只开 RDB：接受「两次快照之间的写入可能整段丢」；适合你明确只要点时间备份、能容忍分钟级窗口的场景。
只开 AOF：可以，但请对照官方关于备份与重启的建议，不要把它当成「已经覆盖 RDB 全部用途」的自动结论。
版本门控：≥7 按 multi-part AOF 运维目录与文件集合（具体见上一节 Toggle）。
范围外：托管云厂商控制台专有行为、本机「感觉很快所以一定没丢」——都不能替代上述配置事实。
进程 ACK 的是内存；磁盘承诺的是你配置的丢失窗口。

一句话收束

你写入 → Redis 内存先改并应答 →（可选）RDB 留下点时间切片、AOF 按 appendfsync 追加写日志 → 进程被 kill 后，能恢复的只有磁盘上那份，且窗口由快照间隔与刷盘策略决定 → 双开时重启更偏 AOF；无持久化的自动拉起还可能在复制场景里放大成空主事故。缓存策略（怎么跟数据库配合）是另一篇文章的问题；本文只钉死「崩溃后磁盘上还剩什么」。
来源与更深阅读
证据复核日期：2026-08-14。
主文档（持久化选项、RDB、AOF、appendfsync、双开加载偏好、≥7 multi-part AOF、BACKUP 版本门控）：https://redis.io/docs/latest/operate/oss_and_stack/management/persistence/
复制文档（无持久化 master 自动重启可能清空已同步副本的警告）：https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
系列下一篇将展开：异步复制、丢失窗口与 Sentinel 自动切换——与本文的「本机磁盘还剩什么」衔接，但不替代持久化选型。
]]> <![CDATA[Redis 扩容靠的不是一致性哈希：16384 个槽如何托住水平扩展？]]> https://ximouzhao.com/article/redis-cluster-hash-slots https://ximouzhao.com/article/redis-cluster-hash-slots Sat, 15 Aug 2026 00:00:00 GMT
💡
购物车与商品缓存已经塞满一台 Redis。你会立刻想到「上一致性哈希（Consistent Hashing）环」——但官方 Redis Cluster 明确说：它不用一致性哈希，而用固定的 16384 个哈希槽（hash slots）。本篇接在 持久化 与 复制 / Sentinel 之后，讲水平扩展这一层承诺什么、不承诺什么。整张地图见从单机到分片。
系列压力阶梯（全系列同一张图；本篇钉住「16384槽(A3)」）。整图说明见从单机到分片。

单机内存不够时，你以为会做「一致性哈希」

一台 master 内存触顶之后，常见直觉是：把键空间切到多台机器上，用一致性哈希环减少「加减节点时整库搬家」。很多客户端或代理分片方案确实走这条路。
Redis Cluster 的官方答案不同：不使用一致性哈希，而是把键空间切成固定数量的哈希槽，再把槽分配给各 master。扩容、缩容时移动的是「槽」（及其上的键），不是重新在环上找邻居。
⚠️
记住边界：社区口头常说「Redis 用一致性哈希」——那通常指客户端/代理自建分片。官方 Cluster 协议明确否定一致性哈希，主机制是 16384 个哈希槽。
开篇先对照两种切法（对比客户端/代理思路 vs Cluster；不涉及任何具名代理的具体算法）：
维度
客户端 / 代理一致性哈希（常见对比）
Redis Cluster（官方）
切分对象
按哈希环把键映射到节点
固定 16384 哈希槽，键先入槽再跟槽走节点
加减节点
环上邻居范围变化；实现各异
在节点间搬迁部分槽，无需停服切分
多键命令
取决于你的分片约定
同一命令 / 事务 / Lua 涉及的键须同槽
路由谁负责
客户端或代理算节点
客户端算槽；连错则节点返回重定向，默认不代答
你这边的 App 仍直接连 Redis；要换的是「怎么知道某个键在哪台机器」，以及「多键操作能不能跨机」。

官方 Cluster 到底怎么切键空间？

键空间被切成 16384 个哈希槽。每个 master 负责其中一部分。稳定时，一个槽只由一个 master 服务（其副本可在读扩展场景下提供可能滞后的副本读）。
映射公式是：哈希槽 = CRC16(键) mod 16384（CRC16 取 XMODEM 变体；实现上常用低 14 位，等价于对 16384 取模）。
举例：三节点起步时，槽可以按区间分给 Node A / B / C；加 Node D 时，从 A、B、C 各挪一部分槽过去即可。挪槽可以在线进行：移动的是槽归属与槽内键，不是「把整台机器从环上摘掉再重哈希一切」。
客户端侧的因果链是：
  1. App 给出键名。
  1. 客户端（或你自己）按公式算出槽。
  1. 查本地「槽 → 节点」映射，直连对应节点。
  1. 映射过期或连错时，节点用重定向把你纠正回来（下一节）。
节点之间另有集群总线（cluster bus）做故障检测与配置传播；客户端只应打命令端口，不要去打总线端口。

{user:42} 在救什么？又会制造什么热点？

多键命令、事务、Lua 脚本在 Cluster 里有硬约束：一次执行里涉及的所有键必须落在同一个哈希槽。否则节点会拒绝这类跨槽操作。
哈希标签（hash tag）就是为同槽而生的例外规则：若键名里出现成对的花括号，且 { 与其后第一个 } 之间有至少一个字符，则只哈希花括号内的子串来算槽。
因此 user:{123}:profile 与 user:{123}:account 保证同槽，可以一起做多键操作。官方示例里，{user1000}.following 与 {user1000}.followers 同理。
规则也有「看起来有花括号其实无效」的情况：例如中间为空的标签，整键照常哈希。写键名时要按规范核对，不要凭感觉。
它救的是：购物车里「同一用户的多条相关键」要原子或同次脚本处理。它制造的风险是：若大量热键共用同一个标签（例如全站都用 {shop}），它们会挤进同一槽、同一 master——水平扩展在容量上失效，热点仍然打在一台机器上。
标签是「强制同槽」的工具，不是「自动打散热点」的工具。

连错节点时，MOVED 和 ASK 差在哪？

Cluster 节点默认不代理请求。你连到「当前不负责该槽」的节点时，它返回重定向错误，让客户端改连。两种重定向语义不同：
  • MOVED：集群认为该槽已经（或应被视作）由另一节点长期负责。客户端应更新本地「槽 → 节点」映射，后续直接打新地址。
  • ASK：常见于槽正在从 A 迁到 B 的窗口。A 上若键已不在本地，会让你这一次去 B 试；客户端应对 B 先发 ASKING，再发原命令，且不要把槽永久改记到 B。迁完之后才会出现 MOVED，再固化映射。
成熟的 Cluster 客户端会在启动和收到 MOVED 时刷新槽表（例如用 CLUSTER SLOTS / CLUSTER SHARDS），平时直连正确节点，把重定向变成偶发事件。若客户端既不懂 MOVED 也不懂 ASK，就不能算完整的 Cluster 客户端。
迁槽期间多键操作为什么可能看到 TRYAGAIN？
即使所有键名义上同槽，迁槽过程中键可能暂时一部分还在源节点、一部分已在目标节点。此时针对「不存在或已拆开」的多键操作可能返回 TRYAGAIN：客户端可稍后重试，或把错误上报给调用方。单键操作在迁槽期间仍可按 MOVED/ASK 规则继续；迁槽结束后，该槽上的多键操作恢复可用。

为什么多键事务/Lua 在 Cluster 里动不动就报错？

根因通常不是「事务坏了」，而是跨槽。
  • MSET a 1 b 2：若 a 与 b 算出不同槽 → 失败。
  • MULTI / EXEC 包住多键、或 Lua 里访问多个键：同样要求整次执行落在同一槽。
  • 没有共同哈希标签、又按业务随意起名的键，很容易散落在不同槽。
可行路径只有两条：
  1. 把必须一起动的键设计进同一哈希标签；或
  1. 改成多次单键命令，由应用自己拼一致性（并接受失去单次多键原子语义）。
从「能跑的单机 Redis」迁到 Cluster 时，官方也把「多键且无相同标签」列为必须改应用的一类。Pipeline 减的是往返次数，不取消同槽约束；同槽细节若要展开，属于客户端效率专题，本篇只钉住 Cluster 的硬边界。

生产常见 6 节点在防哪些挂法？

最小可运行的 Cluster 需要至少 3 个 master（多数派故障判定与选举需要足够的 master）。生产上官方强烈建议 6 节点：3 个 master + 3 个 replica（每个 master 一根副本）。
这套拓扑在防什么：
挂法
大约会发生什么
单个 master 挂
对应 replica 可被提升，该槽区间继续服务
某 master 与其唯一 replica 同时挂
这些槽无法服务；覆盖不全时集群可能拒写（视配置）
少数派网络分区
少数侧写窗口有上限；多数侧在超时后可选举并恢复可用
可用性条件可以记成：多数 master 可达，且每个故障 master 至少还有可达副本可顶上。副本迁移（replicas migration）还能在「某个 master 变孤儿」时，从「副本较多」的 master 挪一根副本过去，降低「先后两次单点故障打穿同一分片」的概率——但若一对 master+replica 同时没了，槽仍会空洞。
对比上一篇的 Sentinel：Sentinel 解决的是单分片自动切主；当你确认「数据集已经装不进一台 master」时，才需要 Cluster 这种按槽水平切开的拓扑。

Cluster 承诺可用性，不承诺你刚写入永不丢

官方写得很直：Redis Cluster 不保证强一致性（strong consistency）。在特定故障下，已经向客户端确认（acknowledged）的写入仍可能丢失。
主因与 复制篇 同源：主从复制默认是异步的。典型顺序是：
  1. 客户端写到 master B；
  1. B 先回复 OK；
  1. B 再把写传播给副本。
若 B 在传播前崩溃，且未收到该写的副本被提升为新主，这次已确认写入就没了。WAIT 可以把「等副本确认」做进路径，降低丢失概率，但官方仍明确：即便使用同步复制语义，Cluster 也不因此变成强一致。
另一类窗口出现在网络分区：客户端与少数派（含某 master）困在一侧时，仍可能短暂写入；多数派超时后提升副本，少数派上的写入会丢。节点超时（cluster-node-timeout）既约束「多久算失败、可被 failover」，也约束少数派「多久之后停止接受写入」——因此丢失窗口有上限，但上限之内的已确认写并不安全。
所以：Cluster 帮你把键空间摊到多机，并在「多数派 + 有副本可顶」时维持分片可用；它不把「写成功回包」升级成跨故障的永不丢承诺。需要更窄丢失窗口时，仍要回到持久化策略与复制确认（见系列前文），并在业务层接受最终一致或补偿。

因果收束：从「环」到「槽」

你以为扩容靠一致性哈希环；官方 Cluster 用的是固定 16384 槽：键 → CRC16 → 槽 → 节点。哈希标签把多键拧进同槽，也会把热点拧进同槽。连错节点时，MOVED 改永久映射，ASK 只改下一次（配合 ASKING）。多键事务与 Lua 报错，多半是跨槽。生产常见 3+3 防的是单 master 挂；主从双挂仍会让槽不可用。可用性有条件，已确认写入在异步复制与分区下仍可能丢。
上线前可自检：
客户端是 Cluster 感知的，能处理 MOVED 与 ASK
必须同事务 / 同 Lua 的键已用哈希标签对齐，并评估热槽
至少 3 个 master；生产按 3 master + 3 replica 部署，且故障域分开
业务接受「非强一致」；关键写结合持久化与复制确认策略
迁槽 / 扩容窗口预留重试（含可能的 TRYAGAIN）
Sources
]]> <![CDATA[主节点挂了，副本为什么不一定有你刚写入的数据？]]> https://ximouzhao.com/article/redis-replication-sentinel https://ximouzhao.com/article/redis-replication-sentinel Sat, 15 Aug 2026 00:00:00 GMT
🛒
Redis 已经加了副本，监控也配了自动切换。主节点突然挂了，Sentinel 很快选出新主，App 重新连上——可刚确认成功的那一笔购物车写入，新主上却没有。本文只回答一件事：异步复制与 Sentinel 自动切换各自承诺什么、不承诺什么，以及「写成功了」为何仍可能丢。
系列压力阶梯（全系列同一张图；本篇钉住「主从+Sentinel(A2)」）。整图说明见从单机到分片。
系列上一篇讲的是本机磁盘还剩什么（RDB / AOF 与丢失窗口）；本文接着讲：主挂之后，副本与自动切换能不能保住你刚拿到的成功应答。缓存怎么跟数据库配合，是同站另一类问题，这里不展开。

加了副本，为什么写成功仍可能丢？

事故现场通常很像这样：App 对 master 写入购物车，命令返回成功；片刻后 master 宕机，Sentinel 把某台副本提升为新主；你再读，刚写下的键不见了。
先固定四个角色，后面整篇都围着它们转：
  • 你 / App：对当前 master 发写命令，等成功应答。
  • master（主节点）：接受写入、改自己的内存，并把复制流推给副本。
  • replica（副本）：跟随 master 的复制流；默认不决定你何时收到写成功。
  • Sentinel（哨兵）：监控、投票、自动 failover（故障切换），并给客户端提供「现在谁是主」的配置发现——它不替你把未复制的写入变出来。
Redis 默认使用异步复制（asynchronous replication）：master 在内存里完成写入并向客户端应答成功时，不会先等副本确认「我已经收到并应用了这笔写」。副本通常很快跟上，但中间永远存在一段「主已 ACK、副本尚未应用」的时间窗。主若正好在这段窗口里挂掉，提升上来的新主就可能没有那笔数据。
读这张图时抓住一点：客户端成功不等于副本已有。加副本解决的是「主挂了还有份内存可提升、读可以分担」，不是「每笔已成功的写都已在副本落稳」。

断线重连：何时只补缺口，何时整库重来？

副本与 master 之间的连接会断、会抖。重连时 Redis 尽量走 PSYNC（Partial Resynchronization，部分重同步）：用复制 ID（replication ID）和复制偏移量（offset），再配合 master 上的复制积压缓冲区（replication backlog），只把断线期间缺的那段命令补回去。
补不回来时，就退化为全量重同步（full resynchronization）：master 生成 RDB 快照发给副本，再跟上快照之后的增量流——代价更大，窗口也更长。
重连结果
大致条件
你看到的代价
部分重同步（PSYNC）
复制 ID 仍匹配；缺口落在 backlog 内
只补偏移量之间的命令
全量重同步
复制历史对不上；缺口超出 backlog；或其它无法部分续传的情况
RDB 快照 + 后续流；更重、更久
PSYNC 不消灭上一节的异步丢写窗口：它管的是「断线后怎么尽快对齐」，不是「主在 ACK 时是否已等副本」。backlog 配太小、断线太久，更容易整库重来——运维上要按流量与抖动现实估 backlog，而不是假设「有副本就永远增量」。

WAIT 能让你睡得更香吗？它承诺了什么？

若某类写入你更不能丢（例如关键 session、结算前购物车快照），可以在写成功之后再发 WAIT：它会阻塞当前客户端，直到至少 N 个副本确认已经收到此前的写，或等到超时。
它承诺的是：在超时前，尽量把「副本确认数」推高，从而缩小 failover 时丢掉已 ACK 写的真实概率。官方也写明：这在 Sentinel / Cluster 的故障切换场景里能改善现实安全性。
它不承诺的是：
  • 不把 Redis 变成强一致（strongly consistent）系统；
  • 不保证超时后「一定已经安全」——你必须检查 WAIT 返回的副本确认数是否大于或等于你要求的 N；
  • 不消除所有丢写路径（例如确认之后副本又挂、或切换选中了仍落后的节点等现实组合）。
⚠️
WAIT 是可选的同步确认台阶，不是分布式事务，也不是「写成功 = 永不可丢」。调用方把返回值当一等公民；把 WAIT 当成强一致开关，会在事故里误判。

无持久化的 master 自动拉起，为什么更危险？

系列上一篇已经钉过：无持久化时，进程没了，本机内存数据就没了。复制拓扑里还有更狠的一跳。
官方在复制文档里强烈提醒：若 master 没有持久化，又被自动重启成一个空实例，而副本随后向这份「空主」同步，副本上原来还在的数据可能被冲成空库。也就是说：你以为「至少副本还活着」，结果空主一归队，把幸存副本一起拖下水。
官方建议很直接：给 Redis 打开持久化；或者不要让无持久化的实例在崩溃后自动拉起就继续当可同步的 master。Sentinel 解决的是「谁来当主」；它不自动修复「空主被当成权威数据源」这种配置事故。
这和「本机 RDB/AOF 丢几秒」差在哪？
本机持久化讨论的是：单进程崩溃后，磁盘上还能装回多少。空主陷阱讨论的是：复制拓扑里，一份错误的权威空数据集，通过同步把别的节点也清空。两层都要管；只开 Sentinel、却让无持久化 master 自动归队，危险面更大。

只要自动切换、数据还装得进一台：为什么是 Sentinel？

当你的问题是「单分片数据还装得进一台机器，但主挂了要自动切、客户端要知道新主在哪」，官方给出的非 Cluster 答案是 Redis Sentinel。
Sentinel 提供四件事（官方能力清单）：
  1. 监控（monitoring）：Sentinel 是否觉得实例按预期在工作。
  1. 通知（notification）：可通过 API 把事件推给管理员或其他程序。
  1. 自动故障切换（automatic failover）：主不可用时，把副本提升为新主，并让其它副本跟随新主。
  1. 配置提供者（configuration provider）：客户端问 Sentinel「当前 master 是谁」，而不是把地址写死在配置文件里。
部署上，官方要求：至少 3 个 Sentinel，并放进独立的故障域（不要三个进程挤在同一台机、同一电源、同一网络故障点上「看起来有三票」）。客户端也必须真正支持 Sentinel 发现，而不是 failover 后仍死盯旧 IP。
Sentinel 做不到的事也要说清：它不做哈希槽分片，不把单机内存上限变没；异步复制下，已向客户端确认的写仍可能在切换后丢失——这与上一节同一因果链。

SDOWN 到切换成功，中间谁说了算？

自动切换不是「任意一个 Sentinel 觉得挂了就立刻切」。官方把主观与客观分开：
  • SDOWN（Subjectively Down，主观下线）：单个 Sentinel 自己认为实例不可达。
  • ODOWN（Objectively Down，客观下线）：达到配置的 quorum（法定人数）——足够多的 Sentinel 同意「master 真的不行了」——之后，才把 master 标成客观下线。
quorum 回答的是：「多少 Sentinel 同意不可达，才把 master 标成 ODOWN」。真正授权并完成 failover，还需要 Sentinel 集合里能够形成多数派（majority）；若只有少数 Sentinel 活在一个网络分区里，它们不应擅自完成切换——否则脑裂风险会反噬你。
因此：监控可以敏感，切换必须「够多人同意」。配 2 个 Sentinel「凑合用」，既不满足官方至少 3 个的独立故障域建议，也容易在分区里失去可靠的多数判断。
Docker / NAT 下 Sentinel 为什么特别容易踩坑？
官方 Sentinel 文档提醒：在 Docker、NAT 或地址翻译环境里，Sentinel 与 Redis 互相宣告的 IP/端口可能和客户端真实可达地址不一致。结果是「Sentinel 内部觉得切成功了」，App 却连错地址或连到不可达端口。部署前先核对：Sentinel 发布的 master 地址，是否就是客户端网络里可达的那一个。

什么时候不该停在 Sentinel，而要走向 Cluster？

Sentinel 适合：还要自动切换，且整库数据与负载仍装得进单个 master（单分片心智），并接受「全键操作仍在一个主上」的模型。
当你的压力变成「一台的内存 / 写入打满了，必须水平切开键空间」，就该走向 Redis Cluster（集群）：用固定哈希槽把键分散到多个主节点。选型可以收成下面这张决策图：
Cluster 不是「Sentinel 加强版」：它换的是数据面拓扑（多主分片），不是把异步复制改成强一致。下一篇会专门讲槽怎么切、客户端如何纠正路由；本文只帮你判断：什么时候不该再假装一台永远够用。

因果收束

你写入 → master 内存先改并应答 → 复制流异步追副本（默认不等待）→ 主在「未送达窗口」挂掉，新主可能没有刚 ACK 的写 → WAIT 只提高副本确认数、不是强一致 → 无持久化空主自动归队可能拖死副本 → Sentinel（至少 3 个、独立故障域、客户端感知）负责单分片监控与切主，ODOWN 看 quorum、真正切换还要 Sentinel 多数 → 单机装不下再上 Cluster。
默认复制是异步的：成功应答不等于副本已应用。
关键写入评估 WAIT，并检查返回的确认数大于或等于要求的 N。
master 打开持久化；避免无持久化实例崩溃后自动当空主再同步。
Sentinel 至少 3 个，放进独立故障域；客户端用 Sentinel 发现当前 master。
理解 quorum（客观下线）与多数派（真正 failover）不是同一句话。
数据仍单分片装得下 → Sentinel；必须水平切开 → Cluster（下一篇）。
范围外：托管云控制台专有行为、把本站应用缓存客户端当成服务端机制证明。
主挂可以自动切；刚成功的写，仍可能停在「未送达」的那一段复制延迟里。
来源与更深阅读
证据复核日期：2026-08-15。
复制（默认异步、PSYNC / 全量重同步、无持久化空主风险、WAIT 作为可选确认）：https://redis.io/docs/latest/operate/oss_and_stack/management/replication/
WAIT 命令（阻塞至 N 个副本确认或超时；非强一致；须检查返回值）：https://redis.io/docs/latest/commands/wait/
Sentinel（非 Cluster 的 HA：监控、通知、自动 failover、配置发现；至少 3 个与故障域；quorum；异步复制下已确认写仍可能丢）：https://redis.io/docs/latest/operate/oss_and_stack/management/sentinel/
系列上一篇（本机 RDB/AOF）：https://ximouzhao.com/article/redis-persistence-rdb-aof
系列下一篇预告：Redis Cluster 哈希槽与水平扩展（分片、路由纠正与部署形态），不在本文展开。
]]> <![CDATA[美白精华怎么选：别追榜单，先看诉求和成分]]> https://ximouzhao.com/article/how-to-choose-whitening-serum https://ximouzhao.com/article/how-to-choose-whitening-serum Sun, 16 Aug 2026 00:00:00 GMT
💡
你盯着一份又一份「美白精华」榜单，想帮她选对，却越看越乱：每一瓶都在承诺提亮，皮肤却各有各的暗沉和斑点。真正要问的不是「哪瓶最火」，而是：她的色素问题像什么、能不能耐受、日常有没有把阳光关住。
本文是通识决策框架，不是个性化医疗建议；黄褐斑样、妊娠/备孕、严重刺激或长期无效时，应咨询皮肤科医生。

为什么「美白精华」榜单帮不了你？

榜单优化的是点击和话术。你的决策对象是另一套东西：她想改善的外观、她皮肤能扛住的刺激，以及每天仍在上调色素的阳光。
营销里常见「美白 / brightening / lightening」。挑选时更有用的问题名是色素沉着（hyperpigmentation）：肤色不均匀、斑点或暗沉比周围更深。合法产品可以有宣称，但你不必用广告词当决策轴——下文也不点名任何网红单品。
把问题改写成色素沉着之后，下一步不是背成分浓度，而是先看：这些不均匀是怎么被「造」出来的。

暗沉和斑点，是怎么「造」出来的？

决定肤色深浅的关键色素是黑色素（melanin）。紫外线（Ultraviolet，UV）——阳光里肉眼看不见、却会晒黑与晒伤皮肤的那部分波段——以及炎症、激素等因素（例如妊娠相关变化）会让黑色素生成路径更活跃；黑色素增多，外观上就是暗沉、斑点更明显。日常防晒常提到的 UVA（长波紫外线） 与 UVB（中波紫外线） 都是 UV 的细分：UVB 更常和晒红、晒伤挂钩；UVA 穿透更深，也参与晒黑与光老化。
看起来都像「斑」，机制却常不一样。粗分是为了选类和预期，不是让你在家自诊；边界不清时交给医生。
粗分
常见诱因线索
预期时间尺度
挑选时意味着什么
黄褐斑样（melasma，面颊等处片状加深）
日照、激素相关变化更常见
改善常按月计，常见约 3–12 个月量级
防晒要更严；别用「七天白」设预期
炎症后色素沉着（post-inflammatory hyperpigmentation，PIH）
痘印、外伤、刺激性护理后留下的深色印记
随炎症控制与周转改善，仍常需耐心
先少刺激；强剥脱可能再造斑
晒斑类（如日光性雀斑样斑，solar lentigines）
长期日晒累积更相关
日防晒决定会不会继续加深
精华帮不上忙时，先查防晒是否到位
同一张脸上可以混有多种线索。你要做的是：用她的描述（痘印 / PIH？蝶形斑？整体发黄暗沉？）做够用的粗分，再进入防晒和成分类——而不是一上来堆「最强美白」。

为什么防晒往往比精华更先？

活性成分试图打断黑色素相关步骤；若输入端（前面说的 UV，黄褐斑语境下还有可见光）一直开着，常见结果是：反弹、停滞，或「精华没用」的错觉。
日常底线：选择并坚持 防晒系数（Sun Protection Factor，SPF）30 及以上的防晒。SPF 是包装上常见的防晒强度标示，主要反映对 UVB（中波紫外线，更常导致晒红、晒伤的那一段）的防护能力——数字越大通常防护越强，但仍需足量涂抹并按时补涂。选购时再看是否标注广谱 / broad-spectrum（同时照顾 UVA）；黄褐斑样诉求里，皮肤科公共教育还常提醒可见光，有色（tinted）或含氧化铁等矿物有色防晒常被作为讨论选项——具体选哪一瓶因人而异，本文不点名品牌。
⏱️
黄褐斑等色素管理，公开教育里常见的改善时间尺度大约是 3–12 个月，不是「七日白」。遇到「快速美白」「七天见效」类话术，先按不合理预期对待，而不是加码刺激性产品。
防晒做的是关输入；精华做的是在合成、转运或周转里打断一步。两者不是替代关系。

活性成分在打断哪一步？

柜面话术喜欢堆成分名。要挑对，先把「变黑」拆成一条可读的流水线——活性成分不是魔法，大多是在这条线的某一环「踩刹车」。

先看清楚：变黑大概经过哪几环？

可以把日常可见的暗沉，想成一条从下令生产到送到表面的传送带：
  1. 下令：紫外线、炎症、激素等因素，让黑色素细胞更愿意加班。
  1. 造色素：黑色素细胞里，酪氨酸酶（tyrosinase） 等关键酶把原料加工成黑色素（melanin）。
  1. 装箱：新造的黑色素装进小包裹——黑素小体（melanosome）。
  1. 交货：黑素小体被转交给周围的角质形成细胞。
  1. 表面可见：交货完成后，肤色才「看起来更深」——这是你照镜子时看到的那一环。
  1. 往上走 / 往下掉：带色素的细胞随表皮周转向外迁移；旧的角质层脱落时，一部分色素也跟着离开。
旁路也很重要：炎症本身会再推高「下令」与造色素；有些成分被叙述为先压炎症、或干预与纤溶酶相关的信号（例如外用氨甲环酸的常见讲法），再间接影响后面几环。
国内监管科普也把功效机制粗归为：抑制生成、阻断转运、还原色素、促进表皮脱落等——你选精华时，买的是「踩在哪一环」，不是广告上的某个百分数。

再形象对照：常见成分类踩在哪一环？

把上图当成地图，成分类大致落在这些「刹车点」（叙述口径，不是保证人人有效）：
一句话记：
  • 关输入（防晒）挡的是第 1 环持续下令；
  • 烟酰胺更常被讲成挡第 4 环「交货」；
  • 维 C / 熊果苷 / 曲酸等更常被讲成挡第 2 环「造色素」；
  • 维 A、酸类更常被讲成加速第 6 环「往下掉」，但刺激过头会回到第 1 环，再造出新的 PIH（炎症后色沉）。
成分类
形象落点
起步友好度 / 失败风险
烟酰胺（niacinamide）
挡「交货」：转运相关
相对常作起步类；仍可能刺激个别皮肤
维生素 C 类
挡「造色素」：抗氧化 / 辅助酪氨酸酶
剂型与稳定性差异大；柜面「VC」≠稳定活性
熊果苷（arbutin）
挡「造色素」：酪氨酸酶相关
欧盟 SCCS（Scientific Committee on Consumer Safety，消费者安全科学委员会）有安全浓度意见；别把广告浓度当疗效
外用氨甲环酸（tranexamic acid，TXA）
偏上游：纤溶酶相关信号叙述
外用 ≠ 口服；口服须医疗评估，勿自行美白口服
壬二酸（azelaic acid）
造色素 + 抗炎旁路
常作色素/炎症相邻选项类；路径因地区而异
曲酸（kojic acid）
挡「造色素」：酪氨酸酶相关
刺激风险需留意；细则见下方 Toggle
维 A 类（retinoids，含视黄醇等）
加速「往下掉」：周转相邻
刺激可诱发 PIH；妊娠期应避免
果酸 / 水杨酸等酸类（AHA/BHA，Alpha-/Beta-Hydroxy Acid）
辅助「往下掉」：表皮周转
过强刺激 → 屏障损伤 → 新的 PIH
失败模式很短：刺激制造新炎症，新炎症再留下 PIH（炎症后色沉）——于是「越美白越斑」。多酸堆叠、新人礼式强维 A，属于高关系成本玩法，不是礼赠默认路径。
曲酸与「浓度营销」：主路径之外要知道的两件事
曲酸常出现在美白配方讨论里。国内监管科普曾转述欧盟消费者安全科学委员会（SCCS）初步意见：约 1% 最大浓度「将不再被认为是安全的」（并提及内分泌相关关注）。其后 SCCS 最终意见则认为：作为皮肤美白剂使用时，曲酸在最高 1% 浓度下可视为安全，但仍提示屏障受损/剥脱等场景下吸收可能升高。
因此本文不把「1%」写成人人可安心照抄的柜面上限，也不把它写成起步首选叙事——个体刺激差异大，主路径仍优先更常作为起步讨论的成分类。
广告上的活性物百分数，说明的是配方宣称，不是疗效证据。浓度可以与刺激相关，却不能拿来证明「这瓶一定更白」。挑选时看成分类匹配、耐受和防晒，而不是比谁数字更大。

在中国买时，标签上该看什么？

成分类解决「可能打断哪一步」；标签与注册解决另一类失败：灰市违禁原料带来的健康风险，以及「宣称祛斑美白却无相应注册」的合规红灯。
全成分表通常按含量降序排列；含量 ≤0.1% 的其他微量成分，法规语境下可合并列出——你仍应通读，而不是只盯住包装正面的大字。
⚠️
氢醌（hydroquinone）：中国化妆品禁用原料语境（国家药监局更新禁用原料目录）；美国皮肤科公共教育亦指出氢醌已不再作为非处方药（Over-The-Counter，OTC，柜台可直接购买的药品路径）销售，处方须医生。灰市「强效美白」常踩这里。
汞：WHO 将含汞皮肤美白产品列为全球健康危害；《水俣公约》化妆品汞限值语境为 1 ppm，非法产品仍在流通。远离来源不明的美白膏/霜。
中国「祛斑美白」宣称：属特殊化妆品，须注册。常见标识形态包括「国妆特字G…」「国妆特进字J…」。并区分「仅具物理遮盖」与功效宣称；警惕「快速美白」「七日白」「医学美白」等话术。用官方渠道核对注册，不要只信包装口号。
国妆特字怎么查（步骤级，可跳过）
先看包装与说明书：是否明确宣称祛斑美白，以及是否印有特殊化妆品注册标识（如国妆特字 / 国妆特进字）。
再到国家药品监督管理局相关官方网站或指定查询 APP，用产品名称或注册证号核对：注册人、产品名称、批准状态是否一致。
若大打祛斑美白却查无对应特殊化妆品注册，或来源渠道可疑，按高风险处理：不买、不代购、不当礼物。
注册信息说明的是监管路径，不是疗效证书；特证产品仍要配合防晒与耐受。

怎么挑：一条可以照着做的决策链

把前面串成可执行检查，而不是再开一份新榜单。
已问清目标更像痘印 / 炎症后色沉（PIH）、黄褐斑样，还是整体暗沉
已确认是否备孕/怀孕（有则避开维 A 与氢醌）；若正在哺乳，先咨询医生再决定活性成分
已确认已知过敏、香精敏感或屏障脆弱史
成分类匹配粗分，且优先单一活性起步，避免多酸堆叠
计划做斑贴试用，而不是全脸首日拉满
日防晒 SPF 30+（防晒系数）已纳入日常（黄褐斑样考虑可见光/有色防晒讨论）
预期按月观察，不接受「七日白」话术
宣称祛斑美白时已核对中国特殊化妆品注册；已通读全成分
拒绝来源不明、疑似氢醌/含汞美白产品
无效、加重或边界不清时，升级到皮肤科，而不是继续加刺激
过程推荐降低踩雷概率，不保证某一类一定有效。

当礼物送时，怎样选才不像「踩雷瓶」？

不能替她做斑贴时，最好的礼物常常不是「最火那瓶」，而是你问过、你懂边界。
先问（比下单重要）：
  • 目标更像痘印、斑点，还是整体暗沉？
  • 是否备孕或怀孕？若正在哺乳，是否已问过医生？
  • 已知过敏、香精敏感、屏障是否脆弱？
  • 能否接受日常防晒？偏好无香还是可接受淡香？
  • 愿不愿意一起逛柜做斑贴，而不是盲盒惊喜？
可接受者，是类而不是 SKU：倾向无香精、单一活性起步类（例如烟酰胺类常被作为相对友好的讨论起点）+ 基础保湿 + SPF 30+（防晒系数）防晒，组成可退换的「起步套装」叙事。仪式感来自你把防晒和时间尺度写进短卡，而不是排名第一。
明确不要送：强酸剥脱、高浓度多酸堆叠、强维 A「新人礼」、七日神效话术瓶、来源不明的祛斑美白、以及口服美白药/针当节日礼物。
不确定时，默认策略是一起选，或礼品卡 + 你整理的成分类短名单——正文到此为止，仍然零商业单品点名。
阳光、炎症和激素把黑色素往上推，外观才出现暗沉与斑点；精华最多打断合成、转运或周转中的一步，关不住输入（UV）就会反弹。过强刺激制造新的 PIH（炎症后色沉）；合规标签与特证降低的是汞、氢醌一类系统性风险，不是替你保证美白速度。挑选是一条「诉求 → 粗分 → 成分类 → 斑贴 → 防晒 → 必要时就医」的过程——不是再追一份榜单。
参考来源（Evidence rechecked: 2026-08-16）
]]> <![CDATA[DeepSeek V4 Pro、Grok 4.6、Claude 与 ChatGPT：能力、价格和场景怎么选？]]> https://ximouzhao.com/article/choose-deepseek-v4-pro-or-grok-4-6 https://ximouzhao.com/article/choose-deepseek-v4-pro-or-grok-4-6 Thu, 13 Aug 2026 00:00:00 GMT
⚠️
你可能同时看到两种价格：API 每 100 万词元几美元，聊天产品每月几十美元。它们不能直接比较。API token 价格 ≠ 聊天订阅价格或可用额度：前者按程序调用量计费，后者购买的是网页或 App 里的模型、工具、界面和动态额度。

先别比模型：你买的是聊天产品还是 API？

假设你既想给自己的项目接入模型，又在考虑购买个人订阅。虽然两边都写着 DeepSeek、Grok、Claude 或 ChatGPT，实际买到的东西不同。
聊天产品是完整的网页或 App，包含模型路由、文件上传、联网搜索、语音等工具和产品额度。应用程序接口（Application Programming Interface，API）模型则由程序通过模型标识符（model ID）调用，按实际输入、输出、缓存和工具用量计费。
因此，本文分成两条路径：
两条路径最后仍回到同一个问题：模型是否能在你的场景里稳定完成任务，而不是它在一张总榜上排第几。

先写下任务：什么才算“更适合你”？

任务成功率是模型在预先写明的验收标准下，完成任务的比例。没有验收标准，“回答看起来不错”很容易变成主观印象。
完整任务成本也不只是 token 账单。它还包括推理、工具调用、失败重试、等待时间以及人工纠错。如果一个便宜模型需要三次重试，另一个较贵模型一次通过，后者的完整成本可能更低。
比较前先写下：
一组来自真实工作的输入，而不是临时编写的演示题。
可判定通过或失败的结果，例如测试通过、引用准确或字段完整。
必须具备的模态、工具和上下文。模态是文本、图片等输入类型；上下文是一次请求能同时处理的材料范围。
每天的任务量、可接受等待时间和预算。
失败后由谁修正，以及必须保留什么回退方案。
本文用八类常见场景贯穿两条路径：日常问答与写作、编程与终端任务、AI 智能体（AI Agent，模型多轮调用工具并根据结果继续行动的系统）、长文档、图片理解、中文任务、高量批处理和高价值复杂任务。

四个模型的能力差距，哪些值得相信？

基准测试（Benchmark）是在固定任务集和运行规则下比较模型的评测。推理努力档（reasoning effort）则控制模型为回答投入多少计算。模型版本、努力档和运行框架不同，分数就不能当成完全公平的单变量比较。
截至 2026 年 8 月 13 日，三个较有用的独立信号如下：
独立证据
当前结果
适合回答的问题
Artificial Analysis Intelligence Index（AA Index）v4.1.1
Claude Opus 5 max 63；GPT-5.6 Sol max 61；Grok 4.6 high 61；DeepSeek 0813 max 53
综合能力是否值得进入候选集
Terminal-Bench v2.1
GPT-5.6 Sol（xhigh）89.5%；Claude Opus 5（Adaptive Reasoning，max）89.1%；Grok 4.6（high）88.4%；DeepSeek V4 Pro 0813 暂无同一 Terminal-Bench v2.1 / Terminus 2 口径结果
终端智能体和编程任务的试用顺序
中文人类偏好榜
Claude high 1575±17；GPT xhigh 1543±19；Grok high 1535±34，且为 preliminary；DeepSeek 0813 票数证据不足
中文开放式回答的初步偏好信号
🧭
Benchmark ≠ IQ。分数描述的是某个精确版本、努力档和评测框架下的结果，不是通用智商，也不能证明它在你的任务里必胜。尤其是中文榜，置信区间、票数和版本证据都不支持宣布一个永久赢家。
厂商能力页仍然有用，但只能按厂商声明理解：Anthropic 将 Claude Opus 5 定位于复杂智能体编程和企业工作；OpenAI 将 GPT-5.6 Sol 定位于复杂专业工作并提供丰富的托管工具；xAI 将 Grok 4.6 定位于编程、智能体和知识工作。它们能说明产品设计方向，不能代替独立测试。
为什么这些基准不能直接排成通用名次？
AA 综合指数包含多个任务，但各模型使用的推理努力档不同。Terminal-Bench 使用指定智能体框架和终端环境，不能覆盖普通写作、视觉或你的内部工具。中文竞技场依赖人类偏好投票，票数、题材和置信区间都会影响排名。正确用法是按场景挑选候选，再用真实任务验证。

如果你选 API：同一任务的总成本和硬约束怎么比？

API 路径应使用精确模型 ID：deepseek-v4-pro、grok-4.6、claude-opus-5 和 gpt-5.6-sol。不要把聊天产品名称、网页端自动路由或相近版本的成绩混进来。
先看决定任务能否执行的硬约束：
API 模型
上下文 / 最大输出
输入；工具执行边界
推理控制
DeepSeek V4 Pro 0813
1M / 384K
文本；函数或工具调用由接入方执行
默认思考，可切换非思考
Grok 4.6
500K / 受上下文边界约束
文本、图片；Web/X 搜索与代码执行由 xAI 托管，函数调用由接入方执行
low 至 xhigh
Claude Opus 5
1M / 128K
文本、图片；Web/Fetch/代码执行等由 Anthropic 托管，Bash、电脑操作等由接入方执行
默认思考，多档 effort
GPT-5.6 Sol
1.05M / 128K
文本、图片；搜索、图片生成、代码和托管命令行环境（Shell）；电脑操作、模型上下文协议（Model Context Protocol，MCP）等按工具文档核对执行位置
none 至 max
以下价格均按每 100 万词元计算。DeepSeek 官方以人民币计价，另外三家以美元计价，两种货币不能直接比较；应按实际结算汇率换算。词元（token）是模型处理文字时使用的切片单位；缓存输入是重复前缀命中供应商缓存后的低价输入。
模型
未缓存输入 / 缓存 / 输出
长请求规则
50K 输入 + 2K 输出
DeepSeek
当前：¥3 / ¥0.025 / ¥6；8 月 17 日起谷时：¥4.5 / ¥0.15 / ¥13.5；峰时：¥9 / ¥0.30 / ¥27
8 月 17 日起采用峰谷价；当前未列长上下文附加档
当前 ¥0.162；新价谷时 ¥0.252、峰时 ¥0.504
Grok
$2 / $0.50 / $6
提示达到 200K 后整单变为 $4 / $1 / $12
$0.112
Claude
$5 / $0.50 / $25
1M 窗口维持标准价
$0.30
GPT
$5 / $0.50 / $30
输入超过 272K 后，整单输入 2 倍、输出 1.5 倍
$0.31
这个标准样例假设 50K 未缓存输入和 2K 输出，不含推理、工具、重试与缓存写入。DeepSeek 一行是人民币，其余三行是美元，需按实际结算汇率换算；即使单次调用便宜，也不能证明它完成同一业务结果的成本最低。
⏱️
DeepSeek 新峰谷价将于北京时间 2026 年 8 月 17 日 00:00 生效：9:00–12:00、14:00–18:00 为高峰，其余时段半价。本文发布时仍适用旧价；上线任务必须按实际调用日期和时段核算。Grok 的 200K、GPT 的 272K 还是整单价格边界。
缓存和完整任务成本怎样计算？
无缓存演示成本为：输入词元 ÷ 1,000,000 × 输入单价 + 输出词元 ÷ 1,000,000 × 输出单价。
真实成本还要加上缓存写入、推理词元、服务端工具、失败重试和人工修正。应比较 完成任务的总支出 ÷ 成功任务数，并同时记录等待时间。只有请求实际命中缓存时，缓存读取单价才有意义。
开放权重和自己部署什么时候才影响选择？
只有当数据边界、离线运行或避免供应商锁定是硬约束时，开放权重才应成为前置条件。可下载权重不等于容易或便宜地部署，也不能自动证明它与某个 API 快照完全一致。
目前不应把已有的 DeepSeek 可下载检查点直接视为 DeepSeek-V4-Pro-0813 API 的同一版本。Claude、Grok 与 GPT 的上述 API 模型也没有提供可自行部署的权重。若必须自建，应另做检查点、许可证、硬件和推理成本评估，而不是继续比较这四个托管 API。

如果你买订阅：该比较产品里的什么？

聊天订阅购买的是产品体验，不是一个固定数量的 API token。你真正需要比较的是：常用模型能否选择、文件与联网工具是否可用、额度如何共享，以及达到限制后工作是否会中断。
聊天产品
个人价格
已确认的产品能力
需要保留的不确定性
DeepSeek
网页与 App 免费
Web 搜索、DeepThink、文件上传
精确模型路由和固定额度未公开
Grok
免费开始；SuperGrok 付费
聊天、文件、图片/视频、语音、连接器
当前消费价格及 Grok 4.6 的精确可用性未稳定披露
Claude
Free $0；Pro $20/月或 $200/年；Max $100 起
网页与多端 App、搜索、文件、代码执行、Projects、连接器
模型访问和动态限制受套餐、任务与使用情况影响
ChatGPT
Free $0；Go 美国 $8；Plus $20；Pro 5x $100 或 20x $200
Web、文件、图片、语音、分析、Projects、Codex
工具和模型配额会变化
ChatGPT 当前给 Free 和 Go 用户提供 GPT-5.6 Luna；Plus 提供 GPT-5.6 Sol Medium 与 High；Pro 再增加 Extra High 和 Sol Pro。这里描述的是 ChatGPT 产品内访问，不代表订阅包含同名 API 的调用额度。
Claude Max 的 5x 或 20x、ChatGPT Pro 的 5x 或 20x，以及 SuperGrok 的共享周额度，都是相对产品基准的用量表达，不是固定消息数。长对话、文件、代码任务和高推理档可能消耗得更快。

八类场景里，谁更值得先试？

下面不是冠军榜，而是试用顺序。先排除缺少必要输入、工具或预算条件的候选，再让剩余模型处理同一批样例。
API 路径
场景
优先试用
主要原因或边界
日常问答与写作
四者并列盲测；若预算或吞吐是硬约束，先试 DeepSeek
写作顺序应由文风、事实可靠性和一次通过率决定；DeepSeek 只在成本约束成立时前置
编程与终端任务
GPT、Claude、Grok
独立 Terminal-Bench 证据接近；DeepSeek 0813 精确版本证据较少
AI Agent 与工具链
GPT、Claude、Grok
三者都有更直接的终端或智能体证据；先按所需工具的执行位置、接入成本和失败恢复能力筛选
长文档
DeepSeek、Claude、GPT；再试 Grok
前三者约 1M 上下文；注意 GPT 与 Grok 的整单涨价边界
图片理解
GPT、Claude、Grok
支持原生图片输入；DeepSeek 该 API 为文本输入
中文任务
四者盲测
当前证据不支持“DeepSeek 自动最好”或任何通用中文冠军
高量批处理
DeepSeek
按实际结算汇率比较；8 月 17 日后还要把调用时段、失败率和输出长度计入总成本
高价值复杂任务
Claude、GPT、Grok 并列试
前沿综合与智能体证据较强；重点看一次通过率和人工纠错
聊天产品路径
场景
优先试用
主要原因或边界
日常问答与写作
先用已有免费入口
DeepSeek、Grok、Claude、ChatGPT 均可低成本试；按文风和工具选择
编程与终端任务
Claude、ChatGPT 与账号可用的 Grok Build 同批实测
Claude Code、Codex 与 Grok Build 属于不同产品入口；应用同一仓库任务实测，不能仅凭功能清单判断谁更完整
AI Agent 与工具链
ChatGPT、Claude、Grok
比较 Codex、连接器、Projects 和共享额度，不把 API 能力自动映射过来
长文档
Claude、ChatGPT、Grok；同时试 DeepSeek 文件上传
用真实文件检查遗漏和引用；产品限制不等于 API 上下文上限
图片理解
ChatGPT、Claude、Grok
产品明确提供视觉或图片工作流；DeepSeek 官方证据仅确认文件上传与文本提取
中文任务
四者盲测
隐藏产品名称，用自己的中文写作、改写与事实题投票
高量批处理
转到 API 路径
聊天订阅额度动态，且不适合无人值守的可计量批处理
高价值复杂任务
Claude Max、ChatGPT Pro；再试 SuperGrok
高档计划提供更多使用空间；不能假定 SuperGrok 固定运行 Grok 4.6

怎样用真实任务决定单用、组合使用或维持现状？

选择不需要以“永久迁移”开始。先挑 20 至 50 个真实样例，隐藏模型名称，以相同输入、工具权限和验收标准运行。
固定样例、提示和必要材料，并记录精确模型 ID 或产品套餐。
同时记录通过率、错误类型、首个结果等待时间和任务总耗时。
API 记录输入、缓存、输出、推理、工具与重试账单。
聊天产品记录模型是否可选、额度消耗、文件与工具是否稳定可用。
让不知模型名称的评审者判断中文质量、引用准确性和可用性。
对失败任务记录人工修正时间，而不是只重跑到成功。
先将少量非关键流量交给候选模型，再逐步扩大。
保留现有模型、预算上限、超时和人工接管路径。
结果通常落在三种方案之一：
  1. 单用：一个候选在主要任务中稳定通过，完整成本和等待时间也可接受。
  1. 组合使用：DeepSeek 承担高量文本任务，Claude、GPT 或 Grok 处理高价值、视觉或工具密集任务；路由规则必须来自实测结果。
  1. 维持现状：新方案没有稳定改善，产品入口或额度不确定，或者节省的 token 费用不足以覆盖重试和人工修正。
最终顺序很简单：先区分聊天产品与 API，再定义真实任务；随后用模态、工具和上下文排除不满足硬约束的候选，比较完整任务成本与等待时间，最后才用真实样例决定单用、组合或维持现状。四个模型都可能在特定条件下合适，但没有一个名字可以替你跳过这条因果链。
资料与出处（能力评测截至 2026-08-13；价格复核于 2026-08-14）
]]>