⾼高可⽤用分布式流数据存储设计 李玥 京东集团 技术架构部 架构师 ⾃自我介绍 ⾃自我介绍 李李玥 京东集团 技术架构部 架构师 负责主导设计新⼀一代京东消息中间件系统，专注于流数据的⼀一致性分发和可靠存储、分布式实时计算和⾼高可⽤用分 布式系统架构等技术领域。 从事互联⽹网研发、架构10余年年，曾在浪潮集团、当当⽹网等公司从事架构相关⼯工作。2017年年加⼊入京东，期间提升京 如何定位？如何融入生态系统？ How 如何实现？如何优化？ WHY 为什什么需要流数据存储？ 单体应⽤用 烟筒式 SOA 微服务 那些年年的服务 MySQL ES HDFS KV HBase Hive 这些年年的数据 Services Data MySQL ES HDFS KV HBase Hive 统⼀一的流数据存储平台 我们的愿景 Services Streaming Storage 000 ns JournalQ有多快？ 32, 961, 776 TPS 测试服务器器：32C/256G/4TB SSD/万兆以太⽹网 测试每条消息⼤大⼩小为：1KB LZ4 压缩 单节点 存储结构设计 0 10 50 55 80 Journal 0 10 50 55 80 Index 0 134217342 268433156 402653853 0 536870912

构建强⼀一致性分布式数据库 TiDB 沈泰宁 R & D Engineer @ PingCAP ⾃自我介绍 ⾃自我介绍 • 沈泰宁 • R&D Engineer @ PingCAP • Maintainer • rust-prometheus • grpc-rs • … ⽬目录 • What is TiDB? • How to test? What is TiDB? Single

• Databus：数据库变更实时传输服务 • Venus：图片服务 11年毕业于天津大学 11 年到 14 年任职于百度，负责分布式文件系统和 KV 存储系统研发 有多年分布式存储研发经验 个人简介 • Cellar起源 • 中心节点架构演进 • 节点高可用和异地容灾 • 服务可用性提升 • Cellar规划 目录 • Cellar起源 • 中心节点架构演进 • 节点高可用和异地容灾 • Cellar日请求量达万亿级，美团点评最大NoSQL存储 Cellar起源 Cellar起源—Tair架构 路由表 Cellar起源—Tair架构 HASH Key 桶号 存储节点 固定HASH算 法 固定数目 数据分片 桶->存储节点 对照表 Cellar起源—Tair架构 服务层 请求 mdb 响应 ldb fdb rdb 引擎层 迁移 复制 • 中心化集群问题 • 可用性问题 Cellar起源 • 中心节点架构演进 • 节点高可用和异地容灾 • 服务可用性提升 • Cellar规划 目录 Cellar—中心节点架构演进 • 性能问题 客户端集中获取路由表 • 隔离性问题 中心节点暴露给客户端 单独的路由表获取模块 Cellar—中心节点架构演进 • 可扩展性： 路由查询能力 可线性扩展 • 隔离性： 客户端与中心节点 完全隔离 Cellar—中心节点架构演进

百度 搜索基础架构 从百度文件系统 看大型分布式系统设计 自我介绍 • 颜世光, 专注于大规模分布式系统 • 代表作品 - 百度第三代Spider系统 - 百度文件系统BFS - 万亿量级实时数据库Tera - 集群调度系统Galaxy • 个人主页&Blog - https://github.com/bluebore - http://bluebore.cn 提纲 • 百度文件系统简介 Stack 网络通信框架Sofa-pbrpc 分布式文件系统 BFS 集群调度系统 Galaxy 分布式协调服务 Nexus 分布式数据库 Tera 分布式计算框架 Shuttle Apps(Spider/Index/Search) 数据中心操作系统(DCOS) • 进程调度&内存管理 - Galaxy - 应用部署和任务调度 • 锁和信号量 - Nexus - 分布式锁 • 数据与计算的分片 • 分区故障容忍 • 数据一致性 • 系统扩展性 • 延迟与吞吐 • 成本与资源利用率 • … 数据与计算的分片 • 哈希分片 - 简单、均衡 - 扩容复杂、易用性差 - 一致性哈希、虚拟节点 • 按范围、数据量分 - 使用简单 - 需要管理元数据 - 中心化与去中心化 元数据管理 • 去中心化 - P2P技术 - 潜在的一致性问题 - 能管理的元数据有限

