参考：node支付宝支付及同步、异步通知、主动查询支付宝订单状态
以下容结合上述链接查看
1. 什么是数据库事务？
1.1. 连续执行数据库操作
在支付成功后，我们在自定义的paidSuccess里，依次更新了订单状态和用户信息。也就说这里先执行了更新订单表的SQL，接着又执行了更新用户表的SQL。
但是大家想一想，有没有可能。订单表更新成功了，但因为某些原因导致用户表更新失败？
比方说用户模型里，用户组的效验写掉了1，导致1存进不去。
又或者大会员有效期计算错误，导致更新失败。
这样就可能订单状态更新成已支付了，但用户却还是普通用户，或者大会员有效期没有增加，造成数据不一致。所以对于这种，连续执行多条SQL语句的操作，正确的做法是要加上事务。所谓数据库的事务
1.2.数据库事务基础概念
- 执行
一组 SQL 操作，这些操作必须全部成功执行，或者全部不执行。 - 如果其中
任意一条SQL执行失败，那就全部回滚(Rollback)，撤销所有已经完成的操作，确保数据的一致性和完整性。 - 如果所有的操作
都成功了，才会提交(Commit)事务，使所有更改永久生效。
1.3. SQL事务的使用：
1.3.1.开启事务 (START TRANSACTION)
-- 开始一个新的事务
START TRANSACTION;
-- BEGIN，简化写法
BEGIN;
1.3.2. 连续连续执行多条 SQL 语句
-- 更新订单表
UPDATE `Orders` SET `tradeNo` = '2024121322001495001404593598', `paidAt` = '2024-12-13 12:35:31', `status` = 1 WHERE `id` = 5;
- 现在用语句查询一下订单信息
-- 查询订单表
SELECT `tradeNo`, `paidAt`, `status` FROM `Orders` WHERE `id` = 5;
发现数据已经更新进去了。但是要注意，因为现在数据库事务还没有提交，所以这里并不是真正的保存进去了。
- 再继续更新用户表
-- 更新用户表
UPDATE `Users` SET `role` = 1, `membershipExpiredAt` = '2025年10月10日' WHERE `id` = 2;
语句里的日期，还是写的错误的，这是无法存进去的。提示我们错误信息了：
1.3.3. 回滚 (ROLLBACK)
现在就造成了订单表更新了，但是用户表更新失败，两个表的数据不一致。碰到这种情况，就可以使用回滚语句：
-- 如果执行失败，回滚所有操作
ROLLBACK;
重新选中查询订单表的 SQL 语句，运行一下，发现订单表中，刚才已经修改的数据，被全部重置了
这样就不用担心两张表的数据不一致了。
1.3.4. 提交事务 (COMMIT)
如果所有语句都执行成功，那要继续用COMMIT提交事务，将数据永久的保存到数据库中。
- 将日期改为正确的时间
UPDATE `Users` SET `role` = 1, `membershipExpiredAt` = '2025-10-10 10:10:10' WHERE `id` = 2;
1.3.5 完整代码：
-- 开始一个新的事务，也可用简写成 BEGIN，二选一即可
START TRANSACTION;
-- 连续执行多条SQL语句：
-- 更新订单表
UPDATE `Orders` SET ...
-- 更新用户表
UPDATE `Users` SET ...
-- 如果执行失败，回滚所有操作
ROLLBACK;
-- 如果执行成功，提交事务，使所有更改成为永久性的
COMMIT;
1.4. 在 Node(ORM) 中使用数据库事务
- 第一种是非托管事务，也就是必须手动执行提交和回滚。
- 另一种是托管事务，代码会自动处理提交和回滚。
1.4.1. 非托管事务
const { sequelize, User, Order } = require('../models');
/**
* 支付成功后，更新订单状态和会员信息
* @param outTradeNo
* @param tradeNo
* @param paidAt
* @returns {Promise<void>}
*/
async function paidSuccess(outTradeNo, tradeNo, paidAt) {
// 开启事务
const t = await Order.sequelize.transaction();
try {
// 查询当前订单（在事务中）
const order = await Order.findOne({
where: { outTradeNo: outTradeNo },
transaction: t,
});
// 对于状态已更新的订单，直接返回。防止用户重复请求，重复增加大会员有效期
if (order.status > 0) {
return;
}
// 更新订单状态（在事务中）
await order.update({
tradeNo: tradeNo, // 流水号
status: 1, // 订单状态：已支付
paymentMethod: 0, // 支付方式：支付宝
paidAt: paidAt, // 支付时间
}, { transaction: t });
// 查询订单对应的用户（在事务中）
const user = await User.findByPk(order.userId, { transaction: t });
// 将用户组设置为大会员。可防止管理员创建订单，并将用户组修改为大会员
if (user.role === 0) {
user.role = 1;
}
// 使用moment.js，增加大会员有效期
// user.membershipExpiredAt = moment(user.membershipExpiredAt || new Date())
// .add(order.membershipMonths, 'months')
// .toDate();
user.membershipExpiredAt = '2025年10月10日';
// 保存用户信息（在事务中）
await user.save({ transaction: t });
// 提交事务
await t.commit();
} catch (error) {
// 回滚事务
await t.rollback();
// 将错误抛出，让上层处理
throw error;
}
}
- 顶部先引用一下。
- 代码里，开启了数据库事务。
- 除了
findOne，是在where后面直接加上transaction: t之外。 - 其他操作里，都要添加第二个参数，加上
{ transaction: t }。关于这点，文档中有说明： 
- 我们给查询语句，也加上了事务。这是因为查询语句，也有可能出错。
- 如果全都执行成功，就提交事务。
- 如果有执行失败的，就回滚。
- 注意，最后这里，要将错误抛出，交给上层来处理。这样调用
paidSuccess的路由里，就会捕获到，然后自动记录到错误日志里。
1.4.2. 托管事务
/**
* 支付成功后，更新订单状态和会员信息
* @param outTradeNo
* @param tradeNo
* @param paidAt
* @returns {Promise<void>}
*/
async function paidSuccess(outTradeNo, tradeNo, paidAt) {
try {
// 开启事务
await sequelize.transaction(async (t) => {
// 查询当前订单（在事务中）
const order = await Order.findOne({
where: { outTradeNo: outTradeNo },
transaction: t,
});
// 对于状态已更新的订单，直接返回。防止用户重复请求，重复增加大会员有效期
if (order.status > 0) {
return;
}
// 更新订单状态（在事务中）
await order.update({
tradeNo: tradeNo, // 流水号
status: 1, // 订单状态：已支付
paymentMethod: 0, // 支付方式：支付宝
paidAt: paidAt, // 支付时间
}, { transaction: t });
// 查询订单对应的用户（在事务中）
const user = await User.findByPk(order.userId, { transaction: t });
// 将用户组设置为大会员。可防止管理员创建订单，并将用户组修改为大会员
if (user.role === 0) {
user.role = 1;
}
// 使用moment.js，增加大会员有效期
// user.membershipExpiredAt = moment(user.membershipExpiredAt || new Date())
// .add(order.membershipMonths, 'months')
// .toDate();
user.membershipExpiredAt = '2025年10月10日';
// 保存用户信息（在事务中）
await user.save({ transaction: t });
});
} catch (error) {
// 将错误抛出，让上层处理
throw error;
}
}
- 非常简单，在
try里，用sequelize.transaction包住所有代码。 - 去掉
commit和rollback。因为这种写法，会自动提交和回滚。 - 其他地方都和之前一样。
1.5. 总结一下
- 要一下执行多个数据库操作，最好加上事务。
- 要么全部执行成功，要么就全部回滚。
- 所以，事务可以保障数据的完整性和一致性。
2. 数据库的乐观锁
2.1.多个事务修改同一条记录
2.1.1 库存问题
例如有个商品表，里面有个库存字段。刚好这个商品现在只有1件了，这时候两个人同时下单。但是因为事务还没有提交，就会造成库存的错误判断。大家看这个表格：
| 事务一（A 下单） | 事务二（B 下单） |
|---|---|
| 查询商品库存：1 件 | |
| 查询商品库存：1 件 | |
| 判断商品库存 > 0，继续执行 | |
| 判断商品库存 > 0，继续执行 | |
| 更新商品库存：1 - 1 = 0 件 | |
| 更新商品库存：1 - 1 = 0 件 | |
| 提交事务，库存：0 件 | |
| 提交事务，库存：0 件 |
最终结果是，只有 1 件库存的商品，却同时卖给了两个用户。这种情况，特别是在高并发的秒杀项目里，是最容易出现问题的。
2.1.2. 例二：金融余额问题
| 事务一（A 给 B 转账） | 事务二（C 给 A 汇款） |
|---|---|
| 查询 A 的余额：1000 元 | |
| 查询 A 的余额：1000 元 | |
| 更新 A 的余额：1000 - 500 = 500 元 | |
| 更新 A 的余额：1000 + 200 = 1200 元 | |
| 提交事务，余额：500 元 | |
| 提交事务，余额：1200 元 |
因为事务二是后提交的，所以最终数据库中保存的结果，A 的余额就成了1200元。A 用户转账给别人的钱，完全没有减少。这在金融项目中，就是灾难了。
2.1.3. 例三：更新订单和用户信息
| 操作步骤 | 操作一 | 操作二 |
|---|---|---|
| 第一步 | 查询订单状态：0 | |
| 第二步 | 查询订单状态：0 | |
| 第三步 | 判断状态为 0，更新状态为：1 | |
| 第四步 | 判断状态为 0，更新状态为：1 | |
| 第五步 | 增加大会员有效期 | |
| 第六步 | 提交事务 | |
| 第七步 | 再次增加大会员有效期 | |
| 第八步 | 提交事务 |
。这就会造成用户的大会员时间，重复增加两次
2.2.乐观锁实践
所谓乐观锁，就是程序非常乐观的认为，当前要操作的记录不会碰到其他人同时在操作。它允许多个事务，同时对一条记录进行操作，但是如果发现其他事务改变了数据，它就报错，提示用户重试。
最常见的做法是在数据库中增加版本号(version)或者时间戳(timestamp)字段。根据Sequelize 文档里的说明，这里要用的是版本号(version)。
2.2.1 增加 version 字段
sequelize migration:create --name add-version-to-orders
打开迁移文件，直接用讲义文档中的内容覆盖，设置了版本号的默认值是0。
'use strict';
/** @type {import('sequelize-cli').Migration} */
module.exports = {
async up (queryInterface, Sequelize) {
await queryInterface.addColumn('Orders', 'version', {
allowNull: false,
defaultValue: 0,
type: Sequelize.INTEGER.UNSIGNED
});
},
async down (queryInterface, Sequelize) {
await queryInterface.removeColumn('Orders', 'version');
}
};
运行迁移命令
sequelize db:migrate
再打开模型文件models/order.js，增加version字段相关的定义：
Order.init({
// ...
version: {
allowNull: false,
type: DataTypes.INTEGER,
defaultValue: 0
},
// ...
}, {
sequelize,
modelName: 'Order',
});
2.2.3. 用 SQL 模拟更新订单
START TRANSACTION;
SELECT `id`, `version`, `status` FROM `Orders` WHERE `id` = 5;
UPDATE `Orders` SET `status` = 1, `version` = `version` + 1 WHERE `id` = 5 and version = 0;
COMMIT;
接着我们开启两个数据库客户端：
不太明确你说的“用上面的方式”具体所指，你是希望我按照上述事务 A 和事务 B 的处理逻辑，再举一个类似的例子吗？还是有其他的想法呢？以下我按照类似的逻辑，以两个用户同时修改商品信息的事务场景为例，再展示一遍：
| 事务 A（用户 1 修改商品信息） | 事务 B（用户 2 修改商品信息） |
|---|---|
| 开启事务，查询商品信息 输出： status: 未上架、version: 0 | |
| 开启事务，查询商品信息 输出： status: 未上架、version: 0 | |
用 where version = 0 作为条件，更新为： status: 已上架 version: 1 | |
| 提交事务 | |
用 where version = 0 作为条件，更新为： status: 已上架 version: 1因为 version 被事务 A 改为 1 了，所以找不到数据，执行失败 | |
| 提交事务 |
2.3.在 Node 项目中实现乐观锁
2.3.1. 手动处理
打开routes/alipay.js，顶部先做引用：
Conflict 类专门用于表示 HTTP 409 状态码对应的错误，也就是 “冲突” 错误
const { Conflict } = require('http-errors');
增加一个函数，实现延迟执行： 此函数只是为了模拟 实际开发中不需要
/**
* 实现延迟
* @param ms
* @returns {Promise<unknown>}
*/
function delay(ms) {
return new Promise(resolve => setTimeout(resolve, ms));
}
然后修改paidSuccess，
async function paidSuccess(outTradeNo, tradeNo, paidAt) {
try {
// 开启事务
await sequelize.transaction(async (t) => {
// 查询当前订单（在事务中）
const order = await Order.findOne({
where: {outTradeNo: outTradeNo}, transaction: t,
});
// 对于状态已更新的订单，直接返回。防止用户重复请求，重复增加大会员有效期
if (order.status > 0) {
return;
}
await delay(5000); // 等待5秒
// // 更新订单状态（在事务中）
// await order.update({
// tradeNo: tradeNo, // 流水号
// status: 1, // 订单状态：已支付
// paymentMethod: 0, // 支付方式：支付宝
// paidAt: paidAt, // 支付时间
// }, {transaction: t});
// 更新订单状态（在事务中），包括版本号检查
// updatedRows 是数据库中受到影响的行数
const [updatedRows] = await Order.update({
tradeNo: tradeNo, // 流水号
status: 1, // 订单状态：已支付
paymentMethod: 0, // 支付方式：支付宝
paidAt: paidAt, // 支付时间
version: order.version + 1, // 增加版本号
}, {
where: {
id: order.id, version: order.version, // 只更新版本号匹配的记录
}, transaction: t,
});
// 如果没有更新数据，提示错误
if (updatedRows === 0) {
throw new Conflict('请求冲突，您提交的数据已被修改，请稍后重试。');
}
// 查询订单对应的用户（在事务中）
const user = await User.findByPk(order.userId, {transaction: t});
// 将用户组设置为大会员。可防止管理员创建订单，并将用户组修改为大会员
if (user.role === 0) {
user.role = 1;
}
// 使用moment.js，增加大会员有效期
user.membershipExpiredAt = moment(user.membershipExpiredAt || new Date())
.add(order.membershipMonths, 'months')
.toDate();
// 保存用户信息（在事务中）
await user.save({transaction: t});
});
} catch (error) {
// 将错误抛出，让上层处理
throw error;
}
}
- 为了
模拟并发请求，增加了延迟 5 秒再执行。 - 注意现在调用的是大写的
Order模型，而不是刚才查询小写的order对象。 - 更新代码里，对
版本号也做了自增。 - 查询条件里，除了
id以外，还增加了之前查到的版本号。 - 执行后，会返回一个数组。数组的第一个元素，表示数据库中受到影响的
行数。 - 如果数据库中，受影响的行数为
0，表示数据没有更新成功，就提示对应的错误信息。
测试
- 重置某条订单信息
UPDATE `Orders` SET `tradeNo` = NULL, `paidAt` = NULL,`version` = 0, `status` = 0 WHERE `id` = 4;
UPDATE `Users` SET `role` = 0, `membershipExpiredAt` = NULL WHERE `id` = 2;
- Apifox 调用
主动查询支付宝接口 因为我们写了等待 5 秒，所以执行的时候会卡住。
- 快速的用数据库客户端，执行下刚才测试用的 SQL 语句，更新下订单状态，并增加版本号。
START TRANSACTION;
SELECT `id`, `version`, `status` FROM `Orders` WHERE `id` = 4;
UPDATE `Orders` SET `status` = 1, `version` = `version` + 1 WHERE `id` = 4 and version = 0;
COMMIT;
- 继续等待 5 秒钟过去，Apifox 中会出现错误提示。
这就是因为版本号已经被刚才数据库客户端修改了，现在再执行更新的时候查不到对应的数据了，所以没更新成功。
2.3.2. Sequelize 自动处理
-
根据官方文档中的说明，在模型里设置version: true，就可以自动实现乐观锁
-
我们现在来试试，打开
models/order.js。在最底下，增加version: true。
Order.init({
// ...
}, {
sequelize,
modelName: 'Order',
version: true, // 乐观锁
});
- 回到路由里，将顶部的引用删掉：
// const { Conflict } = require('http-errors');
paidSuccess修改：
async function paidSuccess(outTradeNo, tradeNo, paidAt) {
try {
// 开启事务
await sequelize.transaction(async (t) => {
// 查询当前订单（在事务中）
const order = await Order.findOne({
where: {outTradeNo: outTradeNo}, transaction: t,
});
// 对于状态已更新的订单，直接返回。防止用户重复请求，重复增加大会员有效期
if (order.status > 0) {
return;
}
await delay(5000); // 等待5秒
// // 更新订单状态（在事务中）
await order.update({
tradeNo: tradeNo, // 流水号
status: 1, // 订单状态：已支付
paymentMethod: 0, // 支付方式：支付宝
paidAt: paidAt, // 支付时间
}, {transaction: t});
// 更新订单状态（在事务中），包括版本号检查
// updatedRows 是数据库中受到影响的行数
// const [updatedRows] = await Order.update({
// tradeNo: tradeNo, // 流水号
// status: 1, // 订单状态：已支付
// paymentMethod: 0, // 支付方式：支付宝
// paidAt: paidAt, // 支付时间
// version: order.version + 1, // 增加版本号
// }, {
// where: {
// id: order.id, version: order.version, // 只更新版本号匹配的记录
// }, transaction: t,
// });
// 如果没有更新数据，提示错误
if (updatedRows === 0) {
throw new Conflict('请求冲突，您提交的数据已被修改，请稍后重试。');
}
// 查询订单对应的用户（在事务中）
const user = await User.findByPk(order.userId, {transaction: t});
// 将用户组设置为大会员。可防止管理员创建订单，并将用户组修改为大会员
if (user.role === 0) {
user.role = 1;
}
// 使用moment.js，增加大会员有效期
user.membershipExpiredAt = moment(user.membershipExpiredAt || new Date())
.add(order.membershipMonths, 'months')
.toDate();
// 保存用户信息（在事务中）
await user.save({transaction: t});
});
} catch (error) {
// 将错误抛出，让上层处理
throw error;
}
}
utils/responses.js的错误响应中，增加一个判断
function failure(res, error) {
if (error.name === 'SequelizeValidationError') { // Sequelize 验证错误
// ...
} else if(error.name === 'SequelizeOptimisticLockError') {
statusCode = 409;
errors = '请求冲突，您提交的数据已被修改，请稍后重试。';
} // ...
}
这是因为Sequelize自动实现的乐观锁，如果出错了，会响应SequelizeOptimisticLockError，所以我们增加一个判断。
测试
- 重置某条订单信息
UPDATE `Orders` SET `tradeNo` = NULL, `paidAt` = NULL,`version` = 0, `status` = 0 WHERE `id` = 4;
UPDATE `Users` SET `role` = 0, `membershipExpiredAt` = NULL WHERE `id` = 2;
- Apifox 调用
主动查询支付宝接口 因为我们写了等待 5 秒，所以执行的时候会卡住。
- 快速的用数据库客户端，执行下刚才测试用的 SQL 语句，更新下订单状态，并增加版本号。
START TRANSACTION;
SELECT `id`, `version`, `status` FROM `Orders` WHERE `id` = 4;
UPDATE `Orders` SET `status` = 1, `version` = `version` + 1 WHERE `id` = 4 and version = 0;
COMMIT;
- 继续等待 5 秒钟过去，Apifox 中会出现错误提示。
这就是因为版本号已经被刚才数据库客户端修改了，现在再执行更新的时候查不到对应的数据了，所以没更新成功。
2.3.3 测试完成后去掉delay函数
// await delay(5000); // 等待5秒
2.4.总结一下
- 防止并发冲突：为了防止多个操作同时修改数据库中的同一条记录，可以使用锁机制。
- 乐观锁：假设冲突很少发生，只有在发现冲突时才进行处理，通常会提醒用户重试。原理是在数据库中增加一个
版本号(version)字段，在更新数据时检查版本号是否匹配，若不匹配则提示用户重试。 - 用户表的乐观锁：我们演示了订单模型的乐观锁。对于用户表的更新，可以用同样的方法，增加
version字段，并且在模型中添加version: true。 - 与事务的关系：乐观锁与事务并没有直接关系，但为了确保所有操作要么全部成功，要么全部回滚，两者经常结合使用以保证更好的一致性。
- 适用场景：乐观锁适用于
并发较低、读多写少的场景。因为在这种情况下，冲突发生的概率较小，乐观锁可以减少不必要的锁定开销，提高系统的并发性能。 - 优缺点：乐观锁的优点是系统并发性能较好，因为不预先加锁，减少了锁定带来的资源占用和等待时间；缺点是需要实现重试逻辑，可能影响用户体验。
- 选择悲观锁的理由：由于当前项目涉及支付，对数据一致性和完整性要求极高，而且提示用户重试会影响体验，因此更适合使用悲观锁。
3.悲观锁
3.1悲观锁是什么？
它认为数据随时都有可能被别人修改。所以，只要在操作数据之前，它就先把数据给锁起来。
-悲观锁里，又分为共享锁和排它锁
- 共享锁：就是大家共享的。一个资源，允许同时存在多个共享锁。每个事务，都可以读到这条记录。但是要想修改、删除，必须等其他共享锁都释放后，才能执行
3.1.1. 共享锁实践FOR SHARE
以订单表为例：
重置一条数据
UPDATE `Orders` SET `tradeNo` = NULL, `paidAt` = NULL,`version` = 0, `status` = 0 WHERE `id` = 4;
UPDATE `Users` SET `role` = 0, `membershipExpiredAt` = NULL WHERE `id` = 2;
接着我们开启两个数据库客户端，都运行相同的 SQL。
加上FOR SHARE就是共享锁
-- 开始一个新的事务
START TRANSACTION;
-- 使用共享锁，查询订单表
SELECT `tradeNo`, `paidAt`, `status` FROM `Orders` WHERE `id` = 4 FOR SHARE;
-- 更新订单表
UPDATE `Orders` SET `tradeNo` = '2024121322001495001404593598', `paidAt` = '2024-12-13 12:35:31', `status` = 1 WHERE `id` = 4;
-- 提交事务
COMMIT;
-
在 A客户端先运行
开启事务及 查询订单表sql
运行一下，可以看到查到东西了。 -
在 B 客户端，也运行前两条语句：
-
因为加的是共享锁，所以 B 客户端，也能查到东西。
- 继续在 A 客户端，运行更新订单表：
注意了，出现弹窗，提示我们正在运行查询。
这就是刚说的，一条数据，可以有多个共享锁，都可以查到东西。但是想要修改数据，就必须得等其他所有的共享锁都释放了，才能修改。
- 现在去 B 客户端了，运行一下提交事务：
可以看到提示信息马上就消失了，执行成功了。这就是因为，除了A 客户端里的当前事务外，其他事务的锁都释放了，所以可以修改了。 - 最后在 A 客户端里，也点一下
提交事务：
| 事务 A | 事务 B |
|---|---|
| 开启事务 | |
| 查询数据，并加共享锁 | |
| 查询成功 | |
| 开启事务 | |
| 查询数据，并加共享锁 | |
| 查询成功 | |
| 修改数据，发现有其他事务的共享锁， 等待释放中… | |
| 提交事务，释放了锁 | |
| 执行成功 | |
| 提交事务，释放了锁 |
- 排它锁：一个资源，同一时间只允许存在一个排它锁。其他事务想要加锁，必须得等待当前事务操作完成，解锁后才行。所以，在锁定期间，其他事务不能读取，更不能修改和删除了
3.1.2 排它锁实践 FOR UPDATE
以订单表为例：
重置一条数据
UPDATE `Orders` SET `tradeNo` = NULL, `paidAt` = NULL,`version` = 0, `status` = 0 WHERE `id` = 4;
UPDATE `Users` SET `role` = 0, `membershipExpiredAt` = NULL WHERE `id` = 2;
接着我们开启两个数据库客户端，都运行相同的 SQL。
加上FOR UPDATE就是排它锁
- A 客户端 先
运行前两句
-- 开始一个新的事务
START TRANSACTION;
-- 使用共享锁，查询订单表
SELECT `tradeNo`, `paidAt`, `status` FROM `Orders` WHERE `id` = 4 FOR SHARE;
-- 更新订单表
UPDATE `Orders` SET `tradeNo` = '2024121322001495001404593598', `paidAt` = '2024-12-13 12:35:31', `status` = 1 WHERE `id` = 4;
-- 提交事务
COMMIT;
B 客户端，运行前两条语句(同上)：
发现现在进行查询，都会卡住，这就是排它锁。A 对数据加上了排它锁后，其他事务就不能再加排它锁了。不给你查，更不给你修改、删除。必须等我执行完成后，你再执行。
- 在 A 客户端，点击提交事务：
- B 客户端，就马上可以执行成功了。接着在 B 客户端里也点一下提交事务，将锁释放掉
以下是将你提供的内容转换为规范 Markdown 表格的形式，这样在 优快云 等平台通常能正常显示：
| 事务 A | 事务 B |
|---|---|
| 开启事务 | |
| 查询数据，并加排他锁 | |
| 查询成功 | |
| 开启事务 | |
| 查询数据，并加排他锁 | |
| 发现有其他事务的排他锁， 等待释放中… | |
| 提交事务，释放了锁 | |
| 查询成功 | |
| 提交事务，释放了锁 |
这里使用 <br> 来处理换行，保证在支持 HTML 的 Markdown 渲染环境下能正确显示换行内容。如果在 优快云 上还是显示异常，可以尝试将整个表格代码放入代码块（用三个反引号包裹）中。
3.2.Node 项目中实现悲观锁
3.2.1.如果你跟着文章内容学习了共享锁 请去掉version: true
- 打开models/order.js
Order.init({
// ...
}, {
sequelize,
modelName: 'Order',
// version: true, // 乐观锁
});
3.2.2. 共享锁的实现 lock: t.LOCK.SHARE
打开routes/alipay.js，找到paidSuccess这里
const order = await Order.findOne({
where: { outTradeNo: outTradeNo },
transaction: t,
lock: t.LOCK.SHARE, // 增加共享锁
});
// 其他...
const user = await User.findByPk(order.userId, {
transaction: t,
lock: t.LOCK.SHARE, // 增加共享锁
});
- 非常简单的找到
查询当前订单和查询当前用户这两个地方。 - 增加上
lock: t.LOCK.SHARE，这就是共享锁了。
打开 Apifox，调用下主动查询支付宝接口：
然后观察终端中的 SQL 语句：
3.2.3. 排它锁的实现 lock: t.LOCK.UPDATE
const order = await Order.findOne({
where: { outTradeNo: outTradeNo },
transaction: t,
lock: t.LOCK.UPDATE, // 增加排它锁
});
// 其他...
const user = await User.findByPk(order.userId, {
transaction: t,
lock: t.LOCK.UPDATE, // 增加排它锁
});
先运行下 SQL，重置一下数据库
UPDATE `Orders` SET `tradeNo` = NULL, `paidAt` = NULL,`version` = 0, `status` = 0 WHERE `id` = 4;
UPDATE `Users` SET `role` = 0, `membershipExpiredAt` = NULL WHERE `id` = 2;
再次调用 Apifox，观察终端中运行的语句：
根据官方文档的说明，排它锁还可以简写成lock: true，我们修改下代码
const order = await Order.findOne({
where: { outTradeNo: outTradeNo },
transaction: t,
lock: true, // 增加排它锁
});
// 其他...
const user = await User.findByPk(order.userId, {
transaction: t,
lock: true, // 增加排它锁
});
4.使用共享锁，还是排它锁？
那么到底是应该用共享锁，还是排它锁呢？在我们这个项目里，订单状态从未支付变为已支付，这是一个关键的业务操作，必须确保一致性，这里使用排它锁更为适合：
- 这样当前事务在处理的时候，其他事务就不能读取了，更不能对这条记录进行修改操作。
- 必须要等待当前事务执行完成后，其他事务才能进行操作。
- 这样就确保了，在同一时间内只有一个事务可以操作当前数据，保证了数据的一致性和完整性。
5.总结
5.1. 乐观锁与悲观锁的适用场景
乐观锁：适用于读多写少的场景，尤其是在高并发环境下，冲突发生的概率较低时。它假设数据在大多数情况下不会被修改，因此在提交更新之前不需要加锁，而是在提交时，通过版本号或时间戳检查是否有冲突发生。悲观锁：适用于写操作频繁、冲突可能性较高的情况下。它假设经常发生冲突，因此在执行任何可能引起冲突的操作前都会先加锁，以确保数据的一致性和完整性。
5.2. 悲观锁的类型及其区别
- 共享锁（S 锁或读锁）：
当前事务加共享锁后，允许其他事务也对该资源加共享锁，但禁止其他事务对该资源加排它锁。
在其他事务的共享锁没有释放之前，当前事务和其他事务都禁止对该资源进行修改操作。 - 排它锁（X 锁或写锁）：
当前事务加排它锁后，禁止其他事务对该资源加共享锁或排它锁。
排它锁确保只有一个事务可以对锁定的数据进行读取和修改。在排它锁未被释放之前，其他事务不能对该资源加任何形式的锁。
5.3. 行锁与全表扫描的影响
加锁时的where条件里，命中索引至关重要。只有通过索引条件来检索数据，才能确保MySQL的InnoDB引擎能够精确地锁定当前记录，这叫做行锁，也就是只锁定一行记录。
但如果查询的数据无法命中索引，MySQL不得不从头开始逐行扫描整个表，直到找到对应的数据，期间会将所有遇到的数据行全都加锁。这种情况虽然不是严格意义上的表锁，但在效果上几乎等同于表锁。它会阻塞其他事务对这些行的操作，显著降低并发性能。
重点：
数据库事务里加锁，如果没有
命中索引，就会造成表锁问题。
除了可以给字段，分别单独加索引外，还可以创建联合索引。
联合索引的顺序非常重要，要注意最左前缀原则。
加锁后where 后的条件一定要加索引
扫一扫
970
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
