DDIA（一）

数据密集应用
- 存储数据以便于再次使用——数据库
- 存储开销较大的计算结果以便于加大读取速度——缓存
- 通过关键字去索引和过滤——搜索引擎
- 发消息给其他进程，异步的处理——流式处理
- 周期的处理大量的积累的数据——批处理
数据密集主要的考虑点：
- 可靠性：reliable，在硬件或者软件甚至是认为错误的情况下仍然可以正确的工作。
- 可伸缩：scalable，处理增长，当业务规模增大的时候能够可靠的方式处理。
- 可维护：maintainable，既可以处理眼下的问题，又可以针对未来的应用场景做转换。
关于可靠性：
- 可靠性的基本要求：
  - 应用的每个功能点能够按预期执行。
  - 能够忍受人为错误或者不正确的运行方式。
  - 在预期的负载和数据量下，能够保证足够的性能。
  - 系统能够避免未授权的访问或者入侵
- 三大类问题：
  - 硬件问题：当系统规模较小的时候，硬件错误的概率很低，且是随机的不可预见的。但是当规模较大的时候，比如一万个节点，硬件错误可能每天都会出现。两种思路：第一种，添加备用硬件，比如磁盘raid或者备用电源等，另一种就是使用集群的方式来避免这个问题。对于小规模的系统第一种已经足够了，但是对于大规模的对可用性要求很高的场景来说，应该使用第二种方式。第二种方式我们需要解决的问题就是我们的应用能够允许部分失败。
  - 软件问题：软件问题和硬件的问题不同，硬件问题独立，随机。但是软件问题往往会有相关性。相对于硬件问题，软件问题往往更加难以预防并且有更大的破坏了。常见的软件问题：1）系统bug，会导致系统中每个实例都crash掉，如闰秒。2）某个进程耗尽了共享资源，如CPU，内存等。3）依赖的服务变慢，如数据库负载高，会导致应用响应变慢。4）瀑布式错误，一个问题引起另一个问题，再由这个问题引起更多的问题。对于软件问题，并没有药到病除的方案，可以加强一些细节把控。如：1）仔细的思考一些假定的场景以及系统之间的关系和耦合。2）测试。3）监控。4）系统内部的周期一致性检查，如dead Message邮件。
  - 人为错误：人是不可靠的，想摆脱人为错误主要在于以下方面：
    - 在设计系统时候，尽量减少犯错的机会，提供好的抽象，api，管理接口让使用者能够很容易做正确的事儿且避免错误。一些必要的校验就是好例子。
    - 环境隔离。
    - 全方位的测试。
    - 当发生认为错误的时候可以快速恢复，如数据库回滚。
    - 监控
    - 管理和培训。
关于可扩展
- 可扩展/可伸缩考虑的问题是当系统的负载变大的时候，我改怎么办的问题。我如何通过增加计算资源来处理额外的负载。
- 描述负载：负载可以用一些负载的参数来衡量，最优的参数取决于你的系统架构。比如对于web系统，它可以是qps、对于数据库可以是读写别理、对于聊天室可以是同时在线人数、对于缓存可以是缓存命中率等等。也许常规的场景是你需要考虑的，也许一些极端的的场景才是你的瓶颈。
- 描述性能：一旦你知道如何描述系统负载，这时候就需要找到一个指标来衡量系统的性能。可以从两个方面去思考：1）人工的增加负载之后，系统的性能将会受到怎样的影响。2）增加了负载之后，如果想维持性能不变，需要新增多少资源。描述性能指标依据系统而定，比如做批处理的Hadoop，指标可以是吞吐量。比如一个线上的系统，那响应时间可以作为性能指标。在人工测试性能的时候，一定要并发的请求，而不是一个请求结束之后才发起另一次请求，否则系统的负载会比你预期的要小一些。
- 处理负载的方式：无非是水平扩展和垂直扩展，垂直扩展比如你可以把内存从64G增加到128G，而水平扩展就是你加一台机器。对于share-nothing架构的服务是很容易水平扩展的。而对于数据库这种，当你水平扩展的时候会遇到很多很复杂的问题，比如数据balance，比如分布式事务一致性问题。这种通常会优先考虑垂直扩展到极限再进行水平扩展。如今的NewSql就是在解决数据库的水平扩展的问题。
关于维护性：
- 主要关心三个方面：
  - 可维护
  - 简单
  - 可进化
- 可维护：
  - 维护应用至少要负责以下这些东西：
    - 监控并且当系统出现问题时候在可控的时间内迅速恢复。
    - 系统问题和性能问题深追到底。
    - 保持最新版本
    - 清楚理解系统间交互，避免修改的时候引发问题。
    - 在问题发生之前就能预见问题并解决。
    - 使用合适的工具用于版本发布和配置变更，并建立一个最佳实践的流程。
    - 能够搞定艰巨的维护任务，比如平台迁移。
    - 在配置发生变化的同时保证安全性。
    - 维护工作制定相关的流程来保证线上系统稳定。
    - 能够保证对系统的充分理解即便发生人员变动。
  - 维护性好意味着对于常规的任务可以轻轻松松搞定，可以让团队人员focus在关键的问题上。数据系统需要至少做到以下几点：
    - 提供监控。
    - 提供良好的持续集成的工具。
    - 避免单点问题。
    - 良好的文档，易用的操作模型。
    - 提供高性能的参数默认值，并允许调整
    - 自我治愈能力，并允许管理员操作。
    - 表现出稳定的预期表现，不要Everyday big surprise
- 简单和进化
  - 一句话：完美的抽象。