Karice의 여행 & 코딩 블로그

1. 인터넷

- 인터넷은 어떻게 작동 될까요?

 - HTTP는 무엇일까요?

- 브라우저와 종작원리

 - DNS와 작동원리

 - 도메인 네임은 무엇일까요?

- 호스팅은 무엇일까요?

2. OS 및 일반적인 지식

- 터미널 사용방법

- OS의 일반적인 작동 방식

- 프로세스 관리

- 스레드와 동시성

- 기본적인 터미널 명령어

- 메모리 관리

- 프로세스간 통신 (IPC)

- 입출력(I/O) 관리

- POSIX 기초 - stdin, stout 등등

- 기본적인 네트워크 개념

3. 언어배우기

- JAVA

- JavaScript

- Ruby

4. 버전 관리

- Git 기본 사용법

5. 관계형 데이터베이스

- PostgreSQL

- MySQL

6. NoSQL 데이터 베이스

- MongoDB

7. 데이터베이스 상세 정보

- ORM

- ACID

- 트랜잭션

- N+1문제

- 데이터 레플리케이션

- 샤딩전략

- CAP 이론

- 데이터베이스 정규화

- 인덱스와 작동방식

8. API에 대해서 배우기

- REST

- JSON APIs

- SOAP

- HATEOAS

- 오픈 API 스펙과 swagger

- 인증

- Cookie 기반

- OAuth

- 기본적인 인증

- 토큰 인증

- JWT

- OpenID

- SAML

9. 캐싱

- CDN

- 서버사이드

- 클라이언트 사이드

- Redis

- Memcached

10. 웹보안 지식

- 해시 알고리즘

- MD5와 사용하지 않는 이유

- SHA Family

- scrypth

- bcrypth

- HTTPS

- 컨텐츠 보안 정책

- CORS

- SSL/TLS

- OWASP 보안 정책

11. 테스팅

- 통합테스트

- 단위 테스트

- 기능 테스트

12. CI/ CD

13. 개발과 설계 원칙

- GOF 디자인 패턴

- 도메인 주도 설계

- 테스트 주도 개발

- SOLID

- KISS

- YAGNI

- DRY

14. 아키텍쳐 패턴

- 모노로틱 앱

- 마이크로서비스

- SOA

- CQRS와 이벤트 소싱

- Serverless

15. 검색엔진

- Elasticsearch

- Solr

16.메세지 브로커

- RabbitMQ

- Kafka

17. 컨테이너화 vs 가상화

- Docker

18. GraphQL

- Apollo

- Relay Modern

19. 그래프 데이터베이스

- Neo4j

20. 웹소켓

21. 웹 서버

- Nginx

- Apache

- Caddy

- MS IIS

22. 확장성

- 마이그레이션 전략

- 수평적 확장 vs 수직적 확장

- 관찰가능성을 고려한 확장

- 마이그레이션 전략

- 측정 / 모니터링 /원격측정의 차이

**네이버 백엔드 개발자가 추천하는 공부내용들**

• 웹 생태계의 스펙
  • HTML, HTTP(1.1 , HTTP/2)
• 기본 SDK, 라이브러리/프레임워크 이해와 활용
• 클라이언트를 위한 API 설계
• 서버/컴퍼넌트/객체 간의 역할 분담/의존성/통신 방법 설계
• 저장소 활용
  • DBMS 설계
  • Cache 적용
    • Global/Local cache 적용범위, 라이프 싸이클, 솔루션 선택
  • 파일 저장 정책/솔루션 선택 활용
• 검색엔진 연동 방식 결정
• 빌드 도구
  • Maven/Gradle
• 배포 전략
• 성능 테스트/프로파일링/튜닝
  • JVM 레벨의 튜닝 (GC 옵션 등)
    • 웹 서버(Nginx,Tomcat)등의 설정/튜닝
  • OS 설정의 주요 값 확인
• 인접 기술에 대한 이해
  • DBMS, Front End 등
