1、万亿级消息背后：小米在消息队列的实践目录 业务背景 架构与关键问题 性能与资源优化 平台化效率业务背景存储计算强耦合：数据不均衡运维痛苦：扩容、容错代价大消费 Rebalance 抖动大Kafka 的痛点小米的业务需求无状态、无感知的快速扩容高弹性的容错机制稳定、快速收敛的消费模型企业级特性：多租户、Replication业务背景Talos：小米自研的分布式消息队列对内满足小米各部门的业务需求，对外为生态链公司提供中间件能力服务化对标 AWS Kinesis、Apache Kafka业务背景-生态角色在线消息队列+数据集成总线目录 业务背景 架构与关键问题 性能与资源优化 平台化效率架构与关键
2、问题基于 HDFS一致性哈希，Partition 在计算层的负载均衡Talos 架构架构与关键问题存储计算分离架构与关键问题DFS Client Tailing ReadHDFS 正在写入的Block 数据不可见保障 Partition 实例唯一性RecoverLease 与 分布式锁滚动升级分片延迟分配减少通信开销 与 消费平滑目录 业务背景 架构与关键问题 性能与资源优化 平台化效率性能与资源优化业务规模爆发增长性能与资源优化线程模型改造写模型优化上下文,GC 调优客户端寻址基于流量均衡的个性化一致性哈希演进之路性能优化性能优化性能优化带宽资源带宽资源性能与资源优化-线程模型T1_P1：R
3、equest of Topic1-Partition1问题？方案？优势？性能与资源优化-线程模型线程模型实践总结读写转发模型不同机器间互相影响不同操作（读/写）间互相影响Talos-Server-1Talos-Server-2Talos-Server-3原则：避免竞争不同的处理对象不同线程不同操作使用不同线程一个流程分解多个步骤，耗时步骤分解到单独的线程性能与资源优化 写优化为了保证不丢：每次写请求会做一次 HDFS FlushP1：User 3 Write，Talos 3 Flush问题？流量突增高 QPS场景性能与资源优化 写优化P1：User 3 Write，Talos 1 Flush1
4、K-1W单机吞吐P99 延迟70ms-5ms性能与资源优化 上下文与GC高并发下、线程数设置不合理竞争锁服务性能指标，防患未然上下文切换GC 调优CMS-G1工具：HotSpot 开发的 gc_log_visualizer方法：1）确定常驻内存，设置 IHOP2）控制变量，调整 Young GC 耗时、触发 MixedGC 时间间隔，以及 Mixed GC 周期内执行 mixedgc 的次数和单次耗时性能与资源优化 上下文与GC平均 GC 耗时 70ms大部分 GC 耗时远高于 100ms客户端寻址带有反馈机制的 Lazy 路由基于流量的个性化一致性哈希流量 I/O 的负载均衡，基于后验带宽值
5、的托管式自动调节性能与资源优化 带宽资源优化40%带宽资源节省 40%50%P95 延迟优化 50%50%机器间日均流量差值优化 50%性能与资源优化-个性化一致性哈希性能与资源优化-个性化一致性哈希目录 业务背景 架构与关键问题 性能与资源优化 平台化效率平台化效率-监控与运营统一、通用的指标运营平台服务于各模块的监控、运营、和计量等平台化效率-资源管理资源管理自动化、资源申请自助化98%节省客服支持压力 98%模拟阈值以下的真实需求模拟阈值以上的夸大需求模拟阈值以上的真实需求70%Partition 是一种资源（用户意识）根据业务真实的增长需求拟合一个增长曲线的阈值大部分工作是可以自动化，只有很少比例的资源申请需要人工干预28%未来规划 事务消息在金融业务的落地 企业级特性 Replication 在云服务场景的落地 读写分离 统一消费模型
sgpjbg002
工作日 8:30 - 17:30
报告分类
