最新golang语言面试题总结（一）_golang面试题(1)，2024年最新2024Golang笔试题

题目：1、（（ 结果是false    
     2、（（））（） 是true   
     3、（（（）））（））是false  用go实现

思路：压栈找到匹配的出栈，找不到还放入栈中，直到栈为空，代表都匹配上了。
代码如下：（仅供参考）
func main() {
	//题目：1、（（ 结果是false
	//2、（（））（） true
	//3、（（（）））（））false  用go实现
	s0 := []string{"(", "("}
	fmt.Println(IsMatch(s0))//false
	s1 := []string{"(", "(", ")", ")", "(", ")"}
	fmt.Println(IsMatch(s1)) //true
	s2 := []string{"(", "(", ")", ")", "(", ")", ")"}
	fmt.Println(IsMatch(s2))//false
}
func IsMatch(str []string) bool {
	//压栈的思想
	if len(str) == 0 {
		return false
	}
	stack := NewStack()
	for _, v := range str {
		if stack.IsEmpty() {
			stack.Push(v)
		} else {
			sp := stack.Pop()
			if sp == "(" && string(v) == ")" {
				continue
			} else {
				stack.Push(sp)
				stack.Push(v)
			}
		}
	}
	if stack.IsEmpty() {
		return true
	}
	return false
}

type Element interface{} //可存入任何类型
type Stack struct {
	list []Element
}

//初始化栈
func NewStack() *Stack {
	return &Stack{
		list: make([]Element, 0),
	}
}
//判断栈是否空
func (s *Stack) IsEmpty() bool {
	if len(s.list) == 0 {
		return true
	} else {
		return false
	}
}

//入栈
func (s *Stack) Push(x interface{}) {
	s.list = append(s.list, x)
}

//出栈
func (s *Stack) Pop() Element {
	if len(s.list) <= 0 {
		fmt.Println("Stack is Empty")
		return nil
	} else {
		ret := s.list[len(s.list)-1]
		s.list = s.list[:len(s.list)-1]
		return ret
	}
}

15、算法题

题目：上楼梯有一阶和两阶
例如3层楼梯有如下种
1  2  1
1  1  2
1    

n阶有多少种：

代码如下：（仅供参考）
func main() {
	n := Upstairs(3)
	fmt.Println(n)
}

var mapData = make(map[int]int, 0)

func Upstairs(n int) int {
	if n == 1 {
		return 1
	}
	if n == 2 {
		return 2
	}
	if _, ok := mapData[n]; !ok {
		mapData[n] = Upstairs(n-1) + Upstairs(n-2)
	}
	return mapData[n]
}

16、用go实现单链表的反转

题目：单链表12345678910反转成10987654321
代码如下：（仅供参考）
func main() {
	//实现单链表的反转例如12345678910变成10987654321
	var head = new(ListNode)
	CreateNode(head, 10)
	PrintNode("前：", head)
	yyy := reverseList(head)
	PrintNode("后：", yyy)
}

type ListNode struct {
	data interface{}
	next *ListNode
}

func reverseList(head *ListNode) *ListNode {
	cur := head
	var pre *ListNode
	for cur != nil {
		cur.next, pre, cur = pre, cur, cur.next
	}
	return pre
}
func CreateNode(node *ListNode, max int) {
	cur := node
	for i := 1; i <= max; i++ {
		cur.next = &ListNode{}
		cur.data = i
		cur = cur.next
	}
}

//打印链表的方法
func PrintNode(str string, node *ListNode) {
	fmt.Print(str)
	for cur := node; cur != nil; cur = cur.next {
		if cur.data != nil {
			fmt.Print(cur.data, " ")
		}
	}
	fmt.Println()
}
结果：
前：1 2 3 4 5 6 7 8 9 10 
后：10 9 8 7 6 5 4 3 2 1 

17、算法题（在线求答案）

题目：
输入文件构成规则如下：
1. 每行代表一条记录，字段之间以逗号（,）分隔
2. 若字段内容包含逗号（,），则以双引号包围该字段
3. 若字段内容包含双引号（"），则以双引号包围该字段，字段内的双引号由一个变两个
请参照上面三条规则，编写一个解析程序，将解析后的记录内容按行输出，字段之间以TAB（\t）分隔，2小时内完成

示例：
    John,33,"足球,摄影",New York
    John,33,"足球,""摄影",New York