• 서버 개발자에만 해당하지는 않는 항목
  • 테스트 코드 작성/리팩토링 기법
  • 버전 관리 전략
    • branch 정책 등

이걸 다 정리해보자 파이팅!!

1. IP (internet protocol) 계층

- 서로 다른 네트워크간 통신이 가능하도록 지원

- IP 게층에서 데이터에 IP주소를 붙임

- IP 주소를 바탕으로 패킷이 목적지에 정확히 도달할 수 있도록 함

2. IP주소(주민번호) vs 도메인 네임(Domian Name Server) (이름)

Domain Name Service가 꼭필요함 -> IP주소와 도메인 네임을 변형하기 위해

- 사람이 사용하는 도메인 이름을 IP주소로 바꿔주는 인터넷 서비스

- 사람이 이해하는 인터넷 주소를 서버나 라우터가 아는 IP주소로 변환해 줌

- 인터넷을 사용하기 위한 필수적인 요소

3. IPv4 주소

- 주소의 범위는 32비트

- 이론적으로 42억... 개의 IP가 존재

- 0 ~ 255 사이의 십진수 네개로 표현 (8비트를 십진수로 표현)

ex) 203.255.176.75 (0.0.0.0 ~ 255.255.255.255)

- 전세계적으로 유일하게 구별

- 주소 부족 문제 발생

※ CMD에서 ipconifg -all로 확인 가능

IP주소는 네트워크 주소(집주소) 와 호스트 주소(집에 사는 사람) 로 구성

정적 IP vs 동적 IP

동적 IP : 요청이 오면 동적으로 IP 할당 - DHCP: 동적주소 할당 프로토콜

공인 IP vs 사설 IP

사설 IP : 공유기가 할당해주는 가짜 IP

4. IPv6 주소

- 인터넷의 주소 고갈 문제를 해결하고 인터넷에 확장성과 데이터 보안을 강화하기 위해 IPv6가 제안됨

- 128비트의 IP 주소 사용

- 2의 128승 개 정도 있음

- 여러가지 새로운 기능을 제공하는 동시에 기존 IPv6와의 호환성을 최대로 하는 방향으로 설계됨

- 16진수로 표현됨

1. TCP(Transmission Control Protocol) 프로토콜

- 연결지향형 서비스

- 대부분의 응용에서 사용하는 수송 계층 프로토콜

- 응용간에 신뢰성 있는 연결을 제공

- 전송 여부 체크, 중복제거 등을 보장

- 데이터에 오류가 있는지 체크

2. UPD (User Datagram Protocol) 프로토콜 - 중요한 정보 X

- 비연결형 서비스

- 불특정 다수에게 데이터 전송가능

- 전송 여부, 중복제거 등을 보장하지 않음

- 단순, 최소의 메커니즘을 통해 상대방에게 데이터 전송 서비스의 신뢰성이 낮음

- 빠른 전송 지원

- Best Effort 서비스

- 데이터에 오류가 있는지 체크

- ex) 인터넷 전화

1. 회선 교환 방식 (Old)

- 통신 기간 동안 독점적인 사용을 위해 두 통신 노드 사이를 연결 - 회선의 낭비가 심함

- 실제로 정보가 흐르는 시간 외에도 점유가 되어 회선의 이용률이 낮아짐

- 초기 전화 시스템의 방식

2.패킷 교환 방식 (New)

- 작은 블록의 패킷으로 데이터를 전송

- 데이터를 전송하는 동안만 네트워크 자원을 사용하기 때문에 이용률이 높음

- 네트워크 연결 상의 모든 노드들 사이에 개별적으로 경로가 제어되고 회선을 공유함

- 가장 많이 사용되는 방식

- 각 패킷의 헤더(머리 부분)에 목적지 주소(전달되는 주소)를, 몸통 부분에 전달되는 내용을 붙여서 네트워크에 주입하는 방식입니다.

- 각 패킷이 자신의 헤더에 붙은 주소를 따라 적절한 경로를 통해 목적지로 도달하도록 하는 방식입니다. 

