Redis 프로젝트의 지식 포인트는 무엇입니까?

프로젝트 하이라이트:

1. 분산형 Sesion을 사용하면 여러 서버가 동시에 응답할 수 있습니다.

2. Redis를 캐시로 사용하여 액세스 속도와 동시성을 높이고, 데이터베이스 부담을 줄이고, 메모리 태그를 사용하여 Redis 액세스를 줄입니다.

3. 정적 페이지를 사용하여 사용자 액세스 속도를 높이고, QPS를 개선하고, 페이지를 브라우저에 캐시하고, 프런트엔드와 백엔드를 분리하여 서버 부담을 줄입니다.

4. 메시지 대기열을 사용하여 비동기식 주문을 완료하고, 사용자 경험을 개선하고, 피크를 줄이고 트래픽을 줄입니다.

5. 보안 최적화: 이중 md5 비밀번호 확인, 플래시 종료 인터페이스 주소 숨기기, 인터페이스 전류 제한 및 브러싱 방지, 수학 공식 확인 코드.

주요 지식 포인트:

분산형 보기

플래시 세일 서비스의 실제 적용은 하나의 서버에만 배포되는 것이 아니라 여러 서버에 배포될 수도 있습니다. 이때 사용자가 첫 번째 서버에 로그인하면 첫 번째 요청은 첫 번째 서버로 이동하지만 두 번째 요청은 두 번째 서버로 이동하므로 사용자의 세션 정보가 손실됩니다.

해결책: 세션 동기화는 어떤 서버에 액세스하든 Redis 캐시 방법을 사용하고 특별히 Redis 서버를 사용하여 사용자의 세션 정보를 저장함으로써 세션을 얻을 수 있습니다. 이런 방식으로 사용자 세션은 손실되지 않습니다. (세션이 필요할 때마다 캐시에서 가져오기만 하면 됩니다.)

redis는 데이터베이스 부담을 덜어줍니다.

이 프로젝트에서는 사용자 정보 캐싱(분산 세션), 상품 정보 캐싱, 상품 재고 캐싱 등 캐싱 기술을 광범위하게 활용합니다. 주문 캐싱, 페이지 캐싱 및 객체 캐싱은 데이터베이스 서버에 대한 액세스를 줄입니다.

범용 캐시 키 캡슐화

한 가지 문제는 동일한 키 값이 존재할 수 있으므로 서로 다른 모듈의 캐시를 어떻게 구별할 것인가입니다.

해결 방법: 추상 클래스를 사용하여 BaseKey(접두사)를 정의하고 캐시 키의 접두사를 정의하고 만료 시간을 통해 캐시된 키를 캡슐화할 수 있습니다. 이를 다른 모듈이 상속받도록 하여, 모듈이 캐시에 저장될 때마다 캐시별 접두사가 추가되고, 서로 다른 만료 시간을 균일하게 설정할 수 있습니다.

페이지 정적화(앞뒤 분리)

페이지 정적화의 주요 목적은 페이지 로딩 속도를 높이는 것입니다. 제품 세부정보 및 주문 세부정보 페이지가 정적 HTML(순수 HTML)로 만들어집니다. 데이터는 서버에 요청하기 위해 ajax를 통해서만 수행되고 클라이언트 브라우저에 캐시될 수 있는 정적 HTML 페이지를 만들기만 하면 됩니다.

비동기 주문을 완료하는 메시지 대기열

메시지 대기열을 사용하여 비동기 주문을 완료하고, 사용자 경험을 개선하고, 피크를 줄이고 트래픽을 줄입니다.

아이디어:

1. 시스템 초기화, 제품 재고 수량 재고를 Redis에 로드합니다.

2. 백엔드는 플래시 판매 요청을 수신하고 Redis는 재고가 임계값에 도달하면 요청을 계속할 필요가 없으며 실패가 직접적으로 반환됩니다. 후속 요청으로 인해 시스템에 압력을 가할 필요가 없습니다.

3. 플래시 세일 주문이 형성되었는지 확인하고, 플래시 세일이 도착했는지 확인하고, 한 계정에서 여러 상품을 피하고, 플래시 세일이 반복되는지 확인합니다.

4. 재고가 충분하고 중복된 플래시 세일이 없습니다. 플래시 세일 요청이 캡슐화되고 메시지가 대기열에 추가되며 코드(0)가 프런트 엔드로 반환됩니다. 이는 대기열로 반환된다는 의미입니다. (반환되는 것은 실패인지 성공인지 판단할 수 없습니다.)

