今天忽然想到一个问题
对于高并发条件下，后台对数据的更新和实例化是怎么进行的？
1、直接插入数据库，然后更新缓存？
这样这个更新操作将会有IO阻塞风险吧、
2、直接更新缓存，然后使用消息队列更新数据库？
只能延缓IO阻塞，并不能避免
3、直接更新缓存，定时批量更新数据库
这样IO的问题是解决了，但是数据在缓存里感觉很慌。
也没实践过真正的高并发系统，这种情况怎么解决？
----------补充----------
总结一下
就是已知直接插入和更新数据库将面临IO阻塞的风险，那么将数据最终实例化到数据库的过程是怎么样的。
天蓬老师2017-04-18 10:25:14
중간 풀, 캐시, 레디스, 그게 무슨 뜻인가요?
풀이 막히면 + 처리 장치를 사용하는 것이 더 좋습니다. 이것은 마치 입이 작은 체리를 먹는 것과 같습니다. 냄비가 아무리 크더라도 체리 입이 있는 마른 남자 10명이나 입을 벌리고 있는 뚱뚱한 남자 10명을 찾으세요.
업데이트:
으아악
高洛峰2017-04-18 10:25:14
먼저 캐시에 쓴 다음 디스크에 지속시킵니다. 작성자는 캐시 서버가 중단되어 데이터가 손실될까 봐 걱정하고 있나요?
일반적인 프로덕션 환경에서는 애플리케이션 서버, 데이터베이스 서버, 캐시 서버 등 적어도 하나가 실패하면 다른 하나가 독립형 서버가 되어서는 안 됩니다. 정상적인 로드 조건에서는 두 대의 머신이 동시에 실패하는 것은 물론이고 단일 머신이 실패할 확률도 그리 높지 않으며 Redis를 클러스터로 사용할 수 있으므로 배포가 정상이라면 다음과 같은 가능성이 있습니다. 이 문제는 매우 낮습니다.
포스터를 보고 CAP 이론을 배울 수 있습니다. 설명에 따르면 달성하려는 효과는 CAP에서 설명하는 것과 유사합니다.
巴扎黑2017-04-18 10:25:14
초대해 주셔서 감사합니다만, 저는 이 문제를 다룬 경험이 없어서 이론적으로만 이야기할 수 있습니다
우선 캐시 디렉토리는 대기 시간을 연장하기 위해 처리할 수 없는 것들을 임시로 저장하는 것입니다. 예를 들어, 갑자기 10분 동안 높은 동시성이 발생하면 처리해야 할 문제가 누적됩니다. 캐싱을 통해 10분짜리 콘텐츠를 30분 안에 처리할 수 있습니다. 물론 여기에는 가정이 있습니다. 즉, 10분간의 높은 동시성 후에는 처리해야 할 문제가 너무 많지 않을 것이라는 가정입니다.
그렇다면 후속 유입 속도가 여전히 매우 높아 전혀 처리할 수 없다면 어떻게 될까요? 최근에 배압이라는 단어를 배웠습니다. 배압을 처리하는 가장 직접적인 방법은 콘텐츠의 일부를 삭제하는 것입니다. 물론, 데이터의 경우 절대 버리고 싶지 않기 때문에 처리 효율 측면에서 방법만 생각하면 되므로 확장, 클러스터링, 오프로딩 등 동시 처리 기술을 많이 활용하세요
위 내용은 개인적인 이해로 구어체를 사용하여 전문적이지 않으므로 참고용으로만 사용하시기 바랍니다
ringa_lee2017-04-18 10:25:14
이것은 큰 문제이며 다양한 시나리오에서 높은 동시성을 위한 다양한 솔루션이 있습니다.
예를 들어 웨이보(Weibo)는 동시성이 높으며, 금융 시스템도 동시성이 높을수록 전자는 정보가 손실되더라도 큰 문제가 되지 않는 반면, 후자는 정보 지속성에 대한 엄격한 요구 사항을 갖고 있습니다.
그리고 이것은 동시성 읽기인가, 동시성 쓰기인가?
일정 기간 내에 높은 동시성을 유지하는 건가요, 아니면 지속적으로 높은 동시성을 유지하는 건가요?
전제 조건을 명시하지 않고 어떻게 대답할 수 있나요?
PHPz2017-04-18 10:25:14
실제로 좋은 질문입니다.
읽기 작업이라면 문제가 없을 것입니다. 대부분의 최신 데이터베이스의 경우 쓰기 시 데이터가 대부분 업데이트되기 때문입니다(쓰기 시 복사). 현재 대부분의 주류 데이터베이스는 이미 데이터베이스에서 매우 잘 수행될 수 있기 때문입니다. 높은 동시성은 동시 읽기를 지원합니다. 핵심은 쓰기 작업에 대한 데이터 일관성을 보장하고 데이터가 업데이트될 때 캐시도 업데이트되도록 하는 방법입니다. 이는 데이터베이스의 ACID 이론에 의해 보장됩니다.
쓰기 작업의 경우 현재 인터넷 데이터베이스의 ACID가 특히 일관성이 있습니다. 이는 기존의 일관성이 아닌 데이터의 궁극적인 일관성을 의미하므로 사용자 요청에 신속하게 응답할 수 있습니다. 이 글은 CAP에 대한 소개입니다. http://blog.csdn.net/starxu85... 참고용
귀하의 질문은 실제로 "Double Eleven" 플래시 세일에 해당되며, 수천명 이상이 참여하고 싶으시다면 제품을 하나 더 가져오면 데이터베이스가 자주 쓰기를 하면 필연적으로 테이블이 잠기고 다른 작업이 차단됩니다. 다행히 일부 데이터베이스에는 이 시나리오에 대한 성능 최적화 기능이 있습니다(예: MySQL 기반의 새로운 오픈 소스 AliSQL은 다음과 같습니다. 플래시 판매). 이러한 요청은 데이터베이스 캐시에 메시지 대기열을 추가한 다음 한 번에 업데이트하여 높은 동시성을 보장할 수 있습니다. 물론 중간에는 고수위와 저수위, 스레드 풀 등 다른 이론적 뒷받침이 있습니다.
위 내용은 전문 DBA가 아닌 저의 소박한 의견입니다. 이론적 오류가 있으면 추가해도 좋습니다.
伊谢尔伦2017-04-18 10:25:14
포스터에서 제기된 이 문제는 대부분의 애플리케이션에서 일반적이며 시스템의 동시성이 높은지 여부와는 거의 관련이 없습니다.
캐싱에 대한 간략한 이야기(2)
먼저 캐시에 대해 이야기하겠습니다. 대부분의 경우 우리 프로그램은 실제로 캐시에 대해 "약한 종속성"을 가져야 합니다. 이 "약한 종속성"을 이해하는 방법은 무엇입니까?
제가 이해한 바는 우리의 데이터가 정확하다는 것입니다. 대부분의 경우 캐시에 있는 데이터로 판단되지 않습니다. 예를 들어 "제품 세부 정보 페이지의 제품 가격"은 실제로 캐시에 있는 데이터이지만 생성할 때의 총 가격입니다. 물론 대부분의 경우를 말하는 것이지만, 데이터의 정확성이 그렇게 엄격하지 않은 경우도 있습니다(예를 들어 추상화, 위로금 개수 등). 일반 비즈니스에 따르면 위문 상품은 구매 시 5위안 할인 등 판매자에게 유리한 추가 혜택이기 때문에 캐시에 사전에 캐시를 보관하고 후속 비즈니스 요구 사항을 캐시에 있는 경품으로 직접 전달할 수 있습니다. 100. 이때 캐시가 실패하더라도 다시 새로고침해도 가맹점에 미치는 영향은 거의 없습니다)
데이터베이스와 캐시 간의 강력한 일관성을 보장할 수 있는 방법이 있나요? 이 프로세스에는 분산 트랜잭션이 포함되며 양측 모두 X/Open XA 프로토콜을 구현하지만 redis 이 프로토콜은 아직 구현되지 않았으며 이로 인해 전체 배포에서 리소스를 잠그는 데 오랜 시간이 필요하므로 이 방법은 권장되지 않습니다(최종 일관성으로 인해 일정 기간 동안 데이터 불일치가 발생할 수 있으며 이로 인해 Redis의 복잡성이 크게 증가합니다)
따라서 일반적인 상황에서는 일반적으로 먼저 데이터베이스 데이터가 올바른지 확인한 다음 캐시를 동기식/무효성/비동기식으로 업데이트합니다