- 회선이 특정 사용자에 의해 독점되지 않으므로 회선의 이용률이 매우 높습니다. 

1. 정의

통신에서는 어떤 시스템이 다른 시스템과 통신을 원활하게 수용하도록 해주는 통신 규약, 약속

2. 기능

1. 세분화와 재합성
2. 캡슐화
3. 연결제어
4. 오류제어
5. 흐름제어
6. 동기화
7. 순서 결정
8. 주소 설정
9. 다중화
10. 전송 서비스

3. 구분

1. 직접 프로토콜 / 간접 프로토콜
2. 단일체 프로토콜 / 구조적 프로토콜
3. 대칭 프로토콜 / 비대칭 프로토콜

4. 종류

대표적으로 인터넷을 할때 사용되는 TCP/IP가 있습니다.

TCP(Transmission Control Protocol) : 

• 전송 계층에서 동작하는 프로토콜
• IP위에서 동작하는 프로토콜로, 데이터의 전달을 보증하고 보낸 순서대로 받게 해준다.
• HTTP, FTP, SMTP 등 TCP를 기반으로 한 많은 수의 애플리케이션 프로토콜들이 IP위에서 동작하기 때문에, 묶어서 TCP/IP로 부른다.

IP(Internet Protocol) : 

• 네트워크 계층에서 동작하는 프로토콜
• 패킷 통신 방식의 인터넷 프로토콜
• 패킷 전달여부를 보증하지 않고, 피킷을 보낸 순서와 받는 순서가 다를 수 있음

5. OSI 7계층

1. 물리 계층

2. 데이터 링크 계층

3. 네트워크 계층

인터넷에서 목적지에 도착하기 위한 패킷의 경로 제공 및 관리의 역할을 합니다 주요 프로토콜로는 IPv4, IPv6 IPSec등이 잇습니다.

4. 전송 계층

호스트 간에 메시지의 교환과 관리가 이루어지며, TCP와 UDP가 전송 프로토콜이다. TCP는 연결형 서비스에 오류 제어와 흐름제어를 하고, UDP는 비연결형 서비스이지만 오류 제어나 흐름 제어는 실시하지 않습니다.

5. 세션 계층

6. 표현 계층

7. 응용 계층 - FTP, Telnet, SMTP, DNS, TFTP, HTTP, POP3, SNMP

FTP (File Transfer Protocol)

대화형으로 클라이언트와 서버가 통신이 가능하다. 

Telnet :

사용자가 원격에 있는 서버에 로그인 하도록 RCP 연결을 설정하며, 직접 조작할 수 있게 해준다.

SMTP (simple Mail Transfer Protocol) : 

말 그대로 메일 서비스이다. 텍스트나 실행 파일 등을 손쉽게 전송할 수 있다. 메일 시스템에서는 우너격 컴퓨터나 네트워크 연결에 장애가 발생한 경우에도 통신이 가능하다.

DNS (Domain Name System) : 

도메인 이름 주소를 통해 IP주소를 확인 할 수 있는 프로토콜이다.

HTTP (HyperText Transfer Protocol)

서버와 클라이언트가 인터넷 상에서 데이터를 주고 받기 위한 프로토콜이다.

참조 : 

https://mindnet.tistory.com/entry/%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC-%EC%89%BD%EA%B2%8C-%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-9%ED%8E%B8-%ED%94%84%EB%A1%9C%ED%86%A0%EC%BD%9C-%EC%9D%B4%EB%9E%80-Protocol-%EC%9D%B4%EB%9E%80-%EB%AC%B4%EC%97%87%EC%9D%B8%EA%B0%80

https://linked2ev.github.io/devlog/2019/06/03/WEB-What-is-protocol/

https://information-science.tistory.com/2

https://coding-factory.tistory.com/346

1. 정의 

