Java multi-threaded and highly concurrent: high concurrent Solutions
Cache Concurrency
When a large number of requests to access the same data is not cached, it will send a large number of requests to the database, the database resulting in excessive pressure, can also lead to consistency problems, so解决方式就是在缓存获取的时候加上针对单个数据的锁，直到缓存被重建成功得到最新数据
Cache breakdown / penetration
Query data does not exist in a database, such as product information, query ID that does not exist, every time access to DB, if someone malicious damage, probably caused by an excessive direct pressure on the DB.
solution:
When a key go through a query data, if the corresponding data in the database does not exist, we see this key corresponding to the value set as a default value.
Cache invalidation
In a highly concurrent environment, the key at this time if the corresponding cache invalidation, when there are multiple processes at the same time will go to query the DB, and then go and set the cache. This time if this key is the hot key system or the number of simultaneous failure of relatively long time, DB traffic will instantly increase, resulting in excessive pressure.
solution:
- The key system time of a cache miss uniformly offset.
- When we go through the key query data, first query cache, query cache at this time if not, then be distributed by locking the lock.
Hot key
Some Key cache (with the possible application of a promotional merchandise) corresponding to the value stored in the cluster a machine, so that all traffic flock to the same machine, the system becomes a bottleneck, the challenge of the problem is that it can not by increasing machine capacity to resolve.
solution:
- Hot key Client cache: The hot key value and a corresponding locally cached at the client, and sets a dead time.
- The hot dispersion into multiple sub-key key, and then stored in the cache cluster on a different machine, the sub-key corresponding to the hot key and value are the same.
message queue
Message queues to solve the problem of speed of production and consumption caused by the inconsistency, the following benefits:
- 减少请求响应时间。比如注册功能需要调用第三方接口来发短信，如果等待第三方响应可能会需要很多时间
- 服务之间解耦。主服务只关心核心的流程，其他不重要的、耗费时间流程是否如何处理完成不需要知道，只通知即可
- 流量削锋。对于不需要实时处理的请求来说，当并发量特别大的时候，可以先在消息队列中作缓存，然后陆续发送给对应的服务去处理
如果想要实现一个消息队列，可以参考这里
最简单的消息队列就是一个消息转发器，基本功能只有三个：消息存储、消息发送、消息删除，可使用LinkedBlockingQueue、ConcurrentLinkedQueue实现
应用拆分
之前翻译过的一篇博文已经提到，如何将已经存在的巨无霸单体应用重构成微服务，点击上面链接即可
限流
限流是为了解决高并发情况下，大量请求导致数据库或服务器压力过大出现延迟或出错的方式，在图中，如果一次性将100多万数据发送给master库，那么服务器与数据库的IO性能将会被大量占用，导致其他服务对数据库的不可用，master库还需要很久的时间将数据同步给slave库
控制某段代码在一定时间内的执行次数，可通过Guava或Semaphore实现
数据库切库、分库、分表
切库：数据库读写分离导致的数据库切换操作
当单个数据库的读写性能达到瓶颈的时候，可根据业务来判断读与写的比重，然后通过将数据库设置为Master-Slave模式完成读写分离并配置好所有库的读写权限。
当查询业务多余读取业务的时候，通过负载均衡，将查询的操作分担给不同的从库，从而减轻主库的压力。
可以通过Spring注解来完成配置
分库分表
当单库的性能达到瓶颈，或当单表容量达到瓶颈，通过SQL与索引的优化之后还是很慢，那么就需要分表
水平分表：表结构保持不变，根据固定的ID将数据划分到不同表中，需要在写入与查询的时候进行ID的路由
垂直分表：将表结构根据数据的活跃度拆分成多个表，来分别提高不同的单表处理能力
问题：
- 事务问题。在执行分库之后，由于数据存储到了不同的库上，数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价；如果由应用程序去协助控制，形成程序逻辑上的事务，又会造成编程方面的负担。
- 跨库跨表的join问题。在执行了分库分表之后，难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上，我们无法join位于不同分库的表，也无法join分表粒度不同的表，结果原本一次查询能够完成的业务，可能需要多次查询才能完成。
- 额外的数据管理负担和数据运算压力。额外的数据管理负担，最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题，这些都可以通过应用程序解决，但必然引起额外的逻辑运算。