输出：
    John 33 足球,摄影 New York
    John 33 足球,"摄影 New York
 
输入：
2,John,45,"足球,摄影",New York
3,Carter Job,33,"""健身"",远足","河北,石家庄"
4,Steve,33,"大屏幕164""","DC""Home"""
5,"Jul,y",33,Football,Canada

求输出！

package main

import (
	"bufio"
	"fmt"
	"os"
	"strings"
)

func parseRecord(line string) string {
	var fields []string
	var inQuote bool
	var field string

	for i := 0; i < len(line); i++ {
		c := line[i]

		if c == ',' && !inQuote {
			fields = append(fields, field)
			field = ""
		} else if c == '"' {
			inQuote = !inQuote
			if i > 0 && line[i-1] == '"' {
				field += "\""
			}
		} else {
			field += string(c)
		}
	}

	fields = append(fields, field)

	return strings.Join(fields, "\t")
}

func main() {
	scanner := bufio.NewScanner(os.Stdin)
	for scanner.Scan() {
		line := scanner.Text()
		fmt.Println(parseRecord(line))
	}

	if err := scanner.Err(); err != nil {
		fmt.Fprintln(os.Stderr, "reading standard input:", err)
	}
}

18、slice和map区别代码输出题

题目一：
func main() {
	s1 := []int{1, 2, 3, 4, 5}
	changeslice(s1)
    fmt.Println(s1)//？s1的结果会变化吗？
	fmt.Println(len(s1), cap(s1))//？s1长度和容量会变化吗？
	m1 := map[int]int{1: 1, 2: 2, 3: 3, 4: 4}
	changeMap(m1)  
	fmt.Println(m1) //？m1中key等于1的值会变化吗？
    fmt.Println(len(m1))//？m1长度和容量会变化吗？
}
func changeslice(s []int) {
	s[0] = 2
	s = append(s, 7, 8, 9, 10)
}
func changeMap(m map[int]int) {
	m[1] = 2
	m[5] = 5
	m[6] = 6
}
答案：s1的值会变化，但是长度和容量不会变化。m1的值会变化，长度会变化。
切记：
 map 没有容量限制，所以内置函数 cap 也不接受 map 类型

题目二：
func main() {
	m := make(map[int]int)
	mdMap(m)
	fmt.Println(m)  //输出结果
}

func mdMap(m map[int]int) {
	m[1] = 100
	m[2] = 200
}
---------------------------------
func main() {
	var m1 map[int]int
	mdMap(m1)
	fmt.Println(m1)//输出的结果
}

func mdMap(m map[int]int) {
	m = make(map[int]int)
	m[1] = 100
	m[2] = 200
}
答案：m结果map[2:200 1:100]     m1的结果map[]

19、mysql有那几种存储引擎

MyISAM：

创建一个myisam存储引擎的表的时候回出现三个文件

1.tb_demo.frm，存储表定义；  2.tb_demo.MYD，存储数据；  3.tb_demo.MYI，存储索引。

MyISAM表无法处理事务，这就意味着有事务处理需求的表，不能使用MyISAM存储引擎。

MyISAM存储引擎特别适合在以下几种情况下使用：

1.选择密集型的表。MyISAM存储引擎在筛选大量数据时非常迅速，这是它最突出的优点。

2.插入密集型的表。MyISAM的并发插入特性允许同时选择和插入数据。例如：MyISAM存储引擎很适合管理邮件或Web服务器日志数据。

InnoDB：

InnoDB是一个健壮的事务型存储引擎MySQL 5.6.版本以后InnoDB就是作为默认的存储引擎。

InnoDB还引入了行级锁定和外键约束，在以下场合下，使用InnoDB是最理想的选择：

1. 更新密集的表。InnoDB存储引擎特别适合处理多重并发的更新请求。

2.事务。InnoDB存储引擎是支持事务的标准MySQL存储引擎。

3.自动灾难恢复。与其它存储引擎不同，InnoDB表能够自动从灾难中恢复。

4.外键约束。MySQL支持外键的存储引擎只有InnoDB。

5.支持自动增加列AUTO_INCREMENT属性。

MEMORY：

