摘要：雙機熱備和備份的區(qū)別熱備份指的是即高可用，而備份指的是即數(shù)據(jù)備份的一種，這是兩種不同的概念，應對的產(chǎn)品也是兩種功能上完全不同的產(chǎn)品。雙機熱備分類按工作中的切換方式分為主備方式方式和雙主機方式方式。

歡迎關(guān)注公眾號：【愛編碼】
如果有需要后臺回復2019贈送1T的學習資料哦??！

注：本文大都來自互聯(lián)網(wǎng)，文字較多，基本是概念，若想深入了解，還需各位自己找文章研究。

表鎖的優(yōu)勢：開銷小；加鎖快；無死鎖
表鎖的劣勢：鎖粒度大，發(fā)生鎖沖突的概率高，并發(fā)處理能力低
加鎖的方式：自動加鎖。查詢操作（SELECT），會自動給涉及的所有表加讀鎖，更新操作（UPDATE、DELETE、INSERT），會自動給涉及的表加寫鎖。也可以顯示加鎖：

共享讀鎖：lock table tableName read;
獨占寫鎖：lock table tableName write;
批量解鎖：unlock tables;

InnoDB默認采用行鎖，在未使用索引字段查詢時升級為表鎖。
即便你在條件中使用了索引字段，MySQL會根據(jù)自身的執(zhí)行計劃，考慮是否使用索引(所以explain命令中會有possible_key 和 key)。
如果MySQL認為全表掃描效率更高，它就不會使用索引，這種情況下InnoDB將使用表鎖，而不是行鎖。因此，在分析鎖沖突時，別忘了檢查SQL的執(zhí)行計劃，以確認是否真正使用了索引。

第一種情況：全表更新。事務需要更新大部分或全部數(shù)據(jù)，且表又比較大。若使用行鎖，會導致事務執(zhí)行效率低，從而可能造成其他事務長時間鎖等待和更多的鎖沖突。

第二種情況：多表查詢。事務涉及多個表，比較復雜的關(guān)聯(lián)查詢，很可能引起死鎖，造成大量事務回滾。這種情況若能一次性鎖定事務涉及的表，從而可以避免死鎖、減少數(shù)據(jù)庫因事務回滾帶來的開銷。

行鎖的劣勢：開銷大；加鎖慢；會出現(xiàn)死鎖
行鎖的優(yōu)勢：鎖的粒度小，發(fā)生鎖沖突的概率低；處理并發(fā)的能力強
加鎖的方式：自動加鎖。對于UPDATE、DELETE和INSERT語句，InnoDB會自動給涉及數(shù)據(jù)集加排他鎖；對于普通SELECT語句，InnoDB不會加任何鎖；當然我們也可以顯示的加鎖：

共享鎖：select * from tableName where … + lock in share more
排他鎖：select * from tableName where … + for update

1 盡可能讓所有數(shù)據(jù)檢索都通過索引來完成，避免無索引行或索引失效導致行鎖升級為表鎖。
2 盡可能避免間隙鎖帶來的性能下降，減少或使用合理的檢索范圍。
3 盡可能減少事務的粒度，比如控制事務大小，而從減少鎖定資源量和時間長度，從而減少鎖的競爭等，提供性能。
4 盡可能低級別事務隔離，隔離級別越高，并發(fā)的處理能力越低。

InnoDB和MyISAM的最大不同點有兩個：
一，InnoDB支持事務(transaction)；
二，默認采用行級鎖。加鎖可以保證事務的一致性，可謂是有人(鎖)的地方，就有江湖(事務)；我們先簡單了解一下事務知識。

事務是由一組SQL語句組成的邏輯處理單元，事務具有ACID屬性。
原子性（Atomicity）：事務是一個原子操作單元。在當時原子是不可分割的最小元素，其對數(shù)據(jù)的修改，要么全部成功，要么全部都不成功。
一致性（Consistent）：事務開始到結(jié)束的時間段內(nèi)，數(shù)據(jù)都必須保持一致狀態(tài)。
隔離性（Isolation）：數(shù)據(jù)庫系統(tǒng)提供一定的隔離機制，保證事務在不受外部并發(fā)操作影響的”獨立”環(huán)境執(zhí)行。
持久性（Durable）：事務完成后，它對于數(shù)據(jù)的修改是永久性的，即使出現(xiàn)系統(tǒng)故障也能夠保持。

