并发控制
waitGroup.done()不是必须写在main方法中吗? 为什么我的协程没有成功等待?
熊:如果用了wait group
,请求就直接卡住了,如果只有一个goroutine
那和直接调用函数没有区别其实。你是想请求立刻返回,然后其他数据稍后返回的话,用中间件比如kafka
。或者用回调callback
错误现场
错误原因:没有能成功等待goroutine
执行完,done
要放goroutine
里,外面是wait
。
参考用例
代码语言:javascript复制var wg sync.WaitGroup
sList := []string{"a", "b"}
wg.Add(len(sList))
for _, d := range sList {
go func() {
defer wg.Done()
fmt.Println(d)
}()
}
wg.Wait()
数据竞争
如果不同的线程写同一个map的不同key内容是不是不用sync.Map了?会存在数据竞争吗?但是如果我make的时候提前指定容量呢?
熊:会影响的,估计map
中的hmap
会影响到,有几率会在运行时报错
机器马:你在用之前没法确定会用哪个key
啊,除非你再用结构体封装一层
熊:我想到两个办法,1是用这个,还有一个是弄个channel
,如果数据用途不一样,弄成结构体channel
,用一个goroutine
来接收他们。单独用一个线程来接受数据,go
这个东西就是个语言,怎么好用怎么来,虽然一直是在推channel
,但只要实现需求。
sync.Map为什么没有len测长度方法?
Mike:看来有人也遇到这么问题,为杀map
支持len()
,而sync.Map
不支持。有兴趣的可以看看issue
. 简单说官方认为 map
本来就不应该有length的实现。
机器马:2017年社区就在吵要不要加个len
方法了。一般syncmap都不会单独使用,而是封装到结构体里,然后再写一层方法,所以一般就会在这一层做count
,用原子操作计数。
追问:sync.Map
这个Range
方法有个返回值,是bool
是用来返回是否range
空map
吗?range
如何处理碰到到空的?
熊:这个bool
是传入函数的返回值,调用完以后如果是Map
是空的,实际上就什么也没做,不会给返回。里面给迭代,你传入的函数处理下k v
的行了。没办法判断是否为空。
登陆验证
我们可以用UUID生成我们的token,为什么还要用jwt呢(redis中存储token和用户信息对应关系)?
Mike:无状态 jwt
不在服务端存储任何状态。RESTful API
的原则之一是无状态,通过redis
存储token
和用户信息,违背了无状态原则。
Mike:JWT的优点:
- 可扩展性好 应用程序分布式部署的情况下,
session
需要做多机数据共享,通常可以存在数据库或者redis
里面。而jwt
不需要。 - 无状态
jwt
不在服务端存储任何状态。RESTful API的原则之一是无状态,发出请求时,总会返回带有参数的响应,不会产生附加影响。用户的认证状态引入这种附加影响,这破坏了这一原则。另外jwt
的载荷中可以存储一些常用信息,用于交换信息,有效地使用JWT
,可以降低服务器查询数据库的次数。
Mike:缺点:由于jwt
的payload
是使用base64
编码的,并没有加密,因此jwt
中不能存储敏感数据。而session
的信息是存在服务端的,相对来说更安全。
熊:关于前端现实当前是哪个用户的问题,只需要后端把用户基本信息存cookie
里就可以了。后端用token
获取用户信息,把二者分离开。
熊:关于Mike
所述的第一个优点,实际上也有弊端,因为必须等待token
记录的时间到期,jwt
才会判定token
过期,服务端无法主动过期。也无法做多平台挤出登陆,类似于QQ那样子。熊:gtoken
就是存redis
此用户名已被占用: jwt
一般还要再加密吧?我记得是有rsa
熊:确实是要加密的
宋跑跑:签名加密?
此用户名已被占用: 难道不是吗? 不然token
裸奔。
宋跑跑 (宋跑跑): 害 信息其实都能拿到了。
异常处理
go你们在项目中都是怎么异常处理的呀,java是抛出自定义有业务异常然后全局异常捕获?
张朝胤:Golang
不是if err=nil
?全局try catch
怎么处理?
Mike:fmt. Errorf
可以包装多层错误,再用 errors.ls
集中判断。没必要把java
里面那一套带进Go
,这两门语言的哲学本来就不一样。
宋跑跑:recover
国玮:exception != error
,错误是错误 异常是异常,错误是可以考虑降级处理 不影响程序运行的 异常反之。例如最常用的 error
级别,Go
语言贡献者 Davio
认为,对错误进行降级处理后,应该打印 info
级别的日志,这意味着我处理了错误,或者往上抛并 warp
它。不过我不是很赞同这个观点 info
和 error
的处理是完全不同的。错误就该打出来。
国玮:对于错误 其实Go
的哲学就是 error is value
,你把它当做一个值来处理,exception
是那种会让程序崩溃的,崩溃恢复用recover
就行。
吆吆好叼啊:可以这么理解吗?service
层出现异常直接返回,controller
层调用service
层方法进行处理,如果出现错误,controller
层返回前端自定义异常json
数。
国玮:可以,调用者处理错误。不需要像java
那样抛出业务异常,有个专门的对controller
层处理的异常处理类。但是这句话里面,要注意,是错误,不是异常!要弄清楚它们的概念呀。
国玮:Java
中的异常,是可以继承的,那么就是说父 exception
可以接收一切 子 exception
,这就没有做到细分。
国玮:错误可以用 Wrap
一层一层往上抛(error std lib
的一个方法),大概意思就是 Warp
去包装错误,为错误提供更多的“证据”和“线索”,但是并没有真正的处理错误,处理错误本质上还是交给调用者。
Mike:其实很灵活的,对于错误处理完全看业务需要,有些错误可以跳过,有些不行,必须得返回。
国玮:嗯嗯,在实际编码中,确实是这样的,不过 Dave
认为,如果你对错误不关心,那么你也不应该关心它返回的值。可能是提醒我们要谨慎吧!
其他
大家有go 单体项目推荐吗,我阅读阅读(最好是格式规范)?
https://github.com/golang-standards/project-layout