pos機按鍵分離,數據庫主從復制

網上有很多關于pos機按鍵分離,數據庫主從復制的知識，也有很多人為大家解答關于pos機按鍵分離的問題，今天pos機之家(www.tonybus.com)為大家整理了關于這方面的知識，讓我們一起來看下吧!

本文目錄一覽：

1、pos機按鍵分離

pos機按鍵分離

隨著互聯網應用的廣泛普及，海量數據的存儲和訪問成為了系統設計的瓶頸問題。對于一個大型的互聯網應用，每天幾十億的PV無疑對數據庫造成了相當高的負載。對于系統的穩定性和擴展性造成了極大的問題。通過數據切分來提高網站性能，橫向擴展數據層已經成為架構研發人員首選的方式。

mysql主從復制原理

主要涉及三個線程：binlog 線程、I/O 線程和 SQL 線程。

binlog 線程 ：負責將主服務器上的數據更改寫入二進制日志（Binary log）中。I/O 線程 ：負責從主服務器上讀取二進制日志，并寫入從服務器的中繼日志（Relay log）。SQL 線程 ：負責讀取中繼日志，解析出主服務器已經執行的數據更改并在從服務器中重放（Replay）。

這張圖就很清晰表達出流程

1：主庫db的更新事件(update、insert、delete)被寫到binlog

2：從庫發起連接，連接到主庫3：此時主庫創建一個binlog dump thread線程，把binlog的內容發送到從庫

4：從庫啟動之后，創建一個I/O線程，讀取主庫傳過來的binlog內容并寫入到relay log

5：還會創建一個SQL線程，從relay log里面讀取內容，從Exec_Master_Log_Pos位置開始執行讀取到的更新事件，將更新內容寫入到slave的db.

主從同步復制模式：

讀寫分離：

MYSQL讀寫分離的原理其實就是讓Master數據庫處理事務性增、刪除、修改、更新操作（CREATE、INSERT、UPDATE、DELETE），而讓Slave數據庫處理SELECT操作，MYSQL讀寫分離前提是基于MYSQL主從復制，這樣可以保證在Master上修改數據，Slave同步之后，WEB應用可以讀取到Slave端的數據。

數據庫分區：

分區并不是生成新的數據表，而是將表的數據均衡分攤到不同的硬盤，系統或是不同服務器存儲介子中，實際上還是一張表。另外，分區可以做到將表的數據均衡到不同的地方，提高數據檢索的效率，降低數據庫的頻繁IO壓力值，分區的優點如下：

1、相對于單個文件系統或是硬盤，分區可以存儲更多的數據；

2、數據管理比較方便，比如要清理或廢棄某年的數據，就可以直接刪除該日期的分區數據即可；

3、精準定位分區查詢數據，不需要全表掃描查詢，大大提高數據檢索效率；

4、可跨多個分區磁盤查詢，來提高查詢的吞吐量；

5、在涉及聚合函數查詢時，可以很容易進行數據的合并；

1、水平分區

這種形式分區是對表的行進行分區，通過這樣的方式不同分組里面的物理列分割的數據集得以組合，從而進行個體分割（單分區）或集體分割（1個或多個分區）。所有在表中定義的列在每個數據集中都能找到，所以表的特性依然得以保持。

2、垂直分區

這種分區方式一般來說是通過對表的垂直劃分來減少目標表的寬度，使某些特定的列被劃分到特定的分區，每個分區都包含了其中的列所對應的行。

什么時候考慮使用分區？

一張表的查詢速度已經慢到影響使用的時候。sql經過優化數據量大表中的數據是分段的對數據的操作往往只涉及一部分數據，而不是所有的數據

分庫分表：

分庫分表的原因：

1、隨著單庫中的數據量越來越大，相應的，查詢所需要的時間也越來越多，相當于數據的處理遇到了瓶頸2、單庫發生意外的時候，需要修復的是所有的數據，而多庫中的一個庫發生意外的時候，只需要修復一個庫（當然，也可以用物理分區的方式處理這種問題）

什么時候考慮使用分庫？

單臺DB的存儲空間不夠隨著查詢量的增加單臺數據庫服務器已經沒辦法支撐

分庫解決的問題：

