参考资料 Link to heading

基本概念 Link to heading

COS(Cloud Object Storage,云对象存储)

Bucket(存储桶)

  • 命名上,由存储桶名称(BucketName)和APPID两部分组成,中间以"-“相连,例如examplebucket-1250000000
  • 存储桶具有着地域(region),对象存储允许用户在不同的地域上创建存储桶。

Object(对象)

  • 存储桶上存储的内容称为对象,对象是对象存储(Cloud Object Storage, cos)的基本单元,包括对象键、对象值和对象元数据
    • 对象键是对象在存储桶中的唯一标识,可以通俗理解为文件路径。
    • 对象值是上传的对象本身,可以通俗的理解为文件内容
    • 对象元数据是一组键值对,可以通俗的理解为文件的属性

对象存储的特点 Link to heading

  • 文件特点:适合存储unstructure的对象,对象的操作与传统的文件不同,上传时只能选择直接上传和分块上传(类append),不能如传统文件一样根据偏移值实现随机存储。
  • 异地容灾
  • 腾讯云cos的特点:冷热分离
  • 速度限制:cos在设计上并不是为了高并发和强一致性,因此基于事务的操作可能不应该选择使用cos。
    • 速度上对于QPS为3W以下的GET/PUT等操作没有问题,3W以上需要采取优化。

示例代码 Link to heading

本身没什么难度,随便放一段示例代码

package main

import (
	"context"
	"encoding/json"
	"fmt"
	"github.com/tencentyun/cos-go-sdk-v5"
	"github.com/tencentyun/cos-go-sdk-v5/debug"
	"io/ioutil"
	"net/http"
	"net/url"
)

func log_status(err error) {
	if err == nil {
		return
	}
	if cos.IsNotFoundError(err) {
		// WARN
		fmt.Println("WARN: Resource is not existed")
	} else if e, ok := cos.IsCOSError(err); ok {
		fmt.Printf("ERROR: Code: %v\n", e.Code)
		fmt.Printf("ERROR: Message: %v\n", e.Message)
		fmt.Printf("ERROR: Resource: %v\n", e.Resource)
		fmt.Printf("ERROR: RequestId: %v\n", e.RequestID)
		// ERROR
	} else {
		fmt.Printf("ERROR: %v\n", err)
		// ERROR
	}
}

type testReq struct {
	BookId  int
	Message string
}

func main() {
	// 存储桶名称,由bucketname-appid 组成,appid必须填入,可以在COS控制台查看存储桶名称。 https://console.cloud.tencent.com/cos5/bucket
	// 替换为用户的 region,存储桶region可以在COS控制台“存储桶概览”查看 https://console.cloud.tencent.com/ ,关于地域的详情见 https://cloud.tencent.com/document/product/436/6224 。
	u, _ := url.Parse("https://wtytest-1252789333.cos.ap-guangzhou.myqcloud.com")
	b := &cos.BaseURL{BucketURL: u}
	c := cos.NewClient(b, &http.Client{
		Transport: &cos.AuthorizationTransport{
			// 通过环境变量获取密钥
			// 环境变量 COS_SECRETID 表示用户的 SecretId,登录访问管理控制台查看密钥,https://console.cloud.tencent.com/cam/capi
			SecretID: "secretID",
			// 环境变量 COS_SECRETKEY 表示用户的 SecretKey,登录访问管理控制台查看密钥,https://console.cloud.tencent.com/cam/capi
			SecretKey: "secretKey",
			// Debug 模式,把对应 请求头部、请求内容、响应头部、响应内容 输出到标准输出
			Transport: &debug.DebugRequestTransport{
				RequestHeader:  true,
				RequestBody:    true,
				ResponseHeader: true,
				ResponseBody:   false,
			},
		},
	})

	// Case1 上传对象
	//t := testReq{BookId: 10009, Message: "this is a message"}
	name1 := "test/cos"
	//data, err := json.Marshal(t)
	//if err != nil {
	//	panic(err)
	//}
	////f := strings.NewReader("test")
	//k := bytes.NewReader(data)
	//_, err = c.Object.Put(context.Background(), name1, k, nil)
	//log_status(err)
	// Case2 下载对象
	resp, err := c.Object.Get(context.Background(), name1, nil)
	log_status(err)
	var result testReq
	bs, _ := ioutil.ReadAll(resp.Body)
	resp.Body.Close()
	json.Unmarshal(bs, &result)
	fmt.Println(result)
}

读写Object本身并没有什么难度,要拿到Object所对应的key可以采取GetBucket的方式读写目录中的所有文件。

代码阅读 Link to heading

问题:如果不关闭resp.Body会发生什么?

  • 按照此文SO上的提问,如果没能读完resp中的所有内容并将其关闭,会导致无法重用HTTP链接。
  • 腾讯云的cos Client,其返回的Body采用了一个自制的TeeReader来读取http请求的resp.Body,因此如果没有关闭返回的Body,问题应该与不关闭resp.Body的问题是一致的。
  • 新的问题:SO上的提问中,JimB提到他偏向于使用io.LimitReader,并提出在连接比较大的时候创建新的链接(原文:I usually use a fairly small limit, since it's faster to make a new connection if the request is too big.)。
    • 对应的资料从io.Reader中读数据。LimitReader的学习有两个点:
      • 用LimitReader读Body的时候为什么能做到make new connection(应该是自动的),什么时候应该使用LimitReader(实验测试,内存和耗时等)
      • LimitReader的使用(与其他Read方法的结合,读完之后数据是会自动消失吗)
      • 可以进一步延伸,io.Read和io.Write方法是否会对数据本身造成影响。如何让其不造成影响。