首页  思维导图  详情



 



高并发互联网架构

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永不过期

使用分布式锁，保证同一时刻只能有一个查询请求重新加载热点数据到缓存中。<br>这样，其他的线程只需等待该线程运行完毕，即可重新从Redis中获取数据。<br>

缓存雪崩

场景

当缓存中有大量的key在同一时刻过期，或者Redis直接宕机了

导致大量的查询请求全部到达数据库，造成数据库查询压力骤增，甚至直接挂掉。

方案

第一种大量key同时过期的情况，解决起来比较简单，只需要将每个key的过期时间打散即可，使它们的失效点尽可能均匀分布。<br>

第二种redis发生故障的情况，部署redis时可以使用redis的几种高可用方案部署

缓存与数据库数据一致性

先取消再写再flush

canal

读写分离

数据库主从

定义不同的数据源，根据业务定位读/写库

分库分表(sharding)

分库

垂直分库/逻辑分库

按照业务，不同业务不同数据库

业务代码简单

容易产生热点数据-如不同用户订单数量不均匀

水平分库

按照某个业务字段，如saler_id分库

不常用

分表

取模（如按照saled_id 模64，可以分成64张表）

热点数据

中间表映射

数据均匀分布，中间表记录数据路由

一致性hash

异步化

AMQ

RabbitMQ

Rocketmq

kafka

redis

微服务

最小的业务单元做成服务

协议

http

基于tcp/ip的RMI协议

服务治理

服务网关

zuul

服务治理

Eureka

Dubbo/Dubbox

Service Mesh（服务网格）

Service Fabric

lstio

Linkerd

Conduit

服务配置

Spring cloud config

ctrip apollo

调用链

CAT

？

熔断

Hystrix

限流

 Collect

Get Started

互联网医院平台订单流程

 Collect

Get Started

互联网本质与思维

 Collect

Get Started

企业级互联网架构

 Collect

Get Started

互联网应用类别与运营案例





0 条评论

下一页