Secure Shell Protocol,의 약자로, 네트워크 프로토콜 중하나로 컴퓨터와 컴퓨터가 인터넷과 같은 Public Network를 통해 서로 통신을 할 대 보안적으로 안전하게 통신을 하기 위해 사용하는 프로토콜입니다.

대표적인 사용으로는 "데이터 전송", "원격제어"가 있습니다.

2. 사용 예시

데이터 전송 :

원격저장소인 Github가 있습니다. 소스 코드를 원격 저장소인 깃헙에 푸쉬할 때 SSH를 활용해 파일을 전송합니다.

원격제어 : 

AWS와 같은 클라우드 서비스를 사용할때, 인스턴스 서버에 접속하여 머신에 명령을 내릴때 SSH를 사용합니다.

3. 특징

다른 FPT나 Telnet과 같은 프로토콜도 있는데 왜 SSH를 사용할까? --> 보안

4. 왜 보안이 좋을까?

SSH는 Private Key와 Public Key를 이용합니다. 저번에 알아본 Cache와 비슷하죠. 다시 알아보면

Public Key : 공개되어도 안전한 Key, 이 키를 통해 메시지를 전송하기전에 암호화를 합니다. but 복호화는 불가능

Private Key : 절대로 외부에 노출되어서는 안되는 Key, 본인 컴퓨터 내부에 저장되어 있고, 복호화를 할 수 있습니다.

참조 : 

https://baked-corn.tistory.com/52

https://velog.io/@hyeseong-dev/%EB%A6%AC%EB%88%85%EC%8A%A4-ssh%EB%9E%80

https://cheershennah.tistory.com/96

1. 정의

부하분산 또는 로드 밸런싱은 컴퓨터 네트워크 기술의 일종으로 중앙처리 장치 혹은 저장장치와 같은 컴퓨터 자원들에게 작업을나누는 것을 말한다.

서버에 가해지는 부하(=로드)를 분산(=밸런싱) 해주는 기술이다.

사업의 규모가 확장되고, 클라이언트의 수가 늘어나게 되면 기존 서버만으로는 정상적인 서비스가 불가능하게 되는데, 이런 증가한 트래픽에 대처할 수 있는 방법은 크게 두가지 이다.

• Scale Up : 서버 자체의 성능을 높이는 것
• Scale Out : 여러대의 서버를 두는것

Scale-out방식에서 로드밸런싱이 필요하다. 각각의 서버에 균등하게 트래픽을 분산시켜주는 것이 바로 load balancer입니다.

2. 로드밸런싱 알고리즘

라운드 로빈

서버에 들어온 요청을 순서대로 돌아가며 배정하는 방식 

서버와의 연결이 오래 지속되지 않는 경우 적합하다.

가중 라운드로빈 방식

각서버에 가중치를 매기고 가중치가 높은 서버에 요청을 우선적으로 배정하는 방식

서버의 트래픽 처리 능력이 다른 경우 사용한다.

최소 연결 방식

요청이 들어온 시점에 가장 적은 연결 상태를 보이는 서버에 트래픽을 배정하는 방식

서버에 분배된 트래픽들이 일정하지 않은 경우에 적합하다.

IP 해시 방식

클라이언트의 IP주소를 특정 서버로 매핑하여 요청을 처리하는 방식

사용자가 항상 동일한 서버로 연결된다.

3. 주요 기능

NAT (Network Address Translation)

--> 사설 IP 주소를 공인 IP주소로 바꾸는데 사용하는 통신망의 주소 변조기입니다.

Tunneling

--> 인터넷 상에서 눈에 보이지 않는 통로를 만들어 통신할 수 잇게 하느 ㄴ개념

--> 데이터를 캡슐화해서 연결된 상호 간에만 캡슐화도니 패킷을 구별해 캡슐화를 해제할 수 있습니다.

DSR(Dynamic Source Routing protocol)

--> 로드 밸런서 사용시 서버에 클라이언트로 되돌아가는 경우 목적지 주소를 스위치의 IP 주소가 아닌 클라이언트의 IP 주소로 전달해서 네트워크 스위치를 거치지 않고 바로 클라이언트를 찾아감

