PingCAP-Infra-Meetup-90-知乎已读服务架构演进

孙晓光老师在本期 Meetup 上提到,知乎已读服务的设计严格意义上来说同很多业务向系统的设计有不少差异,而这些差异反映在过程和结果上有些是正向的,也有些是负向的。但是很高兴的看到至少在上线一年多来,整体的收益是远高于所付出的代价的。
最后他希望在近期全量数据迁移到 TiDB 完成后能够进一步解决目前架构的一些尚存的痛点问题,让这个架构跑的更稳跑的更好。

展开查看详情

1.知乎已读服务架构演进 知乎搜索工程团队 孙晓光

2.大纲 ● 业务场景 ● 架构设计 ● 设计细节 ● 着眼未来

3.知乎: 综合性全民知识内容平台 2.2 亿 27 万 3000 万 1.3 亿 用户数 话题 问题 回答

4.业务场景 ① ② 用户 个性化首页 召回队列 1 ④ ② ① 获取新内容 ② ③ 召回队列 ··· ② 多队列召回用户感兴趣内容 ③ 过滤用户已读内容 ④ 渲染展示 已读过滤 召回队列 n 已读过滤示意图

5.业务特点 ● 历史数据长期保留 ● 写入量较大 ● 查询吞吐高 ● 响应时间高度敏感 ● 可以容忍 false positive

6.应对思路 ● 高可用 ● 可扩展 ● 去并发

7.应对思路 ● 高可用 ○ 自愈机制 ○ 状态可恢复 ○ 隔离变化

8.应对思路 ● 可扩展 ○ 尽量无状态 ○ 收拢强状态 ○ 善用弱状态

9.应对思路 ● 去并发 ○ 缓存 ○ 更聪明的缓存 ○ 更高命中率的缓存 ○ 更高效压缩的存储

10.已读服务架构

11.类比 Memory Hierarchy

12.已读服务架构

13.主要组件 ● Proxy: 客户端访问代理 ● Smart Cache: 扩展 Redis ● MySQL: 分库分表的 MySQL 集群 ● CDC: 数据变更抓取 ● Kafka: 变更事件队列 ● Spread: Kafka 消息 Fanout ● Master: 服务编排

14.Proxy 考量 ● Codis 增加可配置命令 ● Slot 间故障降级 ● Slot 内高可用 ● Slot 内会话粘滞

15.Cache 考量 ● 利用 Redis ● 使用 Golang 扩展 Redis ● 避免惊群 ● 原地更新 ● 业务优化的 Cache 数据结构 ● Cache 状态迁移 ● 在线离线隔离

16.一致性考量 ● 会话内 In Place 更新缓存 ● Peer 间通过变更消息最终一致

17.其它 ● TokuDB 引擎 ● 跨数据中心

18.架构问题 ● MySQL 运维负担 ● 缺乏数据分析能力

19.面向未来 ● TiKV 还是 TiDB ● TiDB 3.0 真香 ● TiFlash 真香

20.Thanks Everybody & My Team 郭春阳 逄振洲 张李阳 赵 龙 RBase Team

TiDB 是一款定位于在线事务处理/在线分析处理( HTAP: Hybrid Transactional/Analytical Processing)的融合型数据库产品,实现了一键水平伸缩,强一致性的多副本数据安全,分布式事务,实时 OLAP 等重要特性。
关注他