高并发扩容思路

一、缓存

缓存需要注意的问题：

1.缓存一致性
数据时效性要求很高，要求缓存中数据库中的数据一致。（更新数据库成功，更新缓存失败、更新缓存成功，更新数据库失败、更新数据库成功，淘汰缓存失败、淘汰缓存成功，更新数据库失败）
解决方法：缓存的更新策略，

2.缓存并发
缓存过期后，高并发情况下多个请求都没有在缓存中得到数据，全部压力都来到了数据库身上，甚至造成雪崩现象。
一个缓存在更新时，有大量请求去访问该缓存也会造成缓存一致性的问题。
解决方法：锁的机制，当缓存更新或过期时，获取到锁，知道数据更新完成或从数据库中得到数据后，再释放锁，会牺牲一定的等待时间。

3.缓存穿透
高并发场景下，某一个key没有被命中，从而到数据库中进行查询，当到达数据库时发现这个值本身就是空的，导致了大量不必要的数据库操作，对数据库造成了巨大的冲击和压力。
解决方法：1.缓存空对象；2.单独过滤处理，对所有值可能为空的key单独存放，在请求前做拦截，避免请求穿透到数据库。

4.缓存的雪崩现象
因缓存故障或缓存并发导致大量请求到达数据库，导致数据库崩溃，从而导致系统崩溃；或者在某个时间点一部分缓存同时失效了，导致大量请求到达数据库，导致雪崩。
解决方式：可通过应用拆分、降级、熔断等方法降低影响；均匀的设置缓存的过期时间；使用多级缓存。

二、消息队列

特性：
1.与业务无关只做消息分发
2.FIFO，先投递先到达
3.容灾，节点的动态增删和消息的持久化
4.性能，吞吐量提升，系统内部通信效率提高

为什么需要消息队列：
1.生产和消费的速度或稳定性等因素不一致

好处：
1.业务解耦，一个事务只关心自身业务，设计到其他系统的操作，只要发送消息即可，无需等待结果。
2.最终一致性，两个系统的操作要么都成功，要么都失败。利用消息队列中提供的记录和补偿机制，如果操作失败则可以依靠定时任务的方式重新进行操作。
3.广播，将消息进行广播，新接入的系统只需要对需要的消息进行处理即可。
4.错峰与流控，当系统上下游处理能力存在差异时，可以存储消息，在下游有能力处理时再进行分发。

三、拆分应用

从整体将一个应用拆分为多个引用
拆分原则：1.业务优先；2.循序渐进；3.兼顾技术（重构、分层）；4.可靠测试
应用拆分需要考虑的问题：
1.应用之间通信：RPC(dubbo，spring cloud)、消息队列。
2.应用之间的数据库设计：每个应用都有独立的数据库。
3.避免事务操作跨应用。

dubbo：分布式服务框架，还提供软负载均衡，

spring cloud：一些独立的服务共同组成系统,各个服务独立部署，各个服务独立维护开发，利用分布式进行管理，按照业务划分组织。

四、微服务、服务降级与服务熔断

微服务
需要考虑的问题：
1.客户端如何访问这些服务：
利用代理（API Gateway）提供统一的访问入口，统一管理所有微服务，使所有服务对前台透明，还通过过滤等管理功能。

2.服务之间是如何通信的：
异步方式：使用消息队列；同步方式：使用rpc（dubbo）
同步异步区别：同步需要等待结果，一致性强；异步不去要等待结果，一致性弱，需要保证数据的最终一致性。

3.如何发现如此多的服务：服务之间如何相互感知、发现，利用zookeeper注册服务。

4.服务挂了该如何解决：微服务宕机如何保证系统正常使用，服务降级（系统异常之后返回给用户的统一的结果或页面）、服务熔断（服务异常后暂停服务）。

服务降级：自动降级：超时、失败次数（通过超时和访问失败次数决定是否降级，采用异步机制探测回复情况）、故障（如网络故障等）、限流（当访问量到达一定高度后续请求进行降级）。
人工降级：秒杀、双11大促等，手动对一些服务进行降级，保证系统的稳定运行。

服务降级要考虑的问题：
1.哪些服务可以降级：核心服务、非核心服务
2.哪些服务可以支持降级，制定降级策略
3.业务放通场景，策略

Hystrix:这个类提供了强大的服务降级功能
1.在通过第三方客户端访问（通常是通过网络）依赖服务出现高延迟或者失败时，为系统提供保护和控制。
2.在分布式系统中防止联级失败
3.快速失败（Fail fast）同时能快速恢复
4.提供失败回退（Fallback）和优雅的服务降级机制
5.提供近实时的监控、报警和运维控制手段

java内存模型的同步操作与规则
Lock,Unlock,Read,Load,Use,Assign,Store,Write

五、数据库的分库分表