Redission 分布式锁原理分析

最新推荐文章于 2024-04-30 08:56:04 发布
最新推荐文章于 2024-04-30 08:56:04 发布
阅读量24 收藏
点赞数
文章标签： 分布式
原文链接：https://mp.weixin.qq.com/s?__biz=MzUzMTA2NTU2Ng==&mid=2247590320&idx=3&sn=e4526af58fb9afc8d2296db779bacc5d&chksm=fbaa6107ff34f753d37e73ff80c4088b9561065ebce9684dba8a17fd11c8f6cc18047f8a4787&scene=126&sessionid=0
版权

👉 这是一个或许对你有用的社群

🐱 一对一交流/面试小册/简历优化/求职解惑，欢迎加入「芋道快速开发平台」知识星球。下面是星球提供的部分资料： 

43f8ee9b5d6352563a6ffff8b4415a6b.gif

👉这是一个或许对你有用的开源项目

国产 Star 破 10w+ 的开源项目，前端包括管理后台 + 微信小程序，后端支持单体和微服务架构。

功能涵盖 RBAC 权限、SaaS 多租户、数据权限、商城、支付、工作流、大屏报表、微信公众号、CRM 等等功能：

  • Boot 仓库：https://gitee.com/zhijiantianya/ruoyi-vue-pro

  • Cloud 仓库：https://gitee.com/zhijiantianya/yudao-cloud

  • 视频教程：https://doc.iocoder.cn

【国内首批】支持 JDK 21 + SpringBoot 3.2.2、JDK 8 + Spring Boot 2.7.18 双版本 

来源：老周聊架构

10bea5c27e8172d240ab4eeeb074a69f.jpeg

一、前言

我们先来说说分布式锁，为啥要有分布式锁呢? 像 JDK 提供的 synchronized、Lock 等实现锁不香吗？这是因为在单进程情况下，多个线程访问同一资源，可以使用 synchronized 和 Lock 实现；在多进程情况下，也就是分布式情况，对同一资源的并发请求，需要使用分布式锁实现。而 Redisson 组件可以实现 Redis 的分布式锁，同样 Redisson 也是 Redis 官方推荐分布式锁实现方案，封装好了让用户实现分布式锁更加的方便与简洁。

基于 Spring Boot + MyBatis Plus + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址：https://github.com/YunaiV/ruoyi-vue-pro

  • 视频教程：https://doc.iocoder.cn/video/

二、分布式锁的特性

  • 互斥性

    任意时刻，只能有一个客户端获取锁，不能同时有两个客户端获取到锁。

  • 同一性

    锁只能被持有该锁的客户端删除，不能由其它客户端删除。

  • 可重入性

    持有某个锁的客户端可继续对该锁加锁，实现锁的续租。

  • 容错性

    锁失效后（超过生命周期）自动释放锁（key失效），其他客户端可以继续获得该锁，防止死锁。

基于 Spring Cloud Alibaba + Gateway + Nacos + RocketMQ + Vue & Element 实现的后台管理系统 + 用户小程序，支持 RBAC 动态权限、多租户、数据权限、工作流、三方登录、支付、短信、商城等功能

  • 项目地址：https://github.com/YunaiV/yudao-cloud

  • 视频教程：https://doc.iocoder.cn/video/

三、Redisson 分布式锁原理

下面我们从加锁机制、锁互斥机制、锁续期机制、可重入加锁机制、锁释放机制等五个方面对 Redisson 分布式锁原理进行分析。

3.0 整体分析

注：redisson 版本 3.24.4-SNAPSHOT

public class RedissonLockTest {
    public static void main(String[] args) {
        Config config = new Config();
        config.useSingleServer()
            .setPassword("admin")
            .setAddress("redis://127.0.0.1:6379");

        RedissonClient redisson = Redisson.create(config);
        RLock lock = redisson.getLock("myLock");

        try {
            lock.lock();
            // 业务逻辑
        } finally {
            lock.unlock();
        }
    }
}

初始化 RedissonLock

