알고리즘
아니, 왜 안풀려? 가까운 숫자 찾기 어렵네!
// indexOf를 써야할 것 같다 -> 조건을 만족하는 가장 첫 인덱스를 찾아 반환. 없으면 -1 반환.
// 이중 for문이니 i가 한 글자씩 픽하면 자기 자신까지만 돌아야 한다 -> j <= i가 범위
// 처음 나와서 앞에 같은게 없으면 -1, 앞에 나온게 있으면 '가장 가까운' 글자와의 거리(인덱스의 차)를 반환
// 앞에 같은게 있는지 없는지는 어떻게 알 수 있을까? -> s[i] === s[j] 이면서 indexOf(s[i])가 s[j]랑 다르면 s[j]는 나중글자
// 그럼 가장 가까운 글자는 어떻게 찾을 수 있을까? -> 같은 글자가 나올 때 인덱스가 저장되어 있거나 같은 글자인 인덱스를 찾아줘야 할것 같은데...
function findSame (s) {
const location = [];
const tmpSum = [];
let indexNum = 0;
for (let i = 0; i < s.length; i++) {
for (let j = 0; j <= i; j++) {
if (s[i] === s[j] && s.indexOf(s[i]) !== j) {
indexNum = Math.abs(j - s.indexOf(s[i]));
} else {
indexNum = -1;
}
// console.log('s[i]: ', s[i])
// console.log("s[j]: ", s[j])
// console.log('s.indexOf(s[i]):', s.indexOf(s[i]))
// console.log('indexNum: ', indexNum)
// console.log('tmpSum: ', tmpSum)
}
location.push(indexNum);
}
return location;
}
function solution(s) {
var answer = [];
console.log(findSame(s));
return answer;
}여러 주석과 함께 끙끙대고 있는 내 알고리즘. 얼추 가닥은 잡은 것 같은데 indexNum이 자꾸 변한다. 어째야 하나🤔
어제부터 고민했던 것인데 안 풀린다면 다음엔 튜터님께 여쭤보도록 하자.
게임개발 심화
과제 - 스테이지 이동 점수 충족여부 검증
강의 코드에서 다음 검증이 완료되었다.
- 클라단에서 보내주는 스테이지 정보와 서버가 같은 지 검증
- 1이 유효하다면 다음으로 넘어갈 타겟 스테이지가 유효한지 검증
이제 문제(?)가 하나 더 남았다. 이 게임에서 스테이지 이동은 일정 점수를 채워야 만족하는데, 스테이지 이동기준이 되는 점수를 만족했는지 검증해야 한다.
-> 이건 과제로 해보도록 하자! 모르겠다면 질문요정이 되자
챌린지반
Atomicity - 원자성. 되면 아예 되고, 안되면 아예 안되고
- stored procedure 라는게 있다
프로그램처럼 동작하는게 있다. 이 안에서 트랜잭션이 돌아간다
Consistency - 데이터의 일관성 보장
- 참조무결성 제약?
내가 참조하는 외래키가 훼손되지 않고 멀쩡히 존재하는 애라는 것
-> 존재하지 않는 게시글에 댓글을 달 순 없다!
Isolation - 격리성 보장
변신 중엔 때리지 않는 국룰이 있다. (개도 안건드린다는데!)
Durability
트랜잭션이 성공적으로 수행되면 이 결과는 영원히 DB에 반영된다.
Isolation에는 성능과 일관성 간 딜레마가 있다 -
나중에 포트폴리오 쓸 때 '기술적 의사결정'에 대해서 쓰라고 한다. '이 기술을 왜 선택했느냐'는것.
Isolation Level도 마찬가지다.
트랜잭션을 거는 순간 성능에는 부하가 걸리는 것이다. 그럼에도 불구하고 거는 이유는 '안 걸었을 때의 후폭풍이 너무 크기 때문'이다.
GS Fresh의 1 + 1 계란이 1개 남았다면?
- Serializable
-> 하나의 트랜잭션이 완료될 때 까지 다른 트랜잭션은 해당 상품의 재고에 접근할 수 없다.
-> A가 신선계란 하나 잡으면 B는 구매는 물론이고 재고확인도 못한다 (빡세다.......)
-
Repeatable Read (MySQL의 기본 설정)
같은 데이터를 반복해서 읽어도 동일한 결과를 보장한다
-> A와 B가 동시에 신선계란의 재고를 확인하고 구매를 시도할 수 있다
-> 하지만 이때 실제 재고 감소 로직은 손이 더 빠른 한명만 가능하다. 동시에 같은 데이터를 수정하려 할 때 한 트랜잭션만 성공할 수 있기 때문
-> A가 먼저 결제 버튼을 눌러버리면 B의 결제는 실패하거나 잠금 대기 상태에 빠질 수 있다
-> Phantom Read 라는 문제가 있긴 하지만, 어찌저찌 방어는 가능하다 -
Read Committed (MySQL 제외 나머지의 기본설정)
-> 한 트랜잭션 내에서 커밋 완료된 데이터만 읽을 수 있는 것을 보장
-> 이 격리 수준에서는 고객 B가 A의 트랜잭션이 완료된 후에만 그 변경 데이터를 읽을 수 있다
-> 즉, B는 언제든 A가 먼저 결제 버튼을 누르는 순간 신선계란의 재고 0을 볼 수 있는 것 -
Read Uncommitted (와 세상에 으악)
한 트랜잭션 내에서 커밋 완료되지 않은 데이터도 읽을 수 있다.
-> Dirty Read 문제가 발생할 수 있고 일관성이 깨진다. 하지만 성능은 좋다. (그렇게 좋은 성능이 무슨 의미가 있는진 모르겠지만...)
Dirty Read가 뭔데?
-> A랑 B가 신선란 5개 남은걸 보고 A가 먼저 3개 구매를 갈긴다
-> B가 보는 재고는 2개가 되고 B는 급한 마음에 2개라도 구매를 갈긴다
-> A의 구매 트랜잭션이 행잉 된 상태에서 롤백되어 재고는 다시 5개가 되어 버리고...
인증과 인가
암호화 복호화
암호화와 복호화에 한 개의 키가 쓰인다 - 대칭키 암호화
암호화 때 사용한 키와 복호화 때 필요한 키가 다르다 - 비대칭키 암호화
- 복호화하지 않고, 암호화된 값 자체를 비교해서 인증을 수행하면 더 안전하지 않을까?
-> 이게 bcrypt로 대표되는 단방향 암호화다. 단방향 알고리즘에도 여러가지가 있는데 궁금하면 한번 찾아보도록 하자.
SQL Injection
프로그램에서 쿼리 인자를 입력할 때는 반드시 Prepared statement를 사용하세요!
-> 이게 뭔 소리야?
Prepared statement라는 형식이 있는데, ?같은 placeholder를 두는 식으로 하고 리턴값을 배열로 던져서 이스케이프 처리가 되게 해야한다.
