Sentinel:给服务装保险丝
商品服务卡住时,别把购物车、订单服务也拖死。
它负责限流、熔断、降级、线程隔离,防止一个故障扩散成整个系统的故障。
先看一遍,不用记术语。
商品服务卡住时,别把购物车、订单服务也拖死。
它负责限流、熔断、降级、线程隔离,防止一个故障扩散成整个系统的故障。
下单做到一半失败,已经扣掉的库存要还回去。
它负责跨服务事务,让订单、库存、购物车等数据库操作一起成功或一起撤销。
假设用户点开购物车,购物车服务需要向商品服务查询最新价格。
| 办法 | 像什么 | 在商城里做什么 |
|---|---|---|
| 限流 | 景区入口每秒只放一批人 | 限制每秒请求数(QPS)。超出的请求立刻处理为“系统繁忙”,不再挤进去。 |
| 线程隔离 | 给某个窗口限定工作人员 | 限制“同时正在处理”的请求数。商品服务再慢,也不能占光购物车服务的线程。 |
| 熔断 | 电路总短路就先拉闸 | 商品服务连续失败或很慢,暂时不再调用它;过一段时间尝试恢复。 |
| 降级 | 主菜做不了,先上简餐 | 查询商品失败时,购物车先显示已有条目,最新价格暂时为空。 |
QPS=5:每秒最多放行 5 次。
线程数=5:同一时刻最多 5 个请求在执行;只要结束得快,一秒可以处理超过 5 次。
熔断决定“还要不要继续调用商品服务”。
降级决定“调用不了时返回什么”。两者经常配合使用。
每个微服务都有自己的数据库,一个数据库的事务只能管自己。
TM:发起和结束整笔全局事务的人,像总指挥。
RM:每个数据库操作的参与者,负责执行和回滚。
TC:协调中心,记录哪些参与者加入,通知提交或回滚。
Seata 在每个参与的业务库建 undo_log 表,保存修改前后的数据快照。全局事务失败时,利用它把已提交的本地数据改回去。
加在下单、余额支付这样的“跨服务操作入口”上。各参与服务仍需正确执行本地数据库操作,并连接同一个 Seata 事务协调器。
这是 Day02 的理论部分,记住场景比背字母有用。
访问不同节点时,读到的数据要一致。
请求来了,系统仍能给出响应。
节点之间的网络断开时,系统仍要面对这种情况。
交易服务建订单 → 商品服务扣库存 → 购物车服务按购买数量减少。原来购物车有 3 件,买 1 件后应该剩 2 件。任何一步失败,前面的修改都要回滚。
用户服务扣余额 → 支付服务更新支付单 → 交易服务更新订单状态。不能出现“钱扣了,但订单仍未支付”。任何一步失败,都要回滚。
先自己选,再点“批改”。答错也没关系,解释会告诉你为什么。
前 5 分钟:复述两个大问题:服务雪崩与跨库数据不一致。
接着 8 分钟:不看表格,自己讲出四种 Sentinel 保护办法。
接着 5 分钟:画出下单三步和支付三步,指出失败后要回滚什么。
最后 2 分钟:完成左侧清单,再做一次小测。