章节 1：后端并发的核心概念与理论基础

📝 本节摘要：

本节首先强调了掌握并发（Concurrency）对于进阶高级后端开发者的重要性。作者将并发定义为“两个进程或事务争夺同一资源”，指出在符合 ACID 标准的数据库中，这主要涉及“隔离性（Isolation）”的处理。

>

通过一个具体的银行账户案例（事务A和B同时操作同一ID），视频引出了两种处理冲突的核心路径：让后续事务等待（悲观策略）或允许其继续修改（乐观策略）。最后，作者澄清了一个关键误区：并发策略的选择不是针对整个应用程序（如 Netflix vs Facebook）或数据库类型（如 Postgres vs MongoDB），而是取决于具体的业务动作（如“更新个人资料”适合乐观并发，而“银行充值”适合悲观并发）。

[原文] [Speaker]: if you're a back-end developer concurrency is one of those things that will make you stand out from other senior developers And it's quite a tricky topic but as always I'm going to make it super easy for you

[译文] [Speaker]: 如果你是一名后端开发人员，并发性（Concurrency）是那些能让你从其他高级开发人员中脱颖而出的技能之一。这虽然是一个相当棘手的话题，但像往常一样，我会让它对你来说变得超级简单。

[原文] [Speaker]: So the plan for today is the following First we're going to try to understand what it is We're going to look at two approaches pessimistic and optimistic concurrency There are trade-offs and as always the best practices

[译文] [Speaker]: 所以今天的计划如下：首先我们将尝试理解它是什么。我们将研究两种方法：悲观并发（Pessimistic Concurrency）和乐观并发（Optimistic Concurrency）。这其中存在权衡，当然还有最佳实践。

[原文] [Speaker]: And before we dive deep into the code as always I want to make sure that we're on the same page when it comes to the theory So we're going to start with a bit of a theory first

[译文] [Speaker]: 在深入代码之前，像往常一样，我想确保我们在理论层面达成共识。所以我们要先从一点理论开始。

[原文] [Speaker]: So concurrency can be seen not only in databases although our video is primarily about concurrency in databases but it's basically about two processes or in our case transactions competing for one resource

[译文] [Speaker]: 并发不仅存在于数据库中（尽管我们的视频主要关于数据库中的并发），但它基本上是关于两个进程——或者在我们的例子中是事务（Transactions）——争夺同一个资源。

[原文] [Speaker]: So in asset compliant databases concurrency is basically taking care of isolation

[译文] [Speaker]: 所以在符合 ACID（原子性、一致性、隔离性、持久性）标准的数据库中，并发基本上是在处理隔离性（Isolation）。

[原文] [Speaker]: So what do I mean let's say we have one table called accounts and obviously we have we have many accounts

[译文] [Speaker]: 那么我是什么意思呢？假设我们要有一个名为 accounts（账户）的表，显然我们有很多账户。

[原文] [Speaker]: So if transaction A is trying to access one of those accounts let's say account ID 1 and it wants to update it while transaction E is doing some work on this ID

[译文] [Speaker]: 如果事务 A 试图访问这些账户中的一个，比如账户 ID 1，并且它想在该 ID 上进行更新，而此时事务 E 正在对这个 ID 进行某些工作。

[原文] [Speaker]: The transaction B has to wait until transaction A is finished so that it can also do it This is one of the ways to deal with concurrency or transaction B can actually go ahead and modify while transaction A is still running

[译文] [Speaker]: 事务 B 必须等待直到事务 A 完成，这样它才能执行操作。这是处理并发的一种方式，或者事务 B 实际上可以在事务 A 仍在运行时继续进行修改。

[原文] [Speaker]: Now which way is better this is the question and this is why we have two different types of concurrency And your job is to choose the one that fits your scenario the best

[译文] [Speaker]: 现在哪种方式更好？这就是问题所在，这也是为什么我们有两种不同类型的并发。而你的工作是选择最适合你场景的那一种。

