一个bug，差点损失几万

发布时间：2025-11-05 08:13:48 来源：码上建站 作者：应用开发

你好，差点我是损失猿java

最近遇到一个线上事故，差点损失好几万，差点故事是损失这样的...

在之前的文章里我们分析了 Redis中运行 Lua脚本是如何保证原子性的。实际上，差点在我们的损失电商业务中也是使用 Redis + Lua来保证库存的原子性操作，Redis是差点 Cluster集群部署，Lua脚本大致如下（本文的损失数据都经过脱敏处理）：

在上面的 Lua脚本中，有 {sku}语法的损失使用，{}是差点在 Redis cluster 模式下特有的 Hash Tag，Redis 的损失哈希标签是一种特殊的语法，网站模板用于在执行命令时将多个 key 分组在一起。差点Hash Tag 由一对大括号 {} 包围，可以将其中的内容视为一个整体来处理。

{}的主要用途包括：

例如，假设有两个 key：{sku}:saleStock 和 {sku}:avalibleStock。如果不使用哈希标签，即sku:saleStock 和 sku:avalibleStock，这两个 key 将被视为不同的 key，可能被映射到不同的哈希槽。这样，同一个 sku的不同库存可能被 hash到不同的b2b供应网 slot，但是，如果使用哈希标签 {sku}，这样，不管 {sku}拼接什么内容，都会被视为同一个分片，从而确保它们被映射到相同的哈希槽，以保证原子性操作的一致性。

更多{}使用,可以参考redis的官方文档。

监控报警，于是研发查排线上日志，如下：

看到这个错误，一脸懵，代码上线半年没有出现过问题，怎么会突然出问题呢？

因为第一次遇到这个问题，于是 Google了一下，找到几个类似的问题，大致意思差不多，下面给出一个stackover上面的例子，链接如下：stackoverflow相同的错误，Lua 脚本摘要如下：

对于错误的解释是：在 Lua中执行多条语句，要保证key hash的香港云服务器 slot是同一个，否则就会出现上面的错误，比如：KEYS[1]和 f3 hash后不在同一个 slot就会出现上述错误。

顺着上面 Google 例子的思路，排查 {sku} hash后的值是否出现变更，线上跑的代码，sku都是 14位的 Long，新上线的 sku 变成了 15位的 Long，会不会是长度变更导致问题？

于是，在中间件部门同事的配合下，找到了中间件的执行log：

太奇怪了，sku传入的是 Long类型，现在变成{1.112422310001e+14}，最后发现在 Redis中间件有个cjson的操作，当传入的 Long类型位数大于 14时，会把 Long转成科学计数法，导致{sku}改变了原有的语义。

在 Java 端，把 sku 从 Long型转成 String类型，再传入Lua，这样可以避免 Long被转换成科学记数法。

因为架构中有小流量集群，每次有新 sku上线，都会在小流量集群上进行灰度发布，所以受影响的面有限，最后定级 P4，保住了 Q2的绩效。

相关文章