예약된 인벤토리 캐싱 기능을 위해 Redis를 사용하는 방법

1. 사업 배경

저희 회사 프로젝트의 배경을 소개하는 것을 피하기 위해 이 질문을 시험지 문제와 비교하기로 했습니다. 사업의 세부 사항은 신경 쓸 필요가 없습니다 ~ 제목 만보세요 :

당신이 특정 국가에서 최고의 수집가이고 연속 가치가있는 다양한 보물을 손에 가지고 있다고 가정 해보십시오. 어느 날 당신은 당신의 컬렉션이 지루해지고 있다고 느끼고 이러한 귀중한 품목을 현금으로 판매하기로 결정할 수도 있습니다.

하지만 이 귀중한 보물을 야채 시장에 팔기에는 가격이 너무 낮습니다. "인터넷+" 시대에는 물론 다른 판매 방법을 사용해야 합니다. 300개의 방이 있는 건물(001~300번)이 귀하의 이름으로 되어 있고, 각 방에는 매일 비밀번호로 잠긴 금고가 있습니다. (12월 1일부터 12월 31일까지) 최고의 "최고의 보물"(A급 보물이라고도 함) 300개를 선택하여 이 300개 방의 금고에 넣습니다. 방에 놓을 보물은 이미 결정되었습니다. 보물을 구매하시려는 분은 최소 하루 전에 온라인으로 예약을 하신 후, 예약번호를 이용해 금고를 열고 상품을 수령하셔야 합니다. 비축하지 않은 보물은 귀하가 다시 가져갈 것이며 더 이상 판매되지 않을 것입니다.

이러한 온라인 예약 시스템을 만들려면 프런트 엔드 인터페이스는 아마도 다음과 같을 것입니다.

위 그림에는 세 가지 컨트롤을 채워야 합니다. 클릭하면 선택 상자가 나타납니다. 이제 문제는 한 방에 보물이 하나만 있고 두 번 예약할 수 없다는 것입니다. 구매자가 보물 유형과 객실 번호를 선택한 후 예약 날짜를 선택할 때 날짜 선택 상자에 몇 가지 프롬프트 정보를 제공하는 것이 좋습니다. 예를 들어 12월 3일에 051호실이 예약되었는데, 다른 사용자가 051호실을 선택했다고 하면 날짜 선택창이 뜨는데 12월 3일은 선택 불가로 설정되어 있어야 합니다. 아래와 같이(12월 3일은 "missing"으로 표시됨):

그렇다면 이렇게 간단한 인벤토리 시스템을 어떻게 Redis에 저장할 수 있을까요?

2. 재고 관리 솔루션(Redis)

우리의 초기 아이디어는 우리의 재고가 거대한 3차원 배열로 간주될 수 있다는 것입니다. 여기서 첫 번째 차원은 보물 유형을 나타내고, 두 번째 차원은 방 번호를 나타내고, 세 번째는 차원은 예약 날짜를 나타냅니다. Redis는 문자열, 해시, 목록, 집합 및 정렬 집합의 5가지 저장소 유형을 제공합니다. Hash 유형을 사용하여 현재 시나리오에서 데이터를 저장할 수 있습니다. 왜냐하면 그것이 우리의 요구 사항을 충족할 수 있고 Set 유형도 실행 가능한 옵션이기 때문입니다.

Redis의 키는 보물 유형 + 방 번호로 설정됩니다(예: A:205, A는 최고의 보물, 205는 방 번호). Redis의 값은 해시 유형이며 해시 키는 날짜(예: 2016-12-05), 해시 값은 true 또는 false로 예약 여부를 나타냅니다. 다이어그램으로 표시:

룸 A 카테고리 158이 12월 8일에 예약된 경우

Redis 값 —&mdash 테이블 ['2016-12-08'=> ; 1]

1 2 3

Redis 키로 저장됩니다. —— A:158Redis Key —— A:158   Redis Value —— hash table ['2016-12-08' => 1]

🎜🎜🎜

3. 고급 시나리오 및 재고 관리 솔루션

클래스 A 일급 보물의 출시가 뜨거운 환영을 받았으며 출시 후 얼마 지나지 않아 많은 주문이 접수되었습니다. 많은 중산층이 수집에 관심을 갖고 있지만 높은 가격 때문에 꺼리는 경우가 많습니다. 그래서 당신은 소장품 중에서 B형 보물을 선택하게 됩니다. A형 보물보다 약간 열등하지만 가격이 더 합리적이어서 "우수한 보물"이라고도 불립니다.