d4a9b7ee4621c5ea41943645feaf589f.png 
/**
 * 加锁方法
 *
 * @param leaseTime 加锁到期时间（-1：使用默认值 30 秒）
 * @param unit 时间单位
 * @param interruptibly 是否可被中断标识
 * @throws InterruptedException
 */
private void lock(long leaseTime, TimeUnit unit, boolean interruptibly) throws InterruptedException {
    // 获取当前线程ID
    long threadId = Thread.currentThread().getId();
    // 尝试获取锁（重点）
    Long ttl = tryAcquire(-1, leaseTime, unit, threadId);
    // lock acquired
    // 成功获取锁, 过期时间为空。
    if (ttl == null) {
        return;
    }

    // 订阅分布式锁, 解锁时进行通知。
    CompletableFuture<RedissonLockEntry> future = subscribe(threadId);
    pubSub.timeout(future);
    RedissonLockEntry entry;
    if (interruptibly) {
        entry = commandExecutor.getInterrupted(future);
    } else {
        entry = commandExecutor.get(future);
    }

    try {
        while (true) {
            // 再次尝试获取锁
            ttl = tryAcquire(-1, leaseTime, unit, threadId);
            // lock acquired
            // 成功获取锁, 过期时间为空, 成功返回。
            if (ttl == null) {
                break;
            }

            // waiting for message
            // 锁过期时间如果大于零, 则进行带过期时间的阻塞获取。
            if (ttl >= 0) {
                try {
                    // 获取不到锁会在这里进行阻塞, Semaphore, 解锁时释放信号量通知。
                    entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                } catch (InterruptedException e) {
                    if (interruptibly) {
                        throw e;
                    }
                    entry.getLatch().tryAcquire(ttl, TimeUnit.MILLISECONDS);
                }
            } else {
                // 锁过期时间小于零, 则死等, 区分可中断及不可中断。
                if (interruptibly) {
                    entry.getLatch().acquire();
                } else {
                    entry.getLatch().acquireUninterruptibly();
                }
            }
        }
    } finally {
        // 取消订阅
        unsubscribe(entry, threadId);
    }
}
cbc6d4263db8b8c4fef11a9bde81e366.png

当锁超时时间为 -1 时，而且获取锁成功时，会启动看门狗定时任务自动续锁：

d17dd7f116dc5a5658e8119ef3a4081b.png dc2162a9ecc52b82c2f8c7f55afc3da8.png

每次续锁都要判断锁是否已经被释放，如果锁续期成功，自己再次调度自己，持续续锁操作。

为了保证原子性，用 lua 实现的原子性加锁操作，见 3.1 加锁机制。

3.1 加锁机制

加锁机制的核心就是这段，将 Lua 脚本被 Redisoon 包装最后通过 Netty 进行传输。

<T> RFuture<T> tryLockInnerAsync(long waitTime, long leaseTime, TimeUnit unit, long threadId, RedisStrictCommand<T> command) {
    /**
     * // 1
     * KEYS[1] 代表上面的 myLock
     * 判断 KEYS[1] 是否存在, 存在返回 1, 不存在返回 0。
     * 当 KEYS[1] == 0 时代表当前没有锁
     * // 2
     * 查找 KEYS[1] 中 key ARGV[2] 是否存在, 存在回返回 1
     * // 3
     * 使用 hincrby 命令发现 KEYS[1] 不存在并新建一个 hash
     * ARGV[2] 就作为 hash 的第一个key, val 为 1
     * 相当于执行了 hincrby myLock 91089b45... 1
     * // 4
     * 设置 KEYS[1] 过期时间, 单位毫秒
     * // 5
     * 返回 KEYS[1] 过期时间, 单位毫秒
     */
    return evalWriteAsync(getRawName(), LongCodec.INSTANCE, command,
            "if ((redis.call('exists', KEYS[1]) == 0) " + // 1
                        "or (redis.call('hexists', KEYS[1], ARGV[2]) == 1)) then " + // 2
                    "redis.call('hincrby', KEYS[1], ARGV[2], 1); " + // 3
                    "redis.call('pexpire', KEYS[1], ARGV[1]); " + // 4
                    "return nil; " +
                "end; " +
                "return redis.call('pttl', KEYS[1]);", // 5
            Collections.singletonList(getRawName()), unit.toMillis(leaseTime), getLockName(threadId));
}

