分布式----负载均衡Nginx

Step1、服务器缓存：降低数据库压力；

Step2、第一定律：就是不要使用分布式；

　　　　分布式：多台服务器完成一台服务器做的事；

　　　　每台服务完成步骤，串行完成全部（狭义分布式）

　　　　广义来说，集群也是分布式；

Step3、系统性能优化第一步就是缓存Cache：

　　优点：

　　　　1、降低服务器压力；

　　　　2、提升相应速度；

　　　　3、成本低；

　　缺点：数据更新不及时

Step4、集群（Cluster）负载均衡

　　集群定义：一台服务器做的事，现在由多台服务器共同承载，每台服务器都是独立完成的

Step5、读写分离

　　数据库瓶颈：数据库的读写分离

　　木桶理论：装水能力是由最短的那块板决定的

　　数据库的唯一性

Step6、CDN缓存（集群负载均衡之前）

　　优点：

　　　　1、缩短网络路径，加快相应速度

　　　　2、减少

Step7、分布式文件系统（Distributed File System）

Step8、专项突破

　　　　场景一：全文搜索

　　　　　　非规范性搜索，不是严格匹配数据库的数据；（关系型数据库做不到）（Luene----Solr----ES）

　　　　　　全文检索技术，分词建索引--搜索时分词--搜索出来的词搜索--能匹配不要求完全匹配--能最大程度上搜索出相关词汇

　　　　场景二：秒杀系统

　　　　　　在高并发下，多个线程并发更新库存，导致库存为负的情况下--超卖问题

　　　　　　1、基于数据库的锁 -- 悲观锁 -- 无法满足高并发

　　　　　　2、乐观锁 -- version -- 多个并发只有一个成功 -- 不会超卖

　　　　　　限流：限制请求达到数据库

　　　　　　防超卖：不能出现库存不够；

　　　　　　Redis（Remote Dictionary Server）-- 远程字典服务器 -- 内存快速读写

　　　　　　单线程多进程模型 -- 只有一个执行流，只有一个人做事儿 -- 10wQPS -- 没有线程安全问题

　　　　场景三：刷榜

　　　　　　直播间刷礼物，实时统计排行，Redis

　　二八原则：

　　　　80%的请求聚焦在20%的数据上

　　　　80%的请求都是查询20%是增删改；

　　读写分离：一主多从，发布订阅

　　　　写库：增删改

　　　　读库：查询，数据来自发布服务器

　　发布服务器：主库增删改操作后，推送日志到补发服务器，从库订阅，基于日志完整数据同步；

　　不限制从库的个数；

DNS（Domain Name System）负载均衡

1、部署多个独立的IP对外提供服务

2、DNS服务器配置多个IP

3、DNS解析时转发

优点：高效，就近原则

缺点：只能轮训，独立IP很贵，不能错误发现

硬件负载均衡：

F5、Array、Netscale　　硬件+软件打包

性能高，稳定好，厂商支持

软件负载均衡：

LVS--Linux Virtual Server　　4层协议（ip+port）　　-- 轮训转发(不能根据保存信息转发)　　--更底层更高效--配置很难

HAProxy--4层/7层--http协议/Http信息--转发更加灵活--非常强大--也不太好配置

Nginx：http,https  协议

　　各种策略：

　　　　轮询(默认)----weight---- ip-hash ---- fair策略 ---- url-hash 

　　用户持久化：IP-hash--会话沾滞--局限性很强

　　　　Session共享--inproc/StateServer/Sql Server--Redis Session

　　　　基于HTTPHeader----Cookie/JWT(Token/IdentityServer4)