負載資料庫

⑴ 資料庫系統應如何負載平衡

在做資料庫多台並行前，要先確定數據一致性需要多高，如果可以容忍有時間差的同步，可以考慮用Big Table架構的資料庫來進行處理，否則就是加快取吧，並且盡量把資料庫讀/寫的任務分散來做。
理論上講，合理的作法應該是要組成Database Cluster才對。在Cluster的環境中，Database主機可以有很多台，但是大家的後端都接到同一個外部存儲器（通常是SAN），所有主機都寫入同一個存儲器內的一個資料庫而已，也因為只有一個存儲器、一個資料庫，所以主機之間沒有同步的需要。
負載平衡設備是不能解決資料庫負載過重的問題，但Databse Server性能不足的原因很多，應詳細探究為何性能不足，架Database Cluster能解決部分問題，但不一定能帶來太大性能上的改進。
拆Table結構是一個方法，通常是用在數據量特大的Table才建議，但用這種方式，程序開發人員一定會很痛苦，如果真要採取這種架構，建議程序架構要多一層數據存取層，商業物件不能直接下sql存取資料庫數據，要通過數據存取層元件來存取資料庫數據，才能避免程序工程師的人為錯誤。
建議是先分析資料庫性能瓶頸，再來決定架構。根據經驗，Disk I/O是最大的問題，而造成Disk I/O的原因，通常是Index沒設好，或是程序設計師撰寫的SQL指令，沒考慮到數據增長後的性能問題。

⑵ 請問資料庫加密產品會增加資料庫伺服器的負載嗎

‎做技術都的都‎知道，以‎安華金和資料庫加‎密系統為例，的‎數據‎加解密能力是通‎過部署在數據‎庫伺服器上的TDE插‎件‎與資料庫服務聯‎合實現‎的，因此，肯定會增‎加一‎點資料庫‎服務‎器的負載。資料庫系統為了提升‎性能‎而使用共‎享內存技術和檢查‎點機‎制，‎數據‎庫加‎密系‎統充分利用資料庫系統的自‎身能力而盡量減小了對資料庫服‎務器的額‎外壓力，‎因此，雖然加密系統的‎運行會增‎加‎資料庫伺服器的負載，但不會‎影響太大‎，具體取決於‎數據‎量的‎大小‎和資料庫‎服務的業務繁忙程度。據我了解安華‎金和‎數據‎庫加‎密是國內唯一一款‎對性能影‎響小的產品。如果滿意我的回答，請採納下

⑶ mysql資料庫伺服器CPU負載超過200%，mysqld進程導致的，如何解決

可以先使用 uptime 命令查看 CPU 平均負載
那個 2 users 表示用戶連接數，指的是總連接數。
那個 load average 就是系統平均負載，1 分鍾、5 分鍾、15 分鍾系統負載的平均值。
指的是一段時間內 CPU 正在處理以及等待 CPU 處理的進程數之和的統計信息，也就是 CPU 使用隊列的長度的統計信息。這個數字越小越好。
然後再用 vmstat 命令看下 CPU 是否飽和
這裡面的 r 就是等待 CPU 的進程數，可以用來判定 CPU 是否飽和，當 r 值高於 CPU 數時，就意味著飽和了。
最右邊那個 us，sy，id，wa，st 表示所有 CPU 的使用百分比。它們分別是 user time，system time，idle，wait I/O 和 steal time 的縮寫。將 us 和 sy 的百分比加和，可以確定 CPU 是否處於忙碌狀態。
如果是多核的機器還可以使用 mpstat 命令查看是否均衡
與 CPU 相關的命令還有 pidstat
這個命令展示了 CPU 消耗在了哪些進程上面，消耗過大的進程需要格外關注下。
基本上你使用上述幾個命令 就可以初步了解 CPU 出現了何種問題
有了猜測的方向之後 你就可以進一步深入去排查了

⑷ 怎樣實現資料庫負載均衡集群

