https://blog.leanku.com/categories/microservice/ Recent content in Microservice on Leanku https://blog.leanku.com/papermod-cover.png https://blog.leanku.com/papermod-cover.png Hugo -- gohugo.io Wed, 11 Jun 2025 20:46:01 +0800 https://blog.leanku.com/post/microservice/%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E8%AF%A6%E8%A7%A3/ Wed, 11 Jun 2025 20:46:01 +0800 https://blog.leanku.com/post/microservice/%E5%88%86%E5%B8%83%E5%BC%8F%E9%94%81%E8%AF%A6%E8%A7%A3/ 分布式锁详解 在高并发和分布式系统中，为保证资源的一致性和互斥访问，分布式锁是必不可少的技术手段。本文将系统地讲解分布式锁的概念、场景、实现原理、使用方式，并附 PHP 示例。 1. 什么是分布式锁 定义： 分布式锁（Distributed Lock）是用于在 多台机器或多个服务实例中控制共享资源访问的机制。它保证在同一时间，只有一个客户端可以操作某个资源，从而避免并发冲突。 特点： 互斥性：同一时间只有一个客户端持有锁。 可重入性（可选）：同一客户端可以重复获取锁。 可靠性：锁过期或客户端异常可自动释放，避免死锁。 可扩展性：适用于分布式系统和微服务架构。 2. 分布式锁的应用场景 分布式锁在企业场景非常常见，典型使用场景包括： 库存扣减 秒杀或抢购场景，防止库存超卖。 订单号生成 保证全局唯一订单号。 任务调度 多实例系统中，保证任务只被单实例执行。 缓存更新 防止缓存击穿时，多实例同时重建缓存。 支付或转账操作 防止重复扣款或资金异常。 3. 分布式锁的实现原理 3.1 数据库锁 原理： 利用数据库唯一索引或事务机制创建锁记录。 示例： INSERT INTO locks(name, create_time) VALUES('order_123', NOW()); -- 成功表示获得锁，失败表示锁已被占用 优缺点： 优点：简单易用，直接使用现有数据库。 缺点：高并发性能较差，数据库可能成为瓶颈。 3.2 Redis 锁 原理： 利用 Redis 的 SETNX 或 SET key value NX PX 原子操作。 设置锁过期时间，防止死锁。 (RedLock红锁可以解决在 Redis ​主从复制或哨兵模式下，使用单实例 Redis 锁可能遇到的锁失效问题。) 释放锁： 需要验证当前客户端持有锁，防止误删他人锁。 优点： https://blog.leanku.com/post/microservice/%E5%85%B3%E4%BA%8E%E5%88%86%E5%B8%83%E5%BC%8F/ Tue, 11 Jun 2024 20:46:01 +0800 https://blog.leanku.com/post/microservice/%E5%85%B3%E4%BA%8E%E5%88%86%E5%B8%83%E5%BC%8F/ 关于分布式 一、什么是分布式？ 一个系统，各组件分别部署在不同服务器。彼此通过网络通信和协调的系统。 可以指多个不同组件分布在网络上互相协作 也可以一个组件的多个副本组成集群，互相协作如同一个组件，比如数据存储服务中心为了数据不丢失而采取的多个服务备份冗余 分布式最早出现的目的首先是解决单点问题，避免单点故障，然后解决了性能问题 二、分布式和微服务的区别？ 微服务并不一定是分布式系统（微服务中多个服务不一定部署在不同服务器，单机部署情况则不算是分布式） 分布式一定不是微服务 （分布式祖耀侧重服务的部署方式，微服务则是针对应用的一种服务拆分的架构） 三、分布式CAP原则 在设计一个分布式项目的时候会遇到三个特性： 一致性（Consistency）：所有节点数据实时同步，读取始终返回最新值 可用性（Availability）：每个请求必须得到响应（无论数据是否最新），高可用 分区容错（Partition Tolerance）：分布式最基本也是必需要有的特性，系统在遇到某个节点或网络分区故障时，仍然能够对外提供服务 三者无法同时满足，最多只能实现其中两个，网络分区发生时，必须牺牲C或A ‌CP（牺牲可用性）‌：如ZooKeeper，确保数据强一致性但可能拒绝请求 ‌AP（牺牲一致性）‌：如Eureka，保证服务可用但允许数据短暂不一致 三、 BASE理论 BASE理论是分布式系统设计原则，BASE 是指基本可用（Basically Available）、软状态（ Soft State）、最终一致性（ Eventual Consistency），核心思想是即使无法做到强一致性（CAP 的一致性就是强一致性），但应用可以采用适合的方式达到最终一致性。 基本可用（Basically Available）：分布式系统，在出现故障的时候，允许损失部分可用性。类似服务降级 软状态（Soft State）：允许系统存在中间状态，而该中间状态不会影响系统整体可用性。这里的中间状态就是 CAP 理论中的数据不一致。 最终一致性（Eventual Consistency）：系统中的所有数据副本经过一定时间后，最终能够达到一致的状态。 四、分布式事务及解决方案 分布式事务 本地事务依赖数据库本身提供的事务特性来实现， 但是在分布式环境下，可能会出现需要远程调用，比如： begin transaction； //1.本地数据库操作：张三减少金额 //2.远程调用：让李四增加金额 commit transation; 张三和李四的账户不在一个数据库中甚至不在一个应用系统里，实现转账事务需要通过远程调用，由于网络问题就会导致分布式事务问题。 分布式事务解决方案 2PC 2PC 即两阶段提交协议，是将整个事务流程分为两个阶段，准备阶段（Prepare phase）、提交阶段（commit phase），2 是指两个阶段，P 是指准备阶段，C 是指提交阶段。偏向数据库 TCC TCC 是 Try、Confirm、Cancel 三个词语的缩写，TCC 要求每个分支事务实现三个操作：预处理 Try、确认 Confirm、撤销 Cancel。Try 操作做业务检查及资源预留，Confirm 做业务确认操作，Cancel 实现一个与 Try 相反的操作即回滚操作。TM 首先发起所有的分支事务的 Try 操作，任何一个分支事务的Try操作执行失败，TM 将会发起所有分支事务的 Cancel 操作，若 Try 操作全部成功，TM 将会发起所有分支事务的 Confirm 操作，其中 Confirm/Cancel 操作若执行失败，TM 会进行重试。偏向代码