Redis 浮点数累计主要是有两个命令
-
INCRBYFLOAT 是 SET 指令的浮点数累计 -
HINCRBYFLOAT 是 HASH 类型的浮点数累计
在内部 HINCRBYFLOAT 和 INCRBYFLOAT 自增实现相同。所以我们分析 INCRBYFLOAT 即可。
基本使用
直接使用指令
INCRBYFLOAT mykey 0.1
INCRBYFLOAT mykey 1.111
INCRBYFLOAT mykey 1.111111
使用 lua 脚本的方式,因为 redis 可以通过 lua 脚本来保证操作的原子性,所以当我们同时操作多个 key 的时候一般使用 lua 脚本的方式。
eval "return redis.call('INCRBYFLOAT', KEYS[1], ARGV[1])" 1 mykey1 "1.11"
eval "return redis.call('INCRBYFLOAT', KEYS[1], ARGV[1])" 1 mykey1 "1.11111"
eval "return redis.call('INCRBYFLOAT', KEYS[1], ARGV[1])" 1 mykey1 "1.11111"
INCRBYFLOAT 可表示范围
按照官方文档的说法 INCRBYFLOAT 可以表示小数位 17 位。比如按照 jedis 的 api 来说,我们能够使用的就是在 double 的精度范围内,也就是 15-16位。这里我也看了 redis 的源码,他在底层实现是通过 c 语言的 long double 类型来进行计算的。
void incrbyfloatCommand(client *c) {
long double incr, value;
robj *o, *new;
o = lookupKeyWrite(c->db,c->argv[1]);
if (checkType(c,o,OBJ_STRING)) return;
if (getLongDoubleFromObjectOrReply(c,o,&value,NULL) != C_OK ||
getLongDoubleFromObjectOrReply(c,c->argv[2],&incr,NULL) != C_OK)
return;
value += incr;
if (isnan(value) || isinf(value)) {
addReplyError(c,"increment would produce NaN or Infinity");
return;
}
new = createStringObjectFromLongDouble(value,1);
if (o)
dbReplaceValue(c->db,c->argv[1],new);
else
dbAdd(c->db,c->argv[1],new);
signalModifiedKey(c,c->db,c->argv[1]);
notifyKeyspaceEvent(NOTIFY_STRING,"incrbyfloat",c->argv[1],c->db->id);
server.dirty++;
addReplyBulk(c,new);
/* Always replicate INCRBYFLOAT as a SET command with the final value
* in order to make sure that differences in float precision or formatting
* will not create differences in replicas or after an AOF restart. */
rewriteClientCommandArgument(c,0,shared.set);
rewriteClientCommandArgument(c,2,new);
rewriteClientCommandArgument(c,3,shared.keepttl);
}
源码地址:https://github.com/redis/redis/blob/unstable/src/t_string.c long double 是 c 语言的长双精度浮点型,在 x86 的 64 位操作系统上占通常占用 16 字节(128 位),相较于 8 字节的 double 类型具有更大的范围和更高的精度。(这部分来源于 chatgpt) 因为 redis 采用的 long double 类型来做浮点数计算, 所以 redis 就可以保证到小数点后 17 位的精度。 整数位也可以表示 17 位 redis 的浮点数计算通常情况下会丢失精度吗? 通常情况下是不会的,但是不能保证一定不会。
浮点数范围测试
测试代码如下:
public class RedisIncrByFloatTest {
public static void main(String[] args) {
Jedis jedis = new Jedis("127.0.0.1", 6379);
BigDecimal decimalIncr = java.math.BigDecimal.ZERO;
String key = "IncrFloat:Digit100";
//测试精度
test_accuracy(jedis, decimalIncr, key);
//测试正浮点数最大值
test_max_positive_float(jedis, decimalIncr, key);
jedis.disconnect();
jedis.close();
}
private static void test_max_positive_float(Jedis jedis, BigDecimal decimalIncr, String key) {
jedis.del(key);
String value = "99999999999999999.00000000000000003";
List<String> evalKeys = Collections.singletonList(key);
List<String> evalArgs = Collections.singletonList(value);
String luaStr = "redis.call('INCRBYFLOAT', KEYS[1], ARGV[1]) return redis.call('GET', KEYS[1])";
Object result = jedis.eval(luaStr, evalKeys, evalArgs);
decimalIncr = decimalIncr.add(new BigDecimal(value));
BigDecimal redisIncr = new BigDecimal(String.valueOf(result));
value = "0.99999999999999996";
evalKeys = Collections.singletonList(key);
evalArgs = Collections.singletonList(value);
luaStr = "redis.call('INCRBYFLOAT', KEYS[1], ARGV[1]) return redis.call('GET', KEYS[1])";
result = jedis.eval(luaStr, evalKeys, evalArgs);
decimalIncr = decimalIncr.add(new BigDecimal(value));
redisIncr = new BigDecimal(String.valueOf(result));
boolean eq = comparteNumber(redisIncr, decimalIncr);
if (eq) {
System.out.println("累计结果正确, 整数位: " + 17 + "位, 结果期望值: decimalIncr " + decimalIncr.toPlainString() + ", 目标值(redis):" + redisIncr.toPlainString());
} else {
System.out.println("累计结果不正确, 整数位: " + 17 + "位, 期望值: decimalIncr " + decimalIncr.toPlainString() + ", 目标值(redis):" + redisIncr.toPlainString());
}
}
private static void test_accuracy(Jedis jedis, BigDecimal decimalIncr, String key) {
jedis.del(key);
for (int i = 16; i < 30; i++) {
String value = createValue(i);
final List<String> evalKeys = Collections.singletonList(key);
final List<String> evalArgs = Collections.singletonList(value);
String luaStr = "redis.call('INCRBYFLOAT', KEYS[1], ARGV[1]) return redis.call('GET', KEYS[1])";
Object result = jedis.eval(luaStr, evalKeys, evalArgs);
decimalIncr = decimalIncr.add(new BigDecimal(value));
BigDecimal redisIncr = new BigDecimal(String.valueOf(result));
boolean eq = comparteNumber(redisIncr, decimalIncr);
if (eq) {
System.out.println("累计结果正确, 整数位: " + i + "位, 结果期望值: decimalIncr " + decimalIncr.toPlainString() + ", 目标值(redis):" + redisIncr.toPlainString());
} else {
System.out.println("累计结果不正确, 整数位: " + i + "位, 期望值: decimalIncr " + decimalIncr.toPlainString() + ", 目标值(redis):" + redisIncr.toPlainString());
break;
}
}
}
private static String createValue(int i) {
String result = "9" + "0".repeat(Math.max(0, i - 1));
return result + ".00000000000000003";
}
private static boolean comparteNumber(BigDecimal redisIncr, BigDecimal decimalIncr) {
return decimalIncr.compareTo(redisIncr) == 0;
}
}
输出结果:
累计结果正确, 整数位: 16位, 结果期望值: decimalIncr 9000000000000000.00000000000000003, 目标值(redis):9000000000000000.00000000000000003
累计结果正确, 整数位: 17位, 结果期望值: decimalIncr 99000000000000000.00000000000000006, 目标值(redis):99000000000000000.00000000000000006
累计结果不正确, 整数位: 18位, 期望值: decimalIncr 999000000000000000.00000000000000009, 目标值(redis):999000000000000000
累计结果正确, 整数位: 17位, 结果期望值: decimalIncr 99999999999999999.99999999999999999, 目标值(redis):99999999999999999.99999999999999999
INCRBYFLOAT 导致精度丢失
INCRBYFLOAT 导致精度丢失有两种情况:
-
累计的范围值超过 INCRBYFLOAT 所能表示的最大精度范围,在 double 范围内。
INCRBYFLOAT 底层计算是通过long double 来计算的在 C语言中 long double占用128 位,其范围为: 最小值: ±5.4×10^-4951 最大值: ±1.1×10^4932 能表示的有效数字在34~35位之间。
-
我们使用类似 jedis 的 api 提供的是 double 类型的参数,可能在调用之前,参数转换的过程就发生了精度问题。比如
StringRedisTemplate template = new StringRedisTemplate();
template.opsForValue().increment("v1", 1.3D);
在 RedisTemplate 的这个 increment 接受的参数类型就是一个 double 所以会发生精度问题
C 语言长双精度类型
因为 redis 底层采用的是long double 计算,所以这个问题转化为长双精度(long double)为什么没有精度问题? 这是因为 long double 具有更大的范围和更高的精度。long double 的范围和精度高于 double 类型:
-
范围更大:long double 可以表示更大和更小的数字 -
精度更高:long double 可以表示的有效数字多于 double 类型这意味着,对于同样的浮点计算,long double 具有更少的舍入误差。
具体来说,几点原因造成 long double 没有精度问题:
-
long double 使用更多的bit位来表示浮点数。 -
long double 使用四舍五入(rounding to nearest)而不是银行家舍入(bankers' rounding),导致更少的误差累加。 -
许多编译器及 CPU 针对 long double 具有优化, 会生成精度更高的机器码来执行 long double 计算。 -
long double 内部采用更大的指数域, 能更准确地表示相同范围内的数字。
综上,long double 的更广范围和更高精度,让它在相同的浮点计算中具有更少的舍入误差。这也就解释了为什么 long double 没有明显的精度问题,因为它天生就是为了提供更高精度而设计的。相比之下,double 使用的位数相对有限,即使采用折中舍入法,在一些场景下它的误差也可能累加显著。所以总的来说,long double 之所以没有精度问题,主要还是源于其更大的范围和更高的内在精度。
问题总结
-
Redis 浮点数累计操作 INCRBYFLOAT 不适合精度要求比较高的金额计算。 -
Redis 浮点数累计操作 INCRBYFLOAT 也不能平替 BigDecimal 计算,如果一定需要存储可以考虑通过 lua 脚本实现 CAS 进行修改,最终存储为 String 类型的一个结果。 -
Redis 的浮点数虽然做了比较好的优化,但是没有从根本解决计算精度问题。
参考文档
-
https://redis.io/commands/incrbyfloat/ -
https://wiki.c2.com/?BankersRounding -
https://www.wikihow.com/Round-to-the-Nearest-Tenth -
https://learn.microsoft.com/zh-cn/cpp/c-language/type-long-double?view=msvc-170 -
https://learn.microsoft.com/zh-cn/cpp/c-runtime-library/reference/strtold-strtold-l-wcstold-wcstold-l?view=msvc-170
最后,求关注。如果你还想看更多优质原创文章,欢迎关注我们的公众号「运维开发故事」。
如果我的文章对你有所帮助,还请帮忙点赞、在看、转发一下,你的支持会激励我输出更高质量的文章,非常感谢!
你还可以把我的公众号设为「星标」,这样当公众号文章更新时,你会在第一时间收到推送消息,避免错过我的文章更新。
我是 老郑,《运维开发故事》公众号团队中的一员,某网资深 Java 工程师,10 余年 Java 互联网项目开发经验,擅长高并发、低延迟分布式互联网核心系统研发。这里不仅有硬核的技术干货,还有我们对技术的思考和感悟,欢迎关注我们的公众号,期待和你一起成长!