集群系統的概要
現在的計算機社會中，持續的提供不停止的服務已經成為通往成功的關鍵。例如僅由於 1
台機器故障或超負荷而宕機就導致對客戶的服務全面停止。這樣的話，不但會帶來莫大的
損失，還會失去客戶的信任。
隨著集群系統的導入，發生意外事故時會將系統停止時間(宕機時間)降低到最小限度、使
負載均衡，提高其可用性。
所謂集群，有「集團」、「團」的意思，顧名思義是「將多個計算機匯集成一群(或者多群)，謀求
提升可靠性及處理性能的系統」。集群系統有多個種類，可分為下列3 種。其中，
NEC ExpressCluster 屬於High Availability 集群。
􀂋 HA (High Availability) 集群
是平時作為運行伺服器作業，在運行伺服器發生故障時將業務交接到待機伺服器的集
群。是以高可用性為目的的集群。包括共享磁碟型、鏡像磁碟型。
􀂋 負載均衡集群
是將客戶端的請求遵從恰當的負荷均衡原則分配給各節點的集群。是以高擴展性為目
的的集群、一般無法進行數據交接。包括load balance 集群、並列資料庫集群。
􀂋 HPC (High Performance Computing)集群
是指計算量非常大的集群。是為使用超級計算機執行單一業務的集群。使用所有節點
的CPU 來執行單一業務的網格計算技術近年來已成為熱點。

⑸ 如何實現mssql資料庫負載均衡

SQL Server 負載均衡集群
一個應用系統隨著業務量的提高,以及訪問量和數據流量的快速增長，各個核心部分的處理性能和計算強度也相應增大，使得單一設備根本無法承擔。在此情況下，如果扔掉現有設備去做大量的硬體升級，必將造成現有資源的浪費，而且下一次業務量的提升，又將導致再一次硬體升級的高額成本投入。於是，負載均衡機制應運而生。 對於應用系統的負載均衡的硬體和軟體比比皆是，因為應用伺服器上的程序基本上認為是不變化的，而且一般的各個應用伺服器上的程序是不交互的。因此應用伺服器的負載均衡非常好做，只需要能夠進行分流的軟體或者硬體把多個客戶端的連接分配到多個應用伺服器上去即可。
因為資料庫內的數據是頻繁變化的，為了數據的一致性以及鎖資源的分配協調等，所以像應用伺服器那樣只有分流是不夠的，各個節點需要頻繁的交互。這也是資料庫集群軟體難做的原因，當然也是賣的貴的原因了。

Oracle Real Application Clusters
對於資料庫負載均衡，大家最為耳熟能詳的就是Oracle RAC了。RAC是雙機並行伺服器(8i及以前版本稱作Oracle Parallel Server，OPS)，用來在集群環境下實現多機共享資料庫，以保證應用的高可用性，同時可以自動實現並行處理及均分負載，還能實現資料庫在故障時的排錯和無斷點恢復。它可以自動進行負載平衡、故障修復和規劃停機時間，以支持高可用性應用程序。若並行伺服器中某節點失效，透明的應用程序容錯能夠把用戶自動轉接到另一節點上繼續運行，應用程序在用戶沒有察覺的情況下繼續執行。這使周期性和非周期性發生故障的系統增大了連續可用性。進程的失效可以完全透明地轉移到另一節點上去，通過適當地配置，可以指定所有查詢都在客戶端進行緩存，這樣它們便可以在轉移後的節點上重新設置。
Moebius for SQL Server
截至到SQL Server 2008，微軟還是沒有推出負載均衡組件，只能靠第三方軟體來實現，好在這個軟體是幾個從微軟出來的人寫的，也算是個小小的巧合。說他們是微軟出來的並不是說他們的技術多厲害，而是他們利用SQL Server的一些內部介面把集群做的非常透明， 無論是應用程序的調用還是開發/管理人員的使用都和面對一個資料庫一樣。
他們的實現原理是這樣的：和SQL Server鏡像一樣，每個資料庫節點都有自己的數據，也就是無共享磁碟架構。他們稱之為「中間件」的程序宿主在資料庫的內部，每個節點資料庫上寫入數據導致數據變化時，SQL Server會激活「中間件」，「中間件」把變化的數據同步到其他的節點上。其他節點發生變化也是一樣。因為「中間件」宿主在資料庫內， 所以它能夠把每個同步的Session和SQL Server的Session綁定到一起，也就是使用戶的執行和數據的同步成為一個原子操作，從而保證數據在每時每刻都是一致的。因此查詢可以隨便到每個機器上去查，從而做到了真正的負載均衡。
這是一種叫"資料庫路由器"的技術,這種技術的特點是靈活性好,但效率比RAC要低，畢竟RAC是在引擎里實現的不管怎麼樣有比沒有強!

