架构通用核心指标
- 延迟(Latency)√
- 吞吐(Throughput)√
- 成本(Cost)√
- 可用性(Availability)
- 其他(可扩展性、可维护性、可测性、可运维性...)
延迟
延迟 ~ 速度 ~ 响应时间
延迟的度量
- 均值(整体)√
- 分布
- 分布曲线
- 50分位值(中位值)
- 90分位值
- 99分位值(长尾)√
- 超时率(失败率)√
延迟常用的SLA
- 均值 < ? ms
- 90分位值 < ? ms
- 99 分位值 < ? ms
- 超时率 < ? % (超时时间 == ? ms)
如何做到低延迟?
Cache就是万金油,有它速度不用愁
并行:
- 多机
- 单机多CPU
- 单CPU多core
- (单core超线程)
2:8原则,优化热点
- 确定热点:日志(分阶段的耗时记录)、监控数据(系统+业务)、借助工具进行profiling
- 如果IO是热点:
- Disk换成SSD -> 更小的IO延迟,更强的IO能力
- Bloom filter -> 减少不必要的读
- 数据分片 + 分布式 + 更多内存 -> 减少/避免IO
- Cache(系统层或应用层) -> 减少重复IO
- 如果网络是热点:
- 打包访问
- 压缩(推荐lzo,snappy等高效算法)
- 减少跨机房网络
还有些更简单有效的
- 升级一下编译器(比如GCC)
- 开一下O3(指GCC的O3优化)
- 换一下技术(比如用HHVM替换PHP官方实现)
- 换一下硬件
- 关注一下系统配置
- 选择适合应用场景的系统
延迟=等待时间+处理时间 -> 少排队或不排队
- 除非资源到了瓶颈,否则不排队:
- 合适的并发模型
- 队伍要均衡
- 过长的队伍,及时柔性处理
- 需要权衡:吞吐、利用率、成本
总结
- 度量方法要精确且合理
- 常用优化方法:
- 单机层面:Cache、并行、热点优化、排队论、基础软件、硬件、技术选型...
- 分布式层面:抗波动、调度策略、优先级机制、柔性架构、在线转离线...
吞吐
吞吐 ~ 流量
定义:满足服务SLA要求的前提下,单位时间内整个系统的处理能力
优化吞吐
- 提高资源利用率:
- 任何资源都还没到瓶颈,但吞吐上不去:不合适的并发模型、过多锁、过大粒度的锁
- 吞吐的克星:等
- 优化瓶颈:CPU瓶颈、IO瓶颈、网络瓶颈
- 转移瓶颈问题:
- IO瓶颈:比如利用压缩 -> CPU换IO量
- CPU瓶颈:比如利用预计算+Cache -> 内存换CPU
- 网络瓶颈:比如利用数据压缩 -> CPU换带宽
- 合适的并发模型:
- 同步多线程不一定适合所有场景:吞吐=线程数/延迟
- 多个线程组(分阶段或分组)
- 局部异步化 VS 全异步化:需考虑代码可维护性
- 避免过多的overhead比例:尤其是细粒度任务
- 策略折中/有损优化/柔性策略
- 简单有效的手段:升级编译器、O3优化、结合硬件特性、开启超线程、合适的系统配置(网络、文件系统等)
成本
度量:
- 投入产出比
- 简单度量:机器数,或者云环境下的资源池需求等
- 可控(可预估、可扩展)
- 人力成本也是成本,避免过度复杂的系统,或者维护成本过高的系统设计
第一原则:为业务选择合适的技术和硬件
兼顾成本的延迟吞吐优化:
- 编译优化
- 热点优化
- 瓶颈优化
- 提高利用率
- Cache
- ...
一些最佳实践
- 设计阶段就得想好(想好 != 过度设计)
- 2:8原则:优化在刀刃上
- 不要死磕:权衡、折中、局部妥协、另辟蹊径,有时更有效
- 简单好用的基础机制,不用白不用,简单有效
- 基础一定要先做(可以考虑公有云服务):指标量化、数据收集、监控统计、有目的地优化
- 为业务负责,满足重要、紧急的需求,适当做技术预判