乐趣区

关于redis:Go-语言开发设计指北

jiezi

情谊提醒：此篇文章大概须要浏览 20 分钟 33 秒，不足之处请多指教，感激你的浏览。订阅本站
此文章首发于 Debug 客栈 |https://www.debuginn.cn

Go 语言是一种强类型、编译型的语言，在开发过程中，代码标准是尤为重要的，一个小小的失误可能会带来重大的事变，领有一个良好的 Go 语言开发习惯是尤为重要的，恪守开发标准便于保护、便于浏览了解和减少零碎的健壮性。

以下是咱们项目组开发标准加上本人开发遇到的问题及补充，心愿对你有所帮忙：
注：咱们将以下束缚分为三个等级，别离是：【强制】、【举荐】、【参考】。

Go 编码相干

【强制】代码格调标准遵循 go 官网规范：CodeReviewComments，请应用官网 golint lint 进行格调动态剖析；

【强制】代码格局标准按照 gofmt，请装置相干 IDE 插件，在保留代码或者编译时，主动将源码通过gofmt 做格式化解决，保障团队代码格局统一（比方空格，递进等）

【强制】业务解决代码中不能开 goroutine，此举会导致goroutine 数量不可控，容易引起零碎雪崩，如果须要启用 goroutine 做异步解决，请在初始化时启用固定数量 goroutine，通过channel 和业务解决代码交互，初始化 goroutine 的函数，原则上应该从 main 函数入口处明确的调用：

func crond() {defer func() {if err := recover(); err != nil {// dump stack & log}
    }()
    // do something
}
func main() {
    // init system
    go crond()
    go crond2()
    // handlers
 }

【强制】异步开启 goroutine 的中央（如各种 cronder)，须要在最顶层减少recover()，捕获panic，防止个别cronder 出错导致整体退出：

func globalCrond() {
   for _ := ticker.C {projectCrond()
      itemCrond()
      userCrond()}
}
func projectCrond() {defer func() {if err := recover(); err != nil {// 打日志，并预警}
   }
   // do 
}

【强制】当有并发读写 map 的操作，必须加上读写锁 RWMutex，否则go runtime 会因为并发读写报 panic，或者应用sync.Map 代替；

【强制】对于提供给内部应用的 package，返回函数里必须带上err 返回，并且保障在 err == nil 状况下，返回后果不为nil，比方：

resp, err := package1.GetUserInfo(xxxxx)
// 在 err == nil 状况下，resp 不能为 nil 或者空值

【强制】当操作有多个层级的构造体时，基于 防御性编程 的准则，须要对每个层级做空指针或者空数据判断，特地是在解决简单的页面构造时，如：

type Section struct {
     Item   *SectionItem
     Height int64
     Width  int64
 }
 type SectionItem struct {
     Tag    string
     Icon   string
     ImageURL string
     ImageList []string
     Action *SectionAction
 }
 type SectionAction struct {
     Type  string
     Path  string
     Extra string
 }

func getSectionActionPath(section *Section) (path string, img string, err error) {
   if section.Item == nil || section.Item.Action == nil { // 要做好足够进攻，防止因为空指针导致的 panic
      err = fmt.Errorf("section item is invalid")
      return
   }

   path = section.Item.Action.Path

   img = section.Item.ImageURL
   // 对取数组的内容，也肯定加上防御性判断
   if len(section.Item.ImageList) > 0 {img = section.Item.ImageList[0]
   }
   return
}

【举荐】生命期在函数内的资源对象，如果函数逻辑较为简单，倡议应用 defer 进行回收：

func MakeProject() {conn := pool.Get()
   defer pool.Put(conn)

   // 业务逻辑
   ...
   return
}

对于生命期在函数内的对象，定义在函数内，将应用栈空间，缩小 gc 压力：

func MakeProject() (project *Project){project := &Project{} // 应用堆空间
   var tempProject Project  // 应用栈空间

   return
}

【强制】不能在循环里加 defer，特地是defer 执行回收资源操作时。因为 defer 是函数完结时能力执行，并非循环完结时执行，某些状况下会导致资源（如连贯资源）被大量占用而程序异样：

// 反例：for {row, err := db.Query("SELECT ...")
   if err != nil {...}
   defer row.Close() // 这个操作会导致循环里积攒许多长期资源无奈开释
   ...
}

// 正确的解决，能够在循环完结时间接 close 资源，如果解决逻辑较简单，能够打包成函数：for {func () {row, err := db.Query("SELECT ...")
      if err != nil {...}
      defer row.Close()
      ...
   }()}

【举荐】对于可预感容量的 slice 或者 map，在make 初始化时，指定 cap 大小，能够大大降低内存损耗，如：