使用MySQL Memory存储引擎的出发点是速度。为得到最快的响应时间，采用的逻辑存储介质是系统内存。虽然在内存中存储表数据确实会提供很高的性能，但当mysqld守护进程崩溃时，所有的Memory数据都会丢失。获得速度的同时也带来了一些缺陷。它要求存储在Memory数据表里的数据使用的是长度不变的格式，这意味着不能使用BLOB和TEXT这样的长度可变的数据类型，VARCHAR是一种长度可变的类型，但因为它在MySQL内部当做长度固定不变的CHAR类型，所以可以使用。

一般在以下几种情况下使用Memory存储引擎：

1.目标数据较小，而且被非常频繁地访问。在内存中存放数据，所以会造成内存的使用，可以通过参数max_heap_table_size控制Memory表的大小，设置此参数，就可以限制Memory表的最大大小。

2.如果数据是临时的，而且要求必须立即可用，那么就可以存放在内存表中。

3.存储在Memory表中的数据如果突然丢失，不会对应用服务产生实质的负面影响。Memory同时支持散列索引和B树索引。B树索引的优于散列索引的是，可以使用部分查询和通配查询，也可以使用<、>和>=等操作符方便数据挖掘。散列索引进行“相等比较”非常快，但是对“范围比较”的速度就慢多了，因此散列索引值适合使用在=和<>的操作符中，不适合在<或>操作符中，也同样不适合用在order by子句中

MERGE：

MERGE存储引擎是一组MyISAM表的组合，这些MyISAM表结构必须完全相同，尽管其使用不如其它引擎突出，但是在某些情况下非常有用。说白了，Merge表就是几个相同MyISAM表的聚合器；Merge表中并没有数据，对Merge类型的表可以进行查询、更新、删除操作，这些操作实际上是对内部的MyISAM表进行操作。Merge存储引擎的使用场景。对于服务器日志这种信息，一般常用的存储策略是将数据分成很多表，每个名称与特定的时间端相关。例如：可以用12个相同的表来存储服务器日志数据，每个表用对应各个月份的名字来命名。当有必要基于所有12个日志表的数据来生成报表，这意味着需要编写并更新多表查询，以反映这些表中的信息。与其编写这些可能出现错误的查询，不如将这些表合并起来使用一条查询，之后再删除Merge表，而不影响原来的数据，删除Merge表只是删除Merge表的定义，对内部的表没有任何影响。

ARCHIVE：

rchive是归档的意思，在归档之后很多的高级功能就不再支持了，仅仅支持最基本的插入和查询两种功能。在MySQL 5.5版以前，Archive是不支持索引，但是在MySQL 5.5以后的版本中就开始支持索引了。Archive拥有很好的压缩机制，它使用zlib压缩库，在记录被请求时会实时压缩，所以它经常被用来当做仓库使用。

20、mysql中事务隔离级别有哪几种

• 读未提交（READ UNCOMITTED）
• 读提交（READ COMMITTED）
• 可重复读（REPEATABLE READ）
• 串行化（SERIALIZABLE）
• | 隔离级别 | 脏读 | 不可重复读 | 幻读 | | --- | --- | --- | --- | | READ UNCOMITTED | √ | √ | √ | | READ COMMITTED | × | √ | √ | | REPEATABLE READ | × | × | √ | | SERIALIZABLE | × | × | × |

mysql数据库事务的隔离级别有4个,而默认的事务处理级别就是【REPEATABLE-READ】,也就是可重复读

21、 B树、B+tree、Hash有什么区别

B树是一种多路自平衡搜索树，它类似普通的二叉树，但是B书允许每个节点有更多的子节点。B树示意图如下：

B树的特点：

1. 所有键值分布在整个树中

2. 任何关键字出现且只出现在一个节点中

3. 搜索有可能在非叶子节点结束

4. 在关键字全集内做一次查找，性能逼近二分查找算法

5. 树深度会很深，因为树顶放到元素比较少导致，检索元素比较慢。

 缺点：

       业务数据的大小可能远远超过了索引数据的大小，每次为了查找对比计算，需要把数据加载到内存以及 CPU 高速缓存中时，都要把索引数据和无关的业务数据全部查出来。本来一次就可以把所有索引数据加载进来，现在却要多次才能加载完。如果所对比的节点不是所查的数据，那么这些加载进内存的业务数据就毫无用处，全部抛弃。

 B+Tree： 

  

从图中也可以看到，B+树与B树的不同在于：

1. 所有关键字存储在叶子节点，非叶子节点不存储真正的data

2. 为所有叶子节点增加了一个链指针