⑹ 資料庫架構選型與落地，看這篇就夠了

隨著時間和業務的發展，資料庫中的數據量增長是不可控的，庫和表中的數據會越來越大，隨之帶來的是更高的 磁碟 、 IO 、 系統開銷 ，甚至 性能 上的瓶頸，而單台伺服器的 資源終究是有限 的。

因此在面對業務擴張過程中，應用程序對資料庫系統的 健壯性 ， 安全性 ， 擴展性 提出了更高的要求。

以下，我從資料庫架構、選型與落地來讓大家入門。

資料庫會面臨什麼樣的挑戰呢？

業務剛開始我們只用單機資料庫就夠了，但隨著業務增長，數據規模和用戶規模上升，這個時候資料庫會面臨IO瓶頸、存儲瓶頸、可用性、安全性問題。

為了解決上述的各種問題，資料庫衍生了出不同的架構來解決不同的場景需求。

將資料庫的寫操作和讀操作分離，主庫接收寫請求，使用多個從庫副本負責讀請求，從庫和主庫同步更新數據保持數據一致性，從庫可以水平擴展，用於面對讀請求的增加。

這個模式也就是常說的讀寫分離，針對的是小規模數據，而且存在大量讀操作的場景。

因為主從的數據是相同的，一旦主庫宕機的時候，從庫可以 切換為主庫提供寫入 ，所以這個架構也可以提高資料庫系統的 安全性 和 可用性 ；

優點：

缺點：

在資料庫遇到 IO瓶頸 過程中，如果IO集中在某一塊的業務中，這個時候可以考慮的就是垂直分庫，將熱點業務拆分出去，避免由 熱點業務 的 密集IO請求 影響了其他正常業務，所以垂直分庫也叫 業務分庫 。

優點：

缺點：

在資料庫遇到存儲瓶頸的時候，由於數據量過大造成索引性能下降。

這個時候可以考慮將數據做水平拆分，針對數據量巨大的單張表，按照某種規則，切分到多張表裡面去。

但是這些表還是在同一個庫中，所以庫級別的資料庫操作還是有IO瓶頸（單個伺服器的IO有上限）。

所以水平分表主要還是針對 數據量較大 ，整體業務 請求量較低 的場景。

優點：

缺點：

四、分庫分表

在資料庫遇到存儲瓶頸和IO瓶頸的時候，數據量過大造成索引性能下降，加上同一時間需要處理大規模的業務請求，這個時候單庫的IO上限會限制處理效率。

所以需要將單張表的數據切分到多個伺服器上去，每個伺服器具有相應的庫與表，只是表中數據集合不同。

分庫分表能夠有效地緩解單機和單庫的 性能瓶頸和壓力 ，突破IO、連接數、硬體資源等的瓶頸。

優點：

缺點：

註：分庫還是分表核心關鍵是有沒有IO瓶頸 。

分片方式都有什麼呢？

RANGE（范圍分片）

將業務表中的某個 關鍵欄位排序 後，按照順序從0到10000一個表，10001到20000一個表。最常見的就是 按照時間切分 （月表、年表）。

比如將6個月前，甚至一年前的數據切出去放到另外的一張表，因為隨著時間流逝，這些表的數據被查詢的概率變小，銀行的交易記錄多數是採用這種方式。

優點：

缺點：

HASH（哈希分片）

