SMALL java3 SnowFlake 적용기 - JavaScript의 자료형 문제 지난 글(SnowFlake 적용기 - 구현)에서 실제로 SnowFlake를 적용해서 채번을 진행해보았다. 채번되어 나온 값은 크다면 크다고 할 수 있는 값이 나오게 되는데, 이렇게 해서 나온 값은 JavaScript에서 문제가 된다. 클라이언트에 값을 내려주고 로직을 처리하기 위한 데이터가 온전한 형태를 유지하지 못하는 모습을 확인할 수 있었다. 이것은 JavaScript의 자료형이 감당(?) 할 수 있는 크기를 넘어서 나온것이고, 실제 문서에도 지원하는 범위가 64비트보다는 작은 모습을 볼 수 있다. JavaScript의 타입과 자료구조 - JavaScript | MDN 모든 프로그래밍 언어에는 내장된 자료구조가 존재하지만 보통 그 내용은 언어마다 다릅니다. 이 글에서는 JavaScript에서 사용할 .. 2023. 1. 10. SnowFlake 적용기 - 구현 해보자 지난 글(SnowFlake 적용기 - Unique한 값)에서는 SnowFlake를 조사하게 된 계기(?)를 이야기 했다. 이번에는 실제로 적용해보자. Twitter의 GitHub에 실제 채번을 위한 코드가 있지만, 이는 Scala로 작성되어 있었다. GitHub - callicoder/java-snowflake: Distributed Unique ID Generator in Java inspired by Twitter Snowflake Distributed Unique ID Generator in Java inspired by Twitter Snowflake - GitHub - callicoder/java-snowflake: Distributed Unique ID Generator in Java .. 2023. 1. 7. SnowFlake 적용기 - Unique한 값 어떤 프로젝트를 진행하던 지금까지 DB의 PK에 대해서 생각해본적은 없었다. 왜냐하면 JPA에 설정해준 전략에 따라서 자동으로 생생해주었고, 항상 유니크한 값을 가지고 있다고 생각했기 때문이다. 하지만 서비스가 커질 수록, 트래픽도 많아지고 분산처리를 해야할 일도 생긴다. 이 말을 들을때도 별로 와닿지는 않았었다. 사실 그만큼의 서비스를 경험해본적도 없고.... 어쨌든! 이러한 요구사항이 생겼다. "기간제로 사용중인 서비스의 이용자의 이용빈도가 적고 사용하지 않기 때문에, 해당 이용자는 데이터 이관을 통해 다른 장비에서 모아서 관리하도록 해야한다." 계속해서 잘 사용하는 이용자에게 좀 더 원할한 서비스... 이를테면 처리도 빠르고 성능도 좋은 그런 서비스를 제공해야하기에 장비의 스펙도 올라가게 되는데, .. 2023. 1. 7. 이전 1 다음 LIST