[原文] [Speaker]: Now when we talk about concurrency it's not like we're talking about a specific app Let's say Netflix is pessimistically concurrent and Facebook is optimistically concurrent

[译文] [Speaker]: 当我们谈论并发时，并不是说我们在谈论某个特定的应用程序。比如（不能说）Netflix 是悲观并发的，而 Facebook 是乐观并发的。

[原文] [Speaker]: No we're also not saying that Postgress is pessimistic and MongoDB is optimistic No we're really talking about specific actions within your application

[译文] [Speaker]: 不，我们也不是说 Postgres 是悲观的而 MongoDB 是乐观的。不，我们真正谈论的是应用程序中的具体操作（Specific Actions）。

[原文] [Speaker]: For example updating your user profile can be optimistically concurrent Updating your bank account or topping up your account can be pessimistic And we're going to talk about this in a minute

[译文] [Speaker]: 例如，更新你的用户资料可以是乐观并发的。更新你的银行账户或给账户充值可以是悲观的。我们将在一分钟后讨论这个问题。

章节 2：悲观并发（Pessimistic Concurrency）——原理与代码实现

📝 本节摘要：

本节详细介绍了“悲观并发”策略。这是一种保守的方法，它假设冲突极有可能发生，因此选择“先发制人”地阻止冲突。作者演示了其底层逻辑：当事务 A 试图修改某行数据（例如账户 ID 1）时，会使用 SQL 中的 FOR UPDATE 关键字锁定该行；此时，试图操作同一行的事务 B 必须强制等待，直到事务 A 完成提交并释放锁。随后，作者展示了如何在 Node.js (Express + Sequelize) 环境中落实这一策略，包括开启事务、配置锁参数（Lock Update）、执行余额扣除逻辑以及最终提交事务的完整代码流程。

[原文] [Speaker]: So we're going to start with pessimistic concurrency What this tells us is that conflicts or we assume that the conflicts are very likely to occur So we're being conservative or pessimistic and pre trying to prevent them up front

[译文] [Speaker]: 那么我们将从悲观并发（Pessimistic Concurrency）开始。这告诉我们的是冲突——或者说我们假设冲突——极有可能发生。所以我们持保守或悲观的态度，并试图预先阻止它们。

[原文] [Speaker]: So what does it mean transaction A is trying to again modify one of the accounts as we saw above and transaction B is trying to do the same But let's take a look at transaction A

[译文] [Speaker]: 那么这意味着什么呢？就像我们上面看到的那样，事务 A 试图再次修改其中一个账户，而事务 B 也试图做同样的事情。但让我们先看看事务 A。

[原文] [Speaker]: So this is basically how transaction A is going to look like We're trying to start the transaction with a begin and then we're fetching or we're grabbing this ID one and this is the keyword for us

[译文] [Speaker]: 这基本上就是事务 A 的样子。我们试图用 begin 来开始事务，然后我们获取或抓取这个 ID 1，这对我们要说是关键字。

[原文] [Speaker]: So for update is basically doing uh or putting a lock on a specific row So this for update is basically locking one of the rows In our case it's the one that has ID1

[译文] [Speaker]: FOR UPDATE 基本上是在做……或者说是在特定行上加一把锁。所以这个 FOR UPDATE 基本上锁定了其中一行。在我们的例子中，就是 ID 为 1 的那一行。

[原文] [Speaker]: And while we're updating here accounts set balance So we're basically subtracting something from our balance Transaction B literally has to wait until all of that is finished because we locked this row Okay

[译文] [Speaker]: 当我们要在这里更新 accounts set balance（账户设置余额）——也就是基本上从我们的余额中减去一些东西时——事务 B 真的必须等待直到所有这些都完成，因为我们锁定了这一行。好吗。

[原文] [Speaker]: And once we commit then only then transaction B can go ahead and do its things Now within the code it's going to look like this

