【正文】 生死鎖，mysql在Server層和存儲引擎層做并發(fā)控制，主要體現(xiàn)在讀寫鎖，根據(jù)鎖粒度不同，有各個級別的鎖(表鎖、行鎖、頁鎖、MVCC)；基于提高并發(fā)性能的考慮，使用多版本并發(fā)控制MVCC來支持事務(wù)的隔離，并基于undo來實現(xiàn)，在做事務(wù)回滾時，也會用到undo段。mysql用redolog來保證數(shù)據(jù)的寫入的性能和失效恢復(fù)，在修改數(shù)據(jù)時只需要修改內(nèi)存，再把修改行為記錄到事務(wù)日志中(順序IO)，不用每次將數(shù)據(jù)修改本身持久化到硬盤(隨機IO)，大大提高性能。在可靠性方面，innodb存儲引擎提供了兩次寫機制doublewriter用于防止在flush頁面到存儲上出現(xiàn)的錯誤，解決磁盤halfwritern的問題。216。對于高并發(fā)高性能的mysql來講，可以在多個維度進行性能方面的調(diào)優(yōu)。a、硬件級別，日志和數(shù)據(jù)的存儲，需要分開，日志是順序的寫，需要做raid1+0，并且用bufferIO；數(shù)據(jù)是離散的讀寫，走directIO即可，避免走文件系統(tǒng)cache帶來的開銷。存儲能力，SAS盤raid操作（raid卡緩存，關(guān)閉讀cache，關(guān)閉磁盤cache，關(guān)閉預(yù)讀，只用writebackbuffer，不過需要考慮充放電的問題），當然如果數(shù)據(jù)規(guī)模不大，數(shù)據(jù)的存儲可以用高速的設(shè)備，F(xiàn)usionIO、SSD。對于數(shù)據(jù)的寫入，控制臟頁刷新的頻率，對于數(shù)據(jù)的讀取，控制cachehit率；因此而估算系統(tǒng)需要的IOPS，評估需要的硬盤數(shù)量(fusionio上到IOPS在10w以上，普通的硬盤150)。Cpu方面，單實例關(guān)閉NUMA，mysql對多核的支持不是太好，可以對多實例進行CPU綁定。b、操作系統(tǒng)級別，內(nèi)核以及socket的優(yōu)化，網(wǎng)絡(luò)優(yōu)化bond、文件系統(tǒng)、IO調(diào)度innodb主要用在OLTP類應(yīng)用，一般都是IO密集型的應(yīng)用，在提高IO能力的基礎(chǔ)上，充分利用cache機制。需要考慮的內(nèi)容有，在保證系統(tǒng)可用內(nèi)存的基礎(chǔ)上，盡可能的擴大innodbbufferpool，一般設(shè)置為物理內(nèi)存的3/4文件系統(tǒng)的使用，只在記錄事務(wù)日志的時候用文件系統(tǒng)的cache；盡量避免mysql用到swap(=0，內(nèi)存緊張時，釋放文件系統(tǒng)cache)IO調(diào)度優(yōu)化，減少不必要的阻塞，降低隨機IO訪問的延時(CFQ、Deadline、NOOP)c、server以及存儲引擎級別（連接管理、網(wǎng)絡(luò)管理、table管理、日志）包括cache/buffer、Connection、IOd、應(yīng)用級別（比如索引的考慮，schema的優(yōu)化適當冗余；優(yōu)化sql查詢導(dǎo)致的CPU問題和內(nèi)存問題，減少鎖的范圍，減少回表掃描，覆蓋索引）216。在高可用實踐方面，支持mastermaster、masterslave模式，mastermaster模式是一個作為主負責(zé)讀寫，另外一個作為standby提供災(zāi)備，maserslave是一個作為主提供寫操作，其他幾個節(jié)點作為讀操作，支持讀寫分離。對于節(jié)點主備失效檢測和切換，可以采用HA軟件，當然也可以從更細粒度定制的角度，采用zookeeper作為集群的協(xié)調(diào)服務(wù)。對于分布式的系統(tǒng)來講，數(shù)據(jù)庫主備切換的一致性始終是一個問題，可以有以下幾種方式：a、集群方式，如oracle的rack，缺點是比較復(fù)雜b、共享SAN存儲方式，相關(guān)的數(shù)據(jù)文件和日志文件都放在共享存儲上，優(yōu)點是主備切換時數(shù)據(jù)保持一致，不會丟失，但由于備機有一段時間的拉起，會有短暫的不可用狀態(tài)c、主備進行數(shù)據(jù)同步的方式，常見的是日志的同步，可以保障熱備，實時性好，但是切換時，可能有部分數(shù)據(jù)沒有同步過來，帶來了數(shù)據(jù)的一致性問題?？梢栽诓僮髦鲾?shù)據(jù)庫的同時，記錄操作日志，切換到備時，會和操作日志做個check，補齊未同步過來的數(shù)據(jù)；d、還有一種做法是備庫切換到主庫的regolog的存儲上，保證數(shù)據(jù)不丟失。數(shù)據(jù)庫主從復(fù)制的效率在mysql上不是太高，主要原因是事務(wù)是嚴格保持順序的，索引mysql在復(fù)制方面包括日志IO和reloglog兩個過程都是單線程的串行操作，在數(shù)據(jù)復(fù)制優(yōu)化方面，盡量減少IO的影響。，可以支持在不同的庫上的并行復(fù)制。216?；诓煌瑯I(yè)務(wù)要求的存取方式平臺業(yè)務(wù)中，不同的業(yè)務(wù)有不同的存取要求，比如典型的兩大業(yè)務(wù)用戶和訂單，用戶一般來講總量是可控的，而訂單是不斷地遞增的，對于用戶表首先采取分庫切分，每個sharding做一主多讀，同樣對于訂單因更多需求的是用戶查詢自己的訂單，也需要按照用戶進行切分訂單庫，并且支持一主多讀。在硬件存儲方面，對于事務(wù)日志因是順序?qū)懀W存的優(yōu)勢比硬盤高不了多少，所以采取電池保護的寫緩存的raid卡存儲；對于數(shù)據(jù)文件，無論是對用戶或者訂單都會存在大量的隨機讀寫操作，當然加大內(nèi)存是一個方面，另外可以采用高速的IO設(shè)備閃存，比如PCIe卡fusionio。使用閃存也適合在單線程的負載中，比如主從復(fù)制，可以對從節(jié)點配置fusionIO卡，降低復(fù)制的延遲。對于訂單業(yè)務(wù)來講，量是不斷遞增的，PCIe卡存儲容量比較有限，并且訂單業(yè)務(wù)的熱數(shù)據(jù)只有最近一段時間的(比如近3個月的)，對此這里列兩種解決方案，一種是flashcache方式，采用基于閃存和硬盤存儲的開源混合存儲方式，在閃存中存儲熱點的數(shù)據(jù)。另外一種是可以定期把老的數(shù)據(jù)導(dǎo)出到分布式數(shù)據(jù)庫HBase中，用戶在查詢訂單列表是近期的數(shù)據(jù)從mysql中獲取，老的數(shù)據(jù)可以從HBase中查詢，當然需要HBase良好的rowkey設(shè)計以適應(yīng)查詢需求。3)分布式數(shù)據(jù)庫對于數(shù)據(jù)的高并發(fā)的訪問，傳統(tǒng)的關(guān)系型數(shù)據(jù)庫提供讀寫分離的方案，但是帶來的確實數(shù)據(jù)的一致性問題提供的數(shù)據(jù)切分的方案；對于越來越多的海量數(shù)據(jù)，傳統(tǒng)的數(shù)據(jù)庫采用的是分庫分表，實現(xiàn)起來比較復(fù)雜，后期要不斷的進行遷移維護；對于高可用和伸縮方面，傳統(tǒng)數(shù)據(jù)采用的是主備、主從、多主的方案，但是本身擴展性比較差，增加節(jié)點和宕機需要進行數(shù)據(jù)的遷移。對于以上提出的這些問題，分布式數(shù)據(jù)庫HBase有一套完善的解決方案，適用于高并發(fā)海量數(shù)據(jù)存取的要求。216。HBase基于列式的高效存儲降低IO通常的查詢不需要一行的全部字段，大多數(shù)只需要幾個字段對與面向行的存儲系統(tǒng)，每次查詢都會全部數(shù)據(jù)取出，然后再從中選出需要的字段面向列的存儲系統(tǒng)可以單獨查詢某一列，從而大大降低IO提高壓縮效率同列數(shù)據(jù)具有很高的相似性，會增加壓縮效率Hbase的很多特性，都是由列存儲決定的高性能LSMTree適合高速寫的場景強一致的數(shù)據(jù)訪問MVCCHBase的一致性數(shù)據(jù)訪問是通過MVCC來實現(xiàn)的。HBase在寫數(shù)據(jù)的過程中，需要經(jīng)過好幾個階段，寫HLog，寫memstore，更新MVCC。只有更新了MVCC，才算真正memstore寫成功，其中事務(wù)的隔離需要有mvcc的來控制，比如讀數(shù)據(jù)不可以獲取別的線程還未提交的數(shù)據(jù)。高可靠HBase的數(shù)據(jù)存儲基于HDFS，提供了冗余機制。Region節(jié)點的宕機，對于內(nèi)存中的數(shù)據(jù)還未flush到文件中，提供了可靠的恢復(fù)機制?？缮炜s，自動切分，遷移通過Zookeeper定位目標RegionServer，最后定位Region。RegionServer擴容，通過將自身發(fā)布到Master，Master均勻分布?？捎眯源嬖趩吸c故障，RegionServer宕機后，短時間內(nèi)該server維護的region無法訪問，等待failover生效。通過Master維護各RegionServer健康狀況和Region分布。多個Master，Master宕機有zookeeper的paxos投票機制選取下一任Master。Master就算全宕機，也不影響Region讀寫。Master僅充當一個自動運維角色。HDFS為分布式存儲引擎，一備三，高可靠，0數(shù)據(jù)丟失。HDFS的namenode是一個SPOF。為避免單個region訪問過于頻繁，單機壓力過大，提供了split機制HBase的寫入是LSMTREE的架構(gòu)方式，隨著數(shù)據(jù)的append，HFile越來越多，HBase提供了HFile文件進行pact，對過期數(shù)據(jù)進行清除，提高查詢的性能。SchemafreeHBase沒有像關(guān)系型數(shù)據(jù)庫那樣的嚴格的schema，可以自由的增加和刪除schema中的字段。HBase分布式數(shù)據(jù)庫，對于二級索引支持的不太好，目前只支持在rowkey上的索引，所以rowkey的設(shè)計對于查詢的性能來講非常關(guān)鍵。7.管理與部署配置統(tǒng)一的配置庫部署平臺8.監(jiān)控、統(tǒng)計大型分布式系統(tǒng)涉及各種設(shè)備，比如網(wǎng)絡(luò)交換機，普通PC機，各種型號的網(wǎng)卡，硬盤，內(nèi)存等等，還有應(yīng)用業(yè)務(wù)層次的監(jiān)控，數(shù)量非常多的時候，出現(xiàn)錯誤的概率也會變大，并且有些監(jiān)控的時效性要求比較高，有些達到秒級別；在大量的數(shù)據(jù)流中需要過濾異常的數(shù)據(jù)，有時候也對數(shù)據(jù)會進行上下文相關(guān)的復(fù)雜計算，進而決定是否需要告警。因此監(jiān)控平臺的性能、吞吐量、已經(jīng)可用性就比較重要，需要規(guī)劃統(tǒng)一的一體化的監(jiān)控平臺對系統(tǒng)進行各個層次的監(jiān)控。平臺的數(shù)據(jù)分類應(yīng)用業(yè)務(wù)級別：應(yīng)用事件、業(yè)務(wù)日志、審計日志、請求日志、異常、請求業(yè)務(wù)metrics、性能度量系統(tǒng)級別：CPU、內(nèi)存、網(wǎng)絡(luò)、IO時效性要求閥值，告警：實時計算：近實時分鐘計算按小時、天的離線分析實時查詢架構(gòu)節(jié)點中Agent代理可以接收日志、應(yīng)用的事件以及通過探針的方式采集數(shù)據(jù)，agent采集數(shù)據(jù)的一個原則是和業(yè)務(wù)應(yīng)用的流程是異步隔離的，不影響交易流程。數(shù)據(jù)統(tǒng)一通過collector集群進行收集，按照數(shù)據(jù)的不同類型分發(fā)到不同的計算集群進行處理；有些數(shù)據(jù)時效性不是那么高，比如按小時進行統(tǒng)計，放入hadoop集群；有些數(shù)據(jù)是請求流轉(zhuǎn)的跟蹤數(shù)據(jù)，需要可以查詢的，那么就可以放入solr集群進行索引；有些數(shù)據(jù)需要進行實時計算的進而告警的，需要放到storm集群中進行處理。數(shù)據(jù)經(jīng)過計算集群處理后，結(jié)果存儲到Mysql或者HBase中。監(jiān)控的web應(yīng)用可以把監(jiān)控的實時結(jié)果推送到瀏覽器中，也可以提供API供結(jié)果的展現(xiàn)和搜索。版權(quán)聲明：本文為博主原創(chuàng)文章，未經(jīng)博主允許不得轉(zhuǎn)載。