2 分布式锁引入
2.1 分布式锁的概念
先说锁
线程是进程的一个实体，同一进程下的多个线程可以进行资源的共享，多个线程共享一个资源时则会进行资源的竞争进而引发线程异常。
基于此类问题，我们引入锁这个概念，锁，是一种线程中的一种同步机制。通过加锁我们就可以实现对共享资源的互斥访问。
为什么会出现分布式锁？
因为集群环境下，无法避免要把一个项目部署成多个节点，但是数据的一致性导致每个节点访问的数据都是一样的，至此我们可以把每一个项目节点都当做一个线程，整个分布式集群当做一个进程，数据就是多个节点共享的资源，因此难免会引发分布式环境下的多线程问题。
2.2 Redis实现分布式锁
package redis_lock import ( "github.com/go-redis/redis/v8" "github.com/go-redsync/redsync/v4" "github.com/go-redsync/redsync/v4/redis/goredis/v8" "time" ) type RLock struct { Mutex *redsync.Mutex } func NewRLock(key string, expire ...time.Duration) *RLock { client := redis.NewClient(&redis.Options{ Addr: "localhost:6379", }) pool := goredis.NewPool(client) rs := redsync.New(pool) option := redsync.WithExpiry(time.Second * 5) if len(expire) == 1 { option = redsync.WithExpiry(expire[0]) } mutex := rs.NewMutex(key, option) return &RLock{Mutex: mutex} } func (r *RLock) Lock() error { return r.Mutex.Lock() } func (r *RLock) Unlock() error { if ok, err := r.Mutex.Unlock(); !ok || err != nil { return err } return nil } 复制代码
2.3 etcd实现分布式锁
package etcd_lock import ( "context" "fmt" "go.etcd.io/etcd/client/v3" "go.etcd.io/etcd/client/v3/concurrency" "time" ) type EtcdLock struct { Mutex *concurrency.Mutex } func NewEtcdLock(key string, expire ...time.Duration) *EtcdLock { timeOut := time.Second * 5 if len(expire) == 1 { timeOut = expire[0] } cli, err := clientv3.New(clientv3.Config{ Endpoints: []string{"127.0.0.1:2379"}, DialTimeout: time.Second * 5, }) if err != nil { fmt.Println(err) } s1, err := concurrency.NewSession(cli, concurrency.WithTTL(int(timeOut/time.Second))) if err != nil { fmt.Println(err) } return &EtcdLock{Mutex: concurrency.NewMutex(s1, key)} } func (r *EtcdLock) Lock(ctx context.Context) error { return r.Mutex.Lock(ctx) } func (r *EtcdLock) Unlock(ctx context.Context) error { return r.Mutex.Unlock(ctx) } 复制代码
2.4 Zookeeper实现分布式锁
package zk_lock import ( "fmt" "time" "github.com/go-zookeeper/zk" ) type ZkLock struct { ZLock *zk.Lock } func NewZkLock(key string, expire ...time.Duration) *ZkLock { timeOut := time.Second * 5 if len(expire) == 1 { timeOut = expire[0] } c, _, err := zk.Connect([]string{"127.0.0.1:2181"}, timeOut) if err != nil { fmt.Println(err) } lock := zk.NewLock(c, fmt.Sprintf("/zkLock/lock-%s", key), zk.WorldACL(zk.PermAll)) return &ZkLock{ZLock: lock} } func (z *ZkLock) Lock() error { return z.ZLock.Lock() } func (z ZkLock) Unlock() error { return z.ZLock.Unlock() } 复制代码
3 实践测评过程与需要注意的问题
以Zookeeper加锁的代码举例：
func RunServer() { http.HandleFunc("/buyBook", func(w http.ResponseWriter, r *http.Request) { username := r.URL.Query().Get("name") buyNum := r.URL.Query().Get("num") zkLock := zk_lock.NewZkLock(username, time.Second*3) err := zkLock.Lock() if err != nil { fmt.Errorf("Lock err = %s",err) w.Write([]byte("购买失败")) return } defer func() { err = zkLock.Unlock() if err != nil { fmt.Errorf("UnLock err = %s",err) } }() resp := service.BuyBook(username, cast.ToInt64(buyNum)) _, err = w.Write([]byte(resp)) if err != nil { fmt.Errorf("write err %s", err) } }) err := http.ListenAndServe(":8081", nil) if err != nil { fmt.Errorf("Http run err %s ", err) } } 复制代码
实践过程就不是很难了，就是一个加锁和解锁的过程，但是要注意的一些问题：
锁过期时间。分布式锁设置过期时间可以确保在未来的一定时间内，无论获得锁的节点发生了什么问题，最终锁都能被释放掉。但是时间也不能过短，防止业务还没有执行完锁就失效了。锁的全局唯一标识。锁的合理释放。我们要考虑在业务执行完成或发生异常时锁也能得到释放。
4 结论
经过Jmeter的分析报告，我们汇总成了一张表格：
依照表格我们可以得出结论：
Redis是三者中吞吐量、平均响应时间最优的一种方式，但是相对而言不如Zookeeper更加稳定，etcd在虽然在各个维度都不如Redis和Zookeeper，但是它仍然是一款比较优秀的云原生领域分布式注册中心，在集群环境中，Redis会产生脑裂、主从同步失败等安全问题，etcd则可以很大程度上屏蔽此类问题，所以我们不能只关注表面的数据，同时也要兼顾每个组件背后的原理和安全性。
最后，做一个小总结，分布式锁是一个相对复杂的组件，除了本文所讲述的以外，如果想要更好的使用分布式锁，还需要考虑其背后的诸多问题，比如锁操作的原子性、一致性、可重入性等，这些当然也与不同组件背后的算法相关，由于篇幅有限就没有一一详解，当然除了etcd、Redis、Zookeeper等组件之外，还有许多方式可以实现分布式锁，比如高性能的关系型数据库、MySQL乐观锁等等，都需要我们针对自身的业务进行选择。其实无论是一般的线程锁，还是分布式锁的作用都是一样的，只是作用的范围大小不同。只是范围越大技术复杂度就越大。