其主要目的是為突破單節點數據庫服務器的 I/O 能力限制，解決數據庫擴展性問題。

垂直拆分

將系統中不存在關聯關系或者需要join的表可以放在不同的數據庫不同的服務器中。

按照業務垂直劃分。比如：可以按照業務分為資金、會員、訂單三個數據庫。

需要解決的問題：跨數據庫的事務、jion查詢等問題。

水平拆分

例如，大部分的站點。數據都是和用戶有關，那么可以根據用戶，將數據按照用戶水平拆分。

按照規則劃分，一般水平分庫是在垂直分庫之后的。比如每天處理的訂單數量是海量的，可以按照一定的規則水平劃分。需要解決的問題：數據路由、組裝。

什么時候考慮分表？

一張表的查詢速度已經慢到影響使用的時候。sql經過優化數據量大當頻繁插入或者聯合查詢時，速度變慢

分表解決的問題

分表后，單表的并發能力提高了，磁盤I/O性能也提高了，寫操作效率提高了

查詢一次的時間短了數據分布在不同的文件，磁盤I/O性能提高讀寫鎖影響的數據量變小插入數據庫需要重新建立索引的數據減少

垂直分表

水平分表

存儲演變：

單庫單表

單庫單表是最常見的數據庫設計，例如，有一張用戶(user)表放在數據庫db中，所有的用戶都可以在db庫中的user表中查到。

單庫多表

隨著用戶數量的增加，user表的數據量會越來越大，當數據量達到一定程度的時候對user表的查詢會漸漸的變慢，從而影響整個DB的性能。如果使用mysql, 還有一個更嚴重的問題是，當需要添加一列的時候，mysql會鎖表，期間所有的讀寫操作只能等待。

可以通過某種方式將user進行水平的切分，產生兩個表結構完全一樣的user_0000,user_0001等表，user_0000 + user_0001 + …的數據剛好是一份完整的數據。

多庫多表

隨著數據量增加也許單臺DB的存儲空間不夠，隨著查詢量的增加單臺數據庫服務器已經沒辦法支撐。這個時候可以再對數據庫進行水平拆分。

數據庫額外小知識：

MySQL 使用自增ID主鍵和UUID 作為主鍵的優劣比較詳細過程（從百萬到千萬表記錄測試）

（1）單實例或者單節點組：

經過500W、1000W的單機表測試，自增ID相對UUID來說，自增ID主鍵性能高于UUID，磁盤存儲費用比UUID節省一半的錢。所以在單實例上或者單節點組上，使用自增ID作為首選主鍵。

（2）分布式架構場景：

20個節點組下的小型規模的分布式場景，為了快速實現部署，可以采用多花存儲費用、犧牲部分性能而使用UUID主鍵快速部署；

20到200個節點組的中等規模的分布式場景，可以采用自增ID+步長的較快速方案。

200以上節點組的大數據下的分布式場景，可以借鑒類似twitter雪花算法構造的全局自增ID作為主鍵。

數據庫分庫分表，何時分？怎樣分？

一. 數據切分

關系型數據庫本身比較容易成為系統瓶頸，單機存儲容量、連接數、處理能力都有限。當單表的數據量達到1000W或100G以后，由于查詢維 度較多，即使添加從庫、優化索引，做很多操作時性能仍下降嚴重。此時就要考慮對其進行切分了，切分的目的就在于減少數據庫的負擔，縮短查詢時間。

數據庫分布式核心內容無非就是數據切分（Sharding），以及切分后對數據的定位、整合。數據切分就是將數據分散存儲到多個數據庫中，使得單一數據庫中的數據量變小，通過擴充主機的數量緩解單一數據庫的性能問題，從而達到提升數據庫操作性能的目的。數據切分根據其切分類型，可以分為兩種方式：垂直（縱向）切分和水平（橫向）切分

什么是垂直（縱向）切分？

垂直切分常見有垂直分庫和垂直分表兩種。

垂直分庫就是根據業務耦合性，將關聯度低的不同表存儲在不同的數據庫。做法與大系統拆分為多個小系統類似，按業務分類進行獨立劃分。與"微服務治理"的做法相似，每個微服務使用單獨的一個數據庫。如圖：