headList := make([]home.Sections, 0, len(srcHomeSection)/2) tailList := make([]home.Sections, 0, len(srcHomeSection)/2)
dstHomeSection = make([]*home.Sections, 0, len(srcHomeSection))
….
if appendToHead {headList = append(headList, info)
} else {tailList = append(tailList, info)
}
….
dstHomeSection = append(dstHomeSection, headList…)
dstHomeSection = append(dstHomeSection, tailList…)

【举荐】逻辑操作中波及到频繁拼接字符串的代码，请应用 bytes.Buffer 代替。应用 string 进行拼接会导致每次拼接都新增 string 对象，减少 GC 累赘：

// 正例：var buf bytes.Buffer
for _, name := range userList {buf.WriteString(name)
   buf.WriteString(",")
}
return buf.String()

// 反例：var result string
for _, name := range userList {result += name + ","}
return result

【强制】对于固定的正则表达式，能够 在全局变量初始化时实现预编译，能够无效放慢匹配速度，不须要在每次函数申请中预编译：

var wordReg = regexp.MustCompile("[w]+")
func matchWord(word string) bool {return wordReg.MatchString(word)
}

【举荐】JSON 解析时，遇到不确定是什么构造的字段，倡议应用 json.RawMessage 而不要用 interface，这样能够依据业务场景，做二次unmarshal 而且性能比 interface 快很多；

【强制】锁应用的粒度须要依据理论状况进行把控，如果变量只读，则无需加锁；读写，则应用读写锁sync.RWMutex；

【强制】应用随机数时 (math/rand)，必须要做随机初始化(rand.Seed)，否则产生出的随机数是可预期的，在某些场合下会带来平安问题。个别状况下，应用math/rand 能够满足业务需要，如果开发的是平安模块，倡议应用crypto/rand，安全性更好；

【举荐】对性能要求很高的服务，或者对程序响应工夫要求高的服务，应该防止开启大量 gouroutine；
阐明：官网尽管号称 goroutine 是便宜的，能够大量开启 goroutine，然而因为goroutine 的调度并没有实现优先级管制，使得一些关键性的goroutine（如网络 / 磁盘 IO，管制全局资源的goroutine）没有及时失去调度而拖慢了整体服务的响应工夫，因此在零碎设计时，如果对性能要求很高，应防止开启大量goroutine。

打点标准

【强制】打点应用. 来做分隔符，打点名称须要蕴含业务名，模块，函数，函数解决分支等，参考如下：

// 业务名. 服务名. 模块. 性能. 办法
service.gateway.module.action.func

【强制】打点应用场景是监控零碎的实时状态，不适宜存储任何业务数据；

【强制】在打点个数太多时，展现时速度会变慢。倡议单个服务打点的 key 不超过 10000 个，key中单个维度不同值不超过 1000 个（千万不要用 user_id 来打点)；

【举荐】如果展现的时候须要拿成千盈百个 key 的数据通过 Graphite 的聚合函数做聚合，最初失去一个或几个 key。这种状况下能够在打点的时候就把这个要聚合的点聚合好，这样展现的时候只有拿这几个 key，对展现速度是微小的晋升。

日志相干

【强制】日志信息需带上下文，其中 logid 必须带上，同一个申请打的日志都需带上 logid，这样能够依据logid 查找该次申请相干的信息；

【强制】对debug/notice/info 级别的日志输入，必须应用条件输入或者应用占位符形式，防止应用字符拼接形式：

log.Debug("get home page failed %s, id %d", err, id)

【强制】如果是解析 json 出错的日志，须要将报错 err 及原内容一并输入，以不便核查起因；

【举荐】对 debug/notice/info 级别的日志，在打印日志时，默认不显示调用地位（如 /path/to/code.go:335）
阐明：go获取调用栈信息是比拟耗时的操作(runtime.Caller)，对于性能要求很高的服务，特地是大量调用的中央，应尽量避免开发人员在应用该性能时，需知悉这个调用带来的代价。

Redis 相干

【举荐】对立应用 : 作为前缀后缀分隔符，这里能够依据 Redis中间件 key proxy 怎么解析剖析 Key 进行自定义，便于根底服务的数据可视化及问题排查；

【强制】防止应用 HMGET/HGETALL/HVALS/HKEYS/SMEMBERS 阻塞命令这类命令在 value 较大时，对 Redis 的 CPU/ 带宽耗费较高，容易导致响应过慢引发零碎雪崩；

【强制】不可把 Redis 当成存储，如有统计相干的需要，能够思考异步同步到数据库进行统计，Redis 应该回归缓存的实质；

【举荐】防止应用大 key，按教训超过 10k 的 value，能够压缩 (gzip/snappy 等算法)后存入内存，能够缩小内存应用，其次升高网络耗费，进步响应速度：

value, err := c.RedisCache.GetGzip(key)
….
c.RedisCache.SetExGzip(content, 60)

【举荐】Redis 的分布式锁，能够应用:

