数据密集型系统设计(1)

数据密集型系统设计

• 第一章--可靠、可扩展与可维护的应用系统

  • 应用类型

    • 计算密集型(compute-intensive)：CPU处理能力一般是第一限制因素

    • 数据密集型(data-intensive)：数据量、数据的复杂度以及数据的快速多变性为限制因素

    • 构成模块

      • 数据库：用以存储数据，可再次访问

      • 高效缓存：缓存复杂或操作代价昂贵的结果，加快下次访问

      • 索引：用户可以按关键字搜索数据并支持过滤

      • 流处理：持续发送消息至另一个进程，处理采用异步方式

      • 批处理：定期处理大量的累积数据

  • 可靠性：当出现意外情况如硬件、软件故障、人为失误等，系统应可以继续正常运转(虽然系统性能可能有所降低，但确保功能正确)

    • 硬件故障

      • 硬件冗余

      • 软件容错(多节点滚动升级)

    • 软件错误

      • 碰到特定条件触发、需要考虑很多细节、细心检查依赖，全面测试、监控等

    • 人为失误

      • 配置错误

      • 解决方法

        • 最小出错的方式来设计系统(需要平衡限制和使用需求)

        • 隔离最容易出错的地方、容易引发 故障的接口(沙箱环境)

        • 充分测试：从各单元测试到全系统集成测试以及手动测试

        • 出现失误时，提供快速恢复机制以尽量减少故障影响(回滚)

        • 设置详细而清晰的监控子系统，包括性能指标和错误率

        • 推行管理流程并加以培训

    • 重要性

      • 法律风险、声誉

      • 平衡可靠性与开发成本或者运营开销

  • 可扩展性：随着规模的增长，例如数据量、流量或复杂性(负载增加)，系统应以合理的方式来匹配这种增长

    • 描述负载

      • 负载可以用称为负载参数的若干数字来描述，参数的最佳选择取决于系统的体系结构(web服务器的每秒请求处理次数、数据库中写入的比例、聊天室同时活动用户数量、缓存命中率等)

      • Twitter例子(发送tweet消息、主页时间线浏览)

        • (联表查询)数据库关联查找出关注者发送的tweet消息

        • (扇出)为每个用户维护一个缓存(类似邮箱)，推送新tweet时，查询其关注者，将tweet插入到每个关注者的时间线缓存中

    • 描述性能

      • 延迟与响应时间

        • 百分位数

        • 中位数也称为50百分位数，缩写为p50

    • 应对负载增加的方法

      • 将响应百分位数添加到服务监控系统中，设置滑动时间窗口，持续跟踪指标

      • 采用一些近似算法来计算响应时间(正向衰减、t-digest、HdrHistogram)

      • 采用直方图

      • 垂直扩展(即升级到更强大的机器)和水平扩展(即将负载分不到多个更小的机器)之间做取舍

      • 自动检测，弹性伸缩计算资源

      • 有状态服务单节点(垂直扩展策略)，无状态服务多节点(水平扩展策略)

  • 可维护性：随着时间的推移，许多新的人员参与到系统开发和运维，以维护现有功能或适配新场景等

    • 可运维性：方便运营团队来保持系统平稳运行

      • 提供对系统运行时行为和内部的可观测性，方便监控

      • 支持自动化，与标准工具集成

      • 避免绑定特定机器，不间断运行同时，允许机器停机维护

      • 提供良好文档和易于理解的操作模式

      • 提供良好的默认配置，允许管理员方便修改

      • 尝试自我修复，需要时让管理员手动控制系统状态

      • 行为可预测，减少意外发生

    • 简单性：简化复杂度

      • 高度抽象

    • 可演化性：易于改变

      • 可以轻松的修改数据系统，使其适应不断变化的需求

      • 通俗易懂的系统往往比复杂的系统更容易修改

      • 数据系统的敏捷性，即可演化性

      • 前面twitter例子，从方法1过渡到方法2