3. 树顶可以放很多元素，树的深度比较矮，检索元素比较快。

 缺点：

       仍然有一个致命的缺陷，那就是它的索引数据与业务绑定在一块，而业务数据的大小很有可能远远超过了索引数据，这会大大减小一次 I/O 有用数据的获取，间接的增加 I/O 次数去获取有用的索引数据 

Hash:

  

特点：数组+链表

          1、查询单条数据很快，先解析出hash值，根据hash找到链表，然后找到索引最后根据索引找到数据。

  缺点：

1. 容易hash碰撞

2. Hash索引仅仅能满足“=”,“IN”,“<=>”查询，不能使用范围查询

3. 联合索引中，Hash索引不能利用部分索引键查询。

4. Hash索引无法避免数据的排序操作

5. Hash索引任何时候都不能避免表扫描

6. Hash索引遇到大量Hash值相等的情况后性能会下降

22、 Mysql 中 MyISAM 和 InnoDB 的区别有哪些？

1. InnoDB支持事务，MyISAM不支持

2. 对于InnoDB每一条SQL语言都默认封装成事务，自动提交，这样会影响速度，所以最好把多条SQL语言放在begin和commit之间，组成一个事务；

3. InnoDB支持外键，而MyISAM不支持。对一个包含外键的InnoDB表转为MYISAM会失败；

4. InnoDB是聚集索引，数据文件是和索引绑在一起的，必须要有主键，通过主键索引效率很高。

5. 但是辅助索引需要两次查询，先查询到主键，然后再通过主键查询到数据。因此主键不应该过大，因为主键太大，其他索引也都会很大。

6. 而MyISAM是非聚集索引，数据文件是分离的，索引保存的是数据文件的指针。主键索引和辅助索引是独立的。

7. InnoDB不保存表的具体行数，执行select count(*) from table时需要全表扫描。而MyISAM用一个变量保存了整个表的行数，执行上述语句时只需要读出该变量即可，速度很快；

8. Innodb不支持全文索引，而MyISAM支持全文索引，查询效率上MyISAM要高

23、 go向关闭的channel发送和读取数据是否报错

package main

import "fmt"

//向已关闭的通道读取数不会报错
func main1() {
	var ch = make(chan int)
	go func() {
		close(ch)
	}()
	fmt.Println(<-ch)
}

//向已关闭的通道发送数据报panic: send on closed channel
func main2() {
	var ch = make(chan int)
	go func() {
		close(ch)
	}()
	ch <- 1
}

//关闭通道向有缓存区接收数据会报错
func main3() {
	var ch = make(chan int, 10)
	go func() {
		close(ch)
	}()
	fmt.Println(<-ch)
}

//关闭通道向有缓冲区发送数据会报错panic:send on closed channel 
func main4() {
	var ch = make(chan int, 10)
	go func() {
		close(ch)
	}()
	ch <- 1
}

//关闭通道向有缓冲区循环发送数据会报错 panic: send on closed channel
func main() {
	var ch = make(chan int, 10)
	go func() {
		close(ch)
	}()
	for {
		ch <- 1
	}
}

24、Golang并发模型有几种

控制并发有三种种经典的方式，一种是通过channel通知实现并发控制 一种是WaitGroup，另外一种就是Context。

1、无缓冲通道

无缓冲的通道指的是通道的大小为0，也就是说，这种类型的通道在接收前没有能力保存任何值，它要求发送 goroutine 和接收 goroutine 同时准备好，才可以完成发送和接收操作。

从上面无缓冲的通道定义来看，发送 goroutine 和接收 gouroutine 必须是同步的，同时准备后，如果没有同时准备好的话，先执行的操作就会阻塞等待，直到另一个相对应的操作准备好为止。这种无缓冲的通道我们也称之为同步通道。

正式通过无缓冲通道来实现多 goroutine 并发控制

func main() {
    ch := make(chan instruct{})
    go func() {
        ch <- struct{}{}
    }()
    fmt.Println(<-ch)
}

当主 goroutine 运行到 <-ch 接受 channel 的值的时候，如果该 channel 中没有数据，就会一直阻塞等待，直到有值。 这样就可以简单实现并发控制

2. 通过sync包中的WaitGroup实现并发控制

