分布式系统测试浅谈

目录

分布式系统的目标

分布式系统的难点

分布式系统如何测试

数据一致性

1)服务内一致

2)服务间一致

业务方面测试

故障模拟和恢复测试

任务调度,负载均衡策略

长时间稳定性测试

异常测试


分布式系统的目标

分布式系统具有软硬件平台分布性、高稳定性、高可用性、高可扩展性、高可管理性、高并发性及数据一致性等多种特性

分布式系统的难点

用户在京东上下了一个订单,发现自己在京东的账户里面有余额,然后使用余额支付,支付成功之后,订单状态修改为支付成功,然后通知仓库发货。假设订单系统,支付系统,仓库系统是三个独立的应用,是独立部署的,系统之间通过远程服务调用。

  订单的有三个状态:I:初始 P:已支付 W:已出库,订单金额100, 会员帐户余额200

  如果整个流程比较顺利,正常情况下,订单的状态会变为I->P->W,会员帐户余额100,订单出库。  

  但是如果流程不顺利了?考虑以下几种情况
1:(支付成功了,但支付回传失败/超时)订单系统调用支付系统支付订单,支付成功,但是返回给订单系统数据超时,订单还是I(初始状态),但是此时会员帐户余额100
方案一:假设调用支付系统支付订单的时候先不扣钱,订单状态更新完成之后,在通知支付系统你扣钱。

可能问题:在同一时刻,这个用户,又支付了另外一笔订单,订单价格200,顺利完成了整个订单支付流程,由于当前订单的状态已经变成了支付成功,但是实际用户已经没有钱支付了,这笔订单的状态就不一致了。

方案二:支付系统上对订单号进行控制,不允许重复支付。订单系统自动发起重试,多重试几次,例如三次,直到扣款成功为止

可能问题:假设应用上重试三次,如果三次都失败,先返回给用户提示支付结果异常。 此时有用户体验问题(当然这种情况比较可能是少数,可以牺牲这一部分的用户体验)
其他的异常情况
  2:订单系统调用支付系统成功,状态也已经更新成功,但是通知仓库发货失败,这个时候订单是P(已支付)状态,此时会员帐户余额是100,但是仓库不会发货。

  3:订单系统调用支付系统成功,状态也已经更新成功,然后通知仓库发货,仓库告诉订单系统,没有货了。这个时候数据状态和第二种情况一样。
参考:https://blog.csdn.net/babyshy/article/details/53495595

分布式系统如何测试

测试前准备:

测试的同学需要比开发更加理解产品的设计原则;

数据准备。如何准备海量的测试数据并保证模拟数据的真实性;

数据一致性

1)服务内一致

考虑一个简单的 key-value 系统,譬如 etcd,支持两个操作:Put(key, value) 和 Get(key)

  • 顺序规范下, put与get是一致的;
  • 线性一致性,多个client同时put,get, 无法确保 put和get是一致的

方案:

  • 测试时随机的,我们需要跑很多次从而确定一个系统的实现是正确的。
  • 多线程跑逻辑assert(expected_output == f(input))
  • 多线程跑数,记录整个操作的历史,然后去验证这个操作历史是否是线性一致的

参考:

http://www.sohu.com/a/191836176_268033

2)服务间一致

假设有一个主数据中心在北京M,然后有成都A,上海B两个地方数据中心,现在的问题是,假设成都上海各自的数据中心有记录变更,需要先同步到主数据中心,主数据中心更新完成之后,在把最新的数据分发到上海,成都的地方数据中心A,地方数据中心更新数据,保持和主数据中心一致性(数据库结构完全一致)

https://blog.csdn.net/leopard_education/article/details/40801085

业务方面测试

  • 功能测试
  • 重复提交后的幂等处理;

故障模拟和恢复测试

分布式系统的目标:任何局部的进程异常都不会影响系统的可用性。例如:测试时候要关注单节点的故障,是否能够快速侦探到,并且快速隔离故障节点。避免节点故障引发数据库或者队列的堵塞,引起大面积业务异常。

故障模拟操作比如机器宕机,重启,断网,主要模块进程重启,假死、部署中等,这些操作都会按照预先设定比例进行随机组合,并结合分布式系统的目标,进行测试。

具体实施上,可以根据分布式系统本身的故障应对目标而定。 例如,曾经测试过一个Akka的分布式服务,项目本身是迁移到了Akka上。 测试方案制定的时候,除了本身功能、性能、集成等通过后,特意对Akka的故障恢复能力做了测试:

1)目标一:一个组内的一台服务器挂掉,自动切换到该组的其他机器上。

2)目标二:一个组内的全部服务器挂掉,自动切换到另外的备用组。

参考:http://www.51testing.com/html/08/15184608-3725886.html

任务调度,负载均衡策略

思考方向:

每个节点处理的任务数不均匀,那就会导致拖尾现象,系统整体的处理性能不高;

在设计调度规则的时候,考虑默认处理节点,及“兜底”处理;

长时间稳定性测试

这里可以结合压力测试、故障模拟一起进行,评估各个主要模块的读写压力,还有一些诸如CPU,Memory,Network的资源消耗器,以模拟机器资源紧张场景。

异常测试

异常测试按性质分为应用层的业务逻辑异常测试、系统硬件/网络/文件/数据库/缓存/中间件异常测试。

业务逻辑异常测试体现在当上述的第二种异常发生时,是否能根据业务的需要或者架构的设计做出合理的业务处理反应,这是建立在第二种异常测试之上的,因此异常测试的关系也已经非常明确了:

  • 第一种测试根据业务的不同,范围和流程有不确定性
  • 第二种测试则是在一些明确的规则和约定下进行。

异常测试中最重要的一些场景:

  • 系统资源:cpu、内存使用率过高,能否能将请求切到到资源利用率低的服务器上;

  • 数据库中间件(mybatis,dabus):锁及慢SQL分析,

  • 缓存(redis):效率提升、雪崩、击穿等

  • 消息中间件(mafka):消息加压/过期/重试等处理;

  • 服务发现:服务不可用:是否有其他处理措施;单台不可用:是否能重新选举,重新建立连接;

  • ESSearch:存储及效率提升

  • 定时调度:数据量多少

https://www.cnblogs.com/TestingOn/p/7904986.html

相关推荐
©️2020 CSDN 皮肤主题: 技术工厂 设计师:CSDN官方博客 返回首页
实付 49.90元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、C币套餐、付费专栏及课程。

余额充值