Weakyon Blog

问题描述

url encoding在golang 1.7中使用的是net/url库

然而这个库有个小陷阱

主要问题是空格在http编码中是编码为%20还是+

从API列表看，编码用的是QueryEscape，解码用的是QueryUnescape

ServerMux是golang官方库中提供的路由框架，能够匹配最大路径分别处理到各个handle

简单的一个例子

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

func newMux() {
    mux := http.NewServeMux()                                                  
    mux.HandleFunc("/v1/", httpV1)                                             
    mux.HandleFunc("/v2/", httpV2)                                             
    server := &http.Server {                                                   
        Addr:               ":8080",                                           
        Handler:            mux,                                               
    }                                                                          
    if err = server.ListenAndServe();err != nil {                              
        fmt.Println("server port serve failed: %s",err)                          
        return                                                                 
    }
}

func httpV1(wr http.ResponseWriter, r *http.Request) {
	fmt.Println(r.URL)
	wr.WriteHeader(200)
}

func httpV2(wr http.ResponseWriter, r *http.Request) {
	fmt.Println(r.URL)
	wr.WriteHeader(200)
}

然而这样的代码，使用curl访问带双斜杠，会返回301，重定向到另外一个路径

对于使用单向加密鉴权(HMAC-SHA1)的代码来说，路径不同会导致鉴权失败

最近在完善强一致性的存储系统的时候，发现对强一致性的理解不够透彻，步入了误区

强一致性存储系统的简单理解和定义

强一致性的理解：

resp返回给客户端之前，保证所有节点的内容都一致。

只要保证存储系统，在同步追加过程中强一致性，那么就能保证各个节点也为强一致性

在使用grpc的时候，对通信协议有着调用链追踪的需求

这部分要封装进框架，对使用方透明，因此协程上下文(Goroutine Local Storage)的用法顺理成章

但是搜索了些资料，发现golang并没有gls

google提供的解决方法是使用golang.org/x/net/context包来传递上下文信息

google的设计理念:context

这是GPRC+ETCD服务发现的一种变种实现

在服务端代码的封装上有很大的区别，一个简单的服务发现系统中，服务端之间的状态互不影响

在主从系统中，主需要知道从的IP来向从复制数据（或者反过来从需要知道主的IP来拉取数据）,当主挂了，需要选举一台从来切换成主

服务发现的变种实现

安装

先安装protobuf的C库

然后安装protoc工具

1
2
3

go get -u github.com/golang/protobuf/proto

go get -u github.com/golang/protobuf/protoc-gen-go

最后安装gRPC-go

难点：

最近公司做用户数据迁移，4TB的量，租借了20Gb的带宽，完整迁移需要25天，给的迁移期只有30天，整个迁移过程的容错性和可靠性要非常强

另外由于数据的特殊性，用户数据的错乱比起迁移失败等等无疑是更严重的问题，所以迁移过程要保证强独立性

然而迁移过程的开发时间只有5天，测试时间5天，非常仓促（实际上线后确实遇到不少问题，又花了5天才全部解决）

分析和解决：

需求是图片，视频等文件的存储

属于少写多读的场合，修改操作较少。文件粒度是大小文件都有。

fastdfs

先谈谈fastdfs，我在公司已经应用了两年了，对他的基本特性比较熟悉，在这种场合下有这些优缺点

golang的http上传文件的实现细节严格遵循了multipart/form-data的RFC1867规范，细节网上已经分析了很多了

本篇只是讨论golang上如何使用官方库实现的框架

客户端上传很简单，利用"mime/multipart"官方库即可完成上传

可以看到这里上传文件时全部加载在内存的bodyBuf字符数组中，所以这里只是上传小文件，大文件这么上传会写爆内存

首先是轮子地址：

https://github.com/tedcy/fdfs_client

最近用go做项目，要用到fastdfs

看了下github上star最多的fastdfs go客户端https://github.com/weilaihui/fdfs_client，稍微看了下感觉不太好。