臟讀，不可重復讀，幻讀，其實都是數(shù)據(jù)庫讀一致性問題，必須由數(shù)據(jù)庫提供一定的事務隔離機制來解決。

https://www.cnblogs.com/zyy16...
https://www.cnblogs.com/itdra...

雙機熱備
雙機熱備特指基于高可用系統(tǒng)中的兩臺服務器的熱備（或高可用），因兩機高可用在國內(nèi)使用較多，故得名雙機熱備。
從廣義上講，就是對于重要的服務，使用兩臺服務器，互相備份，共同執(zhí)行同一服務。當一臺服務器出現(xiàn)故障時，可以由另一臺服務器承擔服務任務，從而在不需要人工干預的情況下，自動保證系統(tǒng)能持續(xù)提供服務。

雙機熱備和備份的區(qū)別
熱備份指的是：High Available（HA）即高可用，而備份指的是Backup,即數(shù)據(jù)備份的一種，這是兩種不同的概念，應對的產(chǎn)品也是兩種功能上完全不同的產(chǎn)品。熱備份主要保障業(yè)務的連續(xù)性，實現(xiàn)的方法是故障點的轉(zhuǎn)移。而備份，主要目的是為了防止數(shù)據(jù)丟失，而做的一份拷貝，所以備份強調(diào)的是數(shù)據(jù)恢復而不是應用的故障轉(zhuǎn)移。

按工作中的切換方式分為：
主-備方式（Active-Standby方式）和雙主機方式（Active-Active方式）。

主-備方式即指的是一臺服務器處于某種業(yè)務的激活狀態(tài)（即Active狀態(tài)），另一臺服務器處于該業(yè)務的備用狀態(tài)（即Standby狀態(tài))。

雙主機方式即指兩種不同業(yè)務分別在兩臺服務器上互為主備狀態(tài)（即Active-Standby和Standby-Active狀態(tài)）。

簡單的說就是把 一個服務器上執(zhí)行過的sql語句在別的服務器上也重復執(zhí)行一遍， 這樣只要兩個數(shù)據(jù)庫的初態(tài)是一樣的，那么它們就能一直同步。
當然這種復制和重復都是mysql自動實現(xiàn)的，我們只需要配置即可。
我們進一步詳細介紹原理的細節(jié)， 這有一張圖：

上圖中有兩個服務器， 演示了從一個主服務器（master） 把數(shù)據(jù)同步到從服務器（slave）的過程。
這是一個主-從復制的例子。 主-主互相復制只是把上面的例子反過來再做一遍。 所以我們以這個例子介紹原理。
對于一個mysql服務器， 一般有兩個線程來負責復制和被復制。當開啟復制之后。

1. 作為主服務器Master，? 會把自己的每一次改動都記錄到 二進制日志 Binarylog 中。 （從服務器會負責來讀取這個log， 然后在自己那里再執(zhí)行一遍。）

2. 作為從服務器Slave， 會用master上的賬號登陸到 master上， 讀取master的Binarylog,? 寫入到自己的中繼日志 Relaylog， 然后自己的sql線程會負責讀取這個中繼日志，并執(zhí)行一遍。? 到這里主服務器上的更改就同步到從服務器上了。

在mysql上可以查看當前服務器的主，從狀態(tài)。 其實就是當前服務器的 Binary（作為主服務器角色）狀態(tài)和位置。 以及其RelayLog（作為從服務器）的復制進度。

參考下面各位大神的配置吧，他們寫得太好了，太詳細了。我就收藏一下。
https://yunnick.iteye.com/blo...
https://www.cnblogs.com/shuid...
https://www.cnblogs.com/fnlin...

基本思想就要把一個數(shù)據(jù)庫切分成多個部分放到不同的數(shù)據(jù)庫(server)上，從而緩解單一數(shù)據(jù)庫的性能問題。

當一張表的數(shù)據(jù)達到幾千萬時，你查詢一次所花的時間會變多，如果有聯(lián)合查詢的話，我想有可能會死在那兒了。分表的目的就在于此，減小數(shù)據(jù)庫的負擔，縮短查詢時間。

