FIX: Input the operation to none master node.

[brido4125]

🔗 Related Issue

https://github.com/jam2in/arcus-works/issues/686#issuecomment-2646933197
위 이슈에서 파생됨

기존 로직에서는 ReplicaPick.Slave 또는 ReplicaPick.RR 시,
Operation의 타입에 상관없이 선택된 노드에 연산을 처리한다.
즉, write 연산인 경우에도 Slave 노드에 연산이 처리될 수 있다.

대략 아래의 흐름에서 문제가 발생한다.

• Repl 사용하는 응용에서 api 호출로 인해 Operation 객체 생성
• addOp 호출
• addOperation 호출
• 내부에서 cache key에 해당하는 node 찾기 위한 findNodeByKey 호출
• findNodeByKey에서 ReplicatkPick.Slave 설정 시 Slave 노드에 해당하는 node 리턴
• 해당 node에 op 객체를 inputQ에 삽입
• 해당 op가 write 연산일 경우 slave 노드에 write 연산을 삽입하는 문제가 발생

⌨️ What I did

1. addOperation 호출 시, 해당 op의 write / read 여부를 확인 후 ReplicaPick을 찾도록 변경
2. groupingKeys의 경우, op 객체가 생성되기 전에 수행되는 로직이다. 그래서 이를 호출하는 api의 타입을 직접 보고 read / write 여부를 인자로 넘겨서 확인 가능하도록 변경

[uhm0311]

2차 질문 남깁니다.

[jhpark816]

@oliviarla
추가 리뷰를 진행해주세요.

[jhpark816]

@brido4125
지금 보니, ReplicaPick 관점에서 일부만 변경되어 있습니다.
1개 commit 단위로 관련된 것을 일괄 수정하는 것이 맞을 것 같습니다.

그리고, 아래 메소드에서 getPrimary() 호출 시에
getReplicaPick() 대신에 ReplicaPick.MASTER을 넘기는 것이 논리적으로 맞습니다.
해당 key에 대해 연산의 read/write 타입을 모르는 상태에서 getReplicaPick() 호출하는 것은 맞지 않습니다.

  public MemcachedNode getPrimaryNode(final String key) {
    /* ENABLE_REPLICATION if */
    if (this.arcusReplEnabled) {
      return ((ArcusReplKetamaNodeLocator) locator).getPrimary(key, getReplicaPick());
    }
    /* ENABLE_REPLICATION end */
    return locator.getPrimary(key);
  }

[brido4125]

@uhm0311 @oliviarla

아래코멘트 반영해서 groupingKey와 같이 op 객체가
생성 되기 전에 node를 찾아야 하는 로직에서 발생하는 버그도 수정했습니다.

#875 (comment)

[uhm0311]

https://github.com/jam2in/arcus-works/issues/691

여기 논의가 끝난 후에 다시 리뷰 시작하겠습니다.

[jhpark816]

리뷰 완료