面试题：MySQL锁粒度策略在复杂分布式系统中的应用

行级锁：
- 适用场景：在分布式电商系统中，对于库存管理，每次扣减库存通常只涉及某一种商品的库存记录，此时行级锁非常适用。例如，当用户下单购买特定商品时，只锁定该商品对应的库存行记录。这样在高并发情况下，不同订单对不同商品的库存操作可以并行执行，极大提高了并发性能。
- 优点：锁粒度细，并发度高，能最大程度减少锁争用。
- 缺点：加锁和解锁的开销相对较大。
表级锁：
- 适用场景：在一些全局操作时使用，比如在进行库存盘点，需要对整个库存表进行操作时，使用表级锁可以保证在盘点过程中不会有其他库存修改操作干扰，确保数据一致性。
- 优点：加锁和解锁速度快，开销小。
- 缺点：锁粒度粗，会降低系统的并发性能，因为一旦锁定表，其他所有对该表的操作都要等待。
页级锁：介于行级锁和表级锁之间，在某些情况下，如果需要锁定的数据量介于单行和整张表之间，页级锁可作为一种选择。例如，在批量处理某几类商品库存时，可能涉及多个行记录，但又不需要锁定整个表，此时页级锁可平衡并发和锁开销。

基于事务的锁控制：
- 订单处理：在处理订单时，使用事务来包裹整个订单流程，从下单、扣减库存到生成订单记录。例如，在MySQL中，通过START TRANSACTION开始事务，在事务内对涉及的库存行记录加行级锁（如SELECT... FOR UPDATE语句），确保在扣减库存时不会出现数据不一致问题。订单处理完成后，使用COMMIT提交事务释放锁。
- 库存管理：对于库存的修改操作，同样放在事务内。在分布式环境下，通过XA协议（如果MySQL支持分布式事务）或者类似TCC（Try - Confirm - Cancel）的补偿机制来保证分布式事务的一致性。
分布式锁的引入：
- 使用场景：由于是分布式系统，可能存在多个节点同时访问和修改数据的情况。为了避免数据冲突，引入分布式锁。例如，可以使用Redis实现分布式锁。当某个节点需要进行关键操作（如扣减库存）时，先尝试获取Redis分布式锁。如果获取成功，则可以进行操作，操作完成后释放锁；如果获取失败，则等待一段时间后重试。
- 实现方式：利用Redis的SETNX（SET if Not eXists）命令来实现锁的获取，通过设置锁的过期时间来防止死锁（即使节点故障未能正常释放锁，锁也会在过期时间后自动释放）。

网络延迟：
- 设置合理的锁等待超时时间：在获取锁时，无论是MySQL的行锁还是分布式锁，都设置一个合理的等待超时时间。例如，在获取MySQL行锁时，如果等待时间过长（超过设定的阈值），则放弃操作并返回错误信息给用户，提示稍后重试。对于分布式锁，在Redis中获取锁时，也设置一个合适的等待时间，避免无限期等待。
- 异步处理：对于一些非关键且耗时的操作，可以采用异步处理方式。例如，订单生成后，一些后续的统计操作可以异步进行，这样可以减少主流程因网络延迟造成的响应时间过长问题。
节点故障：
- 故障检测与自动恢复：在分布式系统中，引入故障检测机制，例如使用心跳检测机制。如果某个节点出现故障，其他节点能够及时感知。对于正在进行的操作，如果是使用分布式锁，当节点故障时，锁会因为过期时间自动释放，其他节点可以重新获取锁进行操作。在MySQL中，如果节点故障导致事务未完成，MySQL的自动恢复机制会回滚未完成的事务，保证数据一致性。
- 数据备份与恢复：定期对数据库进行备份，在节点故障导致数据丢失时，可以通过备份数据进行恢复。同时，采用多副本机制，将数据复制到多个节点，确保即使某个节点故障，数据仍然可用。

星途面试题库