国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【數據庫】MySQL鎖機制、熱備、分表

Meils / 2108人閱讀

摘要:雙機熱備和備份的區別熱備份指的是即高可用,而備份指的是即數據備份的一種,這是兩種不同的概念,應對的產品也是兩種功能上完全不同的產品。雙機熱備分類按工作中的切換方式分為主備方式方式和雙主機方式方式。

歡迎關注公眾號:【愛編碼
如果有需要后臺回復2019贈送1T的學習資料哦!!

注:本文大都來自互聯網,文字較多,基本是概念,若想深入了解,還需各位自己找文章研究。

表鎖和行鎖機制 表鎖(MyISAM和InnoDB)

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

共享讀鎖:lock table tableName read;
獨占寫鎖:lock table tableName write;
批量解鎖:unlock tables;
什么場景下用表鎖

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

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

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

行鎖(InnoDB的行鎖)

行鎖的劣勢:開銷大;加鎖慢;會出現死鎖
行鎖的優勢:鎖的粒度小,發生鎖沖突的概率低;處理并發的能力強
加鎖的方式:自動加鎖。對于UPDATE、DELETE和INSERT語句,InnoDB會自動給涉及數據集加排他鎖;對于普通SELECT語句,InnoDB不會加任何鎖;當然我們也可以顯示的加鎖:

共享鎖:select * from tableName where … + lock in share more
排他鎖:select * from tableName where … + for update
行鎖優化

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

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

MySQL 事務

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

事務隔離級別

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

更多精彩文章

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

雙機熱備 概念

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

雙機熱備和備份的區別
熱備份指的是:High Available(HA)即高可用,而備份指的是Backup,即數據備份的一種,這是兩種不同的概念,應對的產品也是兩種功能上完全不同的產品。熱備份主要保障業務的連續性,實現的方法是故障點的轉移。而備份,主要目的是為了防止數據丟失,而做的一份拷貝,所以備份強調的是數據恢復而不是應用的故障轉移。

雙機熱備分類

按工作中的切換方式分為:
主-備方式(Active-Standby方式)和雙主機方式(Active-Active方式)

主-備方式即指的是一臺服務器處于某種業務的激活狀態(即Active狀態),另一臺服務器處于該業務的備用狀態(即Standby狀態)。

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

mysql 雙機熱備工作原理

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

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

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

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

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

mysql 雙機熱備實現

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

分庫分表

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

為什么要分庫分表

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

垂直切分和水平切分
垂直切分

一個數據庫由很多表的構成,每個表對應著不同的業務,垂直切分是指按照業務將表進行分類,分布到不同的數據庫上面,這樣也就將數據或者說壓力分擔到不同的庫上面

優點:

    1. 拆分后業務清晰,拆分規則明確。
    2. 系統之間整合或擴展容易。
    3. 數據維護簡單。

缺點:

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

水平切分

相對于垂直拆分的區別是:垂直拆分是把不同的表拆到不同的數據庫中,而水平拆分是把同一個表拆到不同的數據庫中。

優點:

    1. 不存在單庫大數據,高并發的性能瓶頸。
    2. 對應用透明,應用端改造較少。     
    3. 按照合理拆分規則拆分,join操作基本避免跨庫。
    4. 提高了系統的穩定性跟負載能力。

缺點:

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

小結

兩張方式共同缺點

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

目前主要有兩種思路:

    A. **客戶端模式**,在每個應用程序模塊中配置管理自己需要的一個(或者多個)數據源,直接訪問各個 數據庫,在模塊內完成數據的整合。 
    優點:相對簡單,無性能損耗。   
    缺點:不夠通用,數據庫連接的處理復雜,對業務不夠透明,處理復雜。
   B. 通過**中間代理層**來統一管理所有的數據源,后端數據庫集群對前端應用程序透明;   
    優點:通用,對應用透明,改造少。   
    缺點:實現難度大,有二次轉發性能損失
Mycat分庫分表

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

常用的分庫分表中間件
簡單易用的組件:

當當sharding-jdbc

蘑菇街TSharding

強悍重量級的中間件:

sharding

TDDL Smart Client的方式(淘寶)

Atlas(Qihoo 360)

alibaba.cobar(是阿里巴巴(B2B)部門開發)

MyCAT(基于阿里開源的Cobar產品而研發)

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

OneProxy(支付寶首席架構師樓方鑫開發)

vitess(谷歌開發的數據庫中間件)

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

更多優質文章

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

最后

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

文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。

轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/18004.html

相關文章

發表評論

0條評論

最新活動
閱讀需要支付1元查看
<