1樓：左輕侯
你沒有給出使用的MySQL引擎
。MySQL
cluster支援分布式架構，可以有效地處理高併發的寫操作，但是由於不支援完整的RDBMS特性，在實際中很少使用。我假定你使用的是innodb引擎。
首先，innodb本身並不支援真正的分布式事務，對於高併發的寫操作場景，並沒有提供乙個官方的解決方案。目前在實際中使用的方案大概如下：
使用一主多從，主機負責寫操作，備機負責讀操作。這個方案的問題之一在於，如你已經意識到的，當寫操作也很多以至於超出了單台主機的處理能力，就無能為力了。另乙個問題是無法保證主機和備機之間的資料一致性。
關鍵在於，如我在這個回答裡提到的：
如何解決主從資料庫同步延遲問題？ - 左輕侯的回答
主從架構本來就是一種高可用性解決方案，而不是高併發解決方案。
分表，將負載最大的乙個或幾個表拆分，分別存放在不同的物理結點上，再寫乙個mysql
proxy來排程。除了主從架構，這可能是網際網路使用得最多的方案。它的缺點也很明顯，首先是應用邏輯會汙染資料庫（應用邏輯一旦發生變動，可能整個系統都要跟著改），然後還是不能保證一致性。
多主架構，即群集中的每個結點既是主機也是備機，都可以處理讀/寫操作，資料更新通過日誌最終同步到所有的結點上。典型代表是mariadb
galera
cluster。但是，這種方案實質上不能夠解決併發壓力，因為資料並沒有被分散存放，而是在每乙個結點上都儲存了乙個完整的副本；任何乙個結點上進行的修改操作，最終都要被同步到所有結點，所以從全域性來看它並不是減少而是增加了成本。它對於峰值的承受能力會很大（多台主機一起扛，峰值過去以後再慢慢同步），但是對於持續的高併發壓力並沒有什麼用（主機之間的gap會越來越大，最後資料完全不可用）。
其它的缺點也很明顯：要處理多主機之間可能的資料衝突；不能保證資料一致性。
資料庫之外的方案是增加針對寫操作的快取層，把寫操作放到佇列裡，排隊到資料庫結點上非同步執行。這種方案也只能增加對峰值的承受能力，而不能真正提高資料庫的處理能力。另外還有資料不一致帶來的種種不便。
同步延遲只涉及到高可用性，和你的問題沒有關係。
你沒有給出應用場景的細節，就我所知，目前網際網路企業對於「高併發的寫操作」問題比較典型的解決方案是分表+寫快取，代價是麻煩+丟失一致性。你可以根據應用場景自行選擇。
如果應用場景要處理高併發的寫操作，又要求資料的強一致性（比如銀行），可以使用真正的分布式資料庫，如DB2
pureScale或者Oracle
RAC，當然價錢也不便宜。
如果應用場景要處理非常非常高的併發，同時又對資料的一致性和可靠性有非常高的要求，而且也不缺錢（比如VISA的全球交易中心），可以考慮IBM的z13大型機，號稱單機能力能處理12個支付寶（雙11的交易峰值），大概是這個領域的終極解決方案了：
今非昔比？ IBM主機擬逆襲X86
2樓：劉鑫
MySQL 的話可以多主啊，把寫入也分布出去。
不過MySQL有個糟心的是同步延遲，據說是最新的 5.7 還是 5.8來著已經解決了，不知道真解決了沒。反正我推薦你要上就上最新的 release 版本，坑少。
MySQL主從複製鏈結問題？
one flower 複製是MySQL資料庫提供的一種高可用 高效能的解決方案，一般用來建立大型的應用。總體來說，複製的工作原理分為以下三個步驟 1 主伺服器把資料更新記錄到二進位制日誌中。2 從伺服器把主伺服器的二進位制日誌拷貝到自己的中繼日誌 Relay Log 中 3 從伺服器重做中繼日誌中的...
資料庫讀寫分離與集群比較？
Gavin Wu 樓上提到的RAC僅是例項級的，說白了就是生產上防止單例項宕機，並在資料庫連線上做了負載均衡，但是與資料庫的資料儲存複製與切割沒有關係。一般oracle 採用db link做分布式拆封，但是這是基於表或者業務邏輯的縱向分割。所以這些技術可以理解為oracle的擴充套件單機技術，RAC...
什麼情況會導致MySQL主從複製延遲？
愛可生 1.網路的延遲由於mysql主從複製是基於binlog的一種非同步複製，通過網路傳送binlog檔案，理所當然網路延遲是主從不同步的絕大多數的原因，特別是跨機房的資料同步出現這種機率非常的大，所以做讀寫分離，注意從業務層進行前期設計。2.主從兩台機器的負載不一致由於mysql主從複製是主資料...