[译文] [Speaker]: 一旦我们要提交（Commit），只有在那时事务 B 才能继续做它的事情。现在在代码中，它看起来会是这样的。

[原文] [Speaker]: So I'm using SQL and Postgress So this is the docker compose YAML file As you can see node and posgress you can uh pull it from my github page and run it yourself

[译文] [Speaker]: 我使用的是 SQL 和 Postgres。这是 docker compose 的 YAML 文件。如你所见是 Node 和 Postgres，你可以从我的 GitHub 页面拉取它并自己运行。

[原文] [Speaker]: We have a simple express app We have two routes optimistic and pessimistic And I'm also crediting um 100 bucks into my account right away

[译文] [Speaker]: 我们有一个简单的 Express 应用程序。我们有两个路由：乐观（optimistic）和悲观（pessimistic）。而且我还会马上往我的账户里存入 100 块钱。

[原文] [Speaker]: So the pessimistic is going to be like this We have the withdraw endpoint and we're taking the amount from the request body And this is where we're starting the transaction by running SQLiz transaction method

[译文] [Speaker]: 那么悲观（路由）将会是这样的。我们有 withdraw（取款）端点，我们从请求体中获取金额。这就是我们要通过运行 Sequelize 的 transaction 方法来开始事务的地方。

[原文] [Speaker]: And the interesting thing is actually here So when we find this account which has ID one the one that interests us we put this parameter here which is called lock and as you saw in the row SQL example here it's basically the same here

[译文] [Speaker]: 有趣的事情其实在这里。当我们找到这个账户——也就是我们感兴趣的 ID 为 1 的账户时——我们在这里放了这个叫做 lock（锁）的参数，正如你在原生 SQL 例子中看到的那样，这里基本上是一样的。

[原文] [Speaker]: So LO update and this means that this transaction is going to be pessimistic okay or with a pessimistic concurrency

[译文] [Speaker]: 所以 LOCK.UPDATE（原文读作 LO update），这意味着这个事务将是悲观的，好吗，或者是采用了悲观并发。

[原文] [Speaker]: And now we're having some checks if we have sufficient founds and if so then we're doing this subtraction simple subtraction from the balance then we save this transaction and then at the end we commit

[译文] [Speaker]: 现在我们进行一些检查，看看是否有足够的资金，如果有，我们就执行这个减法——从余额中进行的简单减法——然后我们保存这个事务，最后我们提交。

章节 3：悲观并发的实战评估——场景、优缺与最佳实践

📝 本节摘要：

本节重点讨论了悲观并发（Pessimistic Concurrency）的适用领域与权衡。作者指出，该策略是金融系统（确保余额一致）和库存管理（防止超卖）的首选方案。

>

其核心优势在于能处理高冲突场景（如演唱会抢票、飞机选座），通过锁定资源防止数据竞争。然而，这种强一致性也带来了代价：阻塞（Blocking）会导致性能下降，且存在死锁（Deadlock）的风险。最后，作者给出了两条黄金法则：保持事务尽可能短小，并使用细粒度的行锁（Fine-grained Locks）而非表锁。

[原文] [Speaker]: Now what are the typical use cases for pessimistic concurrency well finances are really good use case because we want to make sure that our bank accounts balances in our banks are always consistent

[译文] [Speaker]: 那么悲观并发的典型用例有哪些呢？嗯，金融真的是一个很好的用例，因为我们想确保我们银行里的银行账户余额始终是一致的。

[原文] [Speaker]: It's not like I uh add some money and then I pay for something and then I always want to see the correct balance that I have

[译文] [Speaker]: 这不像是……比如我存了一些钱，然后我付了点什么，我总是希望能看到我有正确的余额。

[原文] [Speaker]: Also inventory systems when someone buys something with our shop I want the inventory to always show the correct number and not have any lags

[译文] [Speaker]: 还有库存系统，当有人在我们的商店买东西时，我希望库存总是显示正确的数量，而没有任何延迟。

