老冀_个人页_阿里云开发者社区

老冀_个人页

MySQL InnoDB中的锁-插入意向锁（Insert Intention Lock）

锁列表共享与列排他锁意向锁记录锁间隙锁Next-Key锁插入意向锁AUTO-INC锁这次我们只来讨论和实验意向锁。插入意向锁插入意向锁是一种间隙锁形式的意向锁，在真正执行 INSERT 操作之前设置。当执行插入操作时，总会检查当前插入操作的下一条记录（已存在的主索引节点）上是否存在锁对象，判断是否锁住了 gap，如果锁住了，则判定和插入意向锁冲突，当前插入操作就需要等待，也就是配合上面的间隙锁或者临键锁一起防止了幻读操作。因为插入意向锁是一种意向锁，意向锁只是表示一种意向，所以插入意向锁之间不会互相冲突，多个插入操作同时插入同一个 gap 时，无需互相等待，比如当前索引上有记录 4 和 8，两个并发 session 同时插入记录 6，7。他们会分别为(4,8)加上 GAP 锁，但相互之间并不冲突INSERT 语句在执行插入之前，会先在 gap 中加入插入意向锁，如果是唯一索引，还会进行 Duplicate Key 判断，如果存在相同 Key 且该 Key 被加了互斥锁，则还会加共享锁，然后等待（因为这个相同的 Key 之后有可能会回滚删除，这里非常容易死锁）。等到成功插入后，会在这条记录上加排他记录锁实验建表语句：CREATE TABLE `sys_user` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(10) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '姓名', `name_pinyin` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '姓名拼音', `id_card` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL COMMENT '身份证号', `phone` varchar(20) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci DEFAULT NULL COMMENT '手机号', `age` int(11) NOT NULL DEFAULT 1 COMMENT '年龄', PRIMARY KEY (`id`), UNIQUE KEY `uni_idx_id_card` (`id_card`) USING BTREE COMMENT '唯一索引-身份证号', KEY `idx_phone_name` (`phone`,`name`) USING BTREE COMMENT '普通索引-手机号' ) ENGINE=InnoDB AUTO_INCREMENT=3495 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci COMMENT='用户' 插入记录insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (1, '小六', 'xiaoliu', 300000000, 13000008000, 10); insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (2, '小六', 'xiaoliu', 300000001, 13000008000, 11); insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (3, '小六', 'xiaoliu', 300000002, 13000008000, 13); insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (4, '小六', 'xiaoliu', 300000003, 13000008000, 20); 记录锁插入意向锁插入间隙锁区间内（age字段）阻塞等待时刻事务A事务B1begin;begin;2select * from sys_user where age=13 for update; (在11和20之间添加了间隙锁）) 3 insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (5, '小六', 'xiaoliu', 300000004, 13000008000, 12);（阻塞等待）在事务B阻塞等待时，使用show engine innodb status查看事务(内容删除了一部分）：---TRANSACTION 133643386, ACTIVE 34 sec inserting insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (5, '小六', 'xiaoliu', 300000004, 13000008000, 19) ------- TRX HAS BEEN WAITING 28 SEC FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 484 page no 46 n bits 80 index idx_age of table `employees`.`sys_user` trx id 133643386 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 5 ------------------两个插入意向锁插入相同间隙（age字段）正常插入时刻事务A事务B1begin;begin;2insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (5, '小六', 'xiaoliu', 300000004, 13000008000, 19); 3 insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (6, '小六', 'xiaoliu', 300000005, 13000008000, 18);两个插入意向锁（age字段）死锁时刻事务A事务B1begin;begin;2select * from sys_user where age=14 for update;select * from sys_user where age=14 for update;3insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (6, '小六', 'xiaoliu', 300000005, 13000008000, 14); （事务A和B插入相同记录） 4 insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (6, '小六', 'xiaoliu', 300000005, 13000008000, 14); （事务A和B插入相同记录）死锁日志------------------------ LATEST DETECTED DEADLOCK ------------------------ 2022-03-01 15:04:27 140684024923904 *** (1) TRANSACTION: TRANSACTION 133654731, ACTIVE 29 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 4 lock struct(s), heap size 1136, 3 row lock(s), undo log entries 1 MySQL thread id 4796, OS thread handle 140684279383808, query id 5765383 192.168.1.83 root update insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (6, '小六', 'xiaoliu', 300000005, 13000008000, 14) *** (1) HOLDS THE LOCK(S): RECORD LOCKS space id 484 page no 4 n bits 80 index PRIMARY of table `employees`.`sys_user` trx id 133654731 lock_mode X locks rec but not gap Record lock, heap no 6 PHYSICAL RECORD: n_fields 8; compact format; info bits 128 0: len 4; hex 80000006; asc ;; 1: len 6; hex 000007f768cb; asc h ;; 2: len 7; hex 81000000ac0110; asc ;; 3: len 6; hex e5b08fe585ad; asc ;; 4: len 7; hex 7869616f6c6975; asc xiaoliu;; 5: len 9; hex 333030303030303035; asc 300000005;; 6: len 11; hex 3133303030303038303030; asc 13000008000;; 7: len 4; hex 8000000e; asc ;; *** (1) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 484 page no 46 n bits 80 index idx_age of table `employees`.`sys_user` trx id 133654731 lock_mode X locks gap before rec insert intention waiting Record lock, heap no 5 *** (2) TRANSACTION: TRANSACTION 133654788, ACTIVE 22 sec inserting mysql tables in use 1, locked 1 LOCK WAIT 3 lock struct(s), heap size 1136, 2 row lock(s) MySQL thread id 4798, OS thread handle 140684407801600, query id 5765426 192.168.1.83 root update insert into sys_user (id, name, name_pinyin, id_card, phone, age)values (6, '小六', 'xiaoliu', 300000005, 13000008000, 14) *** (2) HOLDS THE LOCK(S): RECORD LOCKS space id 484 page no 46 n bits 80 index idx_age of table `employees`.`sys_user` trx id 133654788 lock_mode X locks gap before rec Record lock, heap no 5 *** (2) WAITING FOR THIS LOCK TO BE GRANTED: RECORD LOCKS space id 484 page no 4 n bits 80 index PRIMARY of table `employees`.`sys_user` trx id 133654788 lock mode S locks rec but not gap waiting Record lock, heap no 6 PHYSICAL RECORD: n_fields 8; compact format; info bits 128 0: len 4; hex 80000006; asc ;; 1: len 6; hex 000007f768cb; asc h ;; 2: len 7; hex 81000000ac0110; asc ;; 3: len 6; hex e5b08fe585ad; asc ;; 4: len 7; hex 7869616f6c6975; asc xiaoliu;; 5: len 9; hex 333030303030303035; asc 300000005;; 6: len 11; hex 3133303030303038303030; asc 13000008000;; 7: len 4; hex 8000000e; asc ;;资源分配图个人分析死锁图应该是这样的：注意死锁回滚时，InnoDB会选择资源最小的那个事务进行回滚。不用过度担心死锁，因为死锁事务回滚后再次重试就可以了。参考https://dev.mysql.com/doc/refman/8.0/en/innodb-locking.html#innodb-record-lockshttps://www.infoq.cn/article/zau0ewzsdtx9zofr6c8whttps://segmentfault.com/a/1190000019745324

架构模式-微服务架构

引言微服务架构模式作为单体应用和面向服务架构(SOA)的可行替代方案，已经迅速在业界占领了一席之地。由于微服务架构模式还在持续演进中，所以业界对于它是干什么的，以及如何实现它还有很多的疑惑。这部分内容将给你提供必要的关键概念和基础知识，以及微服务架构模式的利弊和它是否适合你的应用。模式描述不论你选择何种拓扑结构或者实现风格，都有几个通用的核心概念来应用到通用架构模式中。第一个核心概念是独立部署单元。如下图，微服务架构中的每个组件都是独立的单元，能够通过有效且流线型的交付管道来提高可伸缩性，高度的将应用和组件解耦。可能理解微服务架构模式最重要的概念是服务组件的理解。大型应用通过良好定义的粒度来拆分成服务组件。服务组件通常有一个或多个模块（例如：java类）可以提供单一目的方法（例如：提供一个具体城镇的天气）或者是一个大型应用的一部分（例如：股票交易或者保险理赔）。设计一个合理的服务组件粒度是微服务架构模式最大的挑战。在后面的服务组件编排部分将会对这个挑战进行更多的讨论。服务架构中的另一个关键概念是分布式架构，这意味着所有的服务组件互相是解耦的，并且可以通过一些远程访问协议进行访问（例如：JMS,AMPQ,REST,SOAP,RMI等）。微服务架构的分布式特性使他可以更好可扩展性以及部署特性。微服务架构是从其他通用架构模式遇到的一些问题演进而来，而不是被创造解决未来遇到的问题。微服务体系架构从两个主要的来源演进而来：使用分层架构的单体应用和通过面向服务的分布式架构。微服务一个演进路线是单体应用。从单体应用到微服务架构主要通过持续交付来实现，从开发到生产环境的持续部署管道概念简化了应用程序的部署。单体应用与它的组件为紧耦合的单个发布单元，这使得单体应用庞大，修改，测试和发布都很困难。通常这些因素都会导致单体应用在每次部署更新时都会遇到更多问题。微服务架构模式通过将应用程序分解为多个独立部署的单元解决了这些问题，这些部署单元称为服务组件，这些服务组件之间独立开发，测试和发布。微服务的另一个演进路线是SOA。SOA模式非常强大，且提供了前所未有的抽象，异构连接，服务编排，将业务功能与IT能力结合起来，但是它对于大部分应用是复杂，昂贵，普遍难以理解与实现。微服务架构通过服务组件概念解决了这些复杂性问题，消除服务编排的需求并简化了服务组件的连接与访问。模式拓扑有很多方式可以实现微服务架构模式，但是有三个的架构拓扑脱颖而出：基于REST API拓扑基于应用REST拓扑集中消息拓扑基于REST API拓扑主要用于网站通过某种形式的API对外暴露小且独立的服务。下图展示了这个拓扑。这个拓扑由细粒度的服务组件组成，每个服务组件包含一个或者多个模块，每个模块负责实现具体的业务逻辑，每个服务组件独立于其他服务组件。在这个拓扑中，通常使用基于REST接口的形式封装这些细粒度的服务，并且这些服务通过基于Web的API层独立发布。基于应用的拓扑与基于REST API拓扑不同的是，客户端的请求通过传统的基于web或者胖客户端的业务应用接收而不是API层。如下图，应用程序的用户层通过独立的web应用进行发布，用户层服务与服务组件通过REST接口进行访问。基于应用的服务组件与及基于REST API服务组件的不同之处在于：基于应用的服务组件一般会更大（更粗粒度），代表着整个业务应用的一部分功能，而不是细粒度，单一的服务。基于应用的拓扑通常应用于中小业务应用，这些业务应用一般业务复杂性相对较低。另一个拓扑模式是集中式消息拓扑。这个拓扑与基于应用的拓扑类似，但是通过轻量级消息代理进行远程访问，而不是使用REST。不要把这个拓扑结构当成SOA或者SOA-lite架构。在这个拓扑中的轻量级消息代理并不执行任何编排，转换，或者复杂的路由(请参考消息驱动架构-Mediator)；它只是在拓扑中承担轻量级服务访问的传输。集中式的消息拓扑经常用于大型业务应用或者需要在用户层和服务组件之间需要复杂的业务控制传输层。避免服务依赖和编排微服务架构模式的一个主要挑战是确定服务组件的一个正确粒度。如果服务组件粒度太粗，你可能又回归到单体应用了（发布，扩展，测试与松耦合统统都丢了）。然而，如果服务组件过于细粒度，就会需要服务编排，那么这就会导致你的微服务变成重量级SOA。如果你发现你需要在应用的用户层或者API层编排服务组件，那么你的微服务中的服务组件就是过于细分（粒度太细）。与之类似，如果你发现为了处理一个请求，你需要进行服务间通信，那么，你的服务组件划分的过于细粒度或者他们并没有根据业务功能进行正确拆分。服务间通信，会导致服务与服务的依赖，但是可以通过共享数据库解决。例如，如果一个服务组件需要处理互联网订单，订单需要查询用户信息，这种业务可以通过访问共享数据库得到这些信息，而不是调用用户服务组件的功能获取。共享数据库可以处理数据需求，但是共享功能如何做？如果一个服务组件需要的功能在另一个服务组件中或者其他通用服务组件中，有时可以复制共享功能在这个服务组件中（违反了DRY原则：don't repeat yourself）。但是在大部分实现了微服务架构模式的业务应用中，这个实践非常常用。权衡一些业务逻辑的冗余，使得服务组件之间能够相互独立，并能能够独立发布。一些工具类可能会分到这些重复代码目录中。如果你发现，不管服务粒度细分的粗或者细，你依然无法避免服务组件的编排，那么微服务架构可能不适合你的业务应用。由于微服务架构模式的分布式特性，一个事务的跨服务调用是难以维护的。微服务架构可能需要一个分布式事务框架来回滚事务，但是这会增加微服务架构的复杂性。架构思考微服务架构解决了很多单体应用和SOA中的常见问题。由于主体服务组件被拆分成小且独立发布的单元，使用微服务架构模式的构建的应用，通常健壮的，很好的扩展性，可以很容易的支持持续交付。微服务架构模式的另一个好处是，它提供了一个实时产品发布能力，因此能够有效的减少传统应用的月度或者周度产品发布。由于服务组件之间通常是独立修改的，那么只有这个服务组件需要发布。如果你只有一个服务组件的实例，那么你可以在发布期间在用户层检测服务组件是否正在热发布中，然后将用户重定向到错误页面或者等待页面。但是，你也可以在实时发布期间，启动多个服务组件实例，这样可以在服务发布期间能够持续提供服务（在基于分层架构模式的应用，有时这是非常困难的）。最后一个需要考虑的是，由于微服务架构也是分布式架构，一些复杂的问题解决需要事件驱动架构模式，包括关系建立，维护，管理，远程系统可用性和远程访问认证与授权。模式分析敏捷性：高由于独立部署单元的概念，所以服务组件之间修改是隔离的，因此服务组件能够更快且容易发布。服务与服务之间松耦合，所以能够更快的响应变化。易于部署：高一般服务组件部署都是独立的软件单元，因此拥有在任何时候能够进行热部署。同时部署风险也大大降低，部署失败可以更快的回滚到老版本。可测试性：高将一个大型应用拆分成独立的小应用，测试可以被界定，能够更有针对性的进行功能测试。对一个特定服务组件的测试更容易，且更容易实施。服务组件是松耦合的，这样在修改服务的时候就不会中断应用的其他服务组件。性能：低微服务的分布式特性就不是高性能的应用架构。可扩展性：高每个服务组件独立扩展。易于开发：高服务小且独立范围界定，使得开发更容易，减少团队之间的协作。

老冀_个人页

个人介绍

擅长的技术

MySQL InnoDB中的锁-插入意向锁（Insert Intention Lock）

消息中间件使用规范(RocketMQ)

架构模式-事件驱动架构-调度者拓扑

架构模式-微服务架构

短链接生成

分布式系统-同步化-时钟同步-物理时钟与Lamport时间戳（逻辑时钟）

分布式选举算法-霸道算法/欺负算法（bully algorithm）

临时文件系统tmpfs-A Virtual Memory File System

Java 读取Excel大文件

MySQL InnoDB中的锁-自增锁（AUTO-INC Locks）

MySQL InnoDB中的锁-插入意向锁（Insert Intention Lock）

MySQL InnoDB中的锁-临键锁（next-key lock）

分治策略(divide and conquer)-微服务与数据库水平拆分

MySQL InnoDB中的锁-间隙锁（Gap Lock）

MySQL COUNT 函数及其优化

MySQL InnoDB中的锁-记录锁

MySQL 覆盖索引（Cover Index）

文件系统-性能优化-磁臂调度算法

项目管理-人月神话

InnoDB中的锁-意向锁

MySQL InnoDB 共享读锁与排他写锁

可靠性问题与解决方案/可靠性理解

通信模型与通信中的问题

MySQL Explain

协议的理解