Golang message streaming practice in Eleme

Transcript

1. Golang在饿了么移动推送 中的实践
2. ⼤纲 • ⽴项背景及现状 • 模型抽像 • 架构、部署 • 踩坑经历 • 最佳实践
3. Taco⽴项背景及⺫标 • 背景 • ⽼项⺫moses系统的缺陷 • 没有⾃有通道，当个推通道出现问题时，推送功能不可⽤ • 国内android⼤⼚禁⽌app链式启动，个推失去了相互唤醒的保活机制，推送触达下降 严重 • APNS通道在美国布署，推送质量⽆法保证 • 项⺫由Python编写，占⽤资源较多 • 需要⼀个性能更⾼、低延迟、⾃建⻓连接的推送系统 • 愿景 • 建⽴推送平台，统⼀公司的所有推送系统 • 功能： • 数据的上⾏(⽀持Android, iOS, H5) • 数据的下⾏(⽀持Android, iOS, H5) • 配置下发(⽀持Android, iOS)
4. 现状 • 已接⼊的业务⽅10+(物流各系统、蜂⻦、饿了么Now、有菜) • ⽇推送量：5亿+ • 在线连接数：160w(⾼峰) • 推送触达率：骑⼿类(90%+)，C端(55%) • 推送耗时(⻓连通道)：1.72~2.2秒
5. 客户端的展⽰模型 • 客户端状态 • Taco SDK不在线 • Taco SDK在线，⽤户App在后台 • Taco SDK在线，⽤户App在前台 • 可靠推送 VS ⽤户体验 • 在优先保证可靠推送的情况下，保证⽤户体验 • Taco SDK在线时，优化使⽤⾃建的⻓连通道 • Taco服务端推送多条消息时，由客户端做去重处理 • ⽤户App在前台时，不弹出系统通知
6. App状态 ⾏为 Taco SDK不在 线 由第三⽅通道SDK展⽰通知，⽤户点击后（App/Taco SDK激 活，转到前台），再将业务数据传到App。 Taco SDK在线， App在后台 Taco SDK弹出系统通知，⽤户点击通知拉起应⽤或主动切换到 前台时，将业务数据传到App Taco SDK在线， App在前台 将业务数据传到App 通知类型 App状态 ⾏为 Taco SDK不在 线 不展⽰系统通知。第三⽅通道SDK接收到数据后，若此时App 在线，将数据传给App，否则，丢弃。 Taco SDK在线， App在后台 不展⽰系统通知，Taco SDK将业务数据透传给App Taco SDK在线， App在前台 不展⽰系统通知，Taco SDK将业务数据透传给App 透传类型
7. 服务端推送流程
9. 布署图
10. 如何将客户端路由数据同步到多个机房？ • 现状 • ⽤户链接信息的存储在Redis，但Redis不⽀持多机房同 步 • 解决思路 a. 将路由信息存储在MySQL中，由db负责同步。 Redis只做cache提⾼查询速度。 b. 调研使⽤⼀个⽀持多数据中⼼复制的Cache系统， 如Acrospike, 携程开源的x-pipe c. 程序⾃⼰处理多数据中⼼的Redis的同步。 • 写多份、删多份 • ⽤⼀个proxy来处理多个数据中⼼的Redis读写操作，⽐如改造 Codis d. 根据⽤户的地理位置，对⽤户进⾏分区。对某个⽤户 的连接、推送、上⾏都转到其归属idc处理。
11. 期望的 Replicator 组件 Redis 集群 应用 Keeper DC1 伪Slave，实 现Redis复制 协议 Redis 集群 应用 Replicator DC2 持久化并推送变更到 多个机房 Keeper 复制变更 Replicator 复制变更 缓存复制组件的需求： • ⾼可靠，数据不丢 • 对应⽤的低耦合 • 秒级同步 处理的情况 • 相同key更新的冲突 处理 • 循环复制
12. Redis DRC 组件 Redis 集群 应用 Replicator Redis 集群 应用 Replicator DC1 DC2 Kafka Kafka 同步流程 • 各机房的Replicator订阅 别的机房的Kafka消息 • 应⽤写本机房Redis(另外 写⼀条记录操作的时间 戳)，写⼀条操作数据到 本机房Kafka • 异地机房的Replicator收 到Kafka消息后，与机房 的操作记录⽐对，如果 key相同且⽐它操作时间 早，则执⾏复制操作，否 则，丢弃。 复制变更 复制变更
13. • 我们的做法 • 实现了⼀个Redis DRC组件(利⽤MQ做跨机房同步) • 感想 • 对程序侵⼊性⽐较⼤，不合适 • 后续的改进 • 推动公司的缓存组件EKV⽀持跨机房同步 • ⾃研跨IDC复制的缓存组件 • 多活环境下，理想的存储组件 (Yahoo!Pnuts) • ⽀持多IDC复制 • 可指定某个key/记录的归属IDC • 读操作：只从本key归属的IDC查询 • 写操作：当写的key不是它归属的IDC时，写到IDC后， 需同步复制到其归属的IDC，再返回。当写的key是其 归属IDC时，就写IDC，返回，再异步复制到其它IDC • ⽀持key/记录的归属IDC变更
14. 多活 • 多活的⺫标 • 突破单机房的物理容量限制 • ⽤户就近接⼊，提升服务品质 • 异常切换: 机房发⽣灾难/容量受限时，切部分流量到另⼀个机房 • 多活不等于多写 • IDC流量切分(uid\loc\shopid) • 订单在同⼀个IDC中完成流转、避免IDC多写 • 避免了数据冲突的发⽣ • 每个机房保存全量(所有IDC)的数据(通过复制组件保证) • 限制 • 复制组件可能延迟或者中断，故业务逻辑不应该强依赖于复制
15. 多活 Sharding • 将全国的数据流量划分成30个shard单位，依据POI进⾏流量的Sharding • POI未知的情况随机/就近路由(例：未登录⽤户) • 路由数据由 ⾼可⽤组件GZS 存储、配置，全量数据/配置变更实时同步到接⼊层 • loc/shopid/… => shardid • shardid => ezone
16. • 客户端的多活路由如何做？ • ⽅案1： • 客户端选择连接不同地域的⺴关服务 • ⺴关选择就近的内⺴机房 • shard切换时，通知客户端。客户端断开连接，并连到新的服务器 • ⽅案2： • 通过DNS将各地域的客户端解析到相应的机房 • 根据shard key/value连接到相应的内⺴机房 • shard切换时，只修改⺴关到内⺴机房的路由 • 服务端MySQL的多活路由 • 特点：推送是由服务端发起的，没法知道客户端路由到哪个机房。 • ⽅案： • 每个消息有⼀个全局的MsgID，其中嵌⼊了Shard ID • 推送时，选择就近机房操作MySQL，并随机选择⼀个本机房的ShardID嵌⼊MsgID。 • ⺴关在收到ACK时，从MsgID中提取出ShardID，根据GZS查询到它对应的EZONE，然 后调⽤对应机房的服务。 • 多活切换 • 若某个内部机房挂掉 • 通知GZS修改指向: 将受影响的shard切到另⼀个内部机房 • 若某个云机房挂掉 • DNS切换: 将域名映射切到另⼀个云机房
17. 后端技术栈 • 语⾔: Golang • RPC框架: gRPC • 存储: MySQL/ElasticSearch/Redis/Hive/MaxQ • ⽇志收集: ELK • 链路跟踪: ETrace • 服务注册/更新/治理: Huskar • 埋点监控: Statsd/Influxdb/Grafana • 报警: watch dogger
18. 踩坑经历: ⺴关间歇性崩溃
19. • 崩溃原因/现象：close_wait状态的连接太多，内存占⽤过⼤，被 OS杀了 • 触发时机：断⺴演练时切DNS(全量到北京机房) • 处理过程 (1) 调整了⼏个参数(keepalive相关)，观察了⼀会，close_wait下降很快，内存下 来了。 (2) (第⼆天)观察到问题没有改善，现象仍旧存在 (3) 把DNS切回上海机房 (4) 回滚到前⼀个版本，没有解决 (5) 为了减少影响，在低峰期重启了所有⺴关进程 (6) 基本定位close_wait的原因是⼼跳定时管理器的bug导致(连接没有正常关闭)。 改了⼏版，快速上线。 (7) 观察发现ack曲线不正常(没有数据)，go routine数也⼀直在增⻓。怀疑是⺴关 ack/openack的逻辑有问题，验证了下，的确有问题。 (8) 梳理ack流程的代码，将有可能导致ack失败的代码修改(异步调⽤->同步调⽤)， 上线。 (9) 现象没有改善(ack曲线不正常)，⾼峰期来了，降级(⻓连接->第三⽅通道)，紧 急扩容了4台机器。 (10) 通过观察协程栈信息，发现有⼤量协程阻塞在gRPC内部函数中。给RPC调⽤加 上了超时时间，上线。
20. • Root Cause • ⼼跳定时管理器的实现存在Bug • gPRC调⽤时没有设置超时时间，对端不返回(由于某 些原因)，导致协程阻塞、内存暴涨
21. 阻塞在 func (t *http2Client) NewStream(ctx context.Context, callHdr *CallHdr) (_ *Stream, err error) { …… sq, err := wait(ctx, nil, nil, t.shutdownChan, t.streamsQuota.acquire()) …… gRPC基础知识 • 传输协议 HTTP2 • (默认)与对端服务只建⼀个TCP连接 • 连接的多路复⽤:每发起⼀个RPC调⽤，会创建⼀个stream，然后 ⼀个⼀个Frame发过去 配额streamsQuota(默认100) • gRPC client通过streamsQuota 限制同⼀时候并发创建stream的个数 (即限制了并⾏发起RPC调⽤的个数)。 原因 • RPC调⽤的处理耗时⾼，⾼峰期的并发请求多，导致并发创建stream 太多，所以在Newstream()时⼀直阻塞着。 解决⽅法 • RPC调⽤加上超时时间 • 优化后端的处理耗时
22. • 事故改进措施 • 重写⼼跳定时管理器模块，严格测试 • 提⾼系统的⾃我保护能⼒。对每个gRPC调⽤都设置超 时(默认5秒,可配置)，加上监控 • 制定⺴关异常的的处理措施，撰写SOP⽂档 • 应⽤机器加上报警(cpu,memory,disk,net in/out) • 感想 • 系统的核⼼模块要经过严格测试 • 发⽣故障时，测试必须在低峰期进⾏，减少对业务的影响 • 线上出现重⼤故障时，代码、架构都是次要的，主要看运维操作
23. 踩坑经历: MQ堆积，导致推送延迟
24. • 故障影响：消息推送延迟超过 30 分钟 • 触发时机：多活切换时把所有流量打到了上海机房 • 处理过程 (1) 开始定位问题，由于近期上线了⼀个Q消费限流的功 能，怀疑此变更导致的问题。再三确认后，实现逻辑 没有问题。 (2) 通知多活切换切回来 (3) 确认时光机发现⽆变更，怀疑是依赖存储的容量问题， 确认了下，没问题。 (4) 观察Q的消费曲线：堆积量⼀直在增加，但是消费速 度没涨。和Q的同事确认后，找到Root Cause。 (5) 堆积的消息慢慢消费完了，服务恢复。
25. • Root Cause • 核⼼Queue的消费者数只有2个(太少)，并发消费能⼒ 不⾜，触发Q的磁盘存储模式(为了换取更⼤消息堆积 量)，使消费者进⼊慢消费状态，加剧了消息的堆积 • 改进措施 • Q的使⽤姿势改造: 扩⼤关键Queue的连接数(动态可 配置) • 重要的业务⽅分Queue隔离，量⼩的共⽤⼀个Queue • 对消息分级(amqp优先级)处理 • 制定SOP • 改进⽅向 • 业务⽅对我们服务的调⽤量是不可预知的，根据当前的负载动态 调整处理能⼒(机器数,docker动态扩容)
26. 踩坑经历: ⺴关崩溃 • 特点：崩溃频率低, 难复现
27. 排查过程 (1) 根据goroutine stack上的信息，初步判断是多协程操作 同⼀个变量，导致slice跨界访问(slice out of bound) (2) 检查了⼏遍代码，没找到多协程race condition的迹象， 怀疑是sync.pool中重复利⽤bufio.Reader时，没有将 buf索引置0。修改完，上线。 (3) 现象仍在，尝试在测试环境复现，复现不出来。 (4) 在索引跨界访问的代码处，加log，上报埋点。了解在崩 溃前的细节(每个索引的值/由哪些函数变更了索引)。修改 完，上线。 (5) 在测试环境运⾏-race编译的⽂件，来记录崩溃时的细节， 但-race会导致内存/cpu使⽤增⼤数倍，导致机器内存耗 光僵死，⽆奈放弃。 (6) 源码啃了⼏遍，⺴上查询相关的pr，⽆果。 (7) 线上复现后，拿到log分析，发现经常有连续两次的跨界 访问导致的崩溃，怀疑使⽤sync.pool时存在race condition(⼀个协程归还对象到sync.pool，但另⼀个协 程还在使⽤此对象)。去掉sync.pool，修改上线。
28. • Root Cause 在serve websocket连接时，先从sync.pool中拿到 bufio.Reader，再启⼀个协程来处理这个连接。 readBufPool = &sync.Pool{ New: func() interface{} { return bufio.NewReaderSize(nil, BufSize) }, } func (s Server) serveWebSocket(w http.ResponseWriter, req *http.Request) { rwc, _, err := w.(http.Hijacker).Hijack() rb := readBufPool.Get().(*bufio.Reader) wb := writeBufPool.Get().(*bufio.Writer) rb.Reset(rwc) wb.Reset(rwc) buf := bufio.NewReadWriter(rb, wb) conn, err := newServerConn(rwc, buf, req, &s.Config, s.Handshake) …… conn = newHybiConn(&s.Config, buf, rwc, req) go func() { s.Handler(conn) rwc.Close() readBufPool.Put(rb) }() 在s.Handler函数中，先设置⼼跳定时器，登录，启⼀个 读协程，本协程进⾏写操作。 func (sess *session) Serve() { // 设置⼼跳超时定时器…... go sess.SignIn() // 登录 <-sess.signInDone if sess.id == 0 { goto done } if sess.s.opts.Debug || sess.debug { log.Infof(“sess: sign in success, %s”, sess) } sess.resetHB() sess.s.putSession(sess) go sess.loopRead() // 读协程 sess.loopWrite() // 写协程 done: sess.clean() } 注：读协程会⼀直使⽤传⼊的bufio.Reader。 虽然读协程和写协程使⽤了同步设施，保证有⼀⽅退出， 另⼀⽅也会退出，但不保证退出的时序。 如果本协程(写协程)先退出，会先将rb归还到sync.pool， ⽽读协程可能还在使⽤rb对象，就会产⽣Race Condition。
29. 感想 • 耐⼼ • 理解原理，追根究底 • 尝试画图，理清每个协程的⽣命期，理清操作时序
30. Context 接⼝原型: type Context interface { Deadline() (deadline time.Time, ok bool) Done() <-chan struct{} Err() error Value(key interface{}) interface{} } context package的public function: func WithCancel(parent Context) (ctx Context, cancel CancelFunc) func WithDeadline(parent Context, deadline time.Time) (Context, CancelFunc) func WithTimeout(parent Context, timeout time.Duration) (Context, CancelFunc) func WithValue(parent Context, key interface{}, val interface{}) Context
31. Context能做什么 • ⼿动、定时、超时发出取消信号 • 跨API传值(协程安全) • 控制⽣成Context树结构(Context链)
32. Context 原理-key/value存取 func doFunc(ctx context.Context, …) { …… newCtx := context.WithValue(ctx, key, value) doChildFunc(newCtx, …) ...... } • Context上下⽂数据是⼀个树结 构，每个结点只保存⼀个key- value对。 • 查询时，如果本结点查不到，则 递归向⽗结点查询，直到查询成 功或失败。
33. Context 原理-cancel • Context内部存储cancel信号的是cancelCtx，也是⼀个树结构，每个结 点会保存所有孩⼦结点的指针
34. Context 取消控制 Ctx1 Ctx2 Ctx3 Ctx5 Ctx6 Ctx7 Ctx4 Ctx8 Ctx9 当cancel掉某个结点cancelCtx，会cancel本结点和其⼦树的所有Context cancel
35. 某天，为了⽀持ETrace，需要在gRPC调⽤过 程中传递RequestID, RpcID，我们的解决⽅ 案是Context。修改后，遇到⼀系列的坑...... 补充背景 所有mysql、maxq、redis的操作接⼝前都会加上context，如果这个 context(或其⽗context)被cancel了，则操作会失败。 func (tx *Tx) QueryContext(ctx context.Context, query string, args ...interface{}) (*Rows, error) func(process func(context.Context, redis.Cmder) error) func(context.Context, redis.Cmder) error func (ch *Channel) Consume(ctx context.Context, handler Handler, queue string, dc <-chan amqp.Delivery) error func (ch *Channel) Publish(ctx context.Context, exchange, key string, mandatory, immediate bool, msg Publishing) (err error)
36. Case 1 • 现象 上线后，5分钟后所有⽤户登录失败，不断收到报警。 • 原因 内部有⼀个localCache，每5分钟Refresh(调⽤注册的回调函数)⼀ 次。 回调函数原型 func getAppIDAndAlias(ctx context.Context, appKey, appSecret string) (string, string, error) 第一次cache.Get(ctx, appKey, appSeret)传的ctx是gRPC call传进来的 context，而gRPC在请求结束或失败时会cancel掉context，导致之后 cache Refresh()时，执行失败。 • 解决⽅法 在Refresh时不使⽤缓存的context，使⽤⼀个不会cancel的 context
37. Case 2 • 现象 上线后，不断收到报警（sys err过多）。看log/etrace产⽣2种sys err： l context canceled l sql: Transaction has already been committed or rolled back • 原因 出现context canceled的场景: gRPC handler处理过程中连接被 断开。
38. 客户端 gRPC-gateway gRPC-client gRPC-server 3 2 1 4 • 客户端发送http restful请求 • gRPC-gateway与客户端建⽴连接，接收请求，转换参数，调⽤后⾯的grpc- server。 • gRPC-server处理请求。其中，gRPC-server会对每个请求启⼀个stream，由 这个stream创建context。 • 客户端连接断开 • gRPC-gateway收到连接断开的信号，导致context cancel。gRPC client 在发送rpc请求后由于外部异常使它的请求终⽌了(即它的context被cancel)， 会发⼀个RST_STREAM。 • gRPC server收到后，⻢上终⽌请求（即gRPC server的stream context被 cancel）。 连接断开 RST_STREAM
39. Root Cause • 出现sql: Transaction has already been committed or rolled back的原因： 在db.BeginTx时，会启⼀个协程awaitDone： func (tx *Tx) awaitDone() { // Wait for either the transaction to be committed or rolled // back, or for the associated context to be closed. <-tx.ctx.Done() // Discard and close the connection used to ensure the // transaction is closed and the resources are released. This // rollback does nothing if the transaction has already been // committed or rolled back. tx.rollback(true) } 在context被cancel时，会进⾏rollback()，⽽rollback时，会操作原⼦变量。 之后，在另⼀个协程中tx.Commit()时，会判断原⼦变量，如果变了，会抛出此错误。 • 解决⽅法 这2个error都是由连接断开导致的，是正常的。将这2个错误转成user error。
40. Case 3 • 现象 上线后，每两天左右有1~2次的mysql事务阻塞。
41. 处理过程 (1) 初步怀疑是跨机房的多个事务操作同⼀条记录导致的。 (2) 将某个接⼝降级，降低多个事务操作同⼀记录的概率。 (3) 减少事务的个数 • 将单条sql的事务去掉 • 通过业务逻辑的转移减少不必要的事务 (4) 调整MySQL Innodb参数: innodb_lock_wait_timeout(120s->50s) • 考虑调整单个事务的超时时间 (5) 使⽤Redis实现⼀个分布式锁：同⼀时间，只能有⼀个事务操作这条记录，操作完后 再放下⼀个事务。 (6) DAL同学报有事务没提交，查看代码，找到root cause
42. Root Cause 在开始事务BeginTxx() 会启⼀个协程： https://github.com/golang/go/blob/master/src/database/sql/sql.go# L1595 // awaitDone blocks until the context in Tx is canceled and rolls back // the transaction if it's not already done. func (tx *Tx) awaitDone() { // Wait for either the transaction to be committed or rolled // back, or for the associated context to be closed. <-tx.ctx.Done() // Discard and close the connection used to ensure the // transaction is closed and the resources are released. This // rollback does nothing if the transaction has already been // committed or rolled back. tx.rollback(true) } 在rollback(true)中，会先判断原⼦变量tx.done是否为1，如果1， 则返回；如果是0，则加1，并进⾏rollback操作。 在提交事务Commit()时，会先操作原⼦变量 tx.done，然后判断context是否被cancel了，如 果被cancel，则返回；如果没有，则进⾏commit 操作。 // Commit commits the transaction. func (tx *Tx) Commit() error { if !atomic.CompareAndSwapInt32(&tx.do ne, 0, 1) { return ErrTxDone } select { default: case <-tx.ctx.Done(): return tx.ctx.Err() } var err error withLock(tx.dc, func() { err = tx.txi.Commit() }) if err != driver.ErrBadConn { tx.closePrepared() } tx.close(err) return err } 如果先进⾏commit()过程中，先操作原⼦变量，然 后context cancel，之后 另⼀个协程在进⾏ rollback()会因为原⼦变量置为1⽽返回。导致 commit()没有执⾏，rollback()也没有执⾏。
43. • 处理⽅法 • 推荐做法: 给官⽅go/src/database/driver/sql提pr (已提pr，合⼊Go 1.9.2) • 不⽤transaction • 不⽤gRPC handler传进来的context，使⽤⼀个不会 取消的context • 让⼯具组修改源码后编译⼀个go的基础镜像，在CI构 建时指定使⽤这个镜像 • 事务阻塞的原因 • 某个事务执⾏的时候太⻓，阻塞了其他事务 • 某个事务没提交，也没回滚
44. Context 使⽤姿势 • 不要把Context存在⼀个结构体中，显式地传⼊函数。Context变量需要 作为第⼀个参数使⽤，⼀般命名为ctx • 即使⽅法允许，也不要传⼊⼀个nil的Context，如果你不确定你要⽤什么 Context的时候传⼀个context.TODO • 使⽤context的Value相关⽅法只应该⽤于在程序和接⼝中传递和请求相 关的元数据，不要⽤它来传递⼀些可选的参数 • Context是协程安全的: 同样的Context可以传递到不同的routine中 • 最重要 • 当下游routine依赖传⼊的context做取消控制时，要搞清楚传⼊ 的ctx何时会被Cancel。如果还没搞清楚，保险起⻅，使⽤⼀个 默认的context(Background,TODO)传⼊更好！
45. gRPC Context FAQ Q: WithValue()只能修改并⽣成⼀个新的⼦结点，但是我想让我做的值修改在多个routine(包括⽗结点)中可⻅，怎么做呢？ A:⺫前这个做不到。 Q: gRPC可以通过ctx传递跨进程 上下⽂数据吗？cancel信号？ A:可以传k-v对（通过incoming, outGoing metadata），但不能传cancel信号。 Q: gRPC 传到内部的ctx是外部传过来的ctx，还是stream⽣成的ctx？ A: gRPC server的context是由内部stream⽣成的，⽽gRPC client的内部context是 由外部(handler)的context传递进去的。 Q: gRPC client调⽤过程中context被cancel了，会导致gRPC server请求终⽌？ A: gRPC client在发送RPC请求后由于外部异常使它的请求终⽌了(即它的context被cancel)，它会发⼀个RST_STREAM，对⽅ gRPC server收到后，会⻢上终⽌请求(即导致gRPC server的stream context被cancel)。 gRPC serverstream.ctx被cancel的时机： 1）连接异常断开 2）数据格式读取不对 3）请求处理完（不管成功或失败） 4）收到⼀个RST_STREAM，即通知这个请求终⽌了。
46. 总结: 经验/最佳实践 • 理解系统中各个组件的原理、特点 • 在引⽤外部库时持谨慎的态度。若引⼊，原理要吃透 (啃源码,pr,issue) • 善⽤pprof • 异常处理 • 梳理系统中关键路径，Fatal Error加监控、报警，输出runtime stack • 在程序(主逻辑)⼊⼝处捕捉panic(提⾼系统健壮性)，加监控、报警，输出runtime stack • 对错误/异常进⾏分级(user/sys/unknown) • 善⽤defer • 并发 • 留⼼协程是否正常退出、资源是否正常释放(协程泄露) • 善⽤并发设施(errgroup,waitgroup,select,atomic,sync.once) • Go的多协程运⾏有调度的开销，要综合考量。性能关键处，还是⽤共享内存+同步 • 完善的监控、报警，各种粒度的限流、降级、熔断 • ⾃动化测试(单元测试、集成测试、压⼒测试) • 编码规范、提交规范、Code Review
47. Q&A