將訂單作為主表，然後將其相關的業務表作為附表，取用戶id然後 hash取模 ，分配到不同的數據表或者資料庫上。

優點：

缺點：

講到這里，我們已經知道資料庫有哪些架構，解決的是哪些問題，因此， 我們在日常設計中需要根據數據的特點，數據的傾向性，數據的安全性等來選擇不同的架構 。

那麼，我們應該如何選擇資料庫架構呢？

雖然把上面的架構全部組合在一起可以形成一個強大的高可用，高負載的資料庫系統，但是架構選擇合適才是最重要的。

混合架構雖然能夠解決所有的場景的問題，但是也會面臨更多的挑戰，你以為的完美架構，背後其實有著更多的坑。

1、對事務支持

分庫分表後（無論是垂直還是水平拆分），就成了分布式事務了，如果依賴資料庫本身的分布式事務管理功能去執行事務，將付出高昂的性能代價（XA事務）；如果由應用程序去協助控制，形成程序邏輯上的事務，又會造成編程方面的負擔（TCC、SAGA）。

2、多庫結果集合並 （group by，order by）

由於數據分布於不同的資料庫中，無法直接對其做分頁、分組、排序等操作，一般應對這種多庫結果集合並的查詢業務都需要採用數據清洗、同步等其他手段處理（TIDB、KUDU等）。

3、數據延遲

主從架構下的多副本機制和水平分庫後的聚合庫都會存在主數據和副本數據之間的延遲問題。

4、跨庫join

分庫分表後表之間的關聯操作將受到限制，我們無法join位於不同分庫的表（垂直），也無法join分表粒度不同的表（水平）， 結果原本一次查詢就能夠完成的業務，可能需要多次查詢才能完成。

5、分片擴容

水平分片之後，一旦需要做擴容時。需要將對應的數據做一次遷移，成本代價都極高的。

6、ID生成

分庫分表後由於資料庫獨立，原有的基於資料庫自增ID將無法再使用，這個時候需要採用其他外部的ID生成方案。

一、應用層依賴類（JDBC）

這類分庫分表中間件的特點就是和應用強耦合，需要應用顯示依賴相應的jar包（以Java為例），比如知名的TDDL、當當開源的 sharding-jdbc 、蘑菇街的TSharding等。

此類中間件的基本思路就是重新實現JDBC的API，通過重新實現 DataSource 、 PrepareStatement 等操作資料庫的介面，讓應用層在 基本 不改變業務代碼的情況下透明地實現分庫分表的能力。

中間件給上層應用提供熟悉的JDBC API，內部通過 sql解析 、 sql重寫 、 sql路由 等一系列的准備工作獲取真正可執行的sql，然後底層再按照傳統的方法（比如資料庫連接池）獲取物理連接來執行sql，最後把數據 結果合並 處理成ResultSet返回給應用層。

優點

缺點

二、中間層代理類（Proxy）

這類分庫分表中間件的核心原理是在應用和資料庫的連接之間搭起一個 代理層 ，上層應用以 標準的MySQL協議 來連接代理層，然後代理層負責 轉發請求 到底層的MySQL物理實例，這種方式對應用只有一個要求，就是只要用MySQL協議來通信即可。

所以用MySQL Navicat這種純的客戶端都可以直接連接你的分布式資料庫，自然也天然 支持所有的編程語言 。

在技術實現上除了和應用層依賴類中間件基本相似外，代理類的分庫分表產品必須實現標準的MySQL協議，某種意義上講資料庫代理層轉發的就是MySQL協議請求，就像Nginx轉發的是Http協議請求。

比較有代表性的產品有開創性質的Amoeba、阿里開源的Cobar、社區發展比較好的 Mycat （基於Cobar開發）等。

優點

缺點

JDBC方案 ：無中心化架構，兼容市面上大多數關系型資料庫，適用於開發高性能的輕量級 OLTP 應用（面向前台）。

Proxy方案 ：提供靜態入口以及異構語言的支持，適用於 OLAP 應用（面向後台）以及對分片資料庫進行管理和運維的場景。

