Spike in oversold issues and solutions for each layer

1.1 spike System Architecture

Technical characteristics spike

Reading and writing less

举例：

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

High concurrency

举例：

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

Resource conflicts

举例：

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

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

1. oversold issues

• 1000 Commodity
• The first step inquiry quantity
• Query Product: A 1000 B read read commodity goods 1000
• Stock deduction: A: 1000-1 = 999 written to the database, B: 1000-1 = 999
• Sold two items, the number of items: 999

2. How optimistic and pessimistic locking to solve the problem of oversold

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

• Principle pessimistic locking to solve (quantity query that moment locked)
  • A number of commodities is read 1000, If we are pessimistic locking, after reading the goods on A number of lock (exclusive lock) the
  • B over the number of commodities, A plus lock has not been released, so B to wait
  • Only when A goods sold, minus a number of goods, the number of items of re-written to the database 999 before releasing the lock
  • Product B is obtained when the product is the amount of data 999 instead of 1000
• Optimistic locking principle to solve the (inventory deductions that moment locked)
  • A number of items read is 1000, If we are optimistic locking, B can still read over 1000, this time there is no lock
  • A commodity when deductions will check whether the current number of items and quantities consistent start
  • After deduction A (exclusive lock) 999 is written either to the product will be the number of the parity check whether the 1000 mysql
  • A beginning and read the same data is written, inconsistent retry

1.2 Solution layers

Application layer (data stored localstorge)

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

1. CDN network layer

• Features: cdn server does not require installation and deployment, not a real back-end server, only the front-end data cache

• Role: relieve pressure source server station, for foreign access, you can more quickly

• CDN than to deploy our services all over the world (too expensive)

• CDN is caching static resources (JS, Html, Css, pictures, videos) will not change

• Web site offers a backend API interface

• You open from the United States to the merchant's product images of the United States a CDN server

• But the request API interface, back-end services may still be deployed in China

• Needs and dynamic interaction with the database, CDN has no effect

2. The support layer (HA)

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

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

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

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

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

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

• ** nginx responsible for balancing: ** https: //www.cnblogs.com/xiaonq/p/10468998.html

• Question: can only address the high concurrency, high availability can not be solved

If a machine added to the main Nginx, you can not solve the high availability?
No, because they are not the same ip. Two Nginx is no way to use a virtual ip's

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

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

• keepalive and lvs, there haproxy understand (to solve the problem of high availability, single point of failure)

• keepalive：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. 新的主机就会启动相关服务接管资源，保证业务的连续性

High concurrency introduction

concept

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）：响应时间是指系统对请求作出响应的时间，一般取平均响应时间

django performance

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

1.5 high concurrency architecture layers can do

• Application layer
  • Local browser cache: cache static page, the data cache Add to Cart
• Network layer
  • CDN cache static resources: html / css / js / images
• Load layer
  • keepalive (haproxy) + nginx reverse proxy (Tencent cloud LB, Ali cloud SLB)
• Service Layer
  • Dynamic static pages (such as Django's cache service), reduce the number of database queries
  • With redis mysql query cache solve a lot of pressure
  • RabbitMQ + asynchronous writes to solve a lot of problems mysql
  • Limiting:
    • Snapped: nginx protection function is provided, when the amount of traffic is automatically dropped (discarded the support layer)
    • The same device, account, up to a second outbound interface ip visits
• Database layer
  • Optimistic locking, pessimistic locking to solve data security
  • mysql from a multi-master, separate read and write: Write main library, read (all data as a database) from the library
    • The same data, then when the data is too big when the inquiry is still very slow
  • Sub-libraries (libraries user id min)
    • Like all of the database table structure, data storage is completely different
    • Real environment to the user id is divided library data for each library are small, up to fast query
  • Part table (part table according to the time)
    • When a table of data is too large, we have to split the table
    • Shopping list table 20 million data
      • During the past six months one million shopping data
      • Six months to a year of data has five million
      • A year ago the data ten million