5. 프런트엔드에서 데이터를 받은 후 큐를 표시하고 제품 ID에 따라 요청 서버를 폴링합니다(1회마다 폴링을 고려함). 200ms).

6. 백엔드 RabbitMQ는 플래시 세일을 위해 MIAOSHA_QUEUE라는 채널을 모니터링합니다. 메시지가 있는 경우 실제 플래시 세일을 실행하기 전에 데이터베이스의 재고를 판단하고 여부를 결정해야 합니다. 플래시 세일을 반복한 다음 플래시 세일 거래를 실행합니다( 플래시 세일 거래는 원자적 작업입니다. 재고를 1씩 줄이고, 주문하고, 플래시 세일 주문을 작성합니다).

7. 이때 프런트엔드는 제품 ID를 기반으로 요청 인터페이스 MiaoshaResult를 폴링하여 제품 주문이 생성되었는지 확인합니다. 요청이 -1을 반환하면 플래시 세일이 실패했음을 의미하며, 반환되면 0은 대기열에 있음을 의미합니다. >0을 반환하면 제품 ID가 플래시 판매에 성공했음을 의미합니다.

보안 최적화

이중 md5 비밀번호 확인, 플래시 킬 인터페이스 주소 숨기기, 인터페이스 전류 제한 및 스와이프 방지, 수학 공식 확인 코드.

우아한 코드 작성

인터페이스의 출력 결과가 Result

잘못된 코드가 CodeMsg에 캡슐화되었습니다.

액세스 캐시가 키에 캡슐화되었습니다

프로젝트 어려움 및 문제 해결:

1 JMeter를 사용할 때. 스트레스 테스트를 위해 5000개의 스레드를 활성화했지만 시스템이 실행되지 않고 예외가 발생합니다

원인: 구성 파일에서 redis 구성 항목 poolMaxTotal을 수정하여 1000으로 설정합니다.

#redis 구성 항목

redis.poolMaxTotal=1000

redis.poolMaxldle=500

redis.poolMaxWait=500

2 캐시를 많이 사용하면 캐시 고장, 캐시 눈사태, 캐시가 발생합니다. 일관성 등 질문이 있습니까?

캐시 침투는 존재해서는 안 되는 특정 데이터를 요청하는 것을 의미합니다. 해당 요청은 캐시를 침투하여 데이터베이스에 도달합니다.

해결책: 존재하지 않는 데이터에 대해 빈 데이터를 캐시하고 해당 요청을 필터링합니다.

캐시 눈사태란 데이터가 캐시에 로드되지 않거나, 캐시된 데이터가 넓은 영역에서 동시에 실패(만료)되거나, 캐시 서버가 다운되어 많은 요청이 도달하는 현상을 말합니다. 데이터베이스.

해결책:

넓은 지역에서 캐시 만료로 인한 캐시 사태를 동시에 방지하기 위해 사용자 행동을 관찰하고 캐시 만료 시간을 합리적으로 설정할 수 있습니다.

캐시 서버 다운타임으로 인한 캐시 사태를 방지하기 위해 다음을 사용할 수 있습니다. 분산 캐시. 캐시의 각 노드는 데이터의 일부만 캐시하며, 노드가 다운되면 다른 노드의 캐시를 계속 사용할 수 있습니다.

시스템 시작 후 바로 캐시되지 않는 대량의 데이터로 인한 캐시 사태를 방지하기 위해 캐시 예열을 수행할 수도 있습니다.

예: 먼저 세션 캐시와 같은 다양한 캐시에 대해 서로 다른 만료 시간을 설정합니다. userKey 접두사에서 설정은 30분 후에 만료되며 사용자가 응답할 때마다 캐시 시간이 업데이트됩니다. 각 세션 획득은 30분씩 연장되므로 캐시 만료 확률은 상대적으로 낮습니다.

캐시 일관성을 유지하려면 데이터가 업데이트되는 동안 캐시된 데이터가 실시간으로 업데이트될 수 있어야 합니다.

해결책:

데이터가 업데이트되면 즉시 캐시를 업데이트합니다. 먼저 캐시에서 읽기를 시도하고, 데이터를 읽을 수 없으면 데이터를 읽은 후 바로 반환하고, 데이터베이스를 읽고, 캐시에 데이터를 씁니다. 반품.