在 sync 包中，提供了 WaitGroup ，它会等待它收集的所有 goroutine 任务全部完成，在主 goroutine 中 Add(delta int) 索要等待goroutine 的数量。在每一个 goroutine 完成后 Done() 表示这一个goroutine 已经完成，当所有的 goroutine 都完成后，在主 goroutine 中 WaitGroup 返回返回。

  func main() {
   var wg sync.WaitGroup
 
  // 开N个后台打印线程
  for i := 0; i < 10; i++ {
  wg.Add(1)
 
   go func() {
   fmt.Println("你好, 世界")
   wg.Done()
   }()
  }
 
  // 等待N个后台线程完成
   wg.Wait()
  }

3. 在Go 1.7 以后引进的强大的Context上下文，实现并发控制

3.1 简介

在一些简单场景下使用 channel 和 WaitGroup 已经足够了，但是当面临一些复杂多变的网络并发场景下 channel 和 WaitGroup 显得有些力不从心了。比如一个网络请求 Request，每个 Request 都需要开启一个 goroutine 做一些事情，这些 goroutine 又可能会开启其他的 goroutine，比如数据库和RPC服务。所以我们需要一种可以跟踪 goroutine 的方案，才可以达到控制他们的目的，这就是Go语言为我们提供的 Context，称之为上下文非常贴切，它就是goroutine 的上下文。它是包括一个程序的运行环境、现场和快照等。每个程序要运行时，都需要知道当前程序的运行状态，通常Go 将这些封装在一个 Context 里，再将它传给要执行的 goroutine 。context 包主要是用来处理多个 goroutine 之间共享数据，及多个 goroutine 的管理。

3.2 package context

context 包的核心是 struct Context，接口声明如下：

// A Context carries a deadline, cancelation signal, and request-scoped values
// across API boundaries. Its methods are safe for simultaneous use by multiple
// goroutines.
type Context interface {
    // Done returns a channel that is closed when this `Context` is canceled
    // or times out.
    Done() <-chan struct{}

    // Err indicates why this Context was canceled, after the Done channel
    // is closed.
    Err() error

    // Deadline returns the time when this Context will be canceled, if any.
    Deadline() (deadline time.Time, ok bool)

    // Value returns the value associated with key or nil if none.
    Value(key interface{}) interface{}
}

• Done() 返回一个只能接受数据的channel类型，当该context关闭或者超时时间到了的时候，该channel就会有一个取消信号

• Err() 在Done() 之后，返回context 取消的原因。

• Deadline() 设置该context cancel的时间点

• Value() 方法允许 Context 对象携带request作用域的数据，该数据必须是线程安全的。

Context 对象是线程安全的，你可以把一个 Context 对象传递给任意个数的 gorotuine，对它执行 取消 操作时，所有 goroutine 都会接收到取消信号。

一个 Context 不能拥有 Cancel 方法，同时我们也只能 Done channel 接收数据。
背后的原因是一致的：接收取消信号的函数和发送信号的函数通常不是一个。
一个典型的场景是：父操作为子操作操作启动 goroutine，子操作也就不能取消父操作。

3.4 context例子

当然，想要知道 Context 包是如何工作的，最好的方法是看一个例子。

func childFunc(cont context.Context, num *int) {
    ctx, _ := context.WithCancel(cont)
    for {
        select {
        case <-ctx.Done():
            fmt.Println("child Done : ", ctx.Err())
            return
        }
    }
}

func main() {
    gen := func(ctx context.Context) <-chan int {
        dst := make(chan int)
        n := 1
        go func() {
            for {
                select {
                case <-ctx.Done():
                    fmt.Println("parent Done : ", ctx.Err())
                    return // returning not to leak the goroutine
                case dst <- n:
                    n++
                    go childFunc(ctx, &n)
                }
            }
        }()
        return dst
    }

    ctx, cancel := context.WithCancel(context.Background())
    for n := range gen(ctx) {
        fmt.Println(n)
        if n >= 5 {
            break
        }
    }
    cancel()
    time.Sleep(5 * time.Second)
}

在上面的例子中，主要描述的是通过一个channel实现一个为循环次数为5的循环，
在每一个循环中产生一个goroutine，每一个goroutine中都传入context，在每个goroutine中通过传入ctx创建一个子Context,并且通过select一直监控该Context的运行情况，当在父Context退出的时候，代码中并没有明显调用子Context的Cancel函数，但是分析结果，子Context还是被正确合理的关闭了，这是因为，所有基于这个Context或者衍生的子Context都会收到通知，这时就可以进行清理操作了，最终释放goroutine，这就优雅的解决了goroutine启动后不可控的问题。

