[feat] 추첨 로직 구현(#40) #43
Conversation
spring MVC에서는 뷰를 생성할 때 message를 자동으로 주입해줬지만, api 서버로 사용할 때는 예외에 자동으로 주입해주지 않음. 따라서 messagesource를 주입받아 직접 변환. 좀 더 일관된 방식이 있다면 변경 예정
JPA로 추첨 이벤트 당첨 정보를 저장하기 위해서는 연관 객체인 EventUser를 객체로 가져와 연관 관계를 지정해야 하고, insertAll을 수행해도 단일 insert 여러번으로 처리된다. 이런 불필요한 작업을 제거하기 위해 JDBC Template 기반으로 bulk insert 기능을 구현한다.
차후 2개의 과정으로 분리할 수도 있음
| if (count - maxPickCount <= 10 || // 두 값 차이가 작을 때 | ||
| ((double) count / maxPickCount) <= 1.1 ) { | ||
| return pickMany(items, maxPickCount); | ||
| } else { | ||
| return pickManyUsingSet(items, maxPickCount); | ||
| } |
There was a problem hiding this comment.
사전조사에서 설계하셨던 내용을 여기에 담으신거군요~! 좋습니다
| @Override | ||
| public void setValues(PreparedStatement ps, int i) throws SQLException { | ||
| EventUserScoreDto userScore = userScores.get(i); | ||
| ps.setLong(1, userScore.score()); | ||
| ps.setLong(2, userScore.userId()); | ||
| } | ||
|
|
||
| @Override | ||
| public int getBatchSize() { | ||
| return userScores.size(); | ||
| } |
There was a problem hiding this comment.
Inner Method를 선택하신 이유가 있을까요??
| @Query(value = "SELECT c.event_user_id as eventUserId, COUNT(c.event_user_id) as count " + | ||
| "FROM comment c " + | ||
| "JOIN event_frame ef ON c.event_frame_id = ef.id " + | ||
| "JOIN event_metadata e ON ef.id = e.event_frame_id " + | ||
| "WHERE e.id = :eventRawId " + | ||
| "GROUP BY c.event_user_id " , nativeQuery = true) |
There was a problem hiding this comment.
유저와 기대평 개수를 카운트해서 Dto로 바로 가져오는 로직이군요!
| String code = e.getErrorCode(); | ||
| String fieldName = e.getName(); | ||
| Locale locale = LocaleContextHolder.getLocale(); // 현재 스레드의 로케일 정보를 가져온다. | ||
| String errorMessage = messageSource.getMessage(code, null, locale); // 국제화 된 메시지를 가져온다. |
| public Map<Long, Long> calculate(long eventId, List<DrawEventScorePolicy> policies) { | ||
| Map<Long, Long> scoreMap = new HashMap<>(); | ||
| for (var policy : policies) { | ||
| ActionHandler handler = handlerMap.get(policy.getAction()); | ||
| handler.handle(scoreMap, eventId, policy.getScore()); | ||
| } | ||
| return scoreMap; | ||
| } |
There was a problem hiding this comment.
점수 계산을 별도로 분리해버리는 것은 좋은 전략인 것 같습니다.
| @@ -14,7 +14,7 @@ | |||
| @NoArgsConstructor | |||
| public class Admin { | |||
| @Id | |||
| @GeneratedValue(strategy = GenerationType.AUTO) | |||
| @GeneratedValue(strategy = GenerationType.IDENTITY) | |||
There was a problem hiding this comment.
초기 의도는 mysql AUTO_INCREMENT Primary Key를 이용하는 방식이었지만, 실제로는 다른 전략을 사용하고 있어 수정했습니다.
| Map<String, String> errors = new HashMap<>(); | ||
| errors.put(e.getName(), e.getLocalizedMessage()); | ||
| return ResponseEntity.badRequest().body(errors); | ||
| public Map<String,String> handleInValidRequestException(MethodArgumentTypeMismatchException e) { |
There was a problem hiding this comment.
Spring MVC 중 View를 사용하는 경우 메세지 소스로부터 메시지 코드를 치환해주지만, API 서버로 사용할 때는 예외 메시지에 대한 메시지를 치환해주지 않습니다. 따라서, 예외에 대한 메시징 기능은 MessageSource를 받아 직접 수정해야 합니다.
MethodArgumentTypeMismatchException은 query parameter / path variable에 대한 타입이 일치하지 않을 때 발생하는 예외입니다. 한국 이외의 국가에서도 현재 시스템을 이용할 수 있는 상황을 염두에 두고, Spring Message 으로 예외 메시지를 관리합니다.
|
|
||
| // actionHandler을 Action 타입으로 가져올 수 있도록 설정 | ||
| @Bean(name = "actionHandlerMap") | ||
| public Map<DrawEventAction, ActionHandler> actionHandlerMap(Map<String, ActionHandler> handlers) { |
There was a problem hiding this comment.
현재 추첨 이벤트의 점수 계산 로직은 하드코딩 된 로직 대신 확장 가능한 액션 ( 댓글 작성 등 ) 및 점수를 포함한 정책을 기반으로 유연하게 변경할 수 있는 구조로 설계되고 있습니다. 액션은 enum 타입으로 관리되고 있는데, 각 Action Handler을 문자열 대신 enum 타입으로 접근할 수 있도록 설정을 추가했습니다.
|
|
||
| @Primary | ||
| @Component | ||
| public class AccSumBasedWinnerPicker implements WinnerPicker { |
There was a problem hiding this comment.
추첨 로직은 다양할 수 있습니다. 현재는 누적 합 기반의 로직을 작성했지만, 추후 더 좋은 방법이 발견되는 경우 쉽게 전환할 수 있도록 WinnerPicker 명세와 누적합 방식의 구현 형태로 분리했습니다.
| public List<PickTarget> pick(List<PickTarget> items, long count) { | ||
| long maxPickCount = Math.min(items.size(), count); | ||
| // TODO: 둘 중 하나를 선택하는 최적 조건 분석하기. | ||
| if (count - maxPickCount <= 10 || // 두 값 차이가 작을 때 |
There was a problem hiding this comment.
조건에 따라 누적합 테이블을 매번 생성하거나, 한번 테이블을 만들고 추첨하는 방식 중에서 선택할 수 있게 구성했습니다. 구체적인 수치는 테스트를 통해 변경할 예정입니다.
| * <p>component 이름은 action 이름 + ActionHandler 형식을 띄어야 한다.</p> | ||
| * <p>액션 = {@link hyundai.softeer.orange.event.draw.enums.DrawEventAction}</p> | ||
| */ | ||
| public interface ActionHandler { |
There was a problem hiding this comment.
각 액션 / 정책에 대한 점수 채점을 수행하는 객체에 대한 명세입니다.
| public void insertMany(List<DrawEventWinningInfoBulkInsertDto> targets) { | ||
| String sql = "insert into draw_event_winning_info (event_user_id, ranking, draw_event_id) VALUES (?, ?, ?)"; | ||
|
|
||
| jdbcTemplate.batchUpdate( |
There was a problem hiding this comment.
Spring Data JPA을 직접 이용하면 mysql에서 Auto Increment Primary Key에 대해 각각 insert 가 발생하므로 DB 성능 측면에서 손해가 발생합니다. 대안으로 JDBC Template 또는 QueryDSL SQL이 있다는 것을 조사했고, 별도의 라이브러리 설치 및 깊은 학습이 필요하지 않은 JDBC 방식을 이용하기로 했습니다.
| */ | ||
| @Transactional | ||
| @Async | ||
| public void draw(Long drawEventId) { |
There was a problem hiding this comment.
현재는 채점 + 추첨 로직을 동시에 진행하고 있지만, 대안에 따라 채점 + 추첨 로직을 별개로 분리하는 것도 염두에 두고 있습니다.
| // 몇 등이 몇명이나 있는지 적혀 있는 정보. 등급끼리 정렬해서 1 ~ n 등 순서로 정렬 | ||
| // 확률 높은 사람이 손해보면 안됨 | ||
| List<DrawEventMetadata> metadataList = drawEvent.getMetadataList(); | ||
| metadataList.sort(Comparator.comparing(DrawEventMetadata::getGrade)); |
There was a problem hiding this comment.
현재 당첨자의 등수를 고려하지 않고 모두 뽑은 후 내부적으로 등수를 책정하는 방식을 이용하고 있습니다. 이때, 등수 정보가 정렬되지 않으면 가산점이 높은 사람이 오히려 낮은 상품을 받아 손해를 볼 여지가 있습니다. 데이터베이스에서 항상 정렬된 상태로 전달된다는 보장이 없으므로 코드 수준에서 정렬을 수행합니다.
| import static org.assertj.core.api.Assertions.assertThat; | ||
|
|
||
| // 매 테스트마다 초기화하는 코드 찾아봐야 할듯? | ||
| @Sql(value = "classpath:sql/CommentRepositoryTest.sql", executionPhase = Sql.ExecutionPhase.BEFORE_TEST_CLASS) |
There was a problem hiding this comment.
테스팅에 필요한 db 데이터를 별도의 파일로 분리하고 어노테이션 기반으로 가져오도록 구성하여, 테스트 코드 수준에서 Jdbc 등을 활용하여 입력하는 보일러 플레이트 코드를 없애고 동일 db 데이터를 여러 테스트 코드에서 공유할 수 있게 했습니다.
#️⃣ 연관 이슈
📝 작업 내용
참고 이미지 및 자료