高可用与一致性:构建强一致性分布式数据库 TiDB-沈泰宁构建强⼀一致性分布式数据库 TiDB 沈泰宁 R & D Engineer @ PingCAP ⾃自我介绍 ⾃自我介绍 • 沈泰宁 • R&D Engineer @ PingCAP • Maintainer • rust-prometheus • grpc-rs • … ⽬目录 • What is TiDB? • How to test? What is TiDB? Single0 码力 | 45 页 | 4.63 MB | 1 年前3
从百度文件系统看大型分布式系统设计中的定式与创新搜索基础架构 从百度文件系统 看大型分布式系统设计 自我介绍 • 颜世光, 专注于大规模分布式系统 • 代表作品 - 百度第三代Spider系统 - 百度文件系统BFS - 万亿量级实时数据库Tera - 集群调度系统Galaxy • 个人主页&Blog - https://github.com/bluebore - http://bluebore.cn 提纲 • 百度文件系统简介 分布式软件栈中的BFS The Baidu Stack 网络通信框架Sofa-pbrpc 分布式文件系统 BFS 集群调度系统 Galaxy 分布式协调服务 Nexus 分布式数据库 Tera 分布式计算框架 Shuttle Apps(Spider/Index/Search) 数据中心操作系统(DCOS) • 进程调度&内存管理 - Galaxy - 应用部署和任务调度 • 文件系统 - The Baidu File System - 持久化存储 百度文件系统架构 设计一个分布式系统要考虑的 • 数据与计算的分片 • 分区故障容忍 • 数据一致性 • 系统扩展性 • 延迟与吞吐 • 成本与资源利用率 • … 数据与计算的分片 • 哈希分片 - 简单、均衡 - 扩容复杂、易用性差 - 一致性哈希、虚拟节点 • 按范围、数据量分 - 使用简单 - 需要管理元数据0 码力 | 24 页 | 937.45 KB | 1 年前3
声明式自愈系统——高可用分布式系统的设计之道-王昕和存储 有状态分布式系统的高可用问题 一致性 可用性 分区容错性 Paxos Raft 2PC Gossip Ø 处理请求需要特定节点 Ø 必须要考虑数据备份和同步 的问题 Ø 容量扩展和高可用需要不同 解决方案 Ø 服务节点不能随便迁移 CAP Is Not Simply 2 out of 3 Ø 没有分区时,可用性和一致 性要兼得 Ø 经常要考虑的是可用性和一 致性各有一部分 Networking Data 启动异常 进程被杀 服务器假死 断电 启动异常 超卖 进程死锁 负载均衡失效 业务线程池满 监控错误 流控不合理 心跳异常 缓存热点 缓存限流 数据库热点 数据库宕机 数据库延迟 CPU 抢占 内存抢占 内存错乱 上下文切换 磁盘满 磁盘坏 网络抖动 网卡慢 断网 DNS 故障 系统单点 异步阻塞 依赖超时 内存溢出 不可读写 目录 Ø 分布式系统面临的高可用问题 有校 验而且幂等,没有缓存情况下系统仍可服务 Ø 错误回复缓存,过期时间不能太长,而且有清晰的 修复建议 Ø 数据库更新与缓存失效的策略 最佳实践分享 有关配置文件 Ø 集群使用统一的配置来源 Ø 定义正常的默认配置,满足读取不到配置的正 常运行 Ø 支持可扩展的配置命令格式 Ø 尽量支持更改配置不需要重启服务 Ø 注意配置项之间的关联性 欢迎与我交流 王昕个人微信 欢迎与我交流0 码力 | 44 页 | 2.47 MB | 1 年前3
领域驱动设计&中台/化繁为简--DDD驱动复杂业务软件架构的演进CONTENTS CONTENT 产品介绍 业务挑战及架构目标 架构演进 总结展望 业务挑战与架构目标 建筑造型多样化,业务模 型复杂度越来越高 业务挑战 新业务基于现有业务进行 扩展,而应用场景及性能 要求不同,既复用又独立; 产品云+端转型,核心业 务逐步实现服务化,不同 业务演化路径不同 简化业务模型复杂度 架构演进目标 不同业务间解耦 各业务独立演化 单体架构 几何算法 通用框架机制 通用算法 CAD/BIM UI 图元绘制 显示层 应用层 CAD识别 BIM模型转换 模型编辑 批量操作 CAD模型 BIM模型 模型数据库 gcad文件 gfc文件 数据库 算量模型持久化 CAD模型持久化 BIM模型持久化 …... 构件模型 …... …... …... …... …... …... 平法模型 钢筋模型 截面钢筋 保护层厚度 规格 端头 弯钩 规格 线筋 位置 参考线 参考点 位置 …... 截面钢筋模型总结 7种构件类型的布筋描述建模为同一种模型,增强了模型的表达能 力,提高了可扩展性 UI边界≠模型边界 通过提炼隐含业务规则完善模型 CONTENTS CONTENT 产品介绍 业务挑战及架构目标 架构演进 总结展望 DDD在研发中落地 统一语言 需求实例化0 码力 | 33 页 | 1.25 MB | 1 年前3
领域驱动设计&中台/可视化的遗留系统微服务改造退货单 ⼊入库单 投诉单 商品 ⽀支付订 单 订单 划分限界上下⽂文 事件⻛风暴暴 命令⻛风暴暴 寻找聚合 划分限界上下⽂文 什什么是限界上下⽂文? 如何探索限界上下⽂文? 业务的扩展会产⽣生越来越多的领域模 型,任何⼤大型项⽬目都会存在很多的领 域模型。当不不同领域模型对应的软件 代码被放在⼀一起后,软件就变得庞⼤大 且复杂,代码难于理理解、且容易易出现 bug,所以需要通过限界上下⽂文来明 明确服务包含的数据表 可视化的拆解遗留留系统 微服务架构、绞杀模式、代码依赖分析、数据库依赖分析、 遗留留系统拆解评分表、降⻰龙⼋八步 庖丁解⽜牛拆解的最⾼高境界 了了解⽜牛的⽣生理理构造 避开筋腱⻣骨节交错的组织 从⻣骨节的缝隙下⼿手 ⼗十九年年⼑刀依然锋利利 再看⼀一眼微服务架构 我们要做应⽤用代码拆分 我们要做数据库拆分 绞杀者模式 ‣“绞杀者模式”在既有系统资产的基础上实现数字IT 与Intellij或Eclipse相 结合,实时查看依赖, 指导拆解过程 已可视化 数据库依赖模式 模块A Data Mapper /ORM 相关联但不不属于 模块A的表 模块A Data Mapper /ORM 属于模块A的表 以模块(java包)为基本单位,从数据库依赖的⻆角度看,有两种模式: 属于模块A 的表 扫描数据库依赖 UserMapper.java UserMapper0 码力 | 54 页 | 3.85 MB | 1 年前3
QCon北京2018-业务高速发展下的互联网金融系统架构演变-张现双+丢失更新等) 业务纵向拆分,化整为零 资源拆分,横向扩展 cache,index,partition parallel non-blocking sync、lock,cas 额度、库存、积分、优惠券… CAP 数据竞争� [sql方案示例] 乐观锁,带来重试代价 悲观锁,开销大,吞吐量差 数据库锁(全局标识拦截): update zabbix,datagod, prometheus… apm工具,商业产品 期望更轻量、无侵入性的业务监控 cat,elk,zipkin等 趋于个性 具有共性 中间件/缓存/数据库/代理/MQ... OS/网络/存储/防火墙... 应用/框架/业务逻辑/系统间调用 自研日志监控[轻量无侵入] Kafka Kafka Spout 策略 Cache 系统配置 预处理bolts 分布式队列(报警系统) 合并降级 报警队列 活动监控 活动队列 报警策略 系统异常 基础策略 监控统计 业务节点 业务数据 业务数据统计 监控 数据流 系统统计 经典流式计算架构,流水线策略,线性扩展 高性能监控核心,灵活的监控策略 关键词模式、上下文模式、时间窗口模式等 轻量、高效、稳定,0侵入 日志监控平台 微信 微信/邮件/短信 高可靠,高响应 高性能 灵活配置0 码力 | 42 页 | 19.96 MB | 1 年前3
刘道平-从0到1,移动政务应用小程序系统架构演化1、政务云电子政务外网 :数据库、应用服务 2、政务云互联网区:静态资源、网关 3、互联网区:小程序、云服务 二、安全防护 1、仅开放指定端口 80 443 2、域名须有HTTPS证书 3、白名单 13、安全渗透测试、运维监控 -- 确保系统稳定 一、业务应用上线前必须经过安全渗透测试。 1、在测试环境中扫描出:越权查询、SQL注入、明文传输等,要求整改 2、正式环境检查: 操作系统、数据库、中间件漏洞,建议打补丁 小程序 端 APP端 运营数 据分析 一体机 端 1.项目建设,考虑的维度有:需求-产品-前后端开发-测试-上线… 2.产品研发,需考虑的维度:产品可扩展,如多端支持(小程序端、APP端、一体机端); 功能可扩展,如支持个人中心、证照、办事、资讯、特色专区等;可移植、易安装等; 及衍生的支撑工具系统,如运营数据分析; 产品视角 目录 一、移动政务应用服务现状与痛点 二、一个特殊的移动政务应用项目0 码力 | 35 页 | 15.60 MB | 1 年前3
微服务和Service Mesh 在多个行业落地实践设计要点四:服务拆分与服务发现 www.163yun.com 设计要点亓:数据库横向扩展 www.163yun.com 设计要点六:缓存的设计 APP缓存 CDN 接入层 静态资源 动态资源静态化 应用本地缓存 分布式缓存 数据库为中心 缓存为中心 www.163yun.com 设计要点七:消息队列与异步化 服务 告警 认证 鉴权 统计 概览 知识 库 APM (应用运行期监控) 运行时 拓扑 性能 监控 服务 筛选 调用 链 调用 栈 JVM 监控 数据库 监控 性能 告警 自定义 数据 服务 告警 监控 大屏 账户 审计 CICD (开发流程管理) 代 码 检 出 代 码 编 译 镜 像 构 建 集 成 测 试 A用户永远只访问A服务v1 VIP用户访问A服务V2,非VIP用户访问A服务V1 参数分流 微服务框架负责服务之间的调用——负载均衡与参数分流 www.163yun.com 分布式数据库 www.163yun.com 某大型银行 www.163yun.com • 两阶段提交XA——中间件DDB • TCC——中间件 Dubbo + DTS • Try 预留 +0 码力 | 39 页 | 3.06 MB | 1 年前3
《58到家技术架构快速规划与落地》 - 沈剑• 分发类实现Tips (1)易扩展的配置 (2)远端接口探测,命令执行 (3)可以无需agent • 汇总类实现Tips (1)agent快速部署 (2)agent从中央获取配置 (3)快速的本地检测 58集团技术专场 2. 监控平台-日志 ERROR日志监控Tips (1)路径规范 (2)日志分级 (3)日志切分 (4)易扩展的配置 日志关键字监控Tips (1)异常关键字 (1)异常关键字 (2)正常关键字 (3)易扩展的配置 58集团技术专场 2. 监控平台-接口 Keepalive统一监控 (1)框架统一实现 (2)中心统一调度 处理时间统一监控 (1)框架统一实现 (2)本地初步汇总 (3)日志收集/udp上报 http接口统一监控 (1)http状态码?内容? (2)易扩展的配置 58集团技术专场 2. 监控平台-接口 • 哪种监控最精准? 58集团技术专场 3. 调用链跟踪-效果 58集团技术专场 3. 调用链跟踪-效果 58集团技术专场 4. 守望者平台 � 服务信息量化管理 (1)上游 (2)下游 (3)缓存 (4)数据库 (5)操作系统 (6)… 58集团技术专场 4. 守望者平台-上游 58集团技术专场 4. 守望者平台-下游 58集团技术专场 4. 守望者平台-DB/Cache 58集团技术专场0 码力 | 42 页 | 1.52 MB | 1 年前3
分布式 KV 存储系统 Cellar 演进之路分布式KV存储Cellar演进之路 美团点评·基础架构 齐泽斌 美团点评基础架构部,存储研发团队负责人 • Cellar:分布式KV存储服务 • Databus:数据库变更实时传输服务 • Venus:图片服务 11年毕业于天津大学 11 年到 14 年任职于百度,负责分布式文件系统和 KV 存储系统研发 有多年分布式存储研发经验 个人简介 • Cellar起源 • 中心节点架构演进 • Cellar—中心节点架构演进 • 性能问题 客户端集中获取路由表 • 隔离性问题 中心节点暴露给客户端 单独的路由表获取模块 Cellar—中心节点架构演进 • 可扩展性: 路由查询能力 可线性扩展 • 隔离性: 客户端与中心节点 完全隔离 Cellar—中心节点架构演进 一致性 • 主备脑裂 • observer与config • Zookeeper选主 • 元数据Zookeeper存储 网络延迟大 专线稳定性差 • 异地容灾需求 跨集群数据同步 Cellar—异地容灾 集群节点同步 消息队列同步 复制延迟 低 高 系统复杂度 低 高 运维成本 低 高 实现难度 高 低 扩展性 低 高 • 低延迟 • 低复杂度(运维成本) Cellar—异地容灾 • Cellar起源 • 中心节点架构演进 • 节点高可用和异地容灾 • 服务可用性提升 • Cellar规划 目录0 码力 | 34 页 | 1.66 MB | 1 年前3
共 24 条
- 1
- 2
- 3













