Java多线程和高并发：高并发解决方案
122018.11.210933605336030字数1，553读5，258
并发高速缓存
image.png
如果请求大量访问同一未缓存的数据，则会向数据库发送大量请求，这会增加数据库压力，并导致一致性问题。 因此，解决方案是在获取缓存时锁定单个数据，直到缓存重建并获得最新数据
高速缓存中断/中断
image.png
每次查询数据库中不存在的数据(如商品详细信息)或不存在的ID时，都会访问数据库。 如果有人恶意破坏，可能会直接给数据库带来过大的压力。
解决方案：
在某个key中查询数据时，如果数据库中不存在对应的数据，则将与此key对应的value设置为默认值。
禁用缓存
在高并发环境中，如果此时禁用了与密钥对应的缓存，则多个进程会同时去检查数据库，然后再同时设置缓存。 此时，在该key是系统上的热点key的情况下，或者同时失效的数量多的情况下，DB访问量瞬间增大，压力过大。
解决方案：
均匀偏移系统中key的缓存过期时间。
在key中查询数据时，首先查询缓存，如果此时无法在缓存中查询，则使用分布式锁定进行锁定。
热点密钥
与缓存中的几个密钥(可能会将促销产品应用于APP应用)相对应的value存储在群集中的一台计算机上，所有通信都涌向同一台计算机，成为系统瓶颈。 这个问题的挑战是不能通过增加机器容量来解决。
解决方案：
客户端热点key缓存：将热点key与value对应并在客户端本地缓存，以设置过期时间。
将热点key分布在多个子key上，并将其存储在缓存群集的不同计算机上。 与这些子key对应的value与热点key相同。
消息队列
消息队列具有以下优势，可以解决由于生产和消费速度不匹配而导致的问题：
缩短请求的响应时间。 例如，注册功能需要调用第三方接口来发送消息，这可能需要很多时间等待第三方的响应
解除服务之间的结合。 主服务只关心核心流程，不需要知道其他不重要的、耗时的流程是如何处理完成的，只需要通知即可
削减流量。 在不需要实时处理请求的情况下，在并发量非常大时，可以在消息队列中缓存，然后依次发送到对应的服务进行处理
如果您想实现消息队列，请访问此处
最简单的消息队列是消息转发器，它的基本功能只有三个：消息存储库、消息发送和消息删除，可以使用LinkedBlockingQueue和ConcurrentLinkedQueue实现
根据以前翻译的博客，单击上面的链接可以了解如何将现有的巨无霸单体APP应用程序重新配置为微服务
极限流
image.png
流限制是一种解决在高并发性情况下，大量请求会增加数据库和服务器压力，从而导致延迟和错误的方法。 在图中，一次将100多万个数据发送到master库会占用大量服务器和数据库I/o性能，导致其他服务无法访问数据库，master库将数据同步到slave库
控制某个代码在一定时间内的执行次数可以通过Guava或Semaphore来实现
数据库剪切、库和表
库剪切：通过读写数据库隔离切换数据库的操作
如果单个数据库的读和写性能遇到瓶颈，则可以根据业务确定读和写的比重，并将数据库设置为Master-Slave模式，从而完成读和写隔离，实现所有库
查询业务额外读取业务时，通过负载均衡将查询操作分担到不同的从站，从而减轻主库的压力。
可以用Spring注释设置
如果单库性能遇到瓶颈，或者即使单表容量遇到瓶颈，SQL和索引优化也会导致速度变慢，则必须将表分开
水平分割表：表结构保持不变，需要根据固定的ID将数据分成不同的表，在写入和查询时进行ID路由
垂直分割表：根据数据的活跃度将表结构分割为多个表，分别提高不同的单表处理能力
问题：
事务问题。 运行库后，数据库事务很难管理，因为数据存储在单独的库中。 如果依赖数据库本身的分布式事务管理功能来执行事务，则需要较高性能成本的APP应用程序配合控制，形成程序的逻辑事务，这将增加编程负担。
库之间的交叉表连接问题。 运行分区表后，不可避免地将原本在逻辑上具有相关性的数据划分为不同的表、不同的库。 我们不能连接到不同库中的表，也不能连接到表粒度不同的表。 结果，本来一次查询就能完成的业务，可能需要多次查询才能完成。
额外的数据管理负担和数据运算压力。 额外的数据管理负担最明显的是数据定位问题和重复添加/删除/重新评估数据的问题，所有这些都可以在APP应用程序中解决，但必然导致额外的逻辑运算。