[原文] [Speaker]: So the strength in this case are going to be that it's good for high conflict scenarios for example seat reservations where a lot of people are trying to book your seats of the airplane and want the same data

[译文] [Speaker]: 所以这种情况下的优势在于，它非常适合高冲突场景（High Conflict Scenarios），例如座位预订，当很多人试图预订飞机的座位并且想要同一份数据时。

[原文] [Speaker]: And in this case with a pessimistic concurrency if we lock this row or the seat of the airplane no one else is going to accidentally reserve the same seat

[译文] [Speaker]: 在这种情况下，使用悲观并发，如果我们锁定了这一行或者说飞机的这个座位，就没有其他人会意外地预订到同一个座位。

[原文] [Speaker]: Also if we want high date consistency for example in our bank account and we're simply lowering the risk of needing to restart transactions because if one transaction is running another one has to wait

[译文] [Speaker]: 另外如果我们需要高数据一致性（Data Consistency），例如在我们的银行账户中；而且我们也简单地降低了需要重启事务的风险，因为如果一个事务正在运行，另一个就必须等待。

[原文] [Speaker]: Now this brings us to weaknesses It can cause blocking because the other transactions have to wait

[译文] [Speaker]: 这就把我们带到了弱点。它会导致阻塞（Blocking），因为其他事务必须等待。

[原文] [Speaker]: Also there's a chance of a deadlock I have a video on deadlock So if you're not aware what that is go check it out It's going to be in the description below as well

[译文] [Speaker]: 此外还有死锁（Deadlock）的风险。我有一个关于死锁的视频，如果你不知道那是什么，去看看吧。链接也会放在下面的描述中。

[原文] [Speaker]: And best practices as always are keeping the transaction short and making sure that the locks are fine grain meaning put the lock on a row like we did here on ID1 and not on the whole table obviously

[译文] [Speaker]: 至于最佳实践，像往常一样，是保持事务短小（Short），并确保锁是细粒度的（Fine-grained），意思是把锁加在某一行上——就像我们在这里对 ID 1 做的那样——显然不是加在整张表上。

章节 4：技术插曲——自动化端到端测试工具

📝 本节摘要：

在这一节中，作者暂时从并发话题转向了后端开发的另一大痛点：繁琐的端到端（E2E）测试。他指出，手动编写测试以确保用户旅程（User Journey）不被新代码破坏是一个非常枯燥的过程。

>

随后，作者介绍了本期视频的赞助商 Test Sprite。这是一个 AI 测试代理，能直接集成到 IDE 中，通过理解产品需求和分析代码库，自动完成从制定测试计划、编写代码到执行和反馈修复的全套流程。作者强调，这能让开发者从繁重的测试工作中解放出来，专注于核心功能的开发。

[原文] [Speaker]: Now at my current company in the last few months I've been writing a lot of E2 tests E2 tests are great for testing the user journey so that you make sure that the user journey doesn't break when you introduce a new line of code

[译文] [Speaker]: 在我现在工作的公司，过去几个月里我一直在编写大量的端到端（E2E）测试。E2E 测试对于测试用户旅程（User Journey）非常有用，这样你就能确保当你引入新代码行时，用户旅程不会崩溃。

[原文] [Speaker]: But this whole process is very mundane The only thing I've been thinking about all the time is why is there no app or platform that can automate writing and executing E2 test well this is until I stumbled upon our sponsor of today's video Test Sprite

[译文] [Speaker]: 但这整个过程非常枯燥。我一直以来唯一在思考的事情就是，为什么没有一个应用程序或平台能够自动化编写和执行 E2E 测试？好吧，直到我偶然发现了今天视频的赞助商 Test Sprite。

[原文] [Speaker]: It works as an AI testing agent that connects directly into your IDE via its MCP server and handles the full testing life cycle in eight simple steps

