面试-如何设计一个高并发 高可用的系统

【摘要】 回答这个问题可以分为以下 几 点 (但最好都要结合着自己的业务系统，讲述下自己系统中的应用)：
系统拆分 Cache(缓存) MQ 数据库拆分(分库分表) 读写分离 HTML 页面静态化 CDN 加速

1系统拆分
将一个系统拆分为多个子系统，使用 Spring Cloud 或者 dubbo 来做。然后每个系统连一个数据库，这样本来就一个库，现在多个数据…

回答这个问题可以分为以下 几点 (但最好都要结合着自己的业务系统，讲述下自己系统中的应用)：

• 系统拆分

• Cache(缓存)

• MQ

• 数据库拆分(分库分表)

• 读写分离

• HTML 页面静态化

• CDN 加速

1系统拆分

将一个系统拆分为多个子系统，使用 Spring Cloud 或者 dubbo 来做。然后每个系统连一个数据库，这样本来就一个库，现在多个数据库，不也可以扛高并发么。

1.1 系统拆分成多个应用有以下优点：

针对可并发 高可用的优点：

可扩展

应对系统业务增长的方法通常采用横向（Scale out）或纵向（Scale up）的方向进行扩展。分布式系统中通常要采用Scale out的方式进行扩展。因为不同的功能会面对不同的负荷变化，因此采用微服务的系统相对单块系统具备更好的可扩展性。当在大促活动期间，我们可以通过增加实例个数来扛过活动期价瞬时流量

高可靠

微服务间独立部署，一个微服务的异常不会导致其它微服务同时异常。通过隔离、融断等技术可以避免极大的提升微服务的可靠性

技术异构

在一个大型系统中，不同的功能具有不同的特点，并且不同的团队可能具备不同的技术能力。因为微服务间松耦合，不同的微服务可以选择不同的技术栈进行开发。

同时，在应用新技术时，可以仅针对一个微服务进行快速改造，而不会影响系统中的其它微服务，有利于系统的演进。

比如在示例中，如果因为库存系统数据量变大，我们需要数据由当前的sqlite数据库修改为MySQL，可以仅修改Inventory Service，而不需要要求整个系统的数据库全部替换。

其他优点：

各服务职责单一，逻辑清晰，多个服务模块间可并行研发；

简化部署，单一模块的更新不会影响到其他服务

灵活组合，在微服务架构中，可以通过组合已有的微服务以达到功能重用的目的。

1.2 服务拆分缺点：

复杂度高：

微服务间通过REST、RPC等形式交互，需要考虑被调用方故障、过载、消息丢失等各种异常情况，分布式系统管理复杂，分布式链路跟踪问题难，分布式事务处理复杂

（分布式链路追踪问题，以dubbo为例，可以参考这篇博客基于SLF4J的MDC机制和Dubbo的Filter机制，实现分布式系统的日志全链路追踪）

运维复杂

在采用微服务架构时，系统由多个独立运行的微服务构成，需要一个设计良好的监控系统对各个微服务的运行状态进行监控。运维人员需要对系统有细致的了解才对够更好的运维系统。

2 缓存

这也是常见的一种优化方式，在数据库层之上加一层缓存，减少对数据库的访问压力。

大部分的高并发场景，都是读多写少，那你完全可以在数据库和缓存里都写一份，然后读的时候大量走缓存不就得了。所以你可以考虑考虑你的项目里，那些承载主要请求的读场景，怎么用缓存来抗高并发。

远端缓存：数据写入redis,毕竟人家 redis 轻轻松松单机几万的并发

高性能本地缓存框架: guava cache , Caffeine(Spring5放弃了使用多年的Guava而采用了Caffeine),所有读数据在缓存加载，提高系统响应速率

缓存雪崩、缓存穿透、缓存击穿问题

针对首页，如果不存在千人千面的状态，我们可以结合缓存采用下面这种方案提高系统响应速率：

3 消息队列（异步、削峰、解耦）

引入了消息队列，那么可能下面一系列问题也就来到了额（重复消费、消息丢失、顺序消费，即 如何保证消息最终一致性）

这篇文章 消息队列 讲述了消息队列的优缺点，以及 如何去解决 消息丢失、消费重复等问题

Kafka、ActiveMQ、RabbitMQ、RocketMQ 有什么优缺点？