混合方案 ：在大型復雜系統中存在面向C端用戶的前台應用，也有面向企業分析的後台應用，這個時候就可以採用混合模式。

JDBC 採用無中心化架構，適用於 Java 開發的高性能的輕量級 OLTP 應用；Proxy 提供靜態入口以及異構語言的支持，適用於 OLAP 應用以及對分片資料庫進行管理和運維的場景。

ShardingSphere是一套開源的分布式資料庫中間件解決方案組成的生態圈，它由 Sharding-JDBC 、 Sharding-Proxy 和 Sharding-Sidecar （計劃中）這3款相互獨立的產品組成，他們均提供標准化的數據分片、分布式事務和資料庫治理功能，可適用於如Java同構、異構語言、容器、雲原生等各種多樣化的應用場景。

ShardingSphere提供的核心功能：

Sharding-Proxy

定位為透明化的 資料庫代理端 ，提供封裝了 資料庫二進制協議的服務端版本 ，用於完成對 異構語言的支持 。

目前已提供MySQL版本，它可以使用 任何兼容MySQL協議的訪問客戶端 (如：MySQL Command Client, MySQL Workbench, Navicat等)操作數據，對DBA更加友好。

向 應用程序完全透明 ，可直接當做MySQL使用。

適用於任何兼容MySQL協議的客戶端。

Sharding-JDBC

定位為 輕量級Java框架 ，在Java的JDBC層提供的額外服務。 它使用客戶端直連資料庫，以jar包形式提供服務，無需額外部署和依賴，可理解為 增強版的JDBC驅動，完全兼容JDBC和各種ORM框架 。

以電商SaaS系統為例，前台應用採用Sharding-JDBC，根據業務場景的差異主要分為三種方案。

分庫（用戶）

問題解析：頭部企業日活高並發高，單獨分庫避免干擾其他企業用戶，用戶數據的增長緩慢可以不分表。

拆分維度：企業ID分庫

拆分策略：頭部企業單獨庫、非頭部企業一個庫

分庫分表（訂單）

問題解析：訂單數據增長速度較快，在分庫之餘需要分表。

拆分維度：企業ID分庫、用戶ID分表

拆分策略：頭部企業單獨庫、非頭部企業一個庫，分庫之後用戶ID取模拆分表

單庫分表（附件）

問題解析：附件數據特點是並發量不大，只需要解決數據增長問題，所以單庫IO足以支撐的情況下分表即可。

拆分維度：用戶ID分表

拆分策略：用戶ID取模分表

問題一：分布式事務

分布式事務過於復雜也是分布式系統最難處理的問題，由於篇幅有限，後續會開篇專講這一塊內容。

問題二：分布式ID

問題三：跨片查詢

舉個例子，以用戶id分片之後，需要根據企業id查詢企業所有用戶信息。

sharding針對跨片查詢也是能夠支持的，本質上sharding的跨片查詢是採用同時查詢多個分片的數據，然後聚合結果返回，這個方式對資源耗費比較大，特別是對資料庫連接資源的消耗。

假設分4個資料庫，8個表，則sharding會同時發出32個SQL去查詢。一下子消耗掉了32個連接；

特別是針對單庫分表的情況要注意，假設單庫分64個表，則要消耗64個連接。如果我們部署了2個節點，這個時候兩個節點同時查詢的話，就會遇到資料庫連接數上限問題（mysql默認100連接數）

問題四：分片擴容

隨著數據增長，每個片區的數據也會達到瓶頸，這個時候需要將原有的分片數量進行增加。由於增加了片區，原先的hash規則也跟著變化，造成了需要將舊數據做遷移。

假設原先1個億的數據，hash分64個表，現在增長到50億的數據，需要擴容到128個表，一旦擴容就需要將這50億的數據做一次遷移，遷移成本是無法想像的。

問題五：一致性哈希

首先，求出每個 伺服器的hash值 ，將其配置到一個 0~2^n 的圓環上 （n通常取32）

其次，用同樣的方法求出待 存儲對象的主鍵 hash值 ，也將其配置到這個圓環上。

