高並行システムが異なります。第二同時ミドルウェア・システム、ゲートウェイシステム要求の何千もの第二の瞬間スパイク大きなプロモーションシステムの何百ものあたり毎日百億リクエストあたりの例メガビットのため。
それらがので、各システムの特性の異なる、高い並行性を扱うので、アーキテクチャに対処するとき、それは同じではありません。
また、並行性の高いシナリオでの注文システム、商品システム、在庫管理システムアーキテクチャ設計で、このような電子ビジネスプラットフォームは、異なっているため、異なるものの舞台裏事業。
最も単純なシステムアーキテクチャ
、システムだけでデータベースに接続し、その背後にあるマシン上に展開され始めている、データベースを単一のサーバーにデプロイされていることを前提としています。
あなたも、データベースサーバは、16コア32Gは、あなたのシステム展開マシンは4コア8Gで、例を挙げて、現実的になりたいことがあります。
このとき、異なるシステムの状況に応じて差別化加入者10万人、登録者数、日活のユーザーの合計にあなたのシステムを想定し、我々はより客観割合、それの10％、毎日のアクティブユーザー10000を取ります。
28が法律に基づいて、それは一日4時間のピークと考えられ、80％を占めアクティブユーザーのピークは、その4時間に積極的に8,000人です。
次に、あなたのシステム上の誰もが要求を開始し、我々は彼が正しいと20回の日を数えます。その後も4時間以内（14400秒）を平均化する毎秒もわずか16万回、毎秒10個の要求8000-開始した要求のピーク。
すべての権利！同時実行性の高い完全な権利、シェアを取りますか？
次に、システムレベルが第2の要求あたり10回で、要求ごとにデータベースへの呼び出しは、クラッド等を行うなど、いくつかのデータベース操作を、有することになります。
だから我々は、これはデータベース層は右、また、1秒間に30のリクエストの場合であることを、最初の要求は、データベースがそれを要求した3回に対応取りますか？
この構成データベースサーバーのサポートによると、全く問題ありません。ビュー示すと、上述したシステムは、これは以下の通りです。
画像
システムクラスタの展開
など、登録ユーザの量として、あなたが急速な成長を始めるユーザー数が500万台に上昇し、50倍に増加したと仮定して、。
この時点日活50万ユーザー、秒あたりの要求のピーク時には、システムは、500 / sです。そして、第二の数あたりのデータベース要求は何が起こるか、この時間、1500 / sのでしょうか？
お使いのシステム内の処理は、いくつかのビジネスロジック、ビジネス・ロジックが重いシステムの一種である、より複雑である場合は、上記のマシン構成によると、その後、比較的時間のかかるCPUです。
この時点で、毎秒4コア8G要求はマシンが500 / sに達したとき、あなたが高いCPUがマシンをロードしていることがわかります可能性があります。
次に、データベース・レベルは、上記構成の点で、実際には、実質的にその後まだ許容1500 / S要求圧力ピーク。
これは、データベースのディスク負荷、ネットワーク負荷、CPU負荷、メモリ負荷マシンを観察するために主に、当社のオンライン経験に基づいて、構成データベースには、1500 / sの要求に圧力下に問題はありません。
だから今は、最初は、あなたのシステムクラスタの展開をサポートすることで、事を行う必要があります。
あなたは、負荷分散層の前にハングアップすることができ、要求は、均一なシステムレベルのヒット、システムは、複数のクラスタ化されたマシンを使用することができ、より高い同時実行性の圧力をサポートしています。
例えば、システムは、機械の配置、各マシンのみ250リクエスト/秒のものとします。
その結果、2台のマシンが大幅にCPUの負荷を軽減します、この最初の「高い同時実行」は、第1のカバーにそれを生きる上ではないのですか？
でも、これが行われていない場合は、極端な場合には、その単一のマシンの負荷が高いと高いが、要求に対応するための十分なリソースを持つことができないマシン上でシステムを展開することが可能である、との要求も、システムのダウンタイムの、こだわって表示されたとき問題のクラス。
だから、簡単な要約、最初のステップ：
- 負荷分散層を追加し、層系の要求が均等にヒット。
- 複数のマシンのクラスタの展開、カン朱予備同時圧力を使用してシステム層。
画像
数据库分库分表 + 读写分离
假设此时用户量继续增长，达到了 1000 万注册用户，然后每天日活用户是 100 万。
那么此时对系统层面的请求量会达到每秒 1000/s，系统层面，你可以继续通过集群化的方式来扩容，反正前面的负载均衡层会均匀分散流量过去的。
但是，这时数据库层面接受的请求量会达到 3000/s，这个就有点问题了。
此时数据库层面的并发请求翻了一倍，你一定会发现线上的数据库负载越来越高。
每次到了高峰期，磁盘 IO、网络 IO、内存消耗、CPU 负载的压力都会很高，大家很担心数据库服务器能否抗住。
没错，一般来说，对那种普通配置的线上数据库，建议就是读写并发加起来，按照上述我们举例的那个配置，不要超过 3000/s。
因为数据库压力过大，首先一个问题就是高峰期系统性能可能会降低，因为数据库负载过高对性能会有影响。
另外一个，压力过大把你的数据库给搞挂了怎么办？
所以此时你必须得对系统做分库分表 + 读写分离，也就是把一个库拆分为多个库，部署在多个数据库服务上，这是作为主库承载写入请求的。
然后每个主库都挂载至少一个从库，由从库来承载读请求。
此时假设对数据库层面的读写并发是 3000/s，其中写并发占到了 1000/s，读并发占到了 2000/s。
那么一旦分库分表之后，采用两台数据库服务器上部署主库来支撑写请求，每台服务器承载的写并发就是 500/s。
每台主库挂载一个服务器部署从库，那么 2 个从库每个从库支撑的读并发就是 1000/s。
简单总结，并发量继续增长时，我们就需要 focus 在数据库层面：分库分表、读写分离。
此时的架构图如下所示：
image
缓存集群引入
接着就好办了，如果你的注册用户量越来越大，此时你可以不停的加机器，比如说系统层面不停加机器，就可以承载更高的并发请求。
然后数据库层面如果写入并发越来越高，就扩容加数据库服务器，通过分库分表是可以支持扩容机器的，如果数据库层面的读并发越来越高，就扩容加更多的从库。
但是这里有一个很大的问题：数据库其实本身不是用来承载高并发请求的，所以通常来说，数据库单机每秒承载的并发就在几千的数量级，而且数据库使用的机器都是比较高配置，比较昂贵的机器，成本很高。
如果你就是简单的不停的加机器，其实是不对的。
所以在高并发架构里通常都有缓存这个环节，缓存系统的设计就是为了承载高并发而生。
所以单机承载的并发量都在每秒几万，甚至每秒数十万，对高并发的承载能力比数据库系统要高出一到两个数量级。
所以你完全可以根据系统的业务特性，对那种写少读多的请求，引入缓存集群。
具体来说，就是在写数据库的时候同时写一份数据到缓存集群里，然后用缓存集群来承载大部分的读请求。
这样的话，通过缓存集群，就可以用更少的机器资源承载更高的并发。
比如说上面那个图里，读请求目前是每秒 2000/s，两个从库各自抗了 1000/s 读请求，但是其中可能每秒 1800 次的读请求都是可以直接读缓存里的不怎么变化的数据的。
那么此时你一旦引入缓存集群，就可以抗下来这 1800/s 读请求，落到数据库层面的读请求就 200/s。
同样，给大家来一张架构图，一起来感受一下：
image
按照上述架构，它的好处是什么呢？
可能未来你的系统读请求每秒都几万次了，但是可能 80%~90% 都是通过缓存集群来读的，而缓存集群里的机器可能单机每秒都可以支撑几万读请求，所以耗费机器资源很少，可能就两三台机器就够了。
你要是换成是数据库来试一下，可能就要不停的加从库到 10 台、20 台机器才能抗住每秒几万的读并发，那个成本是极高的。
好了，我们再来简单小结，承载高并发需要考虑的第三个点：
- 不要盲目进行数据库扩容，数据库服务器成本昂贵，且本身就不是用来承载高并发的。
- 针对写少读多的请求，引入缓存集群，用缓存集群抗住大量的读请求。
image
大家看上面的架构图，首先消息中间件系统本身也是为高并发而生，所以通常单机都是支撑几万甚至十万级的并发请求的。
所以，它本身也跟缓存系统一样，可以用很少的资源支撑很高的并发请求，用它来支撑部分允许异步化的高并发写入是没问题的，比使用数据库直接支撑那部分高并发请求要减少很多的机器使用量。
而且经过消息中间件的削峰填谷之后，比如就用稳定的 100/s 的速度写数据库，那么数据库层面接收的写请求压力，不就成了 500/s + 100/s = 600/s 了么？
大家看看，是不是发现减轻了数据库的压力？到目前为止，通过下面的手段，我们已经可以让系统架构尽可能用最小的机器资源抗住了最大的请求压力，减轻了数据库的负担：
- 系统集群化。
- 数据库层面的分库分表+读写分离。
- 针对读多写少的请求，引入缓存集群。
- 针对高写入的压力，引入消息中间件集群。
- 各种复杂的自研基础架构系统。
- 各种精妙的架构设计（比如热点缓存架构设计、多优先级高吞吐 MQ 架构设计、系统全链路并发性能优化设计，等等）。
- 还有各种复杂系统组合而成的高并发架构整体技术方案。
- 还有 NoSQL（Elasticsearch 等）/负载均衡/Web 服务器等相关技术。