4. 구조

5. 종류

L2 - Mac 주소를바탕으로 Load Balancing 합니다.

L3 - IP주소를 바탕으로 Load Balancing 합니다.

L4 - Transport Layer(IP와 Port) Level에서 Load Balancing을 합니다. ex) TCP, UDP

L7 - Application Layer(사용자의 Request) Level에서 Load Balancing을 합니다. ex) HTTP, HTTPS

6. 동작방식

1. 클라이언트의 브라우저에서 abc.net이라고 입력
2. 클라이언트에 설정된 메인 DNS 서버로 abc.net의 IP주소를 문의
3. 메인 DNS 서버는 abc.net 주소를 관리하는 별도의 DNS 서버에 IP 주소 문의
4. 별도 관리 DNS 서버는 로드 밸런서의 IP 주소를 메인 DNS 서버에게 알려줌
5. 메인 DNS 서버는 획득한 VIP 주소를 클라이언트에 전송
6. 클라이언트에서 로드밸런서의 VIP 주소로 HTTP요청
7. 로드밸런서는 별도 로드밸런싱 방법을 통해 서버에 요청 전송
8. 서버의 작업 결과를 받은 로드밸런서는 전달받은 HTTP 결과를 클라이언트에게 전송 

참조 : 

https://velog.io/@jisoo1170/Load-Balancing%EC%9D%B4%EB%9E%80

https://nesoy.github.io/articles/2018-06/Load-Balancer

https://www.stevenjlee.net/2020/06/30/%EC%9D%B4%ED%95%B4%ED%95%98%EA%B8%B0-%EB%84%A4%ED%8A%B8%EC%9B%8C%ED%81%AC%EC%9D%98-%EB%B6%80%ED%95%98%EB%B6%84%EC%82%B0-%EB%A1%9C%EB%93%9C%EB%B0%B8%EB%9F%B0%EC%8B%B1-load-balancing-%EA%B7%B8/

1. HTTP란

Hyper Text Transfer Protocol의 약자로 서버/클라이언트 모델을 따라 데이터를 주고 받기 위한 프로토콜이다.

즉 HTTP는 인터넷에서 하이퍼텍스트를 교환하기 위한 통신 규약으로 80번 포트를 사용하고 있다. 따라서 HTTP 서버가 80번 포트에서 요청을 기다리고 있으며 클라이언트는 80번 포트로 요청을 보낸다.

애플리케이션 레벨의 프로토콜로 TCP/IP위에서 작동한다. HTTP는 상태를 가지고 있지 않아 stateless 프로토콜이다.

HTTP의 단점으로는 암호화가 되지 않아서 정보를 제 3자가 조회하기가 너무 쉬웠다. 그래서

HTTPS가 등장하게 되었다.

2. HTTPS란

HTTP에서 암호화가 추가된 프로토 콜이다. 433번 포트를 사용하며, 네트워크 상에서 중간에 제 3자가 정보를 볼 수 없도록 공개키 암호화를 지원하고 있다.

공개키 암호화 : 공개키로 암호화를 하면 개인키로만 복호화(암호를 푸는 것) 할 수 있다. -> 개인키는 나만 가지고 잇으므로, 나만 볼 수 있음

개인키 암호화 : 개인키로 암호화하면 공개키로만 복호화 할 수 있다. -> 공개키는 모두에게 공개되어 있으므로, 내가 인증한 정보임을 알려서 신뢰성 확보

3. HTTPS의 동작 과정⭐

서버는 클라이언트가 요청을 보낼 때 암호화를 하기 위한 공개키를 생성해야되는데, 일반적으로는 인증된 기관에 공개키를 전송하여 인증서를 발급받고 있다. 

자세한 과정은

