각 레이어에 대해 과매도 문제와 해결 방법에 스파이크

1.1 스파이크 시스템 아키텍처

기술적 특성 스파이크

읽기 및 덜 쓰기

举例：

淘宝商场在双十一活动时，可能有几千万人在浏览同一个商品，而在这个时间点里读的是特别多，但是真正买到商品的人特别少

높은 동시성

举例：

可能同一时间有很多人都在抢购同一件商品，然后不管抢到抢不到都会发送请求给后端，给后端服务器造成压力，这就是高并发

자원 충돌

举例：

比如有1000件商品，然后有多个人对数据库进行写的操作，也就是减1操作，有没有可能最后卖出了1002件商品，这是不可能的

在python2中，使用多线程进行count操作，如
count=1000，
用100个线程每次进行减1操作      count-=1    
然后减1000次，它可能是1或者是2
因为它有些减的操作被覆盖了

1. 과매도 문제

• 1000 상품
• 첫 번째 단계 문의 주문
• 쿼리 제품 : 1000 B 읽기 읽기 상품 상품 1000
• 주식 공제 : A : 1000-1 = 999 : 데이터베이스, B에 기록 1000-1 = 999
• 판매 두 항목, 항목 수 : 999

낙폭 과대의 문제를 해결하는 방법 낙관적 비관적 잠금 (2)

悲观锁是读取时加锁，然后在写入到数据库之后释放锁
乐观锁是读取时不加锁，写入数据库时加锁

• (순간이 잠겨 있음을 양 질의) 해결하는 원리 비관적 잠금
  • 우리는 비관적 잠금 경우 상품의 수는 잠금 (전용 잠금)의 수에 물품을 읽은 후, 1000을 읽을 수있는
  • 상품, 플러스 잠금의 수에 B는 B 때문에 대기에 공개되지 않은
  • 상품 판매, 마이너스 상품의 수는의 항목 수 잠금을 해제하기 전에 데이터베이스 999 재 작성된 경우에만
  • 제품은 999 데이터의 양 (1000) 대신 때 제품 B가 얻어진다
• 낙관적 잠금 원칙은 (순간이 잠겨 있음을 재고 공제)이를 해결하기 위해
  • 읽을 항목의 수는 우리가 낙관적 잠금 경우, B는 여전히 1000을 통해 읽을 수있는, 1000,이 시간에는 잠금 장치가 없다
  • 상품 때 공제 확인 여부 항목과 수량 일관성 시작의 현재 수
  • 공제 A (배타적 로크) 999 생성물에 쓰여 후 패리티 검사 수있을 것이다 1000 MySQL의 여부
  • 서면됩니다 시작하여 동일한 데이터를 읽고 일관성 재시도

1.2 용액 층

애플리케이션 계층 (데이터 저장 localstorge)

打开浏览器，浏览器里会有缓存，缓存的可能就是静态页面，还有一些按钮控制相关的东西，而我们打开浏览器买东西所访问的静态页面，访问的并不是源站，而是cdn

1. CDN 네트워크 층

• 특징 : CDN 서버 설치 및 배포가 아닌 실제 백 엔드 서버 만 프런트 엔드 데이터 캐시를 필요로하지 않는다

• 역할 : 해제 압력 소스 서버 역, 외국 액세스 수행 할 수 있습니다 더 빨리

• 전 세계에 우리의 서비스를 구축하는 것보다 CDN (너무 비싸다)

• CDN은 정적 리소스 (JS, HTML, CSS, 사진, 비디오)하지 않습니다 변화를 캐싱

• 웹 사이트는 백엔드 API 인터페이스를 제공

• 당신은 미국의 상인의 제품 이미지는 CDN 서버에 미국에서 열

• 그러나 요청 API 인터페이스, 백엔드 서비스는 여전히 중국에서 전개 될 수

• 요구 및 데이터베이스와의 동적 상호 작용, CDN이 적용되지 않습니다

2. 지지층 (HA)

Nginx负载均衡存在问题（单点故障）：

代理的服务器如果死了一半，那么他还剩下另外一半服务器能用，但是如果主服务器死了，那么其他代理服务器也就没用了

负载层不会直接到达Nginx，能保持高并发，不能保活

比如有一个主Nginx服务器，他如果不使用负载均衡的话，他就只有一台服务器，而如果使用负载均衡，就可以把请求代理分发给多台服务器。

不用负载均衡存在问题：多个用户同时访问主Nginx时，他不一定能处理那么多的并发量

Nginx反向代理就是主Nginx不去处理，而是把流量分发给其他机器

• ** 균형에 대한 nginx를 책임 : **은 https : //www.cnblogs.com/xiaonq/p/10468998.html

• 질문 : 만 높은 동시성을 해결할 수있는, 고 가용성 해결할 수없는

기계 메인 Nginx에 추가하면 고 가용성을 해결할 수 있습니까?
아니, 그들은 같은 IP하지 않습니다 때문이다. 두 Nginx에 가상 IP의를 사용하는 방법입니다

