分布式系统后台如何防止重复提交

标签: 分布 系统 后台 | 发表时间:2018-07-18 00:28 | 作者:
出处:http://www.iteye.com

分布式系统后台如何防止重复提交

分布式系统网络拓扑结构

场景描述

秒杀系统提交订单时,由于用户连续快速点击,并且前端没有针对性处理,导致连续发送两次请求,一次命中服务器A,另一次命中服务器B, 那么就生成了两个内容完全相同的订单,只是订单号不同而已.

重复提交的后果

  1. 用户在界面看到两个一模一样的订单,不知道应该支付哪个;
  2. 系统出现异常数据,影响正常的校验.

解决方法

解决思路:相同的请求在同一时间只能被处理一次.
如果是单体服务器,我们可以通过多线程并发的方式解决,但是目前大部分系统,采用了多机负载均衡.

分布式锁

  1. 服务器A接收到请求之后,获取锁,获取成功 ,
  2. 服务器A进行业务处理,订单提交成功;
  3. 服务器B接收到相同的请求,获取锁,失败,
    因为锁被服务器A获取了,并且未释放
  4. 服务器A处理完成,释放锁 实现采用redis ,

    参考: http://www.importnew.com/27477.html

利用数据库唯一性约束

实现思路: 对请求信息进行hash运算,得到一个hash值,
相同的请求信息得到相同的hash值(换成md5也可以) 步骤:

  1. 接口A接收到请求之后,对请求信息hash运算,得到hash值hashCodeA;
  2. 保存hashCodeA 到数据库,并且对应的数据库的列(column)满足unique约束;
  3. 保存成功之后,才进行正常业务逻辑处理,比如提交订单;
  4. 服务器B接收到相同的请求后,也得到相同的hash值,hashCodeA,
  5. 服务器B 保存hashCodeA 到数据库,肯定失败,因为相同的hash值已经存在;
  6. 因为保存失败,所以后面的业务逻辑不会执行.

示例代码: 控制器中:


  
// 使用数据库约束条件,防止重复提交
        try {
            Integer userId = getCurrentId();
            String hashSource = WebServletUtil.buildHashSource(request, userId);
            reqOrderLock(hashSource, houseInfo.getId());
        } catch (IOException e) {
            e.printStackTrace();
        }
		

 Service中:

/***
     * 利用数据库的唯一性约束<br />
     * 防止重复提交
     * @param queryString
     */
    public void reqOrderLock(String queryString, Integer houseInfoId) {
        long crc32Long = EncryptionUtil.getHash(queryString);
        this.orderReqLockDao.addUnique(String.valueOf(crc32Long), houseInfoId, Constant2.Order_type_Label_VISIT_ORDER);
    }

 

dao 中:

public OrderReqLock addUnique(String crc32, Integer houseInfoId, String orderTypeLabel) {
        OrderReqLock orderReqLock = new OrderReqLock();
        orderReqLock.setCrc32(crc32);
        if (null != houseInfoId) {
            orderReqLock.setHouseInfoId(houseInfoId);
        }

        orderReqLock.setOrderTypeLabel(orderTypeLabel);
        CreateTimeDto createTimeDto = TimeHWUtil.getCreateTimeDao();
        orderReqLock.setCreateTime(createTimeDto.getCreateTime());
        orderReqLock.setUpdateTime(createTimeDto.getUpdateTime());
        try {
            add(orderReqLock);
        } catch (org.hibernate.exception.ConstraintViolationException e) {
            e.printStackTrace();
            LogicExc.throwEx(Constant2.ERROR_CODE_Repeat_Operation, "您重复提交了订单,订单类型" );
        } 
        return orderReqLock;
    }

 当然有个隐患: 在增加完锁,即执行addUnique 方法之后,程序挂了,不管是网络原因还是数据库崩溃, 当服务恢复之后,相同的请求无法提交了,因为数据库已经保存了请求的hash(但是实际上,后面的业务逻辑还没有来得及执行). 原因:锁操作addUnique 和业务逻辑肯定不在同一个数据库事务中