1. A기업은 HTTP 기반의 애플리케이션에 HTTPS를 적용하기 위해 공개키/개인키를 발급함
2. CA 기업에게 돈을 지불하고, 공개키를 저장하는 인증서의 발급을 요청함
3. CA 기업은 CA 기업의 이름, 서버의 공개키, 서버의 정보 등을 기반으로 인증서르 ㄹ생성하고, CA 기업의 개인키로 암호화하여 A기업에게 이를 제공함
4. A기업은 클라이언트에게 암호화된 인증서를 제공함
5. 브라우저는 CA기업의 공개키를 미리 다운받아 갖고 있어, 암호화된 인증서를 복호화함
6. 암호화된 인증서를 복호화하여 얻은 A기업의 공개키로 데이터를암호화하여 요청을 전송함

추가적인 HTTPS의 장점은

검색엔진 최적화(SEO)에 있어서도 도움을 받는다.

4. 결론

개인 정보와 같은 민감한 데이터를 주고 받아야 한다면 HTTPS를 이용해야 하지만, 단순한 정보 조회 등만을 처리하고 있다면 HTTP를 이용하면 된다

참고 : 

https://mangkyu.tistory.com/98

http://blog.wishket.com/http-vs-https-%EC%B0%A8%EC%9D%B4-%EC%95%8C%EB%A9%B4-%EC%82%AC%EC%9D%B4%ED%8A%B8%EC%9D%98-%EB%A0%88%EB%B2%A8%EC%9D%B4-%EB%B3%B4%EC%9D%B8%EB%8B%A4/

https://velog.io/@blackb0x/HTTPHTTPS%ED%86%B5%EC%8B%A0%EA%B3%BC-%EC%86%8C%EC%BC%93%ED%86%B5%EC%8B%A0

https://jeong-pro.tistory.com/89

def get_client_ip(request):
    x_forwarded_for = request.META.get('HTTP_X_FORWARDED_FOR')
    if x_forwarded_for:
        ip = x_forwarded_for.split(',')[0]
    else:
        ip = request.META.get('REMOTE_ADDR')
    return ip

참고 : https://stackoverflow.com/questions/4581789/how-do-i-get-user-ip-address-in-django

1. 세션이란?

웹 브라우저와 서버가 HTTP 프로토콜을 통해서 하는 모든 커뮤니케이션은 무상태(stateless)라고 합니다. 메시지가 완벽하게 각각 독립적이라는 뜻이다.

그렇기에 우리는 사이트와 특정 브라우저 사이의 state를 유지시키기 위해서 세션을 사용한다. 세션은 매 브라우저마다 임의의 데이터를 저장하게 하고, 이 데이터가 브라우저에 접속할 때 마다 사이트에서 활용될 수 있도록 한다. 세션에 연결된 각각의 데이터 아이템들은 'key'에 의해 인용되고, 이는 또 다시 데이터를 찾거나 저장하는데 이용된다.

클라이언트 별 정보를 브라우저가 아닌 웹서버에 저장하는 것

웹브라우저에 저장 : cookie

웹서버에 저장 : session

session의 라이프 사이클은 브라우저에 의존한다. 같은 브라우저를 사용하고 있다면 링크를 통해서 다른 사이트로 이동해도 session_id는 유지가 된다. 하지만 브라우저를 닫으면 사라진다.

Django는 세션을 활용할때, session_id를 포함하는 쿠키를 사용해서 세션을 알아낸다.

2.설정

세션사용설정은 프로젝트 settings.py에서 아래와 같이 INSTALLED_APPS 와 MIDDLEWARE 부분에 있다.

