Weakyon Blog

过载原理

过载是指当前负载超出了系统的最大处理能力，例如系统的极限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
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，我在公司已经应用了两年了，对他的基本特性比较熟悉，在这种场合下有这些优缺点