프로젝트 요약 - 웹 프로젝트에서의 데이터 일치성 문제

최근 참여한 프로젝트인 위챗 공중 플랫폼 개발은 코드를 스캔하여 어떤 개발자의 공중 계정을 팔로우할 때 조작이 반응하지 않아 두 번 스캔한 결과 위챗 서버도 두 개의 메시지를 개발자 서버에 전송했다.결과적으로 업무 처리 과정에서 입고된 위챗 팬 기록도 두 가지로 들어갔다. 위챗 팔로우 사건의 처리 절차는 다음과 같다.

/**
 *  ： 
 * @param msgRequest
 * @return
 */
private String subscribe(MsgRequest msgRequest){
	MsgResponseText response = new MsgResponseText();
	response.setFromUserName(msgRequest.getToUserName());
	response.setToUserName(msgRequest.getFromUserName());
	response.setMsgType(MsgType.Text.toString());
	response.setContent(" !");
	response.setCreateTime(System.currentTimeMillis()/1000);
	/*
	 *  
	 */
	String openId = msgRequest.getFromUserName();
	String account = msgRequest.getToUserName();
	FansAccount fansAccount = fansDao.queryByOpenId(openId);
	if(fansAccount==null){
		// ( )
		fansAccount = new FansAccount();
		// 
		refreshFansAccount(fansAccount,openId, account);
		// 
		if(StringUtils.isEmpty(fansAccount.getOpenId())){
			logger.info(" ， ...");
		}else{
			fansDao.addFansAccount(fansAccount);
		}
	}else{
		// （ ）
		refreshFansAccount(fansAccount,openId, account);
		// 
		fansDao.updateWhenFollowOrNot(fansAccount);
	}
	
	// ， 
	List<WexinBaseMsg> list = baseMsgDao.queryByReplyType(Constants.BeaddedReply);
	if(list!=null&&list.size()>0){
		response.setContent(list.get(0).getContent());
	}
	
	String newsToXml = MsgXmlUtil.textToXml(response);
	logger.info("newToXml:
"+newsToXml);
	return newsToXml;
}

위챗이 두 개의 메시지를 작업 플랫폼 서버에 연속으로 전송할 때 서버는 두 개의 라인을 열어 대응하는 요청을 처리한다. 두 개의 요청이 너무 가깝기 때문에 (본질적으로 사용자가 오작한 것) 결과적으로 입고 판단 시 두 개의 라인 판단이 모두 새로운 관심사 팬이고 두 개의 기록을 동시에 입고하는 상황이 발생한다.다중 스레드 환경에서 조회 판단과 입고 조작은 원자 조작이어야 데이터의 일치성을 확보할 수 있다.해결 방법은 같은 업무에서 판단을 실행하고 조작을 삽입할 수도 있고 이 코드에 자물쇠를 채워 원자성을 확보할 수도 있다.
양식을 제출할 때도 중복 제출을 고려해야 한다는 점에서 웨이커 중국의 사용자 체험은 매우 좋지 않다. 방안을 제출할 때 페이지가 반응이 없을 때 중복 제출을 자주 한다. 그 결과 페이지를 새로 고친 후에 중복 제출 N조 기록을 볼 수 있다.웹 프로젝트는 사용자의 중복 조작 상황을 고려할 필요가 있다. 만약에 응답 속도가 빠르지 않고 사용자가 인내심이 없는 상황에서 중복 데이터가 발생할 수 있기 때문이다.