Javaのマルチスレッドと並行性の高い:高い同時ソリューション

Javaのマルチスレッドと並行性の高い:高い同時ソリューション

言葉の122018.11.21九時55分30秒数は4228 1553を読みます

出典:http://www.wangtianyi.top/blog/2018/05/11/javaduo-xian-cheng-yu-gao-bing-fa-liu-gao-bing-fa-jie-jue-si-lu/

同時並行性キャッシュ

 

 
image.png


同じデータにアクセスするための多数の要求がキャッシュされていない場合は、それもそう、整合性の問題につながることができ、データベースに過度の圧力が生じたデータベースを多数の要求を送信します解决方式就是在缓存获取的时候加上针对单个数据的锁,直到缓存被重建成功得到最新数据

 

キャッシュの内訳/浸透

 
image.png

 

誰か悪意のある損傷は、おそらくDB上の過度の直接的な圧力によって引き起こされている場合、クエリデータは、存在していない製品の情報、クエリID、DBに毎回アクセスとして、データベースに存在しません。

ソリューション:

データベース内の対応するデータが存在しない場合、クエリデータによるキーGoは、我々が表示されたら、このキーは、デフォルト値として値セットに対応します。

キャッシュの無効化

並行性の高い環境では、この時点でのキーは、対応するキャッシュ無効化は、複数のプロセスが同時に存在する場合にDBを照会するために移動し、移動してキャッシュを設定するかどうか。このキーは、ホットキーシステムや、比較的長い時間の同時故障の数である場合には、この時間は、DBトラフィックが瞬時に過度の圧力が生じ、増加します。

ソリューション:

  • 一様にオフセットキャッシュミスのキーシステム時間。
  • 私たちは、この時点でキークエリデータ、最初のクエリキャッシュ、クエリキャッシュを経由しないにすると、ロックをロックして配布すること。

ホットキー

同じマシンへのすべてのトラフィックの群れことをクラスタ内のマシンを格納された値に対応する(販売促進商品の可能性のあるアプリケーションを含む)いくつかの重要なキャッシュは、そう、システムがボトルネックとなり、問題の課題は、それが増加し、機械によってできないことです解決するには、容量。
ソリューション:

  • ホットキークライアントキャッシュ:ホットキーの値とローカルクライアントでキャッシュ、およびデッドタイムを設定し、対応します。
  • ホット複数のサブキーのキーに分散し、次に別のマシンにキャッシュ・クラスタに格納されているが、ホットキーおよび値に対応するサブキーは同じです。

メッセージキュー

メッセージ矛盾に起因する生産と消費の速さの問題を解決するためのキュー、次のようなメリット:

  1. 减少请求响应时间。比如注册功能需要调用第三方接口来发短信,如果等待第三方响应可能会需要很多时间
  2. 服务之间解耦。主服务只关心核心的流程,其他不重要的、耗费时间流程是否如何处理完成不需要知道,只通知即可
  3. 流量削锋。对于不需要实时处理的请求来说,当并发量特别大的时候,可以先在消息队列中作缓存,然后陆续发送给对应的服务去处理

如果想要实现一个消息队列,可以参考这里
最简单的消息队列就是一个消息转发器,基本功能只有三个:消息存储、消息发送、消息删除,可使用LinkedBlockingQueue、ConcurrentLinkedQueue实现

应用拆分

之前翻译过的一篇博文已经提到,如何将已经存在的巨无霸单体应用重构成微服务,点击上面链接即可

限流

 
image.png

 

限流是为了解决高并发情况下,大量请求导致数据库或服务器压力过大出现延迟或出错的方式,在图中,如果一次性将100多万数据发送给master库,那么服务器与数据库的IO性能将会被大量占用,导致其他服务对数据库的不可用,master库还需要很久的时间将数据同步给slave库

控制某段代码在一定时间内的执行次数,可通过Guava或Semaphore实现

数据库切库、分库、分表

切库:数据库读写分离导致的数据库切换操作

当单个数据库的读写性能达到瓶颈的时候,可根据业务来判断读与写的比重,然后通过将数据库设置为Master-Slave模式完成读写分离并配置好所有库的读写权限。
当查询业务多余读取业务的时候,通过负载均衡,将查询的操作分担给不同的从库,从而减轻主库的压力。
可以通过Spring注解来完成配置

分库分表

当单库的性能达到瓶颈,或当单表容量达到瓶颈,通过SQL与索引的优化之后还是很慢,那么就需要分表
水平分表:表结构保持不变,根据固定的ID将数据划分到不同表中,需要在写入与查询的时候进行ID的路由
垂直分表:将表结构根据数据的活跃度拆分成多个表,来分别提高不同的单表处理能力
问题:

    • 事务问题。在执行分库之后,由于数据存储到了不同的库上,数据库事务管理出现了困难。如果依赖数据库本身的分布式事务管理功能去执行事务,将付出高昂的性能代价;如果由应用程序去协助控制,形成程序逻辑上的事务,又会造成编程方面的负担。
    • 跨库跨表的join问题。在执行了分库分表之后,难以避免会将原本逻辑关联性很强的数据划分到不同的表、不同的库上,我们无法join位于不同分库的表,也无法join分表粒度不同的表,结果原本一次查询能够完成的业务,可能需要多次查询才能完成。
    • 额外的数据管理负担和数据运算压力。额外的数据管理负担,最显而易见的就是数据的定位问题和数据的增删改查的重复执行问题,这些都可以通过应用程序解决,但必然引起额外的逻辑运算。

おすすめ

転載: www.cnblogs.com/mrchenzheng/p/12124827.html