[译文] [Speaker]: 它作为一个 AI 测试代理运行，通过其 MCP 服务器直接连接到你的 IDE，并分八个简单的步骤处理整个测试生命周期。

[原文] [Speaker]: It understands your product requirements analyzes your codebase then creates a test plan writes the tests executes them adjusts and reruns itself in a feedback loop if needed and then produces consolidated results

[译文] [Speaker]: 它理解你的产品需求，分析你的代码库，然后创建测试计划，编写测试，执行测试，在需要时通过反馈循环进行调整和重新运行，最后生成综合结果。

[原文] [Speaker]: So you can actually focus on development rather than trying to write tests and increase code coverage manually

[译文] [Speaker]: 这样你实际上就可以专注于开发，而不是试图手动编写测试和提高代码覆盖率。

[原文] [Speaker]: What's useful is that it's not only limited to just one layer It can validate front- end user flows backend APIs data consistency and even agent-driven behavior across modern stacks like React Node.js Python Java and more

[译文] [Speaker]: 有用的是，它不仅限于单一层级。它可以验证前端用户流程、后端 API、数据一致性，甚至是跨越 React、Node.js、Python、Java 等现代技术栈的代理驱动行为。

[原文] [Speaker]: Developers won't be spending their time writing tests at all in the near future So if you're already building faster with AI and want to save even more time in your development it's worth taking a look

[译文] [Speaker]: 在不久的将来，开发人员根本不需要花时间编写测试。所以，如果你已经在使用 AI 加快构建速度，并且想要在开发中节省更多时间，那么这值得一看。

[原文] [Speaker]: And I've left a link below if you want to check it out yourself

[译文] [Speaker]: 如果你想亲自查看，我在下面留了一个链接。

章节 5：乐观并发（Optimistic Concurrency）——版本控制机制

📝 本节摘要：

本节介绍了乐观并发（Optimistic Concurrency）的核心理念：假设冲突很少发生，因此不预先锁定数据（No Locks）。

>

作者通过图解展示了其工作流程：事务先读取数据，在内存中修改，最后在提交时检查是否有冲突。如果在此期间（读取和更新之间），另一个事务修改了数据，就会产生冲突。为了解决这个问题，作者引入了 “版本列（Version Column）” 的概念：每次更新时检查数据库中的版本号是否与读取时一致。如果版本号变了（例如从1变成了2），说明数据已被篡改，此时系统会回滚更改并重试，而不是覆盖他人的修改。

[原文] [Speaker]: All right now we come back to optimistic concurrency and let's see what the difference are So in here we're assuming that conflicts are rare Okay

[译文] [Speaker]: 好了，现在我们回到乐观并发（Optimistic Concurrency），看看有什么区别。在这里，我们假设冲突是罕见的。好吗。

[原文] [Speaker]: Instead of locking data immediately we let transactions read and modify without locks which can lead to conflicts and also check for conflicts only at the commit time and not before doing any changes

[译文] [Speaker]: 我们不立即锁定数据，而是让事务在没有锁的情况下读取和修改——这可能会导致冲突——并且只在提交（Commit）时检查冲突，而不是在做任何更改之前。

[原文] [Speaker]: Now this assumes that we have a lot of reader requests and not write requests because when we are reading something from our database we have lower chance for conflicts while pessimistic concurrency is for the time when you have a lot of rights for example booking something or reservation imagine Taylor Swift's concert right

[译文] [Speaker]: 这假设我们有大量的读请求而不是写请求，因为当我们从数据库读取某些内容时，发生冲突的几率较低。而悲观并发适用于你有大量写操作的时候，例如预订某物或预约，想象一下泰勒·斯威夫特（Taylor Swift）的演唱会，对吧。

[原文] [Speaker]: so in this case we're going to have the following thing by the way this doesn't have to be a transaction although it can be a transaction it can also be normal query in this case