前端的解决方法

思路: 进入添加页面时,获取服务器端的token,
提交时把token提交过去,判断token是否存在,
若存在,则进行后续正常业务逻辑,
如不存在,则报错重复提交.

流程图

添加页面接口 使用注解:@RepeatToken(save = true) 提交接口 使用注解 :@RepeatToken(remove = true) token 拦截器代码

package com.girltest.web.controller.intercept;

import com.common.util.WebServletUtil;
import org.apache.log4j.Logger;
import org.springframework.web.method.HandlerMethod;
import org.springframework.web.servlet.handler.HandlerInterceptorAdapter;

import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import java.lang.reflect.Method;
import java.util.UUID;

/**
 * Created by 黄威 on 9/14/16.<br >
 */
public class TokenInterceptor extends HandlerInterceptorAdapter {
    private static final Logger LOG = Logger.getLogger(TokenInterceptor.class);

    @Override
    public boolean preHandle(HttpServletRequest request, HttpServletResponse response, Object handler) throws Exception {
        if (handler instanceof HandlerMethod) {
            HandlerMethod handlerMethod = (HandlerMethod) handler;
            Method method = handlerMethod.getMethod();
            RepeatToken annotation = method.getAnnotation(RepeatToken.class);
            if (annotation != null) {
                boolean needSaveSession = annotation.save();
                if (needSaveSession) {
                    request.getSession(true).setAttribute("token", UUID.randomUUID().toString());
                }
                boolean needRemoveSession = annotation.remove();
                if (needRemoveSession) {
                    if (isRepeatSubmit(request)) {
                        LOG.warn("please don't repeat submit,url:" + request.getServletPath());
                        //如果重复提交,则重定向到列表页面
                        response.sendRedirect(WebServletUtil.getBasePath(request) + "test/list");
                        return false;
                    }
                    request.getSession(true).removeAttribute("token");
                }
            }
            return true;
        } else {
            return super.preHandle(request, response, handler);
        }
    }

    /***
     *
     * @param request
     * @return : true:报错需要重定向 <br />
     * false: 处理后续的正常业务逻辑
     */
    private boolean isRepeatSubmit(HttpServletRequest request) {
        String serverToken = (String) request.getSession(true).getAttribute("token");
        if (serverToken == null) {
            return true;
        }
        String clinetToken = request.getParameter("token");
        if (clinetToken == null) {
            return true;
        }
        if (!serverToken.equals(clinetToken)) {
            return true;
        }
        return false;
    }
}

 

总结

  1. 第二种方法(利用数据库完整性约束)最简便,但是会访问(读写)数据库,给数据库造成一定的压力;
    但也有个隐患,程序执行中途故障了(网络垮了,服务宕了...),后面重复提交,就无法成功了.也有解决方法:定时器清理这个hash数据库表
  2. 第一种方法最复杂,但是符合高性能,高可用

参考

https://my.oschina.net/huangweiindex/blog/1837706
参考: http://www.importnew.com/27477.html

https://my.oschina.net/huangweiindex/blog/1843927

 



已有 0 人发表留言,猛击->> 这里<<-参与讨论


ITeye推荐



相关 [分布 系统 后台] 推荐:

分布式系统后台如何防止重复提交

- - ITeye博客
分布式系统后台如何防止重复提交. 秒杀系统提交订单时,由于用户连续快速点击,并且前端没有针对性处理,导致连续发送两次请求,一次命中服务器A,另一次命中服务器B, 那么就生成了两个内容完全相同的订单,只是订单号不同而已.. 用户在界面看到两个一模一样的订单,不知道应该支付哪个;. 系统出现异常数据,影响正常的校验..

漂亮的系统后台UI 欣赏

