缓存并发
image.png
当大量请求访问同一个没有被缓存的数据的时候，会发送大量请求给数据库，导致数据库压力过大，还会导致一致性问题，所以解决方式就是在缓存获取的时候加上针对单个数据的锁，直到缓存被重建成功得到最新数据
缓存击穿/穿透
image.png
查询一个数据库中不存在的数据，比如商品详情，查询一个不存在的ID，每次都会访问DB，如果有人恶意破坏，很可能直接对DB造成过大地压力。
解决方案：
当通过某一个key去查询数据的时候，如果对应在数据库中的数据都不存在，我们将此key对应的value设置为一个默认的值。
缓存失效
在高并发的环境下，如果此时key对应的缓存失效，此时有多个进程就会去同时去查询DB，然后再去同时设置缓存。这个时候如果这个key是系统中的热点key或者同时失效的数量比较多时，DB访问量会瞬间增大，造成过大的压力。
解决方案：
- 将系统中key的缓存失效时间均匀地错开。
- 当我们通过key去查询数据时，首先查询缓存，如果此时缓存中查询不到，就通过分布式锁进行加锁。
热点key
缓存中的某些Key(可能对应用与某个促销商品)对应的value存储在集群中一台机器，使得所有流量涌向同一机器，成为系统的瓶颈，该问题的挑战在于它无法通过增加机器容量来解决。
解决方案：
- 客户端热点key缓存：将热点key对应value并缓存在客户端本地，并且设置一个失效时间。
- 将热点key分散为多个子key，然后存储到缓存集群的不同机器上，这些子key对应的value都和热点key是一样的。
消息队列
消息队列是为了解决生产和消费的速度不一致导致的问题，有以下好处：
- 减少请求响应时间。比如注册功能需要调用第三方接口来发短信，如果等待第三方响应可能会需要很多时间
- 服务之间解耦。主服务只关心核心的流程，其他不重要的、耗费时间流程是否如何处理完成不需要知道，只通知即可
- 流量削锋。对于不需要实时处理的请求来说，当并发量特别大的时候，可以先在消息队列中作缓存，然后陆续发送给对应的服务去处理
如果想要实现一个消息队列，可以参考这里
最简单的消息队列就是一个消息转发器，基本功能只有三个：消息存储、消息发送、消息删除，可使用LinkedBlockingQueue、ConcurrentLinkedQueue实现
应用拆分
之前翻译过的一篇博文已经提到，如何将已经存在的巨无霸单体应用重构成微服务，点击上面链接即可
限流
image.png
限流是为了解决高并发情况下，大量请求导致数据库或服务器压力过大出现延迟或出错的方式，在图中，如果一次性将100多万数据发送给master库，那么服务器与数据库的IO性能将会被大量占用，导致其他服务对数据库的不可用，master库还需要很久的时间将数据同步给slave库
控制某段代码在一定时间内的执行次数，可通过Guava或Semaphore实现
数据库切库、分库、分表
切库：数据库读写分离导致的数据库切换操作
当单个数据库的读写性能达到瓶颈的时候，可根据业务来判断读与写的比重，然后通过将数据库设置为Master-Slave模式完成读写分离并配置好所有库的读写权限。
当查询业务多余读取业务的时候，通过负载均衡，将查询的操作分担给不同的从库，从而减轻主库的压力。
可以通过Spring注解来完成配置
分库分表
当单库的性能达到瓶颈，或当单表容量达到瓶颈，通过SQL与索引的优化之后还是很慢，那么就需要分表
水平分表：表结构保持不变，根据固定的ID将数据划分到不同表中，需要在写入与查询的时候进行ID的路由
垂直分表：将表结构根据数据的活跃度拆分成多个表，来分别提高不同的单表处理能力
问题：
- 事务问题。在执行分库之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
- 跨库跨表的join问题。在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
- 额外的数据管理负担和数据运算压力。额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算。