[译文] [Speaker]: 所以在这种情况下，我们将遇到以下情况。顺便说一句，这不一定非要是事务，虽然它可以是事务，但在这种情况下它也可以是普通的查询。

[原文] [Speaker]: So let's take a look at what's happening here So we're selecting something from accounts and then as you can see this is not a transaction This is a simple update and a select command right

[译文] [Speaker]: 让我们看看这里发生了什么。我们从账户表中选择（Select）了一些东西，如你所见这不是一个事务。这是一个简单的更新（Update）和选择命令，对吧。

[原文] [Speaker]: then we're updating our accounts table and just disregard this version thing I'm going to explain what that is in a minute But we're basically setting our balance to some value

[译文] [Speaker]: 然后我们要更新我们的账户表——先忽略这个“版本（Version）”的东西，我一会解释它是什么——但我们基本上是将余额设置为某个值。

[原文] [Speaker]: and then also again the version I'm going to explain that in a minute But basically this is what transaction A did or a query or command A did and while this was running transaction B modified the value of the accounts here in between the select and the update

[译文] [Speaker]: 然后还有这个版本号，我一会解释。但基本上这就是事务 A——或者说查询/命令 A——所做的。而在它运行的同时，事务 B 在“选择”和“更新”之间修改了账户的值。

[原文] [Speaker]: So here transaction B actually modified what we read So we read one value and then before we even manage to update it here it actually the value already changed

[译文] [Speaker]: 所以在这里，事务 B 实际上修改了我们读取的内容。也就是说，我们读取了一个值，然后在我们要更新它之前，这个值实际上已经改变了。

[原文] [Speaker]: So here's where the conflict is going to be happening Is this good obviously not So what you can do in this case is to make sure that you have an extra column here So an extra column and it's going to be a version

[译文] [Speaker]: 这就是冲突发生的地方。这好吗？显然不好。所以在这种情况下，你能做的就是确保你这里有一个额外的列。一个额外的列，它就是版本（Version）。

[原文] [Speaker]: And as you can see we always increment the version every time we update it And when we're updating the version we want to make sure that the version matches the version that we expect

[译文] [Speaker]: 如你所见，每次我们更新它时，我们总是增加版本号。当我们更新版本时，我们要确保该版本与我们要预期的版本相匹配。

[原文] [Speaker]: And if the value doesn't match for example we were expecting version one but for some reason during the update we saw that the version is two And this tells us hey someone actually modified our data while we were trying to make an update And this is when you basically roll back your changes and retry

[译文] [Speaker]: 如果值不匹配——例如我们预期的是版本 1，但由于某种原因在更新期间我们看到版本是 2——这就告诉我们：嘿，当我们试图进行更新时，实际上有人修改了我们的数据。这时候你基本上就要回滚（Roll back）你的更改并重试。

章节 6：乐观并发的工程落地——代码示例与策略总结

📝 本节摘要：

本节首先明确了乐观并发的适用场景：读多写少的系统以及需要高扩展性的分布式系统。

>

接着，作者展示了在 Node.js (Sequelize ORM) 中的具体实现：只需在模型定义中添加 version: true。在代码层面，这极大地简化了逻辑——不再需要显式的 transaction 块，只需调用 save() 方法。ORM 会在底层自动比对版本号：如果版本不匹配，更新将失败。

>

最后，作者总结了该策略的优劣：优势在于无锁（No Locks）带来的高吞吐量；劣势在于频繁冲突会导致大量回滚（Rollback），浪费 CPU 资源。作者特别提醒，在处理失败时，不仅要有稳健的重试机制，还要注意用户体验，避免直接向用户抛出晦涩的技术错误信息。

[原文] [Speaker]: So typical use cases would be systems with many reads and fewer writes distributed systems with need for scalability

[译文] [Speaker]: 所以典型的用例将是那些读多写少的系统，以及需要可扩展性的分布式系统。