캐시를 읽기 전에 먼저 캐시가 최신인지 확인하세요. 최신이 아닌 경우 먼저 업데이트하세요. 데이터를 업데이트해야 할 경우 먼저 데이터베이스를 업데이트한 후 해당 데이터를 무효화(삭제)하세요. 캐시.

3. 캐시를 과도하게 사용하면 캐시 서버에 많은 부담이 가해집니다. Redis 액세스를 줄이는 방법을 고민하시나요?

redis가 인벤토리를 미리 줄이면 isOvermap이 메모리 표시로 메모리에 유지됩니다. 인벤토리가 없으면 true로 설정됩니다. 각 플래시세일 업체가 Redis에 접속하기 전, 맵마크를 확인하세요. true이면 재고가 없다는 의미이며, Redis 서버에 요청하지 않고 바로 실패를 반환합니다.

4. 동시 요청이 많은 비즈니스 시나리오에서 많은 요청이 처리하기에 너무 늦거나 심지어 요청이 쌓이는 경우도 있나요?

요청을 비동기적으로 처리하는 데 사용되는 메시지 대기열. 요청이 들어올 때마다 요청을 처리하는 대신 메시지 대기열에 넣은 다음 백그라운드에 리스너를 배치하여 메시지가 오면 비즈니스 로직이 실행됩니다. 이렇게 하면 여러 요청이 동시에 작동할 때 너무 많은 데이터베이스 연결이 발생하는 예외가 방지됩니다.

5. 사용자가 반복 주문을 할 수 없도록 하려면 어떻게 해야 하나요?

해결책: 플래시 판매 주문 테이블(참조는 사용자 ID 및 상품 ID)에 고유 인덱스를 생성하여 첫 번째 레코드를 삽입할 수 있지만 두 번째 레코드는 오류가 발생하고 트랜잭션을 통해 롤백됩니다. 사용자가 동시에 여러 기록을 발행하는 것을 방지하기 위해 요청 처리, 여러 제품의 즉시 판매.

고유 인덱스는 데이터베이스 테이블 구조의 필드에 고유 인덱스를 추가한 후 데이터베이스가 저장 작업을 수행할 때 해당 데이터가 데이터베이스에 이미 존재하는지 여부를 확인하는 경우에만 삽입 작업을 수행할 수 있습니다. 데이터가 존재하지 않습니다.

이것은 작은 기술이지만 실제로 비즈니스 개발에서는 매우 실용적인 기술입니다. 예를 들어 동시성이 높은 비즈니스에서 데이터베이스는 데이터가 두 개의 동일한 주문 번호를 동시에 삽입하는 것을 어떻게 방지할 수 있습니까? 물론 고유 인덱스를 추가하는 것은 가장 빠른 방법 중 하나입니다. 물론 인덱스를 추가할지 비즈니스 코드를 통해 해결할지는 회사의 비즈니스에 달려 있습니다

6.

과매도 시나리오: 여러 사용자가 요청을 읽었을 때 제품 재고가 충분하다는 것을 확인한 후 동시에 요청을 시작하여 재고를 줄이기 위한 플래시 세일 작업을 수행하여 재고가 마이너스로 감소합니다. 숫자.

가장 간단한 방법은 재고를 줄일 때 데이터베이스를 업데이트하고, ReduceStock(GoodsVo productsvo) 메소드에서 sql에 stock_count > 0을 하나 더 추가하고, 과매도 문제를 방지하기 위해 데이터베이스 기능을 사용하는 것입니다. 여전히 0보다 큰 경우, stock_count를 읽은 다음 1만큼 줄입니다. @Update("update miaosha_goods set stock_count=stock_count-1 where products_id=#{goodsId} and stock_count>0")

public void ReduceStock(MiaoshaGoods 상품)

7. 페이지 정적화 과정은 무엇이며 브라우저 캐시란 무엇인가요?

클라이언트 브라우저에서 HTML 정적 페이지를 캐시하면 Ajax 비동기 호출 인터페이스를 통해 데이터만 가져옵니다. 데이터의 일부만 상호 작용하므로 대역폭이 줄어들고 사용자 액세스 속도가 빨라집니다.

