高并发互联网架构
2023-12-18 10:13:22 1 举报AI智能生成
高并发的互联网相关的理论
作者其他创作
大纲/内容
变迁
单应用单db
多应用单db-负载均衡
多应用单db+缓存
多应用读写分离db+缓存+文件/图片服务器
多应用读写分离+分库分表+缓存
多应用读写分离+分库分表+缓存+异步化
SOA
微服化
技术点
CAP原则
定义
Consistency（一致性）
等同于所有节点访问同一份最新的数据副本
在分布式系统中的所有数据备份，在同一时刻是否同样的值
Availability（可用性）
对数据更新具备高可用性
在集群中一部分节点故障后，集群整体是否还能响应客户端的读写请求。
Partition tolerance（分区容错性）
以实际效果而言，分区相当于对通信的时限要求。
系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择
CAP三者不可兼得
负载均衡
web服务无状态
API网关
ngix
业务网关
缓存
框架
redis
单点
分片
持久化
集群
memchaed
问题
故障分类
缓存穿透
场景
查询一个缓存中和数据库中都不存在的数据，导致每次查询这条数据都会透过缓存，直接查库，最后返回空。
当用户使用这条不存在的数据疯狂发起查询请求的时候，对数据库造成的压力就非常大，甚至可能直接挂掉
方案
缓存空对象
布隆过滤器
缓存击穿
场景
当缓存中某个热点数据过期了，在该热点数据重新载入缓存之前，有大量的查询请求穿过缓存，直接查询数据库。
这种情况会导致数据库压力瞬间骤增，造成大量请求阻塞，甚至直接挂掉。
方案
设置key永不过期
使用分布式锁，保证同一时刻只能有一个查询请求重新加载热点数据到缓存中。
这样，其他的线程只需等待该线程运行完毕，即可重新从Redis中获取数据。
这样，其他的线程只需等待该线程运行完毕，即可重新从Redis中获取数据。
缓存雪崩
场景
当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了
导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。
方案
第一种大量key同时过期的情况，解决起来比较简单，只需要将每个key的过期时间打散即可，使它们的失效点尽可能均匀分布。
第二种redis发生故障的情况，部署redis时可以使用redis的几种高可用方案部署
缓存与数据库数据一致性
先取消再写再flush
canal
读写分离
数据库主从
定义不同的数据源，根据业务定位读/写库
分库分表(sharding)
分库
垂直分库/逻辑分库
按照业务，不同业务不同数据库
业务代码简单
容易产生热点数据-如不同用户订单数量不均匀
水平分库
按照某个业务字段，如saler_id分库
不常用
分表
取模（如按照saled_id 模64，可以分成64张表）
热点数据
中间表映射
数据均匀分布，中间表记录数据路由
一致性hash
异步化
AMQ
RabbitMQ
Rocketmq
kafka
redis
微服务
最小的业务单元做成服务
协议
http
基于tcp/ip的RMI协议
服务治理
服务网关
zuul
服务治理
Eureka
AP
Dubbo/Dubbox
CP
Service Mesh（服务网格）
Service Fabric
lstio
Linkerd
Conduit
服务配置
Spring cloud config
ctrip apollo
调用链
CAT
？
熔断
Hystrix
限流
0 条评论
下一页