A형보다 B형에 보물이 더 많기 때문에, 이 300개의 방에서는 각 방에 금고를 하나씩 놓을 예정입니다. B형 보물을 각 상자에 넣으세요. 예약되지 않은 보물은 이 시간 이후에 회수되며 다음 시간 동안 보물로 교체됩니다. 구매자가 예약을 한 후, 예정된 시간에 따라 보물을 픽업하게 됩니다. 카테고리 B 보물의 경우 예약 시스템에 픽업 시간이라는 추가 옵션이 있습니다. 아래 사진과 같이

이제 추가적으로 정해진 조건(픽업 시간)이 있으니, 재고 보관을 할 때 대략적으로 생각해보면 재고는 사실 큰 4차원 배열입니다. 이 문장은 다음과 같이 다시 쓸 수 있습니다. 4차원 정보에는 보물 유형, 객실 번호, 예약 날짜 및 픽업 시간이 포함됩니다. 이런 종류의 보물을 Redis에 어떻게 저장하나요?

사실 잘 생각해보면 Class A 최고 품질의 보물을 저장할 때 Redis에 저장하는 것은 차원 낭비입니다.

실제로는 하나의 hashValue만 사용하여 미리 정해진 상태를 저장했기 때문에 차원이 발생했습니다. 정보가 낭비됩니다. 픽업시간이 모두 정시, 즉 0~1시, 1~2시,..., 23~24시라는 점을 고려하면 하루 총 24가지 상황이 발생하며, 따라서 예약된 항목 시간을 나타내기 위해 이진 정수를 완전히 사용할 수 있습니다. 예를 들어 1은 0~1점을 나타내고, 2는 1~2점을 나타내고, 4는 2~3점을 나타내고,...,

23~24점은 2의 23승(8388608)으로 나타낼 수 있습니다. 여러 기간을 예약하려면 해당 값에 대해 논리적 OR 연산만 수행하면 됩니다.

이렇게 하면 Redis 구조는 다음과 같습니다.

예를 들어 103호, Class B 보물은 12월 5일과 6일 오전 8시부터 오전 12시까지 예약되어 Redis에

로 저장됩니다. Redis 값 —— > 코드><code>'2016-12-05'=> 3840, '2016-12-06'=> ]

1 2 3

Redis 키 —— B:103Redis Key  —— B:103   Redis Value —— hash table ['2016-12-05' => 3840, '2016-12-06' => 3840]

🎜🎜🎜

B 카테고리 보물의 경우 새로 예약할 때 원래 해시 값을 먼저 꺼내고 새로운 예약 픽업 시간으로 논리 OR 연산을 수행한 다음 그 결과를 카테고리 A와 달리 Redis에 다시 써야 합니다. 보물과 같습니다. , hSet을 직접 호출하여 해시 값을 설정합니다. 예약 취소 시 원래 해시 값을 먼저 빼내고 해시 값에서 취소할 기간을 뺀 후(배타적 OR + 논리 AND 연산) 추가합니다. 남은 예정된 픽업 시간은 Redis에 다시 기록되며 hDel을 직접 호출하여 삭제할 수 없습니다.

4. 고급 및 재고 관리 계획

B등급 보물 출시 이후 귀하의 비즈니스는 이전보다 훨씬 더 인기를 얻었습니다. 그래서 새로운 수요가 다시 생겼습니다. 이제 이 도시를 찾는 사람들은 기념품을 가져오고 싶어하는 많은 관광객, 학생 및 저축이 없는 사람들이 있습니다. B형 보물의 가격은 A형 보물의 가격보다 약간 낮지만, 이런 사람들에게는 여전히 약간 비싼 편입니다. 따라서 귀하는 가장 저렴한 보물(카테고리 C 보물)을 판매하기로 결정했습니다.

이 300개의 방 중에서 Type C 보물이 가장 많은 수를 저장하므로 각 방에 Type C 보물을 보관하기 위해 특별히 100개의 보물 상자를 추가합니다. 이 100개의 보물상자에는 1번, 2번,..., 100번이 매겨져 있습니다. 마찬가지로, 하루 중 매 시간마다 300개의 방 각각에 있는 100개의 보물 상자에 C 유형 보물을 넣게 됩니다. 즉, 건물 전체가 매시간 30,000개의 C 유형 보물을 업데이트한다는 의미입니다. 아무도 예약하지 않으면 보물은 다음 시간에 교체됩니다. 마지막으로, 모든 사람의 요구가 충족될 수 있습니다.

C형 보물의 경우 예약 인터페이스는 다음과 같습니다.

다른 예약 조건을 추가했습니다. 현재 재고보관 문제에 직면해 있습니다. 평소와 마찬가지로 이 인벤토리는 실제로 보물 유형, 객실 번호, 예약 날짜, 픽업 시간 및 보물 상자 번호가 각각 1차원을 차지하는 큰 5차원 배열입니다. 이전에 Redis의 용량을 모두 사용했습니다. 이제 데이터를 저장하려면 어떻게 해야 합니까?