垂直切分

一個數(shù)據(jù)庫由很多表的構(gòu)成，每個表對應著不同的業(yè)務，垂直切分是指按照業(yè)務將表進行分類，分布到不同的數(shù)據(jù)庫上面，這樣也就將數(shù)據(jù)或者說壓力分擔到不同的庫上面

優(yōu)點：

    1. 拆分后業(yè)務清晰，拆分規(guī)則明確。
    2. 系統(tǒng)之間整合或擴展容易。
    3. 數(shù)據(jù)維護簡單。

缺點：

    1. 部分業(yè)務表無法join，只能通過接口方式解決，提高了系統(tǒng)復雜度。
    2. 受每種業(yè)務不同的限制存在單庫性能瓶頸，不易數(shù)據(jù)擴展跟性能提高。
    3. 事務處理復雜。

水平切分

相對于垂直拆分的區(qū)別是：垂直拆分是把不同的表拆到不同的數(shù)據(jù)庫中，而水平拆分是把同一個表拆到不同的數(shù)據(jù)庫中。

優(yōu)點：

    1. 不存在單庫大數(shù)據(jù)，高并發(fā)的性能瓶頸。
    2. 對應用透明，應用端改造較少。     
    3. 按照合理拆分規(guī)則拆分，join操作基本避免跨庫。
    4. 提高了系統(tǒng)的穩(wěn)定性跟負載能力。

缺點：

    1. 拆分規(guī)則難以抽象。
    2. 分片事務一致性難以解決。
    3. 數(shù)據(jù)多次擴展難度跟維護量極大。
    4. 跨庫join性能較差。

小結(jié)

兩張方式共同缺點

    1. 引入分布式事務的問題。
    2. 跨節(jié)點Join 的問題。
    3. 跨節(jié)點合并排序分頁問題。

目前主要有兩種思路：

    A. **客戶端模式**，在每個應用程序模塊中配置管理自己需要的一個（或者多個）數(shù)據(jù)源，直接訪問各個 數(shù)據(jù)庫，在模塊內(nèi)完成數(shù)據(jù)的整合。 
    優(yōu)點：相對簡單，無性能損耗。   
    缺點：不夠通用，數(shù)據(jù)庫連接的處理復雜，對業(yè)務不夠透明，處理復雜。
   B. 通過**中間代理層**來統(tǒng)一管理所有的數(shù)據(jù)源，后端數(shù)據(jù)庫集群對前端應用程序透明；   
    優(yōu)點：通用，對應用透明，改造少。   
    缺點：實現(xiàn)難度大，有二次轉(zhuǎn)發(fā)性能損失

Mycat分庫分表

Mycat的架構(gòu)其實很好理解，Mycat是代理，Mycat后面就是物理數(shù)據(jù)庫。和Web服務器的Nginx類似。對于使用者來說，訪問的都是Mycat，不會接觸到后端的數(shù)據(jù)庫。

常用的分庫分表中間件

簡單易用的組件：

當當sharding-jdbc

蘑菇街TSharding

強悍重量級的中間件：

sharding

TDDL Smart Client的方式（淘寶）

Atlas(Qihoo 360)

alibaba.cobar(是阿里巴巴（B2B）部門開發(fā))

MyCAT（基于阿里開源的Cobar產(chǎn)品而研發(fā)）

Oceanus(58同城數(shù)據(jù)庫中間件)

OneProxy(支付寶首席架構(gòu)師樓方鑫開發(fā))

vitess（谷歌開發(fā)的數(shù)據(jù)庫中間件）

具體實現(xiàn)可以參考下面這些文章：
http://www.cnblogs.com/joylee...
http://www.mycat.io/
https://github.com/MyCATApache

更多優(yōu)質(zhì)文章

https://www.cnblogs.com/sunny...
https://www.cnblogs.com/mfmda...
https://www.cnblogs.com/jshen...
http://www.cnblogs.com/firstd...

如果對 Java、大數(shù)據(jù)感興趣請長按二維碼關(guān)注一波，我會努力帶給你們價值。覺得對你哪怕有一丁點幫助的請幫忙點個贊或者轉(zhuǎn)發(fā)哦。
關(guān)注公眾號【愛編碼】，回復2019有相關(guān)資料哦。