分布式一致性和CAP理论
CAP
- C:一致性
- A:可用性
- P:分区容错性
读写分离和集群扩展
- write是排它锁,不允许其他操作包括读
- read是共享锁,只能被其他线程读取
- write和read是互斥的,所以读写分离能提高相关性能
分库分表
分表
- 垂直分表
- 水平分表
分库
- 垂直分库,相当于根据业务进行区分库
- 水平分库
对分库分表的数据进行迁移和扩容
主从数据库,从库转正
- 比如有2个库,之前是通过路由打到对应的库,现在要扩容了,将对应的从库接触绑定关系进行扩容.如:之前是id%2=0为0号库,现在变为4个,0号库为原来的主库,2号库是0号库之前的从库,以此类推.现在id%4=2为2号库,这样流量就进行了均匀分散.
- 扩容的注意点就是要成倍增加,2变4,4变8.
- 新增加库的数据是从哪个库承接过来的,新增加的就要承接旧的路由请求
增量存量同步
修改路由规则,新库开始承接业务
- 也只能成倍增加,2变4
- 所有库都同步完数据之后才能修改路由规则
- 新增加库的数据是从哪个库承接过来的,新增加的就要承接旧的路由请求
热点数据:在极短时间内被高并发频繁访问到的数据
中心缓存的不靠谱
- 前提是大数据量情况下,比如像天猫京东那些平台,热点数据动不动就有上亿的数据量,如果在这样的数据量下,数据库没崩溃,缓存系统就GG了
- 这种大数据量下,缓存也是按分区进行处理的
- 如果热点缓存被击穿,会将流量直接打到数据库上,导致数据库的团灭,为了避免这种情况的发生,要将热点数据进行隔离
如果处理热点数据
- 多级缓存(使用堆外缓存,避免堆内缓存引发频繁的GC进而影响性能)
- 热点库(将热点数据从缓存中迁移出来,单独给与相关节点和资源,将热点的访问路由到各个相关节点)
监听热点数据
- 接口参数聚合,日志埋点统计抓取相关热点数据(高频访问的数据)
- 通过stream技术聚合分析,发布相关的热点数据
- 哪些业务需要相关热点就订阅它,转而去热点库查取
- 当热点数据的热度降低,删除相关热点数据
数据备份和失效转移
冷备
- 定时,低成本,不一致,数据丢失
- 适用于历史订单,业务报表,时效性不高业务
- 只在最最最坏情况使用
热备
- 同步热备(会存在一致性问题,比如,一个库成功,一个库失败,到底是回滚还是成功要根据业务场景判定)
- 主从热备
应用水位:当前QPS/容量评估承压QPS
应用层设计
服务器集群的伸缩性
- mac地址负载均衡(直接路由),数据链路层Linux的LVS技术
- DNS负载均衡
- 反向代理(http转发)
