シングルポイントデータベース
データベースのパフォーマンスは、多くの場合、システムのボトルネックである、通常、データベースへの頻繁なアクセスを避けるために、システム設計におけるキャッシュ機構の多様性を紹介しています。一度システムにリンクされているデータベースは、実質的に使用されないためさらに、理由はその重要性のデータベースは、高可用性の要件は、避けられません。
そして、これらは共通の単一制限点データベースに起因する問題、これらの問題を解決し、高い性能を達成するために、高可用性を目的としている、我々は、データベースクラスタシステムアーキテクチャ設計でプログラムを採用する必要があります。
性能試験
データベースのパフォーマンスの問題の一つのポイントがありますので、その後、実際のデータではありませんか？ここでは、どのくらいの程度の同時実行の制限かどうかを確認するために、シングルポイントデータベースの性能試験を実施しなければなりません。私はここ2、コア2Gクラウドサービスは、MySQLバージョン8.0.18を使用していました。
mysqlはツールをテストし、パフォーマンスが付属しています：mysqlslapは、我々はテスト、特定のテストパラメータにツールを使用することができます次のとおりです。
[root@localhost ~]# mysqlslap -hlocalhost -uroot -pyour_password -P3306 --concurrency=500 --iterations=1 --auto-generate-sql --auto-generate-sql-load-type=mixed --auto-generate-sql-add-autoincrement --engine=innodb --number-of-queries=500| 主なパラメータ： |
パラメータ | 説明 |
|---|---|---|
--concurrency |
クライアントの同時数、すなわちシミュレートされた数 | |
--iterations |
何回テストを実行します | |
--auto-generate-sql |
生成されたSQLスクリプトを測定するために、独自のシステムを使用してください | |
--auto-generate-sql-load-type |
読み取りまたは書き込み、またはその両方の組み合わせ（：読み取り、書き込み、更新、混合値）をテストします | |
--auto-generate-sql-add-autoincrement |
増分は自動的に生成されたテーブルの列に追加されます | |
--engine |
ストレージエンジンをテストするには | |
--number-of-queries |
各クライアントのアクセス時間、値は、本実施例では、周波数と各クライアントへの同時アクセスの数で分割されています。500 / 500 = 1 |
- より詳細な公式ドキュメント
ここで私は500、1000と5000の同時接続で、テストの大きさの異なる順序だった、データベースはまた、通常は大きな問題を処理できません。
# 500个并发连接
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.391 seconds
Minimum number of seconds to run all queries: 0.391 seconds
Maximum number of seconds to run all queries: 0.391 seconds
Number of clients running queries: 500
Average number of queries per client: 1
# 1000个并发连接
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 0.802 seconds
Minimum number of seconds to run all queries: 0.802 seconds
Maximum number of seconds to run all queries: 0.802 seconds
Number of clients running queries: 1000
Average number of queries per client: 1
# 5000个并发连接
Benchmark
Running for engine innodb
Average number of seconds to run all queries: 3.884 seconds
Minimum number of seconds to run all queries: 3.884 seconds
Maximum number of seconds to run all queries: 3.884 seconds
Number of clients running queries: 5000
Average number of queries per client: 11ワットの同時接続をテストする場合でも、データベースが間違っているの接続のgettinされません。
このテストケースから、1ワット程度の同時接続についての通常の単一ノードのデータベースのパフォーマンスのボトルネック。もちろん、マシンのハードウェアの違いで、ここでのテスト結果は、参照のみを提供するために、関連します。
PXCクラスタリングソリューション
前のセクションデータベースの問題だけでなく、簡単なパフォーマンステストの単一点の存在に。これらの問題に対処するために、我々は、データベースクラスタ内の単一のポイントに移行する必要があります。
現在のところ、データベース・クラスタリング・ソリューションの数があり、これらのソリューションはどれが良いか悪いかであることもありませんが、唯一のフィット感は良好です。このセクションでは、主流を導入するためのオプションの一つである：PXCのクラスタプログラム以下のように、そのアーキテクチャ図です。
- PXC集群最大的特点就是数据读写的强一致性，在图中的任意一个节点写入数据，其他的节点就一定能读到这个数据。不会出现A节点成功写入，而读B节点时读取不到数据。该特性使得PXC集群适合存储高价值重要数据，因为类似于订单、钱有关的数据基本都有强一致性的要求
上图只是PXC集群最基础的架构，所以还有优化的余地。我们都知道mysql的单表数据处理的性能极限在2千万左右，当数据达到这个量级时，mysql的处理性能就会很低下了。而上图中每个PXC节点都会进行数据的同步，所以当每个节点的数据量级都达到2千万时，整个集群的性能就会降低。
这时就需要增加多一个集群，并且这两个集群之间的数据是不进行同步的。为了让不同的集群存储不同的数据，就得引入Mycat这种数据库中间件将数据进行切分，让数据可以在不同的集群上进行读写，分散存储压力。在这个场景下，一个集群称为一个数据分片。如图：
PXC集群工作原理
我们知道数据库数据的一致性和持久性是通过事务来保证的，而PXC集群的强一致性也是采用了事务，只不过这个事务是分布式事务。
客户端在写入数据完成后，同样需要提交一个事务，在事务内节点之间会进行数据的同步复制。该事务会作用到集群内的所有节点上，保证所有节点要么全写入成功，要么全写入失败。这里用一个时序图表达一下大致流程：
搭建PXC集群需要注意的事项：
- PXC集群中的节点并不是越多越好，节点多并不能提高性能。相反，节点多意味着同步数据所需的耗时就越多，反而会降低性能。通常来讲，一个PXC集群最好是不超过15个节点。若需要更多的节点时，应当搭建一个新的集群，然后用中间件来做分片。
- PXC集群的性能不取决于配置最好的那个节点，而是取决于配置最差的那个节点，这和电脑硬件是类似的。所以我们应当尽量保证PXC集群内的节点配置都趋于一致，避免某个节点配置太差而拖慢了集群的整体性能。
PXC简介
说了那么多，我们还没介绍PXC是个啥玩意呢。PXC是Percona XtraDB Cluster的缩写，PXC是基于mysql自带的Galera集群技术，将不同的mysql实例连接起来，实现的多主集群。在PXC集群中每个mysql节点都是可读可写的，也就是主从概念中的主节点，不存在只读的节点。
PXC可以集群任何mysql的衍生版本，例如MariaDB和Percona Server。由于Percona Server的性能最接近于mysql企业版，性能相对于标准版的mysql有显著的提升，并且对mysql基本兼容。所以在搭建PXC集群时，通常建议基于Percona Server进行搭建。
Replication集群方案
PXC集群的数据强一致性是以牺牲性能为代价的，因为客户端需要等待所有的节点写入数据。而与之相反的一种集群方案就是本小节要介绍的Replication集群。该方案不牺牲性能，但不具有数据强一致性，正可谓鱼和熊掌不可兼得。
所谓读写非强一致的意思就是在A节点成功写入数据，并提交了事务。但在B节点上进行读取时，可能会读取不到写入的数据。
因为这里提交的事务只是该节点的本地事务，只能保证数据成功写入了该节点，而不保证数据成功写入整个集群内的节点。当该节点与其他节点进行数据同步时，可能会由于种种原因没有成功同步数据，从而导致在其他节点上读不到该数据。
所以该集群方案就不适合保存高价值的数据，但对于非高价值的数据，又对读写性能要求高的，就适合采用该集群方案。例如，用户行为日志、操作日志及商品描述等这类非重要的数据。
同样的，上图只是Replication集群最基础的架构，也需要在数据量达到一定规模时采用Mycat对数据进行分片处理。如图：
実際には、大規模なシステムアーキテクチャ、多くの場合、単独のクラスタソリューションの特定の種類ではなく、結合のためのさまざまなプログラム。例えば、PXCクラスタとクラスタレプリケーションはPXCは、高価値データ、クラスタストレージ複製低い値データの記憶をクラスタ化させて、と組み合わせて使用することができます。次に示すように、データを完了し、クラスタ間の断片を管理するようにデータベースミドルウェアMycatを使用しました：
概要
- 強力なクラスタ内のデータの整合性を確保するために、提出するすべてのクラスタノードで同時に提出しない、またはトランザクションまたは同期レプリケーションを使用してPXCクラスター、。ただし、パフォーマンスが相対的に低い、クライアントは、すべてのノードが同期レプリケーションを完了を待つ必要があります
- 非同期レプリケーションを使用してクラスタレプリケーションは、強力なデータの一貫性を保証することはできません。パフォーマンスが比較的高く、クライアントは、すべてのデータノードが正常にコピーを待たずに、正常に送信することができ、対象ノードのローカル業務を待つ必要があります
- PXCレプリケーションクラスタのみデータの同期、データなしのセグメンテーション機能を実現。他のデータベースを導入するために必要なデータの量がMycatセグメンテーションとデータ管理を行うミドルウェアとき
- PXCとレプリケーションのクラスター・アプローチは、排他的ではなく、長所と短所は、相補性を達成するために、と組み合わせて使用することができます。クラスタに格納されているPXC高価値データ、クラスタ複製を低値データストレージ