第七十三天

主丛同步的原理? mysql还有什么相关的log文件?

MySQL主从同步（Replication）的原理主要基于以下步骤：

1. 主库Binlog记录：

   • 主数据库开启二进制日志（Binary Log）功能，将所有更改数据的SQL语句（包括INSERT、UPDATE、DELETE等DML操作，以及CREATE、ALTER、DROP等DDL操作）以及相关的事务信息记录到Binlog中。

2. 从库I/O线程：

   • 从库启动I/O线程，该线程连接到主库并请求主库的Binlog日志。主库将Binlog日志的内容发送给从库的I/O线程。

3. Relay Log存储：

   • 从库的I/O线程接收到Binlog内容后，将其写入到本地的中继日志（Relay Log）中。

4. SQL线程应用：

   • 从库启动SQL线程，该线程读取Relay Log中的事件，并按照事件发生的顺序在从库上重新执行这些事件，从而实现主库数据的同步。

5. 心跳和错误处理：

   • 主从之间通过定期的心跳包（Heartbeat）维持连接状态，并及时处理网络中断、主库宕机等情况，保证主从同步的可靠性。

MySQL相关的日志文件还包括：

• 错误日志（Error Log）：记录MySQL服务器启动、运行过程中的错误信息以及警告信息。
• 慢查询日志（Slow Query Log）：记录执行时间超过设定阈值的SQL查询语句。
• 通用查询日志（General Query Log）：记录服务器接收的所有SQL语句，无论是否成功执行，可用于审计或诊断。
• InnoDB事务日志（Redo Logs）：对于使用InnoDB存储引擎的表，除了Binlog之外，还会有redo log记录事务操作，用于事务的持久性和崩溃恢复。

分布式锁的原理?

分布式锁是一种在分布式系统中，用来在不同节点间实现资源共享互斥访问的机制，以保证在分布式环境下对公共资源进行并发控制。以下是一些典型的分布式锁实现原理：

1. 基于数据库实现：

   • 创建一个专门的锁表，其中每一行代表一把锁，通过插入唯一键（如锁ID）的方式来获取锁，获取锁的操作是原子性的（如使用INSERT IGNORE、INSERT INTO...ON DUPLICATE KEY UPDATE或者SELECT FOR UPDATE NOWAIT/LIMIT 1等SQL语句）。
   • 当需要释放锁时，通过删除对应的行来释放资源。
   • 还可以通过设置锁的超时时间，防止锁持有者因意外未能释放锁而造成死锁。

2. 基于Redis实现：

   • 使用Redis的原子操作如SETNX（Set if Not Exists）命令来获取锁，如果设置成功则获取锁成功。
   • 设置锁的过期时间（expire time）以防止死锁，如果持有锁的节点挂掉，锁也能自动释放。
   • 使用Lua脚本或者Redisson这样的客户端库来封装更复杂的获取、续期和释放锁的操作，以保证操作的原子性。

3. 基于ZooKeeper实现：

   • 在ZooKeeper的节点树（ZNode）上创建临时有序节点，第一个创建成功节点的客户端获取锁。
   • 获取锁的客户端监听父节点，当持有锁的客户端失效时，ZooKeeper会自动删除其临时节点，此时下一个序号最小的节点可以继承锁。
   • 可以通过设置Watcher来通知客户端锁的状态变化。

4. 基于Consul实现：

   • 类似于ZooKeeper，Consul也支持创建带有TTL（Time To Live）的键值对，客户端通过API争抢锁，同时也需要监听锁的变化并在锁即将过期时进行续约。

分布式锁的核心要点包括：

• 互斥性：在任何时刻，只有一个客户端能持有锁。
• 公平性（可选）：按照请求的顺序依次分配锁，即先请求的客户端优先获得锁。
• 可重入性（可选）：同一个客户端在已经持有锁的情况下，可以再次请求并获取锁。
• 容错性：在节点失败或网络分区等异常情况下，仍能保证锁的正确释放和分配。
• 锁超时：防止客户端在获取锁后因故无法释放，导致其他客户端长期等待。