golang的协程调度
众所周知,golang作为协程调度模型,是非抢占式而是自主放弃式的。
我的理解是,当一个协程进行IO的阻塞操作时,就会让出CPU,让调度程序来调度其他协程来进行操作
调度程序并不会因为你的实际调用时间过长就干掉你,如果你觉得自己调用时间太长,可以用runtime库的Gosched()让出CPU
但实际的测试(基于1.7版本)和之前的理解有差距,测试过程是递进的,可以直接跳过看结论
众所周知,golang作为协程调度模型,是非抢占式而是自主放弃式的。
我的理解是,当一个协程进行IO的阻塞操作时,就会让出CPU,让调度程序来调度其他协程来进行操作
调度程序并不会因为你的实际调用时间过长就干掉你,如果你觉得自己调用时间太长,可以用runtime库的Gosched()让出CPU
但实际的测试(基于1.7版本)和之前的理解有差距,测试过程是递进的,可以直接跳过看结论
过载是指当前负载超出了系统的最大处理能力,例如系统的极限QPS是100,但实际的请求达到了1000QPS
对一个完全没有过载保护的系统来说,原本是0.01秒完成的请求,并不是直觉上皆大欢喜的0.1秒完成
而是一部分请求稍微延长了请求时间,而另外一部分请求超时很多秒
这种现象的本质原因,是因为不管是基于epoll的异步调度模型,还是golang的协程模型等等
做文件系统的后台数据统计,需要实时统计数据库存储文件状况
写代码来做的话,文件的sql操作和文件表的更新要做到原子性,就很复杂。所以需要依赖mysql本身的功能。
事务,存储过程和触发器都能做到。
对于数据统计来说,由于本身对业务逻辑相对独立(操作完全独立的汇总表),因此我认为触发器就足堪大用了
url encoding在golang 1.7中使用的是net/url库
然而这个库有个小陷阱
主要问题是空格在http编码中是编码为%20还是+
从API列表看,编码用的是QueryEscape,解码用的是QueryUnescape
ServerMux是golang官方库中提供的路由框架,能够匹配最大路径分别处理到各个handle
简单的一个例子
1 | func newMux() { |
然而这样的代码,使用curl访问带双斜杠,会返回301,重定向到另外一个路径
对于使用单向加密鉴权(HMAC-SHA1)的代码来说,路径不同会导致鉴权失败
最近在完善强一致性的存储系统的时候,发现对强一致性的理解不够透彻,步入了误区
强一致性的理解:
resp返回给客户端之前,保证所有节点的内容都一致。
只要保证存储系统,在同步追加过程中强一致性,那么就能保证各个节点也为强一致性
在使用grpc的时候,对通信协议有着调用链追踪的需求
这部分要封装进框架,对使用方透明,因此协程上下文(Goroutine Local Storage)的用法顺理成章
但是搜索了些资料,发现golang并没有gls
google提供的解决方法是使用golang.org/x/net/context包来传递上下文信息
这是GPRC+ETCD服务发现的一种变种实现
在服务端代码的封装上有很大的区别,一个简单的服务发现系统中,服务端之间的状态互不影响
在主从系统中,主需要知道从的IP来向从复制数据(或者反过来从需要知道主的IP来拉取数据),当主挂了,需要选举一台从来切换成主
先安装protobuf的C库
然后安装protoc工具
1 | go get -u github.com/golang/protobuf/proto |
最后安装gRPC-go