断点走一波就很清晰了：

3be3922f7d9d2aba9cb7f261abd864da.png

KEYS[1]) ：加锁的key ARGV[1] ：key的生存时间，默认为30秒 ARGV[2] ：加锁的客户端ID (UUID.randomUUID()） + “:” + threadId)

84a4b1622136815dd3b242e50a5a4c46.png

上面这一段加锁的 lua 脚本的作用是：第一段 if 判断语句，就是用 exists myLock 命令判断一下，如果你要加锁的那个锁 key 不存在的话（第一次加锁）或者该 key 的 field 存在（可重入锁），你就进行加锁。如何加锁呢？使用 hincrby 命令设置一个 hash 结构，类似于在 Redis 中使用下面的操作：

cfd7047ed78ff9aa8246070feb315b53.png

整个 Lua 脚本加锁的流程画图如下：

5c3adef027d8f520b0bc7f2d5b4ad7cf.png

可以看出，最新版本的逻辑比之前的版本更简单清晰了。

3.2 锁互斥机制

此时，如果客户端 2 来尝试加锁，会如何呢？首先，第一个 if 判断会执行 exists myLock，发现 myLock 这个锁 key 已经存在了。接着第二个 if 判断，判断一下，myLock 锁 key 的 hash 数据结构中，是否包含客户端 2 的 ID，这里明显不是，因为那里包含的是客户端 1 的 ID。所以，客户端 2 会执行：

return redis.call('pttl', KEYS[1]);

返回的一个数字，这个数字代表了 myLock 这个锁 key 的剩余生存时间。

锁互斥机制主流程其实在 3.0 整体分析 里有讲，具体可以看这个 org.redisson.RedissonLock#lock(long, java.util.concurrent.TimeUnit, boolean) 方法。

3.3 锁续期机制

客户端 1 加锁的锁 key 默认生存时间是 30 秒，如果超过了 30 秒，客户端 1 还想一直持有这把锁，怎么办呢？

Redisson 提供了一个续期机制， 只要客户端 1 一旦加锁成功，就会启动一个 Watch Dog。

3.4 可重入加锁机制

ce02ffdb6275943cbd40af0dcc694be0.png e56ba2cf168e245b49aa3664dce3dda4.png

Watch Dog 机制其实就是一个后台定时任务线程，获取锁成功之后，会将持有锁的线程放入到一个 RedissonBaseLock.EXPIRATION_RENEWAL_MAP 里面，然后每隔 10 秒 （internalLockLeaseTime / 3） 检查一下，如果客户端 1 还持有锁 key（判断客户端是否还持有 key，其实就是遍历 EXPIRATION_RENEWAL_MAP 里面线程 id 然后根据线程 id 去 Redis 中查，如果存在就会延长 key 的时间），那么就会不断的延长锁 key 的生存时间。

注：

  1. 如果服务宕机了，Watch Dog 机制线程也就没有了，此时就不会延长 key 的过期时间，到了 30s 之后就会自动过期了，其他线程就可以获取到锁。

  2. 如果调用带过期时间的 lock 方法，则不会启动看门狗任务去自动续期。

3.5 锁释放机制

5b91fe76de0c72ee9b657e45005ea513.png 
// 判断 KEYS[1] 中是否存在 ARGV[3]
"if (redis.call('hexists', KEYS[1], ARGV[3]) == 0) then " +
    "return nil;" +
"end; " +
// 将 KEYS[1] 中 ARGV[3] Val - 1
"local counter = redis.call('hincrby', KEYS[1], ARGV[3], -1); " +
// 如果返回大于0 证明是一把重入锁
"if (counter > 0) then " +
    // 重置过期时间
    "redis.call('pexpire', KEYS[1], ARGV[2]); " +
    "return 0; " +
"else " +
    // 删除 KEYS[1]
    "redis.call('del', KEYS[1]); " +
    // 通知阻塞等待线程或进程资源可用
    "redis.call('publish', KEYS[2], ARGV[1]); " +
    "return 1; " +
