golang的http客户端读写超时设置
net/http库中提供的Client中的Timeout字段是针对整个读写过程的。
也就是说如果下载或者上传一个很大的文件,Timeout字段设置为10秒,那么到10秒的时候不管你在做什么这个连接会报出Timeout
而一般而言,客户端其实需要的是每个连接的read,write timeout。这里需要设置Client中的Transport字段
Transport字段是一个接口
1 | type RoundTripper interface { |
net/http库中提供的Client中的Timeout字段是针对整个读写过程的。
也就是说如果下载或者上传一个很大的文件,Timeout字段设置为10秒,那么到10秒的时候不管你在做什么这个连接会报出Timeout
而一般而言,客户端其实需要的是每个连接的read,write timeout。这里需要设置Client中的Transport字段
Transport字段是一个接口
1 | type RoundTripper interface { |
大学的时候对设计模式走入了误区,总以为那是没什么用的东西,看了局限自己的思维,让自己无法发挥自己的灵性天马行空的编码。
这实在是个错误,是随着代码慢慢码多了,原来觉得没什么问题的代码,耦合越来越严重。才寻求解决办法。
命令模式最初看的别人文章的时候觉得没什么用,因为每个人的理解都不一样。
有的人的重点在于JAVA没有回调函数,所以把命令模式当作当作JAVA的回调函数。
有的人的重点在于命令模式可以方便的进行DO和UNDO。
众所周知,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包来传递上下文信息