数据脱敏和接口幂等性

最新推荐文章于 2024-08-20 16:05:17 发布

LeZhi_126

最新推荐文章于 2024-08-20 16:05:17 发布

阅读量1.2k

点赞数 2

分类专栏： 201808

201808 专栏收录该内容

2 篇文章 0 订阅

订阅专栏

【转载出处——胡玉洋《数据脱敏——什么是数据脱敏》】

一、什么是数据脱敏？

　　数据脱敏(Data Masking),又称数据漂白、数据去隐私化或数据变形。
　　
　　百度百科对数据脱敏的定义为：指对某些敏感信息通过脱敏规则进行数据的变形，实现敏感隐私数据的可靠保护。在涉及客户安全数据或者一些商业性敏感数据的情况下，在不违反系统规则条件下，对真实数据进行改造并提供测试使用，如身份证号、手机号、卡号、客户号等个人信息都需要进行数据脱敏。
　　
　　生活中不乏数据脱敏的例子，比如我们最常见的火车票、电商收货人地址都会对敏感信息做处理，甚至女同志较熟悉的美颜、有些视频中的马赛克都属于脱敏。
　　
这里写图片描述

二、为什么要进行数据脱敏？

　　上面说到，在“涉及客户安全数据或者一些商业性敏感数据的情况下”对数据进行改造，说明我们要进行改造的数据是涉及到用户或者企业数据的安全，进行数据脱敏其实就是对这些数据进行加密，防止泄露。
　　

　　对于脱敏的程度，一般来说只要处理到无法推断原有的信息，不会造成信息泄露即可，如果修改过多，容易导致丢失数据原有特性。因此，在实际操作中，需要根据实际场景来选择适当的脱敏规则。改姓名，身份证号，地址，手机号，电话号码等几个客户相关字段。

三、如何实现数据脱敏

　　按照脱敏规则，可以分为可恢复性脱敏和不可恢复性脱敏。可恢复性脱敏就是数据经过脱敏规则的转化后，还再次可以经过某些处理还原出原来的数据，相反，数据经过不可恢复性脱敏之后，将无法还原到原来的样子，可以把二者分别看做可逆加密和不可逆加密。

　　我们目前遇到的场景是日志脱敏，即在把日志中的密码，甚至姓名、身份证号等信息都进行脱敏处理。
　　
　　脱敏前：
　　
这里写图片描述

　　脱敏后：
　　
这里写图片描述

　　如上图，仔细分析会发现，打日志之前，获得脱敏的数据就两个步骤：【拿到要输入的数据(user实体)】→【进行序列化】，所以要进行数据脱敏可以考虑在这两个步骤上进行实现。第一个方法就是在序列化实体之前先把需要脱敏的字段进行处理，之后正常序列化；第二个方法就是在实体序列化的时候，对要脱敏的字段进行处理。

　　后面来分享一下具体实现数据脱敏的方法。

二接口幂等性

对于一次订单支付过程，如果用户重复多次点击支付按钮，或者是网络异常导致订单已经支付成功了但没有及时反馈给用户，用户再次点击支付按钮，就可能造成重复扣款，造成严重后果。
考虑到幂等性的原理，可以给订单生成一个guid，客户端请求服务端时携带guid参数，服务端就可以验证此次请求是不是同一个订单，再判断订单是否已经支付完成。
1、生成订单时，生成guid；
2、支付时请求参数携带guid。

为了减少服务端压力，对于短时间多次重复请求，做接口过滤

1、什么是幂等性

抄用一段数学上的定义：f(f(x)) = f(x)。x被函数f作用一次和作用无限次的结果是一样的。幂等性应用在软件系统中，我把它简单定义为：某个函数或者某个接口使用相同参数调用一次或者无限次，其造成的后果是一样的，在实际应用中一般针对于接口进行幂等性设计。举个栗子，在系统中，调用方A调用系统B的接口进行用户的扣费操作时，由于网络不稳定，A重试了N次该请求，那么不管B是否接收到多少次请求，都应该保证只会扣除该用户一次费用。

2、幂等性设计

幂等性一般应用于协议设计，TCP协议支持幂等吗?答案是肯定的，在网络不稳定时，操作系统可以肆无忌惮的重发TCP报文片段。TCP协议能够保证幂等的核心在于sequence number字段，一个序列号的在较长的一段时间内均不会出现重复。对于应用层的协议设计，原理和TCP是类似的，我们需要一个不重复的序列号。再简单一点说，在一个业务流程的处理中，我们需要一个不重复的业务流水号，以保证幂等性。

举个实际应用场景：用户A在网页上发起一笔游戏充值请求，浏览器引导用户去银行支付，支付成功后系统给用户进行充值。

协议设计上，我们通过全局唯一的充值订单号贯穿整个业务流程，使该业务支持幂等。

应用实现上，我们列举在银行支付成功后回调系统，进行充值的步骤进行说明。

func pay_notify(orderid,value,state){//有问题的实现

order = db.query("select * from payorder where orderid=$orderid");
check(order,orderid,value,state);//判断支付金额是否与订单金额一致，判断是否是支付成功回调。
if(order.state=='未支付'）{
db.update("update payorder set state='已支付' where orderid=$orderid");
charge(order.username,value);//执行充值
}else{
return result("订单已处理")//返回订单已处理，或者返回处理成功
}
}

上述实现的问题在于，当回调出现并发时，order.state已经是脏读了，有可能重复充值，该实现并不能100%保证幂等。

列举三种改进方式：

1、悲观锁，select for update，整个执行过程中锁定该订单对应的记录。

2、乐观锁，affectrows = db.update("update payorder set state='已支付' where orderid=$orderid and state='未支付' ")，如果affectrows=1，执行充值，否则返回已处理。

3、定义notifylog表，orderid为unique key或者primary key，执行前，先insert，若insert成功则执行充值，否则返回已处理。

以上简单例子用以说明幂等性常用应用实现，在SOA化系统中，可能很多原子功能都被拆分到不同的进程里，如charge充值这个函数，可能在另一个进程中，那么整个业务的链路就会更长，可能回调成功了，但是充值失败。同理，只要充值接口保证幂等性，对于已经回调过但是充值结果未返回的请求，回调接收程序，应当重复发起充值请求。更深入更复杂的应用场景，在数据一致性中再细讲。