브라우저 캐싱은 요청된 웹 리소스(예: HTML 페이지, 그림, js, 데이터 등)의 복사본을 브라우저에 저장하는 것입니다. 캐시는 들어오는 요청에 따라 출력 콘텐츠의 복사본을 유지합니다. 다음 요청이 올 때 동일한 URL이면 캐시는 캐싱 메커니즘에 따라 복사본을 직접 사용하여 액세스 요청에 응답할지 아니면 요청을 다시 원본 서버로 보낼지 결정합니다. 더 일반적인 것은 브라우저가 웹 사이트에서 방문한 웹 페이지를 캐시한다는 것입니다. URL 주소를 다시 방문할 때 웹 페이지가 업데이트되지 않은 경우 웹 페이지는 다시 다운로드되지 않지만 로컬에서는 캐시된 웹페이지가 직접 사용됩니다. 웹사이트에서 리소스가 업데이트되었음을 ​​명확하게 식별하는 경우에만 브라우저가 웹페이지를 다시 다운로드합니다.

8. 플래시세일 아키텍처 디자인 컨셉은?

트래픽 제한: 소수의 사용자만 즉시 종료에 성공할 수 있으므로 대부분의 트래픽을 제한해야 하며 트래픽 중 극히 일부만 서비스 백엔드에 들어갈 수 있습니다.

플래시 세일을 진행하면, 러시 세일이 시작되면 순간적으로 사용자가 몰려 성수기가 됩니다. 따라서 피크컷 대책을 강구해야 한다. 높은 피크 트래픽은 시스템을 압도하는 중요한 이유이므로 순간적인 높은 트래픽을 일정 기간 동안 안정적인 트래픽으로 전환하는 방법도 플래시 세일 시스템 설계에 있어서 매우 중요한 아이디어입니다. 피크 클리핑을 달성하기 위해 일반적으로 사용되는 방법에는 캐싱 및 메시지 미들웨어와 같은 기술의 사용이 포함됩니다.

비동기 처리: 플래시 세일 시스템은 동시성이 높은 시스템입니다. 비동기 처리 모드를 사용하면 시스템 동시성 양을 크게 늘릴 수 있습니다. 실제로 비동기 처리는 피크 클리핑을 달성하는 방법입니다.

메모리 캐시: 플래시 세일 시스템의 가장 큰 병목 현상은 일반적으로 데이터베이스 읽기 및 쓰기입니다. 데이터베이스 읽기 및 쓰기는 디스크 IO에 속하므로 일부 데이터 또는 비즈니스 로직을 메모리 캐시로 전송할 수 있으면 성능이 매우 낮습니다. 효율성이 크게 향상될 것입니다.

확장 가능: 물론 더 많은 사용자와 더 큰 동시성을 지원하려면 트래픽이 발생하면 시스템을 확장할 수 있도록 시스템을 설계하는 것이 가장 좋습니다. Taobao 및 JD.com과 같은 Double Eleven 이벤트 기간에는 거래 피크에 대처하기 위해 많은 수의 기계가 추가됩니다.

9. 플래시 세일 시스템 아키텍처 디자인 아이디어?

시스템 업스트림에서 요청을 차단하여 다운스트림 압력을 줄입니다. 플래시 킬 시스템은 동시성이 많은 것이 특징이지만 성공적인 플래시 킬 요청의 실제 개수는 매우 적으므로 전면에서 차단하지 않으면 종료되면 데이터베이스 읽기-쓰기 잠금 충돌이 발생하고 최종 요청 시간이 초과될 수 있습니다.

캐시 사용: 캐시를 활용하면 시스템 읽기 및 쓰기 속도를 크게 향상시킬 수 있습니다.

메시지 대기열: 메시지 대기열은 대량의 동시 요청을 차단할 수 있습니다. 이는 또한 비동기 처리 프로세스이기도 하며 자체 처리 기능을 기반으로 비즈니스 처리를 위해 메시지 대기열에서 요청 메시지를 적극적으로 가져옵니다.

10. 재고가 줄어들었는데 사용자가 결제를 하지 않으면 어떻게 재고를 복구하고 계속해서 급매에 참여할 수 있나요?

최대 결제 시간을 30분 등으로 설정하고 예정된 작업이 있나요? 백그라운드에서(타이머 사용) 회전이 30분을 초과하면 지불할 주문(주문 상태는 데이터베이스에서 결정됨)이 주문이 종료되고 재고가 복원됩니다.

위 내용은 Redis 프로젝트의 지식 포인트는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!