关于幂等的那些事

幂等讲的是一个操作无论是我们执行一次还是无数次,所产生的影响是一样的。

在我们应用系统中,有时因为系统超时等原因,需要调用方重试,如果这个时候没有设计好一个幂等方案,则会对系统带来副作用,比如多创建一比订单。

要做到幂等性的交易接口,首先需要一个唯一的标识,来标志交易是同一笔交易,而这个交易ID由谁来分配也是一件头疼的事,这个标识需要做到全局唯一。

如果由一个中心系统来分配,那么每一次交易都需要找那个中心系统,这样增加了程序的性能开销,如果由上游系统来生成,则可能导致ID重复的问题,因为上游系统可能会是一个集群,它们同时承担相同的工作。

另外全局ID生成,我们需要使用一个不会冲突的算法,比如使用UUID这样冲突非常小的算法,但是它的字符串占用空间比较大,索引效率很低,ID值不具备可读性,且没有递增,无法实现排序。

目前比较好的方案是使用Twitter的雪花算法。另外其他的像Redis,Zookeeper,MongoDB的ID的生成算法也是比较好的选择。

实现幂等设计的核心处理流程

对于幂等性的处理流程来说,就是要过滤一下已经收到的交易,要做到这个事,那我们先需要一个存储来记录收到的交易。因为我们的幂等服务是分布式的,所以需要这个存储也是共享的,通常可以使用关系型数据库,也可以使用key-value的NoSQL(如Redis)来构建这个存储。


image.png

上述流程节本实现了幂等,但是有个问题,因为绝大多数请求应该不是重发过来的,所以让所有的请求都到存储里查询交易,这会导致处理流程变慢。

所以,我们可以通过思考在sql中做优化,使其能实现幂等。比如是插入操作,则使用 insert into ... values .. on duplicate key update . 如果是更新操作,则使用 update tabel set money = money + 10 where id = xxx and version = v1.

你可能感兴趣的:(关于幂等的那些事)