什么样的系统是数据密集型系统?
对于数据密集型系统而言,CPU的处理能力不是第一限制因素,关键是数据量,数据的复杂度和数据的快速多变性.一般包括如下模块:
- 数据库:持久化保存数据.
- 高速缓存:缓存复杂的或者计算代价高昂的数据
- 索引:支持数据筛选,过滤等
- 流式处理:持续发送消息给其他进程,异步处理.
- 批处理:定时处理大量数据的任务.
数据密集型系统的目标
可靠性
可以容忍一定的错误,保持服务可以正常运行.
可以容忍的错误一般包括:
- 硬件故障
可以通过硬件冗余配置的方式来降低系统的故障率.
近期云计算的发展,我们也可以通过软件容错的方式来降低系统故障率. - 软件错误
一般任务硬件故障是相互独立的,但是软件错误往往是相互关联的.例如:
- 由于软件错误,当输入某些特定值时导致服务崩溃
- 应用服务使用的共享资源失控.
- 依赖的服务,突然延迟增加或者不可用.
- 级联故障,由于一个组件的故障导致故障传递引发更大的故障.
我们设计的软件一般会对运行的环境进行一些假设,但是一旦环境发生变化导致这些假设不是都成立就会导致问题.
- 人为失误
人为的操作失误和配置失误.如果假设人的操作是不可靠的,我们可以采用下面的方式维持系统的可靠性:
- 以最小出错的方式设计系统.降低使用成本.
- 分离最容易出错的地方,容易引发错误的接口.
- 充分的测试.
- 当出现人为失误的时候支持快速恢复.
- 设置详细的监控和告警.
- 加强流程.
可扩展性
可扩展性描述的是如果负载增加的话,我们的服务能否正常的运行.我们在考虑可扩展性的时候一般需要思考:如果系统以某种方式增长,我们应对措施有哪些.我们应该如何添加资源以处理增加的负载.
描述负载
负载可以用若干负载参数描述.参数选择一般可能有:每秒请求处理次数、数据库中写入的比例、聊天室同时活动的用户数量、缓存命中率等.
我们既要关心平均值,同时也要关心峰值带来的影响.描述性能
在负载增加的情况下我们一般需要思考两个问题:
- 负载增加,在系统资源不变的情况下,服务的性能会有什么变化.
- 负载增加,如果要保持性能不变,我们需要增加哪些资源,增加多少.
为了解决性能的描述,我们需要一种量化的指标.
例如针对请求响应时间,我们可以根据请求的处理时间不同,生成一个数值分布图.
一般描述性能时我们采用百分位数这个指标.例如中位数就是一个这样的数:他表示有一半的请求处理时间低于这个数值,有一半的请求处理时间高于这个值.同样的我们可以使用p99来表示有99%的请求处理时间低于这个值,有1%的请求处理时间高于这个值.
对于这个量化的指标,排队延迟有着很大的影响,越高的百分位数(p50,p99)影响越大.对于一些处理很慢的请求,如果他后面有很多简单的请求也会导致后面的请求被阻塞,直到他们消耗完.
对于一个请求需要并行的请求很多个其他服务才能处理完成的场景中,耗时最长的那个子请求将拖累整个系统,这种现象被称为:长尾效应.
- 应对策略
针对负载的增加,我们一般采用垂直和水平扩展两种方案.
一般对无状态的服务进行水平扩展,因为比较简单.
对有状态的例如数据存储,一般先采用垂直扩展的方式,直到不能满足需求在进行水平扩展.
后续将详细讨论如何进行通用模块的可扩展架构.
可维护性
可维护性主要关注三个方面:
- 可运维:方便运营人员保持系统平稳运行.
- 简单性:简化系统的复杂性.通过抽象等方式来实现.
- 可演化: 后续工程师可以轻松的对系统进行改造.
- 简单性:简化复杂度
复杂性的表现形式多种多样:状态空间膨胀,模块耦合度高、相互依赖关系,不一致的命名和术语、为了性能采用的特殊处理、为了特定问题引入的特殊框架等.
总结下来就是:复杂性来源于实现.
所以后续将讨论如何做好抽象.