3.5 Context 使用原则

• 不要把Context放在结构体中，要以参数的方式传递

• 以Context作为参数的函数方法，应该把Context作为第一个参数，放在第一位。

• 给一个函数方法传递Context的时候，不要传递nil，如果不知道传递什么，就使用context.TODO

• Context的Value相关方法应该传递必须的数据，不要什么数据都使用这个传递

• Context是线程安全的，可以放心的在多个goroutine中传递

25、go分布式锁有几种

1 、进程内加锁

想要得到正确的结果的话，要把对计数器（counter）的操作代码部分加上锁：
// ... 省略之前部分
var wg sync.WaitGroup
var l sync.Mutex
for i := 0; i < 1000; i++ {
	wg.Add(1)
	go func () {
		defer wg.Done()
		l.Lock()
		counter++
		l.Unlock()
	}()
}
wg.Wait()
println(counter)
// ... 省略之后部分
这样就可以稳定地得到计算结果了：
❯❯❯ go run local_lock.go
1000

2、trylock

在某些场景，我们只是希望一个任务有单一的执行者。而不像计数器场景一样，所有goroutine都执行
成功。后来的goroutine在抢锁失败后，需要放弃其流程。这时候就需要trylock了。
trylock顾名思义，尝试加锁，加锁成功执行后续流程，如果加锁失败的话也不会阻塞，而会直接返回
加锁的结果。在Go语言中我们可以用大小为1的Channel来模拟trylock：

package main
import (
"sync"
)
type Lock struct {
	c chan struct{}
}

// NewLock generate a try lock
func NewLock() Lock {
	var l Lock
	l.c = make(chan struct{}, 1)
	l.c <- struct{}{}
	return l
}

// Lock try lock, return lock result
func (l Lock) Lock() bool {
	lockResult := false
	select {
	case <-l.c:
		lockResult = true
	default:
	}
	return lockResult
}

// Unlock , Unlock the try lock
func (l Lock) Unlock() {
	l.c <- struct{}{}
}

因为我们的逻辑限定每个goroutine只有成功执行了 Lock  才会继续执行后续逻辑，因此
在 Unlock  时可以保证Lock结构体中的channel一定是空，从而不会阻塞，也不会失败。上面的代
码使用了大小为1的channel来模拟trylock，理论上还可以使用标准库中的CAS来实现相同的功能且
成本更低，读者可以自行尝试。
在单机系统中，trylock并不是一个好选择。因为大量的goroutine抢锁可能会导致CPU无意义的资源
浪费。有一个专有名词用来描述这种抢锁的场景：活锁。
活锁指的是程序看起来在正常执行，但实际上CPU周期被浪费在抢锁，而非执行任务上，从而程序整体
的执行效率低下。活锁的问题定位起来要麻烦很多。所以在单机场景下，不建议使用这种锁。

3、基于Redis的setnx

在分布式场景下，我们也需要这种“抢占”的逻辑，这时候怎么办呢？我们可以使用Redis提供
的 setnx  命令：

package main

import (
"fmt"
"sync"
"time"

"github.com/go-redis/redis"
)

func incr() {
	client := redis.NewClient(&redis.Options{
		Addr:     "localhost:6379",
		Password: "", // no password set
		DB:       0,  // use default DB
	})

	var lockKey = "counter_lock"
	var counterKey = "counter"
	// lock
	resp := client.SetNX(lockKey, 1, time.Second*5)
	lockSuccess, err := resp.Result()

	if err != nil || !lockSuccess {
		fmt.Println(err, "lock result: ", lockSuccess)
		return
	}

	// counter ++
	getResp := client.Get(counterKey)
	cntValue, err := getResp.Int64()
	if err == nil {
		cntValue++
		resp := client.Set(counterKey, cntValue, 0)
		_, err := resp.Result()
		if err != nil {
			// log err
			println("set value error!")
		}
	}
	println("current counter is ", cntValue)

	delResp := client.Del(lockKey)
	unlockSuccess, err := delResp.Result()
	if err == nil && unlockSuccess > 0 {
		println("unlock success!")
	} else {
		println("unlock failed", err)
	}
}
func main() {
	var wg sync.WaitGroup
	for i := 0; i < 10; i++ {
		wg.Add(1)
		go func() {
			defer wg.Done()
			incr()
		}()
	}
	wg.Wait()
}
看看运行结果：
1.  ❯❯❯ go run redis_setnx.go
2.  <nil> lock result: false
3.  <nil> lock result: false
4.  <nil> lock result: false
5.  <nil> lock result: false
6.  <nil> lock result: false
7.  <nil> lock result: false
8.  <nil> lock result: false
9.  <nil> lock result: false
10.  <nil> lock result: false
11.  current counter is 2028
12.  unlock success!