[原文] [Speaker]: Actually write down in the comments if you have any examples of where optimistic concurrency would be ideal

[译文] [Speaker]: 实际上，如果你有任何关于乐观并发理想应用场景的例子，请写在评论区。

[原文] [Speaker]: And by the way looking at the code the first thing that I really want to show you is the account And this is our schema for the table

[译文] [Speaker]: 顺便看一下代码，我真正想向你们展示的第一件事是账户（Account）。这是我们这张表的架构（Schema）。

[原文] [Speaker]: And the way you allow optimistic concurrency in SQLize is by adding this version true which means our table is going to have this extra column called version version which we can later use for resolving conflicts

[译文] [Speaker]: 在 Sequelize 中允许乐观并发的方式是添加 version: true，这意味着我们的表将拥有这个名为 version（版本）的额外列，我们稍后可以用它来解决冲突。

[原文] [Speaker]: Now we're going to have version all the time and the optimistic example is looking like this

[译文] [Speaker]: 现在我们将一直拥有版本号，而乐观并发的例子看起来像这样。

[原文] [Speaker]: As you can see we don't have a transaction We're simply finding the account by private key ID and then we're subtracting something and then we simply do a save

[译文] [Speaker]: 如你所见，我们没有事务。我们要做的只是通过主键 ID 找到账户，然后减去一些数额，接着简单地执行保存（Save）。

[原文] [Speaker]: All right we're not committing anything Just account.save and save is automatically going to do this check here Version equals the version that we expect under the hood

[译文] [Speaker]: 好了，我们没有提交任何东西。只是 account.save，而保存操作会自动在底层进行这个检查：版本等于我们要预期的版本。

[原文] [Speaker]: And it's doing it with the help of the fact that we said version is true All right as simple as that

[译文] [Speaker]: 它是借助于我们设置了 version 为 true 这一事实来完成的。好了，就是这么简单。

[原文] [Speaker]: Now going back to the board strengths are that there are going to be no logs and the higher concurrency and higher throughput meaning a lot of read requests can go at the same time

[译文] [Speaker]: 现在回到白板，优势在于将没有锁（注：原文口误说成 logs，结合语境应为 locks），以及更高的并发性和更高的吞吐量，这意味着大量的读请求可以同时进行。

[原文] [Speaker]: Weaknesses are that if there is a conflict and if they're frequent then a lot of transactions will be rolled back and this is a lot of CPU power Okay

[译文] [Speaker]: 弱点是如果存在冲突，而且如果冲突很频繁，那么大量的事务将被回滚，这会消耗大量的 CPU 算力。好吗。

[原文] [Speaker]: And requires a good version tracking meaning you should have some custom logic there if you're using this version that we saw or you can also use kind of a time stamp of the database

[译文] [Speaker]: 这需要良好的版本跟踪，意味着如果你使用我们看到的这种版本控制，你应该那里有一些自定义逻辑，或者你也可以使用数据库的时间戳之类的东西。

[原文] [Speaker]: So you need to have a robust logic for version tracking and also best practices as we said you need to have versioning your retries should be robust

[译文] [Speaker]: 所以你需要有稳健的版本跟踪逻辑。还有最佳实践，正如我们所说，你需要进行版本控制，你的重试机制应该是稳健的。

[原文] [Speaker]: and showing telling the users that hey there's an error because we need to roll back the transaction It's probably not ideal You need to find a creative way of telling the users hey sorry something went wrong please retry again

[译文] [Speaker]: 而向用户展示并告诉他们“嘿，有个错误，因为我们需要回滚事务”，这可能不太理想。你需要找到一种创造性的方式告诉用户“嘿，抱歉，出错了，请重试”。

[原文] [Speaker]: As simple as that If you guys learned anything new subscribe so that you see more videos like this And I'm going to see you in the next one

[译文] [Speaker]: 就这么简单。如果你们学到了任何新东西，请订阅以便看到更多像这样的视频。我们下期见。