"end; " +
"return nil;"

KEYS[1]: myLock KEYS[2]: redisson_lock_channel:{myLock} ARGV[1]: 0 ARGV[2]: 30000 (过期时间) ARGV[3]: 66a84a47-3960-4f3e-8ed7-ea2c1061e4cf:1 (Hash 中的锁 field)

同理，锁释放断点走一波：

e77bff0f02e6896659cd7282c23682e6.png

锁释放机制小结一下：

  • 删除锁（这里注意可重入锁）

  • 广播释放锁的消息，通知阻塞等待的进程（向通道名为 redisson_lock__channel:{myLock} publish 一条 UNLOCK_MESSAGE 信息）

  • 取消 Watch Dog 机制，即将 RedissonLock.EXPIRATION_RENEWAL_MAP 里面的线程 id 删除，并且 cancel 掉 Netty 的那个定时任务线程。

四、主从 Redis 架构中分布式锁存在的问题

  • 线程A从主redis中请求一个分布式锁，获取锁成功；

  • 从redis准备从主redis同步锁相关信息时，主redis突然发生宕机，锁丢失了；

  • 触发从redis升级为新的主redis；

  • 线程B从继任主redis的从redis上申请一个分布式锁，此时也能获取锁成功；

  • 导致，同一个分布式锁，被两个客户端同时获取，没有保证独占使用特性；

为了解决这个问题，redis引入了红锁的概念。

需要准备多台redis实例，这些redis实例指的是完全互相独立的Redis节点，这些节点之间既没有主从，也没有集群关系。客户端申请分布式锁的时候，需要向所有的redis实例发出申请，只有超过半数的redis实例报告获取锁成功，才能算真正获取到锁。跟大多数保证一致性的算法类似，就是多数原理。

public static void main(String[] args) {
    String lockKey = "myLock";
    Config config = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6379");
    Config config2 = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6380");
    Config config3 = new Config();
    config.useSingleServer().setPassword("123456").setAddress("redis://127.0.0.1:6381");

    RLock lock = Redisson.create(config).getLock(lockKey);
    RLock lock2 = Redisson.create(config2).getLock(lockKey);
    RLock lock3 = Redisson.create(config3).getLock(lockKey);

    RedissonRedLock redLock = new RedissonRedLock(lock, lock2, lock3);

    try {
        redLock.lock();
    } finally {
        redLock.unlock();
    }
}

当然, 对于 Redlock 算法不是没有质疑声，两位大神前几年吵的沸沸腾腾，大家感兴趣的可以去 Redis 官网查看Martin Kleppmann 与 Redis 作者Antirez 的辩论。

额，想收一收了，再讲下去感觉要绕不开分布式经典问题 CAP了。

五、分布式锁选型

鱼和熊掌不可兼得，如果你想强一致性的话可以选择 ZK 的分布式锁，但 ZK 的话性能就会有一定的下降，如果项目没有用到 ZK 的话，那就选择 Redis 的分布式锁吧，比较你为了那极小的概率而丢去性能以及引入一个组件很不划算，如果无法忍受 Redis 的红锁缺陷，那自己在业务中自己保证吧。

下面是常见的几种分布式锁选型对比：

8a2240acfd0cb285f58eda7350f5865b.png

欢迎加入我的知识星球，全面提升技术能力。

👉 加入方式，“长按”或“扫描”下方二维码噢：

d2f0704db5aab554cc4f670e40136c7e.png

星球的内容包括：项目实战、面试招聘、源码解析、学习路线。

3f36ed4b1466489c9c7a0e369a074d91.png

9972180740fbe61c4f413abd070d487d.png3ae458861bb10fbef55daa91fc5f6f94.png1407faef6fbf8d6b09a3e75dc42382e4.pngaef48810ff7138592dbc68a8e7d2fcda.png