垂直分表是基于數據庫中的"列"進行，某個表字段較多，可以新建一張擴展表，將不經常用或字段長度較大的字段拆分出去到擴展表中。在字段很多的情況下（例 如一個大表有100多個字段），通過"大表拆小表"，更便于開發與維護，也能避免跨頁問題，MySQL底層是通過數據頁存儲的，一條記錄占用空間過大會導 致跨頁，造成額外的性能開銷。另外數據庫以行為單位將數據加載到內存中，這樣表中字段長度較短且訪問頻率較高，內存能加載更多的數據，命中率更高，減少了 磁盤IO，從而提升了數據庫性能。

垂直切分的優點：

解決業務系統層面的耦合，業務清晰與微服務的治理類似，也能對不同業務的數據進行分級管理、維護、監控、擴展等高并發場景下，垂直切分一定程度的提升IO、數據庫連接數、單機硬件資源的瓶頸

缺點：

部分表無法join，只能通過接口聚合方式解決，提升了開發的復雜度分布式事務處理復雜依然存在單表數據量過大的問題（需要水平切分）什么是水平（橫向）切分？

當一個應用難以再細粒度的垂直切分，或切分后數據量行數巨大，存在單庫讀寫、存儲性能瓶頸，這時候就需要進行水平切分了。

水平切分分為庫內分表和分庫分表，是根據表內數據內在的邏輯關系，將同一個表按不同的條件分散到多個數據庫或多個表中，每個表中只包含一部分數據，從而使得單個表的數據量變小，達到分布式的效果。如圖所示：

庫內分表只解決了單一表數據量過大的問題，但沒有將表分布到不同機器的庫上，因此對于減輕MySQL數據庫的壓力來說，幫助不是很大，大家還是競爭同一個物理機的CPU、內存、網絡IO，最好通過分庫分表來解決。

水平切分的優點：

不存在單庫數據量過大、高并發的性能瓶頸，提升系統穩定性和負載能力應用端改造較小，不需要拆分業務模塊

缺點：

跨分片的事務一致性難以保證跨庫的join關聯查詢性能較差數據多次擴展難度和維護量極大

水平切分后同一張表會出現在多個數據庫/表中，每個庫/表的內容不同。

什么時候考慮切分

1、能不切分盡量不要切分

并不是所有表都需要進行切分，主要還是看數據的增長速度。切分后會在某種程度上提升業務的復雜度，數據庫除了承載數據的存儲和查詢外，協助業務更好的實現需求也是其重要工作之一。

不到萬不得已不用輕易使用分庫分表這個大招，避免"過度設計"和"過早優化"。分庫分表之前，不要為分而分，先盡力去做力所能及的事情，例如：升級硬件、升級網絡、讀寫分離、索引優化等等。當數據量達到單表的瓶頸時候，再考慮分庫分表。

2、數據量過大，正常運維影響業務訪問

這里說的運維，指：

1）對數據庫備份，如果單表太大，備份時需要大量的磁盤IO和網絡IO。例如1T的數據，網絡傳輸占50MB時候，需要20000秒才能傳輸完畢，整個過程的風險都是比較高的

2）對一個很大的表進行DDL修改時，MySQL會鎖住全表，這個時間會很長，這段時間業務不能訪問此表，影響很大。如果使用pt- online-schema-change，使用過程中會創建觸發器和影子表，也需要很長的時間。在此操作過程中，都算為風險時間。將數據表拆分，總量減 少，有助于降低這個風險。

3）大表會經常訪問與更新，就更有可能出現鎖等待。將數據切分，用空間換時間，變相降低訪問壓力

3、隨著業務發展，需要對某些字段垂直拆分

4、數據量快速增長

隨著業務的快速發展，單表中的數據量會持續增長，當性能接近瓶頸時，就需要考慮水平切分，做分庫分表了。此時一定要選擇合適的切分規則，提前預估好數據容量

5、安全性和可用性

雞蛋不要放在一個籃子里。在業務層面上垂直切分，將不相關的業務的數據庫分隔，因為每個業務的數據量、訪問量都不同，不能因為一個業務把數 據庫搞掛而牽連到其他業務。利用水平切分，當一個數據庫出現問題時，不會影響到100%的用戶，每個庫只承擔業務的一部分數據，這樣整體的可用性就能提 高。