然後，從數據映射到的位置開始順時針查找，將數據分布到找到的第一個伺服器節點上。

一致性hash的優點在於加入和刪除節點時只會影響到在哈希環中相鄰的節點，而對其他節點沒有影響。

所以使用一致性哈希在集群擴容過程中可以減少數據的遷移。

好了，這次分享到這里，我們日常的實踐可能只會用到其中一種方案，但它不是資料庫架構的全貌，打開技術視野，才能更好地把存儲工具利用起來。

老規矩，一鍵三連，日入兩千，點贊在看，年薪百萬！

本文作者：Jensen

7年Java老兵，小米主題設計師，手機輸入法設計師，ProcessOn特邀講師。

曾涉獵航空、電信、IoT、垂直電商產品研發，現就職於某知名電商企業。

技術公眾號 【架構師修行錄】 號主，專注於分享日常架構、技術、職場干貨，Java Goals：架構師。

交個朋友，一起成長！

⑺ MySQL資料庫負載很高連接數很多怎麼處理

您好，很高興為您解答。

第一先限制Innodb的並發處理.如果innodb_thread_concurrency = 0 可以先改成 16或是64 看機器壓力,如果
非常大,先改成16讓機器的壓力下來,然後慢慢增達,適應自已的業務.
處理方法: set global innodb_thread_concurrency=16;
第二: 對於連接數已經超過600或是更多的情況,可以考慮適當的限制一下連接數,讓前端報一下錯,也別讓DB掛了.
DB在了,總是可以用來載入一下數據,當數據載入到了nosql里了,慢慢的DB壓力也會降下來的.
限制單用戶連接數在500以下. 如:
set global max_user_connections=500;
(MySQL隨著連接數的增加性能會是下降的,這也是thread_pool出現的原因)
另外對於有的監控程序會讀取information_schema下面的表的程序可以考慮關閉下面的參數
innodb_stats_on_metadata=0
set global innodb_stats_on_metadata=0;
這個參數主要防止對讀取information_schema時造成大量讀取磁碟進行信息統計(如果慢查詢中出現關於information_schema中表時,也可以考慮禁用該參數)
處理依據:
當學校的一個食堂一分鍾只能為兩個打飯, 忽然來了100個時人來打飯,又沒排隊, 不出會現了打飯的師傅要用點時間
去選擇為那個用戶服務了, 人越多,場面就越亂, 難免出現用戶大吼該他的場面, 最後有可能就出現不是打飯了,而時之間相互
打架了,打飯的師傅也將收到同時有90個以上的Server too busy. 如果能排一下隊.最多也就50分鍾能處理完了.
以前辦法,應該可以讓MySQLD不會掛掉.如果業務支撐受到限制,還是想辦法處理一下.

如若滿意，請點擊右側【採納答案】，如若還有問題，請點擊【追問】

希望我的回答對您有所幫助，望採納！

~ O(∩_∩)O~

⑻ 如何測試資料庫伺服器的負載性能

哥們的描述很模糊哦，
在線訪問，說明應該有可視化界面，可以使用loadrunner工具去錄制界面操作然後跑並發即可，設置Vuser數，Vuser數一定條件下可以理解為你的在線用戶數。將這個值一直往上加，壓到你的伺服器CPU,MEN,IO等還剩下20%左右的時候得出最大活躍用戶數，然後再反推在線用戶數。
PS：
用戶在線對伺服器的壓力不大，登陸後未必會操作，操作的話也未必會同時操作，壓力點在於活躍用戶數，比如1000個在線，有100個用戶處於活躍狀態，其他900個非活躍狀態。那麼就是1:9.......
至於我說得方法合不合適，還得根據你伺服器的實際情況而論。

⑼ 什麼是資料庫負載均衡

負載均衡集群是由一組相互獨立的計算機系統構成，通過常規網路或專用網路進行連接，由路由器銜接在一起，各節點相互協作、共同負載、均衡壓力，對客戶端來說，整個群集可以視為一台具有超高性能的獨立伺服器。