lock: redis.Do("SET", lockKey, randint, "EX", expire, "NX")
unlock: redis.GetAndDel(lockKey, randint) // redis 暂不反对，能够用 lua 脚本

【举荐】尽量避免在逻辑循环代码中调用 Redis，会产生流量放大效应，申请量较大时需采纳其余办法优化（比方动态配置文件）；

【举荐】key 尽量离散读写，通过 uid/imei/xid 等跟用户 / 申请相干的后缀摊派到不同分片，防止分片负载不平衡；

【参考】当缓存量大，申请量较高，可能超出 Redis 接受范畴时，可充分利用本地缓存 (localcache)+redis 缓存的组合计划来缓解压力，削减峰值：

应用这个办法须要具备这几个条件：

  • cache 内容与用户无关，key 状态不多，属于公共信息；
  • 该 cache 内容时效性较高，然而访问量较大，有峰值流量。
key := "demoid:3344"
value := localcacche.Get(key)
if value == "" {value = rediscache.Get(key)
   if value != "" {
      // 随机缓存 1~5s，各个机器间错开峰值，只有比 redis 缓存短即可
      localcache.SetEx(key, value, rand.Int63n(5)+1)
   }
}
if value == "" {
   ....
   // 从其余零碎或者数据库获取数据
   appoint.GetValue()

   // 同时设置到 redis 及 localcache 中
   rediscache.SetEx(key, content, 60)
   localcache.SetEx(key, content, rand.Int63n(5)+1)
}

【参考】对于申请量高，实时性也高的内容，如果纯正应用缓存，当缓存生效霎时，会导致大量申请穿透到后端服务，导致后端服务有雪崩危险：

如何兼顾扛峰值，爱护后端系统，同时也能放弃实时性呢？在这种场景下，能够采纳随机更新法更新数据，办法如下：

  1. 失常申请从缓存中读取，缓存生效则从后端服务获取；
  2. 在申请中依据随机概率 1%（或者依据理论业务场景设置比率）会跳过读取缓存操作，间接从后端服务获取数据，并更新缓存。

这种做法能保障最低时效性，并且当访问量越大，更新概率越高，使得内容实时性也越高。

如果联合上一条 localcache+rediscache 做一二级缓存，则能够达到扛峰值同时放弃实时性。

数据库相干

【强制】操作数据库 sql 必须应用 stmt 格局，应用占位符代替参数，禁止拼接 sql；

【强制】SQL 语句查问时，不得应用 SELECT （即形如 SELECT FROM tbl WHERE），必须明确的给出要查问的列名，防止表新增字段后报错；

【强制】对于线上业务 SQL，需保障命中索引，索引设计基于业务需要及字段区分度，个别可辨别状态不高的字段（如 status 等只有几个状态），不倡议加到索引中；

【强制】在成熟的语言中，有实体类，数据拜访层 (repository / dao) 和业务逻辑层 (service)；在咱们的标准中存储实体struct 搁置于 entities 包下；

【强制】对于联结索引，需将区分度较大的字段放后面，区分度小放前面，查找时能够缩小被检索数据量；

-- 字段区分度 item_id > project_id
alter table xxx add index idx_item_project (item_id, project_id)

【强制】所有数据库表必须有主键 id；

【强制】主键索引名为 pk 字段名; 惟一索引名为 uk 字段名; 一般索引名则为 idx_字段名；

【强制】避免因字段类型不同造成的隐式转换，导致索引生效，造成全表扫描问题；

【强制】业务上有惟一个性的字段，即便是多字段的组合，也必须建成惟一索引；

【强制】个别事务规范操作流程：

func TestTXExample(t *testing.T) {
   // 关上事务
   tx, err := db.Beginx()
   if err != nil {log.Fatal("%v", err)
      return
   }

   // defer 异样
   needRollback := true
   defer func() {if r := recover(); r != nil {  // 解决 recover，防止因为 panic，资源无奈开释
         log.Fatal("%v", r)
         needRollback = true
      }
      if needRollback {xlog.Cause("test.example.transaction.rollback").Fatal()
         tx.Rollback()}
   }()

   // 事务的逻辑
   err = InsertLog(tx, GenTestData(1)[0])
   if err != nil {log.Fatal("%v", err)
      return
   }

   // 提交事务
   err = tx.Commit()
   if err != nil {log.Fatal("%v", err)
      return
   }
   needRollback = false

   return
}

【强制】执行事务操作时，请确保 SELECT ... FOR UPDATE 条件命中索引，应用行锁，防止一个事务锁全表的状况;

【强制】禁止超过三个表的 join，须要join 的字段，数据类型必须统一，多表关联查问时，保障被关联的字段有索引;

【强制】数据库 max_open 连接数不可设置过高，会导致代理连接数打满导致不可用情况;

退出移动版