- 飞虫 - 博客园-首页原创精华区
     UI即User Interface(用户界面)的简称. UI设计则是指对软件的人机交互、操作逻辑、界面美观的整体设计. 好的UI设计不仅是让软件变得有个性有品味,还要让软件的操作变得舒适、简单、自由、充分体现软件的定位和特点..        现在软件设计也分为两个部分:编码设计与UI设计.

分布式缓存系统 Xixibase

- Le - 开源中国社区最新软件
Xixibase是一个高性能,跨平台的分布式缓存系统. Xixibase server 采用 C++ 实现,底层网络库采用的是Boost Asio. Xixibase 主要特点: 1. 实现'Local Cache'功能, 当客户端打开'Local Cache'选项, 客户端可以将数据同时存储在Server 端和本地,并且保证本地数据和Server 端的数据的一致性.

分布式检索系统 ElasticSearch

- - 丕子
ElasticSearch最近发展不错,github等都用它,可以关注I下. ElasticSearch是分布式,REST风格,搜索和分析系统. 具有实时数据,实时分析,分布式,高可用性,多租户,全文搜索,面向文档,冲突管理,自由模式,rest风格API,每个操作的持久性,Apache 2的开源许可证,基于Apache Lucene之上的特点.

分布式消息系统:Kafka

- - 标点符
Kafka是分布式发布-订阅消息系统. 它最初由LinkedIn公司开发,之后成为Apache项目的一部分. Kafka是一个分布式的,可划分的,冗余备份的持久性的日志服务. 在大数据系统中,常常会碰到一个问题,整个大数据是由各个子系统组成,数据需要在各个子系统中高性能,低延迟的不停流转. 传统的企业消息系统并不是非常适合大规模的数据处理.

分布式系统介绍-PNUTS

- - CSDN博客推荐文章
PNUTS是Yahoo!的分布式数据库系统,支持地域上分布的大规模并发操作. 它根据主键的范围区间或者其哈希值的范围区间将表拆分为表单元(Tablet),多个表单元存储在一个服务器上. 一个表单元控制器根据服务器的负载情况,进行表单元的迁移和拆分. 每条记录的数据都没有固定的模式(采用JSON格式的文本).

Ganglia:分布式监控系统

- - CSDN博客移动开发推荐文章
1         环境安装配置. 1.1      依赖软件下载. Ganglia是伯克利开发的一个集群监控软件. 可以监视和显示集群中的节点的各种状态信息,比如如:cpu 、mem、硬盘利用率, I/O负载、网络流量情况等,同时可以将历史数据以曲线方式通过php页面呈现. 而ganglia又依赖于一个web服务器用来显示集群状态,用rrdtool来存储数据和生成曲线图,需要xml解析因此需要expat,配置文件解析需要libconfuse.

kafka分布式消息系统

- - CSDN博客云计算推荐文章
Kafka[1]是linkedin用于日志处理的分布式消息队列,linkedin的日志数据容量大,但对可靠性要求不高,其日志数据主要包括用户行为(登录、浏览、点击、分享、喜欢)以及系统运行日志(CPU、内存、磁盘、网络、系统及进程状态). 当前很多的消息队列服务提供可靠交付保证,并默认是即时消费(不适合离线).

分布式内存文件系统:Tachyon

- - 杨尚川的个人页面
Tachyon是一个分布式内存文件系统,可以在集群里以访问内存的速度来访问存储在Tachyon里的文件. Tachyon是架构在最底层的分布式文件系统和上层的各种计算框架之间的一种中间件,其主要职责是将那些不需要落地到DFS里的文件,落地到分布式内存文件系统中,来达到共享内存,从而提高效率,减少内存冗余,减少GC时间等.

FastDFS分布式文件系统

- - 开源软件 - ITeye博客
       FastDFS是一个开源的轻量级 分布式文件系统,它对文件进行管理,功能包括:文件存储、文件同步、文件访问(文件上传、文件下载)等,解决了大容量存储和负载均衡的问题. 特别适合以中小文件(建议范围:4KB < file_size <500MB)为载体的在线服务,如相册网站、视频网站等等.