文章有帮助的话，在看，转发吧。
谢谢支持哟 (*^__^*）
公众号-芋道源码
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
redission分布式锁工具类
07-18
redission分布式锁工具类，在分布式系统中需要加锁可以直接使用
Redission分布式锁详解
qq_36010886的博客
07-27 9020
​ 在分布式系统中，当不同进程或线程一起访问共享资源时，会造成资源争抢，如果不加以控制的话，就会引发程序错乱。而分布式锁它采用了一种互斥机制来防止线程或进程间相互干扰，从而保证了数据的一致性。​ **Redission是一个基于Redis实现的Java分布式对象存储和缓存框架。它提供了丰富的分布式数据结构和服务。**例如：分布式锁、分布式队列、分布式Rate Limiter等。
Redission分布式锁加锁解锁获取锁源码分析
农夫三拳
04-11 664
原理：前置学习：Redis发布订阅模式，学不会别来。
Redis分布式锁-这一篇全了解(Redission实现分布式锁完美方案)
热门推荐
Coder
09-03 11万+
前言 在某些场景中，多个进程必须以互斥的方式独占共享资源，这时用分布式锁是最直接有效的。 随着技术快速发展，数据规模增大，分布式系统越来越普及，一个应用往往会部署在多台机器上（多节点），在有些场景中，为了保证数据不重复，要求在同一时刻，同一任务只在一个节点上运行，即保证某一方法同一时刻只能被一个线程执行。在单机环境中，应用是在同一进程下的，只需要保证单进程多线程环境中的线程安全性，通过 JAVA 提供的 volatile、ReentrantLock、synchronized 以及 concurrent
Redission分布式锁
jueduifeng的博客
03-14 520
Redission分布式锁 使用及原理 //看门狗（锁） RLock lock = redisson.getLock("myLock"); lock.lock(); lock.unlock(); 加锁机制（源码Lua脚本分析1） 某个客户端要加锁，如果他面对的是一个redis cluster集群，他首先会根据hash节点选择一台机器。这里注意，仅仅只是选择一台机器！这点很关键！ 紧接着，就会发...
Java注解如何基于Redission实现分布式锁
08-25
主要介绍了Java注解如何基于Redission实现分布式锁,文中通过示例代码介绍的非常详细，对大家的学习或者工作具有一定的参考学习价值,需要的朋友可以参考下
记录redisson实现redis分布式事务锁
04-24
自己封装redisson方法，同时通过注解的方式加入redis分布式事务锁，可靠。
springboot 集成Redission 简单完美解决分布式锁
06-03
springboot 集成Redission 简单完美解决分布式锁,上手看一眼就会
分布式锁原理讲解视频资料
09-19
分布式锁的原理、实现方式、应用场景，经典学习视频。
debian配置distcc分布式编译
随手写下笔记和感悟
04-24 628
distcc 是一个用于在网络上的多台机器上分发 C、C++、Objective C 或 Objective C++ 代码构建的程序。distcc 应始终生成与本地构建相同的结果，易于安装和使用，并且通常比本地编译快得多。distcc 不要求所有机器共享文件系统、同步时钟或安装相同的库或头文件。如果安装了交叉编译器，它们甚至可以具有不同的处理器或操作系统。它甚至不要求远程主机安装额外类库。
Kafka：分布式流处理平台的深度解析
shiranyyds的博客
04-21 1621
Kafka：分布式流处理平台的深度解析
pytest-xdist：远程多主机 - 分布式运行自动化测试
we chat：玩转测试开发
04-26 921
需要特别注意的是rsync功能被弃用，因为它的实现在远程工作者中再现开发环境方面存在缺陷，而且没有明确的解决方案。出于这个原因，rsync计划在4.0版中删除，让团队专注于一组较小的功能。请注意，SSH和套接字服务器不是计划删除的，因为它们是execnet功能集的一部分。：pytest-xdist插件使用新的测试执行模式扩展了pytest，最常用的是在多个CPU之间分发测试以加快测试执行，即。：在远程服务器端会生成一份相应的项目数据，因为我们使用的是 ./ 即 把当前项目远程拷贝到目标服务器执行。
Seata分布式原理及优势
y666__的博客
04-30 330
Tc global_table 全局 xid branch_table 分支的信息 lock_table 此时此刻锁的表。2、每个业务库都有自己的undo_log表：业务sql操作之前和之后的镜像数据。回滚的之后恢复数据，正常成功后 异步删除。业务库 undo_log。1、长事务分成多个短事务。锁资源时间短，效率高。
分布式与一致性协议之CAP(一)
Cover_sky的博客
04-24 1326
在开发分布式系统的时候，会遇到一个非常棘手的问题，那就是如何根据业务特点，为系统设计合适的分区容错一致性模型，以实现集群能力。这个问题棘手在当发生分区错误时，应该如何保障系统稳定运行而不影响业务。CAP理论对分布式系统的特性做了高度抽象，比如抽象成一致性、可用性、分区容错性，并对特性间的冲突(也就是CAP不可能三角)做了总结。问题来了:什么是一致性、可用性和分区容错性？它们之间有什么关系？我们又该如何使用CAP理论来思考和设计分区容错一致性模型呢？
分布式与一致性协议之拜占庭将军问题(三)
Cover_sky的博客
04-23 1333
CFT算法解决的是分布式系统中存在故障，但不存在恶意节点的场景下的共识问题。也就是说，这个场景可能会丢失消息或者有消息重复，但不存在错误消息或者伪造消息的情况，常见的CFT算法有Paxos算法、Raft算法、ZAB协议。需要注意的是，拜占庭将军问题描述的是最困难，也是最复杂的一种分布式故障场景，该场景除了存在故障行为，还存在恶意行为。在存在恶意行为的场景中(比如在数字货币的区块链技术中)，我们必须使用拜占庭容错算法还有PBFT算法、POW算法。反之则推荐使用拜占庭容错算法，例如区块链中使用Pow算法。
【分布式通信】NPKit，NCCL的Profiling工具
参谋谋的博客
04-25 697
以NCCL为例，如何使用？
分布式与一致性协议之CAP(二)
Cover_sky的博客
04-24 1021
CAP不可能三角是指对于一个分布式系统而言，一致性、可用性、分区容错性指标不可兼得，只能从中选择两个，如图所示。CAP不可能三角最初是埃里克·布鲁尔(Eric Brewer)基于自己的工程实践提出的一个猜想，后被塞斯·吉尔伯特(Seth Gilbert)和南希·林奇(Nancy Lynch)证明，(https://dl.acm.org/citation.cfm?id=564601)基于证明的严谨性的考虑，塞斯吉尔伯特和南希林奇对指标的含义做了预设和限制，比如，将一致性限制为原子一致性。
后端开发是一个涉及广泛技术和工具的领域.docx
最新发布
04-30
后端开发是一个涉及广泛技术和工具的领域，这些资源对于构建健壮、可扩展和高效的Web应用程序至关重要。以下是对后端开发资源的简要介绍： 首先，掌握一门或多门编程语言是后端开发的基础。Java、Python和Node.js是其中最受欢迎的几种。Java以其跨平台性和丰富的库而著名，Python则因其简洁的语法和广泛的应用领域而备受欢迎。Node.js则通过其基于JavaScript的单线程异步I/O模型，为Web开发提供了高性能的解决方案。 其次，数据库技术是后端开发中不可或缺的一部分。关系型数据库（如MySQL、PostgreSQL）和非关系型数据库（如MongoDB、Redis）各有其特点和应用场景。关系型数据库适合存储结构化数据，而非关系型数据库则更适合处理大量非结构化数据。 此外，Web开发框架也是后端开发的重要资源。例如，Express是一个基于Node.js的Web应用开发框架，它提供了丰富的API和中间件支持，使得开发人员能够快速地构建Web应用程序。Django则是一个用Python编写的Web应用框架，它采用了MVC的软件设计模式，使得代码结构更加清晰和易于维护。
redission分布式锁原理
03-30
Redission分布式锁的原理是基于Redis的原子性操作实现的。当多个进程或线程试图获取同一个锁时，只有一个进程或线程能够成功获取锁，其他进程或线程则需要等待锁的释放。 具体实现步骤如下： 1. 在Redis中创建一个...

“相关推荐”对你有帮助么？

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值