Xiayf的技术笔记

架构通用核心指标

  • 延迟(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原则:优化在刀刃上
  • 不要死磕:权衡、折中、局部妥协、另辟蹊径,有时更有效
  • 简单好用的基础机制,不用白不用,简单有效
  • 基础一定要先做(可以考虑公有云服务):指标量化、数据收集、监控统计、有目的地优化
  • 为业务负责,满足重要、紧急的需求,适当做技术预判