시스템이 높은 동시성을 지원하는 방법 : 사람들이 무엇을 해야할지 특정 문제에 대해 물었을 때 많은 사람들이 인터뷰?
학생들의 대부분은 문제가 단순히 사실, 본질은 정말 높은 동시 시스템이 베일을 성질 경험하지 않습니다 어디에서 시작해야할지 모르고 대답을 생각 아무것도하지 않았다 물었다.
어떤 프로젝트 경험을 저기 관련되어 있기 때문에, 우리는 진정한 경험과 답변의 집합의 경험에서 자신을 추출 할 수 없습니다 것입니다, 그들은 너무 복잡한 시스템에서 나오는 방법의 체계적인 박람회는 높은 동시을 지원합니다.
이 문서에 대한 이러한 관점은 잠시이 문제로 절단에서 그래서, 우리는 어떻게 대처하는 가장 간단한 아이디어를 사용하는 방법을 가르칩니다.
물론, 여기에 첫 번째 명확한 전제 : 고도의 동시성 시스템은 다르다. 두 번째 동시 미들웨어 시스템, 요청 수천의 초 순간 스파이크 승진 시스템 수백 당 백억 요청 매일 게이트웨이 시스템 당 예를 들어 메가 비트하십시오.
그들이 때문에 각 시스템의 서로 다른 특성의 높은 동시성 처리, 그래서 아키텍처를 처리하는 경우는 동일하지 않습니다.
비즈니스 시나리오가 다른 뒤에 있기 때문에 또한, 높은 동시성 시나리오에서 주문 시스템, 상품 시스템, 재고 시스템 아키텍처 설계 등 전자 상거래 플랫폼은 다르다.
따라서이 문서는 당신이 면접관 大眼瞪小眼와 인터뷰에서이 질문을하지 않도록 그것은 복잡한 아키텍처 설계를 포함하지 않는, 당신이 생각 같은 질문에 대한 답변을 제공하기 위해 주로이다.
특히 면접이 문제에 정말 좋은 대답에, 우리는 당신이이 문서의 생각을 참조하는 것이 좋습니다, 당신의 손은 건축 연습에 관련된 일을하는 것이 가장 시스템의 생각이 더 인 책임이있다.
1, 먼저 간단한 시스템 아키텍처를 고려
시스템이 그냥 데이터베이스와 연결된 뒤에 기계에 배포하기 시작한다고 가정하면, 데이터베이스가 단일 서버에 배포됩니다.
심지어 현실적 할 수 있습니다, 시스템 배포 기계는 4 코어 8 세대는 같은 데이터베이스 서버는 16 코어 32G입니다.
이 시점에서 100,000의 총량, 드물게 사용자의 양이, 니 카츠의 사용자가 서로 다른 시스템의 상황에 따라 차별화 된 시스템의 사용자가, 우리는보다 객관적인 비율, 그것의 10 %, 매일 활성 사용자 10000을 가정한다.
파레토 법칙에 따르면, 하루 중 피크 4 시간, 80 %를 차지 활성 사용자의 피크를 계산, 그 4 시간에서 활동 8천명이다.
그런 다음 시스템에 모두 20 번 우리가 계산 하루에 따라 요청을 시작합니다. 이어서도 초당 8,000 개시 요청의 최대 16 만회은 4 시간 내에 10 개 초당 요청 (1만4천4백초)를 평균한다.
좋아! 높은 동시성과 완벽한 오른쪽 몫을?
그런 다음 시스템 레벨은 두 번째 요청에 따라 10 배마다는 CRUD 등을하는 등 여러 가지 데이터베이스 작업을 요청할 데이터베이스에 호출합니다.
그래서 우리는이 데이터베이스 계층은 바로, 또한, 초당 30 개 요청하는 경우 즉, 첫 번째 요청은 데이터베이스가 요청할 세 번에 해당 걸릴?
이 구성 데이터베이스 서버 지원에 따라 전혀 문제가 없다.
도시 한 도면으로, 상기 시스템은, 이는 다음과 같다 :
이 시스템 클러스터 구축
사용자의 수는 등록 된 사용자의 양이 빠르게 성장하기 시작한다고 가정하면 500 만 달러로 상승, 50 배 증가했다.
이 시점 니 카츠 50 만 사용자, 초당 요청의 피크에서, 시스템은 500 / s입니다. 그런 다음 두 번째 숫자 당 데이터베이스 요청 1500 / S는 무슨 일이 일어날 지이 시간입니까?
위의 시스템 구성에 따라, 경우 프로세스가 더 복잡한 시스템의 일부 비즈니스 로직, 비즈니스 로직은 무거운 시스템의 종류, 다음, 상대적으로 시간이 많이 소요되는 CPU입니다.
이 시점에서, 초당 4 코어 8 세대 요청이 기계는 컴퓨터를로드 CPU 높은 가능성이 500 / s에 도달하면.
다음 데이터베이스 레벨은 전술 한 배열의 관점에서, 실제로, 실질적으로 허용 정지 후, 1500 / S를 요청 압력 피크.
이는 1500 /의 요청에 우리의 온라인 경험에 따라 데이터베이스 디스크 부하, 네트워크 부하, CPU 부하, 메모리 부하, 구성 데이터베이스가 압력을 받고 아무 문제가 없다 기계를 관찰하기 위해 주로이다.
따라서이 경우는 첫 번째는 시스템 클러스터의 배포를 지원하는 것입니다, 일을 할 필요가있다.
로드 밸런싱 층의 앞에 놀 수, 요청이 시스템이 여러 개의 클러스터 시스템은 높은 동시성 압력을 지원 사용할 수 있습니다, 균일 한 시스템 수준을 기록했다.
예를 들어, 시스템은 여기에서 가정의 컴퓨터의 배치는, 각 기기가 250 만 요청 / 초있다.
그 결과, 크게 CPU의 부하를 줄일 수 두 시스템이 초기 "높은 동시성 '을 살고있는 제 1 커버에 있지?
심지어이 완료되지 않을 경우, 극단적 인 경우, 그 단일 시스템 부하가 더 높은는 요청에 응답 할 수있는 충분한 자원이없는 시스템에 시스템을 배포 할 수 있으며, 요청에도 시스템 다운 타임의, 붙어 나타날 때 문제 클래스입니다.
그래서 간단하게 요약하면, 첫 번째 단계 :
로드 밸런싱 층을 추가, 레이어 시스템 요청을 고르게했다.
여러 시스템의 클러스터 구축, 강 Zhu의 예비 동시 압력을 사용하여 시스템 층.
이 아키텍처 다이어그램에서 다음과 같이된다 :
3, 데이터베이스가 하위 라이브러리 별도의 읽기 및 하위 테이블을 쓰기 +
사용자의 수는 계속 증가한다고 가정하면 1,000 만 등록 된 사용자에 도달하고 매일 100 만 사용자가 일상 생활이다.
那么此时对系统层面的请求量会达到每秒1000/s，系统层面，你可以继续通过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。
但是，这时数据库层面接受的请求量会达到3000/s，这个就有点问题了。
此时数据库层面的并发请求翻了一倍，你一定会发现线上的数据库负载越来越高。
每次到了高峰期，磁盘IO、网络IO、内存消耗、CPU负载的压力都会很高，大家很担心数据库服务器能否抗住。
没错，一般来说，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述我们举例的那个配置，不要超过3000/s。
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。
另外一个，压力过大把你的数据库给搞挂了怎么办？
所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写入请求的。
然后每个主库都挂载至少一个从库，由从库来承载读请求。
此时假设对数据库层面的读写并发是3000/s，其中写并发占到了1000/s，读并发占到了2000/s。
那么一旦分库分表之后，采用两台数据库服务器上部署主库来支撑写请求，每台服务器承载的写并发就是500/s。每台主库挂载一个服务器部署从库，那么2个从库每个从库支撑的读并发就是1000/s。
简单总结，并发量继续增长时，我们就需要focus在数据库层面：分库分表、读写分离。
此时的架构图如下所示：
4、缓存集群引入
接着就好办了，如果注册用户量越来越大，此时你可以不停地加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。
然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。
但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的。所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。
如果不停地加机器，这是不对的。
在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。
单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。
可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。
具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。
这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
比如说上面那个图里，读请求目前是每秒2000/s，两个从库各自抗了1000/s读请求，但是其中可能每秒1800次的读请求都是可以直接读缓存里的不怎么变化的数据的。
那么此时你一旦引入缓存集群，就可以抗下来这1800/s读请求，落到数据库层面的读请求就200/s。
同样，给大家来一张架构图，一起来感受一下：
按照上述架构，好处是什么呢？
可能未来你的系统读请求每秒都几万次了，但是可能80%~90%都是通过缓存集群来读的，而缓存集群里的机器可能单机每秒都可以支撑几万读请求，所以耗费机器资源很少，可能就两三台机器就够了。
要是换成数据库来试一下，可能就要不停地加从库到10台、20台机器才能抗住每秒几万的读并发，那个成本是极高的。
好了，我们再来简单小结，承载高并发需要考虑的第三个点：
不要盲目进行数据库扩容，数据库服务器成本昂贵，且本身就不是用来承载高并发的
针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求
5、引入消息中间件集群
接着再来看看数据库写这块的压力，其实是跟读类似的。
假如说所有写请求全部都落地数据库的主库层，当然是没问题的，但是写压力要是越来越大了呢？
比如每秒要写几万条数据，此时难道也是不停的给主库加机器吗？
可以当然也可以，但是同理，耗费的机器资源是很大的，这个就是数据库系统的特点所决定的。
相同的资源下，数据库系统太重太复杂，所以并发承载能力就在几千/s的量级，所以此时你需要引入别的一些技术。
比如说消息中间件技术，也就是MQ集群，是非常好的做写请求异步化处理，实现削峰填谷的效果。
假如说，现在每秒是1000/s次写请求，其中比如500次请求是必须请求过来立马写入数据库中的，但是另外500次写请求是可以允许异步化等待个几十秒，甚至几分钟后才落入数据库内的。
那么此时完全可以引入消息中间件集群，把允许异步化的每秒500次请求写入MQ，然后基于MQ做一个削峰填谷。比如就以平稳的100/s的速度消费出来然后落入数据库中即可，此时就会大幅度降低数据库的写入压力。
此时，架构图变成了下面这样：
大家看上面的架构图，首先消息中间件系统本身也是为高并发而生，所以通常单机都是支撑几万甚至十万级的并发请求的。
所以，这本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用来支撑部分允许异步化的高并发写入是没问题的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。
而且经过消息中间件的削峰填谷之后，比如就用稳定的100/s的速度写数据库，那么数据库层面接收的写请求压力，不就成了500/s + 100/s = 600/s了么？
大家看看，是不是发现减轻了数据库的压力？
到目前为止，通过下面的手段，我们已经可以让系统架构尽可能用最小的机器资源抗住了最大的请求压力，减轻了数据库的负担。
系统集群化
数据库层面的分库分表+读写分离
针对读多写少的请求，引入缓存集群
针对高写入的压力，引入消息中间件集群
初步来说，简单的一个高并发系统的阐述是说完了。
但是，其实故事到这里还远远没有结束。
6、现在能Hold住高并发面试题了吗？
看完了这篇文章，你觉得自己能回答好面试里的高并发问题了吗？
很遗憾，答案是不能。而且我觉得单单凭借几篇文章是绝对不可能真的让你完全回答好这个问题的，这里有很多原因在里面。
첫째, 높은 동시성 주제 자체는 기사의 일부는 명확하게 말할 수에서 매우 복잡한 멀지 않은, 본질은 고도의 동시성 시스템 아키텍처의 실제 지원 복잡한 비즈니스 시나리오가 실제로 매우 복잡하다는입니다.
두 번째 동시 미들웨어 시스템 당 예를 들어 메가 비트, 게이트웨이 시스템 백억 매일 요청, 초당 요청 수천 수백 승진 시스템을 스파이크, 즉시, 큰 규모와 높은 전력 비즈니스 플랫폼 아키텍처 등의 수백만 사용자의 지원 수백 .
높은 동시 요청을 지원하기 위해, 시스템 아키텍처 설계, 특정 비즈니스 시나리오 및 특성에 바인딩 기본 기술 지원이 많이 필요 복잡한 구조의 다양한 설계되며, 정교한 구조와 메커니즘을 설계 할 수있는 능력이 필요합니다.
마지막으로, 지금까지 대부분의 학생들 이상으로 복잡한 시스템 아키텍처의 복잡성의 발표는 상상력 연락하지 않았다.
그러나 복잡한 시스템 아키텍처, 기사의 일부는 어려운 통해 명확하게 다양한 내부 정보와 바닥의 생산 과정 대답.
둘째, 높은 동시성이 콘텐츠 항목 자체가 용지 말했다보다 훨씬 더 들어 있습니다 그래서 여러 주제 : 하위 라이브러리 하위 테이블, 캐시, 뉴스.
완전하고 복잡한 고도의 동시성 시스템 아키텍처, 문의부터 복잡한 인프라 시스템의 다양한 전체 링크를 포함합니다 핫 캐시 아키텍처, 멀티 우선 순위가 높은 처리량 MQ 아키텍처 설계, 시스템과 같은 정교한 건축 디자인 (다양한 동시 성능 최적화 설계 등)뿐만 아니라, 시스템의 높은 동시성 아키텍처의 전반적인 기술 프로그램 복잡한 조합뿐만 아니라, NoSQL에 (elasticsearch 등) / 부하 분산 / 웹 서버 및 기타 관련 기술을 제공합니다.
그래서 우리는 기술의 두려움을 유지하기 위해 기억, 이런 일들은 일부 기사에 의해 명확하게 표현하기가 어렵습니다.
마지막으로, 실제 착륙 할 때 높은 동시성 시나리오에서 생산 시스템은 기술적 인 문제가 많이있을 것입니다.
예를 들어, 메시징 미들웨어의 처리량을 최적화 할 필요가 증가하지 않는, 디스크 용량이 너무 쉽게 폭발 너무 많은 압력 성능 저하, 메모리 소비 쓰기, 하위 서브 테이블 데이터베이스 미들웨어는 모르는 이유에 손실 된 데이터 등.
이 기사는 모든 것이 명확하게하여 매우 같은 질문, 그것은 불가능하다.