istio spring-gateway、linkerd、zuul 移动服务C 接入层 服务A 服务B 措施:合冗余[消除链路.裁剪节点] 冗余链路消除40多条 减少系统间交互80多次 裁剪冗余系统节点4个,消除接口200多个 减少对接成本，目的就是快 "� "� before� after before� after C 接入层/GW 服务A 分布式事务，补偿、撤销机制 接口缓存，热数据尽可能前置 DB跟随服务 代码、逻辑、结构等都要适时重构 最终架构[简版] 移动后台打散，界限趋于不明显 极大消除冗余，三级两层划分 底层服务有序汇总直面前端 流量统一出口 积分系统 优惠券 基金服务 保险服务 理财服务 支付中心 电子签章 第三方系统 营销支持 基础服务 数据支持 批处理 … 网关(略) 共享资源串行操作 数据一致性(脏读,丢失更新等) 业务纵向拆分，化整为零 资源拆分，横向扩展 cache，index，partition parallel non-blocking sync、lock，cas 额度、库存、积分、优惠券… CAP 数据竞争� [sql方案示例] 乐观锁，带来重试代价 悲观锁，开销大，吞吐量差 数据库锁(全局标识拦截)：

处理消息的服务节点可以随机选择 不必处理数据复制和同步的问题 系统容量和高可用能力可以同步提升 服务节点可以随意迁移，不必固定 IP 和存储 有状态分布式系统的高可用问题 一致性 可用性 分区容错性 Paxos Raft 2PC Gossip Ø 处理请求需要特定节点 Ø 必须要考虑数据备份和同步 的问题 Ø 容量扩展和高可用需要不同 解决方案 Ø 服务节点不能随便迁移 Networking Data 启动异常 进程被杀 服务器假死 断电 启动异常 超卖 进程死锁 负载均衡失效 业务线程池满 监控错误 流控不合理 心跳异常 缓存热点 缓存限流 数据库热点 数据库宕机 数据库延迟 CPU 抢占 内存抢占 内存错乱 上下文切换 磁盘满 磁盘坏 网络抖动 网卡慢 断网 DNS 故障 系统单点 异步阻塞 依赖超时 内存溢出 不可读写 目录 Ø 分布式系统面临的高可用问题 注意慢操作可能造成的客户端冲突问题 最佳实践分享 有关缓存的使用 Ø 缓存的内容：服务发现应答，DNS 结果，元数据， 数据，之前的请求 Ø 逻辑正确性不能依赖缓存，写操作服务端必须有校 验而且幂等，没有缓存情况下系统仍可服务 Ø 错误回复缓存，过期时间不能太长，而且有清晰的 修复建议 Ø 数据库更新与缓存失效的策略 最佳实践分享 有关配置文件 Ø 集群使用统一的配置来源 Ø 定义正常的默认配置，满足读取不到配置的正

交易系统架构设计-设计目标 • 吞吐量5w TPS, 延迟10ms • 能睡个好觉(数据持久化，数据最终一致性，容错) • 设计简单，运维方便 交易系统架构设计-关键点 • 内存撮合服务的状态持久化和高可用 • 消息处理顺序的保证 • 异步服务之间消息传送的可靠性 • K线：实时的分组聚合操作 • 高效利用关系数据库 交易系统架构设计-架构图 撮合 资金清算 行情推送 K线计算 历史成交 交易系统架构设计-关系数据库批量操作 insert into trades values (1, …) (2, …) … psycopg2.extras.execute_values( cur, ‘insert into trades values %s’, data ) stream = io.StringIO() # 往stream写csv格式的数据 cur.copy_from(stream copy_from(stream, ‘trades’) 交易系统架构设计-关系数据库批量操作 with tmp(id, amount) as ( values (1, …), (2, …), (3, …)) update orders set amount=tmp.amount from tmp where orders.id=tmp.id; delete

