이전 공장에서는 이렇게 사용했습니다.

• 사용자 정보 등의 엔터티 데이터는 MySQL의 2차 캐시로 protobuf 인코딩으로 memcached에 저장되며 만료일은 1주일입니다.
• 사용자의 구독 목록 등 목록 데이터는 redis에 저장되며, 해당 데이터도 MySQL에 백업되어 있습니다. 단, redis가 이를 읽을 수 없으면 MySQL에서 다시 읽을 수 없습니다.

요약:

• Redis는 풍부한 데이터 구조를 갖고 있으며 세트, 목록 또는 순서가 지정된 테이블을 저장하는 데 적합합니다
• 당시 Redis는 상대적으로 완전한 분산 솔루션이 없었기 때문에 대규모 엔터티 데이터를 저장하지 않으려고 노력했습니다. (물론 사용자 수가 급격히 증가함에 따라 나중에 해시 키를 사용하여 의사 분산을 구현했습니다.)
• memcached는 redis보다 상대적으로 간단하고 빠르며 엔터티 데이터를 저장하는 데 적합합니다. 그러나 당시 직면한 문제는 json의 패키징과 파싱이 병목 현상이 된다는 점이었기 때문에 나중에 모두 memcached로 교체했습니다. protobuf

키/값 외에 더 많은 데이터 유형을 지원해야 하거나 저장된 데이터를 삭제할 수 없는 경우 Redis를 사용하는 것이 더 적합합니다. 단순히 데이터를 캐시하기만 한다면 memcached를 사용하는 것이 더 적절합니다. 즉, 이에 비해 저장에는 redis가 더 적합하고, 캐싱에는 memcache가 더 적합합니다.

频繁查询과 变化频率不是太高가 필요한 모든 것에는 이 두 가지가 유용합니다

Stackoverflow의 누군가가 "Memcached는 Redis에 비해 공룡인가요?"라는 질문을 했고, Redis 작성자가 답변을 주었습니다(http://stackoverflow.com/questions/2873249/is-memcached-a-dinosaur- Redis와 비교). 전체적으로 둘 다 성능이 매우 좋기 때문에 어느 쪽이 더 높은 성능을 낼지 고민할 필요가 없습니다. 하지만 redis에서 제공하는 지속성 및 데이터 동기화 메커니즘은 memcached에서는 사용할 수 없으므로 지속성을 원할 경우 redis만 사용할 수 있습니다. 또한 간단한 키-값 저장에는 memcached로도 충분하지만 hash, list, set, zset 등과 같은 고급 데이터 구조를 사용하려는 경우 redis가 이러한 유형을 제공하므로 사용하기 더 편리합니다.