通过代码和执行结果可以看到，我们远程调用 setnx  实际上和单机的trylock非常相似，如果获取
锁失败，那么相关的任务逻辑就不应该继续向前执行。
setnx  很适合在高并发场景下，用来争抢一些“唯一”的资源。比如交易撮合系统中卖家发起订单，
而多个买家会对其进行并发争抢。这种场景我们没有办法依赖具体的时间来判断先后，因为不管是用户
设备的时间，还是分布式场景下的各台机器的时间，都是没有办法在合并后保证正确的时序的。哪怕是
我们同一个机房的集群，不同的机器的系统时间可能也会有细微的差别。
所以，我们需要依赖于这些请求到达Redis节点的顺序来做正确的抢锁操作。如果用户的网络环境比较
差，那也只能自求多福了。

4、基于ZooKeeper

package main

import (
"time"

"github.com/samuel/go-zookeeper/zk"
)

func main() {
	c, _, err := zk.Connect([]string{"127.0.0.1"}, time.Second) //*10)
	if err != nil {
		panic(err)
	}
	l := zk.NewLock(c, "/lock", zk.WorldACL(zk.PermAll))
	err = l.Lock()
	if err != nil {
		panic(err)
	}
	println("lock succ, do your business logic")

	time.Sleep(time.Second * 10)

	// do some thing
	l.Unlock()
	println("unlock succ, finish business logic")
}

基于ZooKeeper的锁与基于Redis的锁的不同之处在于Lock成功之前会一直阻塞，这与我们单机场景
中的 mutex.Lock  很相似。
其原理也是基于临时Sequence节点和watch API，例如我们这里使用的是 /lock  节点。Lock会在
该节点下的节点列表中插入自己的值，只要节点下的子节点发生变化，就会通知所有watch该节点的程
序。这时候程序会检查当前节点下最小的子节点的id是否与自己的一致。如果一致，说明加锁成功了。
这种分布式的阻塞锁比较适合分布式任务调度场景，但不适合高频次持锁时间短的抢锁场景。按照
Google的Chubby论文里的阐述，基于强一致协议的锁适用于 粗粒度  的加锁操作。这里的粗粒度指
锁占用时间较长。我们在使用时也应思考在自己的业务场景中使用是否合适。

5、基于etcd

etcd是分布式系统中，功能上与ZooKeeper类似的组件，这两年越来越火了。上面基于ZooKeeper我
们实现了分布式阻塞锁，基于etcd，也可以实现类似的功能：

package main

import (
"log"

"github.com/zieckey/etcdsync"
)

func main() {
	m, err := etcdsync.New("/lock", 10, []string{"http://127.0.0.1:2379"})
	if m == nil || err != nil {
		log.Printf("etcdsync.New failed")
		return
	}
	err = m.Lock()
	if err != nil {
		log.Printf("etcdsync.Lock failed")
		return
	}

	log.Printf("etcdsync.Lock OK")
	log.Printf("Get the lock. Do something here.")

	err = m.Unlock()
	if err != nil {
		log.Printf("etcdsync.Unlock failed")
	} else {
		log.Printf("etcdsync.Unlock OK")
	}
}

etcd中没有像ZooKeeper那样的Sequence节点。所以其锁实现和基于ZooKeeper实现的有所不同。
在上述示例代码中使用的etcdsync的Lock流程是：

1. 先检查 /lock  路径下是否有值，如果有值，说明锁已经被别人抢了

2. 如果没有值，那么写入自己的值。写入成功返回，说明加锁成功。写入时如果节点被其它节点写
   入过了，那么会导致加锁失败，这时候到 3

3. watch  /lock  下的事件，此时陷入阻塞

4. 当 /lock  路径下发生事件时，当前进程被唤醒。检查发生的事件是否是删除事件（说明锁被持有
   者主动unlock），或者过期事件（说明锁过期失效）。如果是的话，那么回到 1，走抢锁流程。

