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