而keepalive可以做到，是因为keepalive-master、keepalive-slave虽然名字不一样，但是他们的ip一样
```

客户端——>互联网——>keepalive-master——>后端——>数据库——>请求返回给客户端

• 킵 얼라이브와 정맥 주사가 존재 이해 haproxy (실패의 고 가용성의 문제를 해결하기 위해, 단일 지점)

• 킵 얼라이브 : HTTPS : //www.cnblogs.com/xiaonq/p/11694253.html

keepalive双活机制：
两台keepalive服务器（或者多台，只有master干活）同时监听一个虚拟IP，同一时间只有keepalive-master集群能够进行服务代理,当keepalive-master宕机，keepalive-slave会立刻顶替master执行集群代理服务

keepalive软件有两种功能：监控检查、VRRP冗余协议.

keepalieve会从以下三层来检查集群中的服务是否正常：
1）layer3：通过ICMP协议ping测试
2）layer4：比如web服务，keepalived检查80端口是否启动
3）layer7：根据用户的设定检查服务器程序运行是否正常

keepalived--VRRP冗余协议原理:
    vrrp是虚拟路由冗余协议，就是当出现单点故障问题通过竞选方式决定vip走向的一种机制.
    
1. Keepalived高可用是通过vrrp协议通信的，vrrp是通过竞选机制决定主备
2. Keepalived 主的服务器会一直发送 VRRP广播包,告诉备它还活着
3. 当备机监听不到主发送的广播包时，就人为主机不可用，所有备机通过配置文件中的优先级选举新的主机
4. 新的主机就会启动相关服务接管资源，保证业务的连续性

높은 동시성 소개

개념

1. PV(访问量)： 页面访问量，页面刷新一次算一次。
2. UV(独立访客)： 即Unique Visitor，一个客户端（电脑，手机）为一个访客；理论以终端辨别
3. DAU(日活跃用户数)：登录或使用了某个产品的用户数，这与流量统计工具里的访客（UV）概念相似。
4. 峰值QPS：
qps衡量一个公司架构的最低并发量
	原理：每天80%的访问集中在20%的时间里，这20%时间叫做峰值时间
    公式：( 总PV数 * 80% ) / ( 每天秒数 * 20% ) = 峰值时间每秒请求数(QPS)
5. QPS/TPS(每秒查询率)：每秒能够查询次数（QPS/TPS= 并发数 / 平均响应时间）
	并发数：并发数是指系统同时能处理的请求数量，这个也是反应了系统的负载能力。
    吐吞量：吞吐量是指系统在单位时间内处理请求的数量
    响应时间（RT）：响应时间是指系统对请求作出响应的时间，一般取平均响应时间

장고 성능

跟带宽，服务器性能有关，比如4核8G机器正常每秒可以处理500上下的并发量

1.5 높은 동시성 아키텍처 층을 수행 할 수 있습니다

• 응용 프로그램 계층
  • 현지 브라우저 캐시 : 캐시 정적 페이지, 데이터 장바구니에 담기 캐시
• 네트워크 계층
  • CDN 캐시 정적 자원 : HTML / CSS / JS / 이미지
• 로드 층
  • 킵 얼라이브 (haproxy) + nginx를 리버스 프록시 (텐센트 구름 LB, 알리 구름 SLB)
• 서비스 레이어
  • (예 : 장고의 캐시 서비스 등) 동적 정적 페이지, 데이터베이스 쿼리의 수를 감소
  • 레디 스 MySQL은 쿼리 캐시로 많은 압력을 해결
  • RabbitMQ + 비동기 쓰기 문제 mysql을 많이 해결하기 위해
  • 제한 :
    • 스냅 : 트래픽의 양이 자동으로 제거 될 때 Nginx의 보호 기능이 제공된다 (지지층을 삭제)
    • 두 번째 아웃 바운드 인터페이스 IP 방문에 동일한 장치, 계정, 최대
• 데이터베이스 층
  • 낙관적 잠금, 데이터 보안을 해결하기 비관적 잠금
  • 다중 마스터, 별도의 읽기 및 쓰기에서 MySQL의 : 쓰기 중앙 도서관, 도서관에서 (데이터베이스 모든 데이터)를 읽고
    • 문의는 매우 느린 아직 때 동일한 데이터는, 데이터가 너무 큰 경우
  • 서브 - 라이브러리 (라이브러리 사용자 ID 분)
    • 데이터베이스 테이블 구조의 모든 마찬가지로, 데이터 저장은 완전히 다릅니다
    • 사용자 ID에 실제 환경은 각 라이브러리에 대한 라이브러리에 데이터를 나누어 빠른 쿼리까지, 작은
  • (시간에 따라 일부 테이블) 부 테이블
    • 데이터 테이블이 너무 큰 경우, 우리는 테이블을 분할해야
    • 목록 테이블에게 2,000 만 데이터를 쇼핑
      • 지난 6 개월 백만 쇼핑 데이터시
      • 데이터의 6 달에 년 500 만있다
      • 데이터 천만 년 전