이번에는 Redis 인벤토리 스토리지가 비즈니스 특성과 결합되어야 합니다. 우선 보물상자 번호와 픽업 시간이라는 두 가지 차원은 값 범위가 너무 많지 않습니다. 보물 상자 번호는 100개뿐입니다. 그냥 해시 값을 길이가 100인 배열로 변경하고 배열의 각 위치를 지정하면 됩니다. INT가 포함되어 있습니다. 유형에 표시된 픽업 시간이 충분합니다. 하지만 해시 값은 문자열만 가능합니다... 따라서 배열 직렬화 작업을 수행한 다음 읽을 때 다시 역직렬화해야 합니다. 다행스럽게도 길이가 100에 불과하므로 직렬화 효율성이 시스템의 병목 현상이 되지는 않습니다.

보관방법은 : 12월 23일과 24일 258호 C형 보물 중 97번과 99번 보물상자를 오전 11시부터 오후 1시까지 예약해두었습니다

Redis 값 —— 23'=> '[97 => 6144, 99 => 6144]', ' 2016-12-24'=> '[97 => 6144, 99 => 6144]'] code>

1 2 3

Redis 키 —— C:258Redis Key —— C:258   Redis Value —— hash table ['2016-12-23' => '[97 => 6144, 99 => 6144]', '2016-12-24' => '[97 => 6144, 99 => 6144]' ]

🎜🎜🎜

6144의 바이너리 표현은 "110000000000"이며, 해시 값은 배열 직렬화 후의 문자열입니다. 실제 프로젝트에서는 json 형식을 사용할 수 있습니다. 좋습니다. 이제 Redis에는 세 가지 유형의 보물을 저장할 수 있는 저장소가 생겼습니다.

C 카테고리 보물의 경우 사용자가 예약을 취소하거나 새로운 예약을 추가할 때 단순히 hSet, hDel을 호출하여 설정을 덮어쓰고 삭제하는 것도 불가능합니다. 이미 예약된 상황을 꺼내야 합니다. 이미 예정된 픽업 시간으로 조정하세요.

5. 저장소 최적화

인벤토리는 이론적으로 다차원 배열입니다. 우리가 하는 주요 작업은 각 차원을 합리적으로 저장하고 추가, 삭제 및 쿼리를 쉽게 만드는 것입니다. 메모리 절약의 관점에서 볼 때 처음에 아무도 예약하지 않은 경우 Redis는 완전히 비어 있을 수 있습니다. A급 보물의 경우 해시 값이 false이고 해당 Redis 키나 해시 키가 전혀 없습니다. . 효과적인.

또한, 보물 유형과 방 번호를 결합하여 Redis 키를 만들면 Redis의 보물 인벤토리와 관련된 키의 수가 더 많아지므로 이러한 키의 통합 관리를 용이하게 하기 위해 Redis 캐시를 하나 더 추가할 수 있습니다. 특히 보물 인벤토리와 관련된 모든 redis 키 값은 아래 그림에 나와 있습니다. 이 경우, Hash 데이터 타입을 사용하는 대신 Set 데이터 타입을 사용하는 것이 요구사항을 충족할 수 있다는 점에 유의해야 한다. 왜냐하면 Set 데이터 타입의 추가, 삭제, 수정, 조회의 복잡도가 O(1)이기 때문이다. Redis에 이미 존재하는 모든 인벤토리 키 값을 저장합니다.

이렇게 하면 어느 날 특별한 상황이 발생하여 모든 인벤토리 관련 캐시를 지워야 하는 경우 모든 인벤토리 키를 쉽게 꺼내서 삭제할 수 있다는 장점이 있습니다. 또 다른 이점은 지속적인 확장을 위한 아이디어를 제공한다는 것입니다... 현재 가장 복잡한 상황은 총 5차원의 C형 보물이라고 상상해 보세요. 미래에 보물을 판매하기 위해 더 이상 한 건물의 300개 방을 사용하지 않고 여러 건물을 사용한다고 가정하면 사용자는 주문할 때 건물 번호라는 또 다른 차원을 추가해야 합니다. 이러한 상황이 발생하면 건물 번호에 설정된 추가 인벤토리 키를 완전히 줄여 발생할 수 있는 더 복잡한 상황에서 확장성을 보장할 수 있습니다.

이번 확장 이후에는 새로운 예약 기록을 추가할 때마다 해당 Redis 키 값이 인벤토리 키 세트에 이미 존재하는지 확인해야 합니다. 존재하지 않는 경우에는 Redis 키 값을 인벤토리에 추가해야 합니다. 키 세트. 삭제 작업도 비슷합니다.

위 내용은 예약된 인벤토리 캐싱 기능을 위해 Redis를 사용하는 방법의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!