1、扩容

扩容思路：

u 垂直扩容（纵向扩展）：提高系统部件能力

u 水平扩容（横向扩展）：增加更多系统成员来实现

数据库扩容：

读操作扩展：memcache、redis、CDN等缓存

写操作扩展：Cassandra、Hbase

2、缓存

(1) 浏览器：页面静态化

(2) 网络转发：nginx反向代理

(3) 应用服务：集群

(4) 数据库：读写分离、分表分库

缓存特性：

命中率：命中数/（命中数+没有命中数）

最大元素（空间）

清空策略：FIFO（先进先出）、LFU（淘汰一定时期内被访问次数最少的）、LRU（淘汰最长时间未被使用的）、过期时间、随机等

一般来说：项目中开发，使用缓存的时候，都是读多写少；

可以使用复制特性扩展读性能

可以使用客户端分片扩展写性能

缓存分类和应用场景

本地缓存：编程实现（成员变量、局部变量、静态变量）、Guava Cache

分布式缓存：Memcache、Redis

Guava Cache相当于利用hashmap实现了本地缓存的管理

高并发场景下缓存常见问题

u 缓存一致性

u 缓存并发问题

u 缓存穿透问题

u 缓存的雪崩现象

缓存一致性

雪崩：

执行了增删改操作，此时缓存中并没有key所对应的数据（缓存被清除了），那么可能某一时间点，多个请求同时访问，越过缓存服务器直接访问数据库服务器，造成服务雪崩现象；

解决方案：使用锁机制解决该问题

第一个请求去访问数据库拿数据到缓存，然后加锁不让其它的请求向下执行，直到第一个请求将最新的数据库中的数据同步到缓存，再释放锁让其它请求向下执行；

穿透：

因为某些原因，缓存中的数据key对应的值为null，此时请求会穿过缓存服务器直接访问数据库，当然这样最终也会造成雪崩啦；

解决方案：

缓存空对象或者数字

比如key对应的是new HashMap()而不是null；

再比如key对应的是-99，替代了null；

3、消息队列思路

u 业务无关：只做消息分发

u FIFO：先投递先到达

u 容灾：节点的动态增删和消息的持久化

u 性能：吞吐量提升，系统内部通信效率提高

为什么需要消息队列？

【生产】和【消费】的速度或稳定性等因素不一致

消息队列的好处

业务解耦

最终一致性

广播

错峰和流控

事务一致性分两种：

强一致性：分布式事务就是其中一种体现

最终一致性：

总结：

消息队列：处理对别人重要，对自己不用要的事情

4、应用拆分

跑定时任务耗内存，需要单独的定时任务服务器

弊端：管理成本变高，硬件成本变高

应用拆分原则

u 业务优先

u 循序渐进（边拆分边测试）

u 兼顾技术：重构、分层

u 可靠测试

应用拆分注意点

u 应用之间通信：RPC（dubbo等）、消息队列

u 应用之间数据库设计：每个应用都有独立的数据库

u 避免事务操作跨应用

应用拆分涉及到的技术点：Dubbo、SpringCloud

Dubbo相比于SpringCloud的优势：RPC调用远程方法，配置好就像调用本地方法一样无感知，

Dubbo相比于SpringCloud的劣势，不是所有语言都支持tcp协议，而SpringCloud应用之间访问遵循http协议，多数语言都支持http协议；那么SpringCloud微服务架构就更灵活，方便应用的扩展；

RPC与REST架构的区别参考地址：

https://baijiahao.baidu.com/s?id=1617168792520937104&wfr=spider&for=pc

Dubbo架构图

SpringCloud架构图

微服务标准

u 1、分布式服务组成的系统

u 2、按照业务去划分的服务，而不是按技术划分组织

u 3、强服务个体，弱通信

u 4、自动化运维DevOps https://blog.csdn.net/weixin_44221613/article/details/88651494

u 5、高度容错性

u 6、可以快速演化和迭代

使用微服务需要解决的问题

u 1、客户端如何访问服务端

网关：提供统一的服务入口，领各服务对前台透明；

提供安全、过滤、流控的API管理功能

u 2、每个服务之间的通信方式

异步：使用消息队列

同步：使用REST、RPC

u 3、如此之多的服务如何实现

主要解决服务上线下线，服务感知服务发现相关问题，

用到注册中心即可解决这一问题

u 4、服务挂了如何解决

  重试、限流、熔断、负载均衡、系统降级

5、应用限流

计算器法

滑动窗口

漏桶算法

令牌桶算法

计数器法

滑动窗口算法

漏桶算法

令牌桶算法

应用限流算法对比

u 计数器法 VS 滑动窗口

相比于计算器算法，滑动窗口算法，每个格子都有一个计数器，所以需要更多的内存空间；精度越高，内存要求就更高；

u 漏桶算法 VS 令牌桶算法

漏桶算法保证了消费端均匀消费；

令牌桶算法限制了请求入口，等桶里的请求被消费完了，才能存放其它的请求

6、服务熔断服务降级

u 自动降级：超时、失败次数、故障、限流

u 人工降级：双杀、双11大促等

触发原因：

u 熔断：下游服务故障

u 降级：从整体负荷考虑

服务降级要考虑的问题

u 核心服务、非核心服务

u 是否支持降级、降级策略

u 业务放通场景、策略

Hystrix

u 在通过第三方客户端访问（通常是通过网络）依赖服务出现高延迟或者失败，为系统提供保护和控制

u 在分布式系统中防止级联失败

u 快速失败（Fail fast）同时能快速恢复

7、数据库切库、分库、分表

数据库瓶颈

u 单个库数据量太大（1T~2T）：多个库

u 单个数据库服务器压力过大、读写瓶颈：多个库

u 单个表数据量过大：分表

主库：实时数据查询，及数据更新

从库：非实时数据查询，实际应用读多写少

读库占用资源过多，所有采用读库需要拆分，让不同的从库分担查询压力；

数据库切库

u 切库的基础及实际应用：读写分离

u 自定义注解完成数据库切库 - 代码实现

数据库支持多个数据源与分库

u 支持多数据源、分库

u 数据库支持多个数据源 ~ 代码实现

数据库分表

u 什么时候考虑分表

u 横向（水平）分表 与 纵向（垂直）分表

u 数据库分表：mybatis分表插件 shardbatis2.0

横向：按时间

纵向：按活跃度

冷数据：博客标题、博客内容、作者、时间...

热数据：点击量、评论数....

8、高可用手段

u 任务调度系统分布式：elastic-job + zookeeper

u 主备切换：Apache curator + zookeeper 分布式锁实现

u 监控报警机制

未完待续：以上只是提供了解决思路，后续本人会针对每一种解决方案有相关的代码论证；

当然，这个过程可能会耗时比较久！！！