26、定时器的实现原理

1、 时间堆

最常见的时间堆一般用小顶堆实现，小顶堆其实就是一种特殊的二叉树，见图6-4

 小顶堆的好处是什么呢？实际上对于定时器来说，如果堆顶元素比当前的时间还要大，那么说明堆内所
有元素都比当前时间大。进而说明这个时刻我们还没有必要对时间堆进行任何处理。定时检查的时间复
杂度是 O(1)  。
当我们发现堆顶的元素小于当前时间时，那么说明可能已经有一批事件已经开始过期了，这时进行正常
的弹出和堆调整操作就好。每一次堆调整的时间复杂度都是 O(LgN)  。
Go自身的内置定时器就是用时间堆来实现的，不过并没有使用二叉堆，而是使用了扁平一些的四叉堆。
在最近的版本中，还加了一些优化，我们先不说优化，先来看看四叉的小顶堆长什么样：

2、时间轮

 用时间轮来实现定时器时，我们需要定义每一个格子的“刻度”，可以将时间轮想像成一个时钟，中心有
秒针顺时针转动。每次转动到一个刻度时，我们就需要去查看该刻度挂载的任务列表是否有已经到期的
任务。
从结构上来讲，时间轮和哈希表很相似，如果我们把哈希算法定义为：触发时间%时间轮元素大小。那
么这就是一个简单的哈希表。在哈希冲突时，采用链表挂载哈希冲突的定时器。

3、任务分发

 

 每一个实例每隔一小时，会去数据库里把下一个小时需要处理的定时任务捞出来，捞取的时候只要取那
些 task_id % shard_count = shard_id  的那些任务即可。
当这些定时任务被触发之后需要通知用户侧，有两种思路：

1. 将任务被触发的信息封装为一条消息，发往消息队列，由用户侧对消息队列进行监听。

2. 对用户预先配置的回调函数进行调用。
   两种方案各有优缺点，如果采用1，那么如果消息队列出故障会导致整个系统不可用，当然，现在的消
   息队列一般也会有自身的高可用方案，大多数时候我们不用担心这个问题。其次一般业务流程中间走消
   息队列的话会导致延时增加，定时任务若必须在触发后的几十毫秒到几百毫秒内完成，那么采用消息队列就会有一定的风险。如果采用2，会加重定时任务系统的负担。我们知道，单机的定时器执行时最害
   怕的就是回调函数执行时间过长，这样会阻塞后续的任务执行。在分布式场景下，这种忧虑依然是适用
   的。一个不负责任的业务回调可能就会直接拖垮整个定时任务系统。所以我们还要考虑在回调的基础上
   增加经过测试的超时时间设置，并且对由用户填入的超时时间做慎重的审核。

27、负载均衡有几种方式

如果我们不考虑均衡的话，现在有n个服务节点，我们完成业务流程实际上只需要从这n个中挑出其中的
一个。有几种思路:
1. 按顺序挑: 例如上次选了第一台，那么这次就选第二台，下次第三台，如果已经到了最后一台，
那么下一次从第一台开始。这种情况下我们可以把服务节点信息都存储在数组中，每次请求完成
下游之后，将一个索引后移即可。在移到尽头时再移回数组开头处。
2. 随机挑一个: 每次都随机挑，真随机伪随机均可。假设选择第 x 台机器，那么x可描述
为 rand.Intn()%n  。
3. 根据某种权重，对下游节点进行排序，选择权重最大/小的那一个。
当然了，实际场景我们不可能无脑轮询或者无脑随机，如果对下游请求失败了，我们还需要某种机制来
进行重试，如果纯粹的随机算法，存在一定的可能性使你在下一次仍然随机到这次的问题节点。 

4、基于洗牌算法的负载均衡

在Go的标准库中实际上已经为我们内置了该算法:

  func shuffle(n int) []int {
   b := rand.Perm(n)
   return b
  }

网上学习资料一大堆，但如果学到的知识不成体系，遇到问题时只是浅尝辄止，不再深入研究，那么很难做到真正的技术提升。

需要这份系统化的资料的朋友，可以添加戳这里获取

一个人可以走的很快，但一群人才能走的更远！不论你是正从事IT行业的老鸟或是对IT行业感兴趣的新人，都欢迎加入我们的的圈子（技术交流、学习资源、职场吐槽、大厂内推、面试辅导），让我们一起学习成长！