业务场景
因为项目刚上线，目前暂不打算引入其他中间件，所以打算通过 mysql 来实现分布式读写锁；而该业务场景也满足分布式读写锁的场景，抽象后的业务场景是：特定资源 X，可以执行 2 种操作：读操作和写操作，2种操作需要满足下面条件:
- 执行操作的机器分布式在不同的节点中，也就是分布式的；
- 读操作是共享的，也就是说同时可以有多个 goroutine 对资源 X 执行读操作；
- 写操作是互斥的，也就是说同一时刻只允许有一个 goroutine 对资源 X 执行写操作；
- 读操作和写操作是互斥的，也就是说写操作和读操作不能同时存在
既然需要如此实现，下面我们看下什么是分布式读写锁。
什么是分布式读写锁
大家对于锁肯定不陌生，在 golang 中 sync.Mutex 锁是常见的，一般用在单节点多 goroutine 中对资源的并发访问；但是分布式场景下，单节点 sync.Mutex 加锁的方式就会失去作用，于是人们为了在分布式环境中实现对共享资源的互斥访问，实现了各种分布式锁。
而分布式读写锁是比分布式锁粒度更小的锁，对业务场景的加锁会更加灵活，其中分布式读写锁也遵循读写锁的原则：
- 读模式共享，写模式互斥。
- 它三种模式状态: 读加锁状态、写加锁状态、无锁状态。
分布式读写锁的访问原则与读写锁类似，下面我们具体看下。
分布式读写锁的访问原则
以下列表为读写锁(也就是分布式读写锁)的读写访问原则
| 当前锁状态 | 读锁请求 | 写锁请求 |
|---|---|---|
| 无锁状态 | 可以 | 可以 |
| 读锁状态 | 可以 | 不可以 |
| 写锁状态 | 不可以 | 不可以 |
读锁
- 只有在无锁和读锁下可以获取读锁。
- 读锁的模式下，任何请求读锁都可以。
- 读锁的模式下， 请求写锁不可以，直到所有读锁解锁，写锁才能获取到锁。
写锁
- 只有在无锁状态下可以获取写锁。
- 写锁的模式下，任何请求读锁和写锁都阻塞，直到写锁解锁。
具体实现
如果本地没有 mysql 数据库，可以通过这篇文章快速搭建: 如何使用 docker 搭建一个 mysql 服务
通过 gorm 连接 mysql
gorm 是一个 golang 的 orm 框架，可以使用它快速连接数据库，具体代码如下:
首先我们定义了一个库存表 stocks，并且在其中添加三个和读写锁相关的字段，三个字段的含义如下：
- LockMark: 表示某条数据加锁的状态，只能是读锁、写锁、无锁状态中的一种。
- ReadLockCount: 首先读模式是共享的，意味着可以有多个 goroutine 并发访问，而 ReadLockCount 字段则记录当前并发访问的 goroutine 数量。
- LockReason: 记录当前加锁的原因；读锁是最新的 goroutine 的 lockReason，写锁则是写锁 goroutine 的 lockReason。
其余则是一些 gorm 连接 mysql 逻辑，这里不再多赘述。
实现读锁模式
具体代码如下:
执行以上代码是可以正常运行的， 下面我们分析下:
- 读锁的 sql 语句如下，只要在非写锁状态下就能加读锁。
- 解读锁的 sql 语句如下，只有在读锁状态下才能解读锁，另外还要更新 read_lock_count 和 lock_reason 字段。
实现写锁模式
具体代码如下:
执行以上代码也是可以运行，下面是分析结果
- 写锁的 sql 语句如下，只有在无锁状态下才能加锁成功
- 解写锁的 sql 语句如下，只有在写锁状态下才能解写锁
总结
分布式读写锁的实现有多种方式，也可以通过 etcd、redisson 的方式进行实现，而本文着重说明可通过 mysql 来实现，这种方式的优势在于不必引入额外的组件且实现较为简单，因此也有一定的应用场景，