高并发笔记
- 为什么用分布式架构
处理，高并发，高可用，大数据
高并发事前： 添加硬件资源
高并发事中： 故障转移、熔断、限流
大数据特点： 读多写少
关键的瓶颈是数据库，处理方案：按读写拆分数据库、按业务拆分数据库、按节点增加数据库
生产库进行设计：数据进行增删改的操作，和少量的试试操作
查询库进行设计： 存放历史年度的海量数据。不能用 关系型数据库。应该用nosql 数据库。
未来有三种数据库
- 关系型数据库，rdbs ，最典型就是mysql。适合少量数据的增删改查。数据的界限就是：单表千万级数据量。达到千万，必须进行压测判断数据库是否能抗住。亿级，必然抗不住。
- 亿级，分布式数据库，newsql。数据库结构 k-v。
与nosql 不同点： newsql 有保持一致性框架。newsql 保证了一致性，但性能后相对低些。nosql 性能好，不能保证一致性。海量查询，就要用nosql。
分布式设计的核心重点，就是分布式数据库。
实现高可用：
云原生过程：1. 技术框架 2. 过程管理 3. 交付形式（jenkins） 4. 部署方式
技术框架、过程管理、部署方式：
原先是 开发人员进行开发，开完成交给运维人员进行部署。
现在是 开发人员开发完，按照要求编写部署文件。交给云平台后，直接进行部署，省略了运维人员的工作步骤。
交付形式：
Jenkins 从 git 上拉取代码，然后打包为 docker仓库，然后在 k8s进行部署
亿级流量的问题：
逐级限流。
性能最好的是 服务网关，性能最差的是 数据库（IO最差）。形成倒三角。
- 网关限流： 负载均衡，身份鉴权，安全防护，限流措施
- 业务层限流： 动静分离，前后端分离，异步化设计，熔断机制（最后的倔强）
- 服务层限流： k8s 横向限流、故障转移、服务降级、数据缓存
- 数据库鞥限流： 读写分离、数据库分离、内存数据库、分布数数据库
生产库（OLTP）与查询库(OLAP)的使用
查询库，可以作为数据库中台,数据仓库（也是重点，以后再学习）
从生产库与查询库，有t+1的同步，每天0点获取数据
es 查询多是查询库查询
-
纵向切分： 按照业务的切分
面临的难题：（迟早都会遇到的） -
库之间的关联查询
-
修改原表的查询方式
-
跨库的事物处理
-
跨库关联处理方式：
1.1 数据补填（干掉 join）
因为数据量大的情况下，时间长。如果有翻页的话，我们在主表查询20条，然后对20条数据，进行补填，返回给前台显示
1.2 空间换时间 (不遵循第三范式)
不管是 jion 或者补填，都需要查询一个数据量比较大的表，去获取简单的数据。我可以通过在主表添加字段的方式，减少对大数据量表的查询。
本地缓存VS分布式缓存
本质区别是：分布式缓存，会使用一个或多个服务器，专门用于存储缓存。 而本地缓存，永远是有限的。
分布式缓存，经典服务就是redis。 k-v 存储数据
内存数据库适应场景：对于反复修改的情况，比较适合内存数据库
内存数据库： reids
设计：不管是增删改查，我都先redis。这样redis 变成可读可写，然后再将同步到数据库中。事物也是在内存数据库写入时结束，这样速度上去了，吞吐量上去了。但内存数据库，不保险，需要不定时的同步到数据库中，但不属于事物，不影响吞吐。
存在的问题：
如果宕机，存在内存数据库的数据，可能丢失。
解决方案：
- 写入本地日志。记录写入内存数据库的内容
- 多节点部署（gamfrie 金菲尔）
分布数缓存不要在service层处理，应该在仓库区处理