缺乏分布式运算和集中管理功能 无法做到高可用 TBSchedule Elatic-Job Java事实任务标准 关注点在定时任务而非数据， 缺少分布式并行调度的功能 阿里早期开源的分布式任务调度系 统，代码略陈旧 作业类型较单一，只能是获取/处理 数据一种模式 当当开源的分布式任务调度系统 代码较新，使用Quartz进行调度。提供 高可用和分布式功能 功能单一，只支持Java，不支持 CfgCenter 统一鉴权中心 AuthCenter 服务网关 Janus 安全管理平台 Salus 有女初张成 唯品会弹性调度系统的架构与功 能窥探 域 应用包 作业 执行节点 1 1 * 1 * * 创建 Binding 调度器 物理机 1 1 分片 1 * * 领域模型 Ready Running Stopping Stopped 启用 触发（手工 完美兼容现有PHP的作业，可无缝迁移，成本最低 • 提供多种业务开发模式，满足不同的业务需求 • 多种业务运行模式，即可分布式管理也可本地管理 • 通过异步消息实现业务编排* 多种作业类型 人工指定 运行节点 系统自动 平衡负载 资源利用 • 灵活的运维配置与部署 • 高效资源利用 • 简便的管理 人工指定 自动平衡 资源平衡调度算法 框架代码 与业务代 码隔离 集中化动 态增加与 删除作业

对架构设计的影响I -- 数据中心的设计 数据中心早期架构 数据中心碰到的问题 • 跨国网络引起的技术问题 • 来自法务的问题 • 来自安全部门的问题 数据中心最终方案 用户访问量对应的web架构 用户访问量 服务器架构 百万以下 单台或多台的简单架构,可以简单通过升级服务器 配置支持更多用户 百万到千万 增加Nginx(反向代理)或DNS负载均衡,redis内存 cache,数据库(Mysql)多台(数据在一个数据中心) 数据库(Mysql)多台(数据在一个数据中心) 千万到亿 增加Web服务器内存缓存,集群,IP负载均衡,基于内 容请求分发,Mysql优化(如减少写,2/8原则),数据在 一个数据中心 亿以上 增加异地部署(建议核心点集中,其它节点分散开),较 难分割或核心数据在同一数据中心,其它分散到不 同的节点 对架构设计的影响II -- 数据库表设计 数据库表早期设计 ID ... Type Name Size Create

业务模型 BUSINESS MODEL BUSINESS MODEL 业务模型 BUSINESS MODEL 服务/方案 基础产品 基础支撑 金融云服务 聚合支付 乐享理财 帮你贷 八方数据 … 资金管理 供应链 分期支付 扫码分销 … 基础支付1 SDK支付 扫码支付 分期支付 比特币 银行卡 开户 监控 报表 … 基础支付2 单笔代收 单笔代付 语音支付 余额查询 批量代付 快捷 … 账务 开户 记账 对账 账户托管 … 现金罗盘 代付工资 对外付款 企业理财 企业报销 资金划拨 供应链 … 其他 贷款 理财 供应链 征信 … 数据分析 … 运营后台 用户系统 商户后台 官网 企业网银 个人网银 解决方案 实时监控 业务属性 BUSINESS ATTRIBUTES 实时性、一致性 安全性、中间账户 聚合的复杂性、第三方依赖性 Oracle Nginx keepalived 数据库双机 网络分发层 业务处理 渠道适配器 交易预处理 交易预检查 交易风控 交易路由 通知 响应 查询 通道 交易拆分 业务2.0痛点 BUSINESS 2.0 PAIN POINTS 业务野蛮发展 交易量高速增加 并发请求增加 交易响应速度过慢 数据库单表 数据量剧增 模块耦合度高 开发效率低下 … 思考