分布式系统测试浅谈

目录

分布式系统的目标

分布式系统的难点

分布式系统如何测试

数据一致性

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