案例分析

1、用戶中心業務場景

用戶中心是一個非常常見的業務，主要提供用戶注冊、登錄、查詢/修改等功能，其核心表為：

任何脫離業務的架構設計都是耍流氓，在進行分庫分表前，需要對業務場景需求進行梳理：

用戶側：前臺訪問，訪問量較大，需要保證高可用和高一致性。主要有兩類需求：用戶登錄：通過login_name/phone/email查詢用戶信息，1%請求屬于這種類型用戶信息查詢：登錄之后，通過uid來查詢用戶信息，99%請求屬這種類型運營側：后臺訪問，支持運營需求，按照年齡、性別、登陸時間、注冊時間等進行分頁的查詢。是內部系統，訪問量較低，對可用性、一致性的要求不高。

2、水平切分方法

當數據量越來越大時，需要對數據庫進行水平切分，上文描述的切分方法有"根據數值范圍"和"根據數值取模"。

"根據數值范圍"：以主鍵uid為劃分依據，按uid的范圍將數據水平切分到多個數據庫上。例如：user-db1存儲uid范圍為0~1000w的數據，user-db2存儲uid范圍為1000w~2000wuid數據。

優點是：擴容簡單，如果容量不夠，只要增加新db即可。不足是：請求量不均勻，一般新注冊的用戶活躍度會比較高，所以新的user-db2會比user-db1負載高，導致服務器利用率不平衡

"根據數值取模"：也是以主鍵uid為劃分依據，按uid取模的值將數據水平切分到多個數據庫上。例如：user-db1存儲uid取模得1的數據，user-db2存儲uid取模得0的uid數據。

優點是：數據量和請求量分布均均勻不足是：擴容麻煩，當容量不夠時，新增加db，需要rehash。需要考慮對數據進行平滑的遷移。

3、非uid的查詢方法

水平切分后，對于按uid查詢的需求能很好的滿足，可以直接路由到具體數據庫。而按非uid的查詢，例如login_name，就不知道具體該訪問哪個庫了，此時需要遍歷所有庫，性能會降低很多。

對于用戶側，可以采用"建立非uid屬性到uid的映射關系"的方案；對于運營側，可以采用"前臺與后臺分離"的方案。

3.1、建立非uid屬性到uid的映射關系

1）映射關系

例如：login_name不能直接定位到數據庫，可以建立login_name→uid的映射關系，用索引表或緩存來存儲。當訪問login_name時，先通過映射表查詢出login_name對應的uid，再通過uid定位到具體的庫。

映射表只有兩列，可以承載很多數據，當數據量過大時，也可以對映射表再做水平切分。這類kv格式的索引結構，可以很好的使用cache來優化查詢性能，而且映射關系不會頻繁變更，緩存命中率會很高。

3.2、前臺與后臺分離

對于用戶側，主要需求是以單行查詢為主，需要建立login_name/phone/email到uid的映射關系，可以解決這些字段的查詢問題。

而對于運營側，很多批量分頁且條件多樣的查詢，這類查詢計算量大，返回數據量大，對數據庫的性能消耗較高。此時，如果和用戶側公用同一批服務或數據庫，可能因為后臺的少量請求，占用大量數據庫資源，而導致用戶側訪問性能降低或超時。

這類業務最好采用"前臺與后臺分離"的方案，運營側后臺業務抽取獨立的service和db，解決和前臺業務系統的耦合。由于運營側對可用 性、一致性的要求不高，可以不訪問實時庫，而是通過binlog異步同步數據到運營庫進行訪問。在數據量很大的情況下，還可以使用ES搜索引擎或Hive 來滿足后臺復雜的查詢方式。

常用的支持分庫分表中間件：sharding-jdbc（當當）TSharding（蘑菇街）Atlas（奇虎360）Cobar（阿里巴巴）MyCAT（基于Cobar）Oceanus（58同城）Vitess（谷歌）

以上就是關于pos機按鍵分離,數據庫主從復制的知識，后面我們會繼續為大家整理關于pos機按鍵分離的知識，希望能夠幫助到大家！