跨实例
在分布式系统中，“跨实例”指的是多个独立部署的服务进程（实例），在协作处理同一任务或操作同一资源时的交互场景。简单说，就是“你的代码不是只在一台机器/一个进程里跑，而是在多台机器/多个进程里跑，这些进程之间需要协同工作”——这也是分布式系统区别于单体系统的核心特征，更是分布式锁要解决的核心问题。
一、先理解“实例”：什么是服务实例？
在解释“跨实例”前，先明确“实例”的概念：
当你把一个Java服务（如淘票票的支付服务）打包成Jar/War包后，每启动一次这个Jar包，就生成一个“服务实例”。每个实例拥有独立的内存空间、线程池，运行在独立的进程中（甚至不同的服务器上）。
举个具体例子：
你开发了一个支付服务pay-service，为了应对高并发（如淘票票的节假日高峰期），你在3台服务器上各启动了一个pay-service进程：
- 实例1：运行在服务器A（IP：192.168.0.101）
- 实例2：运行在服务器B（IP：192.168.0.102）
- 实例3：运行在服务器C（IP：192.168.0.103）
这3个pay-service进程，就是3个“服务实例”，它们的代码完全相同，但运行环境、内存数据完全独立。
二、“跨实例”场景：多个实例如何交互？
“跨实例”的核心是“多个实例共享同一资源或协作处理同一任务”，最典型的场景就是并发操作同一数据——这也是分布式锁要解决的痛点。
以淘票票的“支付”场景为例，看看“跨实例”会带来什么问题：
- 用户小明点击“支付”按钮，请求被负载均衡器分配到实例1；
- 几乎同时，小明误触再次点击“支付”，第二个请求被分配到实例2；
- 两个实例同时执行“支付逻辑”：查询订单状态→调用支付渠道→扣减金额；
- 若没有分布式锁控制，会导致小明被“重复支付”（扣两次钱）。
这个场景中，实例1和实例2就是“跨实例”，它们在无协调的情况下操作同一订单资源，引发并发冲突。
三、为什么“本地锁”解决不了跨实例问题？
很多人会疑惑：“我在代码里用synchronized或ReentrantLock加了锁，为什么还会出现跨实例并发问题？”
因为synchronized、ReentrantLock是本地锁，它们的作用范围仅限于“单个实例内部”，无法跨实例生效。
还是以支付场景为例：
- 实例1中的
synchronized锁，只能控制实例1内部的线程并发（如实例1的线程1和线程2不会同时执行支付）； - 但实例1的锁“管不到”实例2，实例2的线程仍能自由执行支付逻辑；
- 最终两个实例还是会并发操作同一订单，导致重复支付。
这就是“跨实例”场景的核心挑战：本地锁只能控制单实例内的并发，跨实例的并发需要“所有实例都能识别的共享锁”——这也是分布式锁（如Redisson实现的锁）的价值所在。
四、“跨实例”场景的解决方案：共享锁+统一协调
要解决跨实例的并发问题，核心是让所有实例“共享同一把锁”，通常需要一个独立的第三方协调组件（如Redis、ZooKeeper、Etcd）来存储锁信息，确保所有实例都能“看到”锁的状态。
以淘票票的Redisson分布式锁为例，跨实例的协调流程是：
- 实例1和实例2在执行支付前，都会向Redis请求获取“订单123”的锁；
- Redis通过
Hash结构记录锁的持有者（如实例1的线程），实例2请求时会发现锁已被占用； - 实例1执行完支付后，向Redis释放锁；
- Redis删除锁记录，实例2才能获取到锁（若仍有请求）。
在这个流程中，Redis就是“统一协调组件”，所有实例通过Redis判断锁的状态，从而实现跨实例的并发控制。
五、总结：“跨实例”是分布式系统的核心特征
- 定义：多个独立的服务实例，协作处理同一任务或操作同一资源的场景；
- 痛点：本地锁失效，易出现重复操作、数据不一致等并发问题；
- 解决方案：通过Redis、ZooKeeper等组件实现分布式锁，让所有实例共享同一把锁；
- 典型场景：淘票票的支付防重复、电影票库存防超卖、订单状态同步等。
理解“跨实例”，就能理解分布式锁的必要性——它本质是为了解决“多个独立进程如何安全共享资源”的问题，是分布式系统高并发防护的核心技术。