INSTALLED_APPS = [ ... 'django.contrib.sessions', ....

MIDDLEWARE = [ ... 'django.contrib.sessions.middleware.SessionMiddleware', ....

3. 사용

세션은 request.session으로 바로 사용할 수 있다. dictionary 형식으로 key값을 넣어주면 된다.

# Get a session value by its key (e.g. 'my_car'), raising a KeyError if the key is not present
my_car = request.session['my_car']

# Get a session value, setting a default if it is not present ('mini')
my_car = request.session.get('my_car', 'mini')

# Set a session value
request.session['my_car'] = 'mini'

# Delete a session value
del request.session['my_car']

4. Session의 원리

1. 유저가 웹사이트에 접속
2. 웹사이트의 서버가 유저에게 session_id를 부여
3. 저의 브라우저가 이 session_id를 cookie에 보존
4. 통신할때마다 session_id를 웹서버에 전송
5. session_id에 의해 웹사이트는 많은 접속 유저중 특정 유저를 인식할 수 있음

5.Cookie란

웹사이트에서는 cookie를 사용해 유저의 로그인 상태를 유지하거나 유저의 사이트 이용설정을 기억시킵니다.

6. 캐시(Cache)란?

리소스 파일들의 임시저장소. 같은 웹 페이지에 접속할 때 사용자의 PC에서 로드하므로 서버를 거치지 않아도 된다. 자주 사용되는 데이터들은 빠르게 접근 가능하게 cache에 넣는다.

캐시 순서 : 

1. URL이 오면, 그 페이지를 먼저 캐시에서 찾는다.
2. 캐시에 있다. -> 캐시된 페이지를 보여준다.
3. 캐시에 없다. -> 페이지를 가져오고 캐시에 저장하고, 보여준다.

7. 캐시 설정

pip install django-redis

Settings.py에 설정을 해준다.

CACHES = {
    'default': {
        'BACKEND': 'django_redis.cache.RedisCache',
        'LOCATION': 'redis://{URL}:6379',
    },
}

아래는 캐시를 사용하는방법이다.

from django.core.cache import cache

def get_post_count():
        cache_key = 'my_blog_post_count'
        count = cache.get(cache_key, None)
        if not count:
            count = self._get_post_count()
            cache.set(cache_key, count, 60 * 60)
        return count

cache.get()을 통해 캐시에 접근하고,

cache.set()을 통해 캐시를 저장한다.

캐시는 Key-Value구조이다.

cache.set할때 마지막 인자값은 캐시의 유효기간이다. 

8. Redis

Key - Value 기반의 인-메모리 데이터 저장소입니다. 그래서 쿼리를 따로 할 필요없이 결과를 바로 가져올 수 있습니다. 디스크에 데이터를 쓰는 구조가 아니라 메모리에서 데이터를 처리하기 때문에 속도가 빠르다.

싱글 스레드라서 한번에 하나의 명력어만 실행할 수 있다.

Redis의 데이터 구조

1. Strings : 단순한 키-값 매핑 구조입니다.

2. Lists : Array형식의 데이터구조입니다. List를 사용하면 처음과 끝에 데이터를 넣고 빼는 것은 속도가 빠르지만 중간에 데이터를 삽입할 때는 어려움이 있습니다.

3. Sets : 순서가 없는 Strings 데이터 집합입니다. Sets에서는 중복된 데이터는 하나로 처리하기 때문에, 중복에 대한 걱정을 할 필요가 없습니다.

4. Sorted Sets : 위의 Sets와 같은 구조이지만, Score를 통해서 순서를 정할 수 있습니다. Sorted Sets를 사용하면 Leaderboard와 같은 기능을 손쉽게 구현하실 수 있습니다.

5. Hashes : 키-값의 구조를 여러개 가진 object 타입을 저장하기 좋은 구조입니다.

참조 : 

https://developer.mozilla.org/ko/docs/Learn/Server-side/Django/Sessions

https://valuefactory.tistory.com/708

https://ryusae.tistory.com/7

https://lee-seul.github.io/django/2019/05/02/django-cache-framework.html

http://milooy.github.io/TIL/Django/django-cache.html#%E1%84%8F%E1%85%A2%E1%84%89%E1%85%B5

추가적인 Cache 종류

https://dingrr.com/blog/post/django-seo-%EB%8D%94-%EB%B9%A0%EB%A5%B4%EA%B2%8C-cache%EC%99%80-%EC%95%95%EC%B6%95

Redis 정리

https://brunch.co.kr/@jehovah/20