Update README.md

README.md

@@ -342,7 +342,9 @@ where ..
 대부분의 요청도 커넥션 풀 대기가 발생하는 상황 발견
 
 **문제 발견 후 사고과정**
-- X락으로 인해 여러 조회요청이 몰리는경우 앞의 트랜잭션이 커밋이나 롤백되기전까지 일시적으로 대기하기때문에 인메모리나 캐시에서 카운팅하고 주기적으로 반영해보기로 판단했습니다.
+- 커넥션풀 대기가 발생한다면 커넥션 반납이 늦어지는걸 줄여볼수있다고 생각했고 그 방법들로는 트랜잭션이 너무 길지않은지, DB쿼리 횟수나 쿼리응답시간을 최적화해보기 였습니다.
+- 우선 X락으로 인해 여러 조회요청이 몰리는경우 앞의 트랜잭션이 커밋이나 롤백되기전까지 일시적으로 대기하기때문에 인메모리나 캐시에서 카운팅하고 주기적으로 반영해보고, 조회마다 발생하는 좋아요와 댓글수에 대한 count쿼리를 매번 발생시키기보다는, 
+데이터의 실시간성은 포기하고 메모리에 update해두고 count쿼리 자체를 줄여보는 방법을 선택했습니다.
 - 조회수 요청마다 이벤트발생 + 비동기 방식으로 처리해주는 방법도 결국 update쿼리가 발생하는것 자체가 문제이기때문에 고려하지않았습니다.
 
 
@@ -366,8 +368,8 @@ where ..
 ![image](https://github.com/youngreal/inflearn/assets/59333182/99dd1c54-9cc1-433d-ac74-bbd030fa95a5)
 
 ### 잠재적 문제 & 한계
-- redis를 도입해서 인기글테이블의 존재대신, redis에 캐싱하게되면 현재 커넥션 풀 대기상황을 좀더 완화하여 더 많은 트래픽을 처리할 수 있습니다. 하지만 서버를 scale-out해서 더 많은 처리량을 얻어낼수도있습니다.
-- 스프링서버 scale-out을 먼저할지 redis를 먼저 도입해볼지 어려웠습니다. 
+- 특정 서버에서 장애발생시 해당 서버에서 카운팅된 조회수가 손실될수 있습니다. 조회수는 어느정도 손실되도 괜찮은 성질이므로 감당 가능합니다.
+- redis를 도입해서 인기글테이블의 존재대신, redis에 캐싱하게되면 현재 커넥션 풀 대기상황을 좀더 완화하여 더 많은 트래픽을 처리할 수 있습니다. 하지만 서버를 scale-out해서 더 많은 처리량을 얻어낼수도있습니다. 스프링서버 scale-out을 먼저할지 redis를 먼저 도입해볼지 어려웠습니다. 
 
 ## 5. LIKE %word%로 게시글 검색 시 full table scan이 발생해 레이턴시가 증가하는 문제를 fulltext-search로 개선하기