mysql binlog同步的三種方式？mysql復(fù)制主要有三種方式：基于SQL語(yǔ)句的復(fù)制(statement-based replication， SBR)，基于行的復(fù)制(row-based rep

mysql binlog同步的三種方式？

mysql復(fù)制主要有三種方式：基于SQL語(yǔ)句的復(fù)制(statement-based replication， SBR)，基于行的復(fù)制(row-based replication， RBR)，混合模式復(fù)制(mixed-based replication， MBR)。對(duì)應(yīng)的，binlog的格式也有三種：STATEMENT，ROW，MIXED。

Facebook用戶量十分龐大，為什么還使用MySQL數(shù)據(jù)庫(kù)？

盡管Facebook使用MySQL，但它們并不是一成不變的使用它。 事實(shí)上，他們的團(tuán)隊(duì)已經(jīng)提交了許多MySQL核心和Innodb插件的高性能增強(qiáng)。 他們的主要重點(diǎn)是增加性能計(jì)數(shù)器到Innodb。 其他更改集中在IO子系統(tǒng)上，包括以下新功能：

1 innodb_io_capacity：設(shè)置服務(wù)器的IO容量以確定后臺(tái)IO的速率限制

2 innodb_read_io_threads， innodb_write_io_threads：設(shè)置后臺(tái)IO線程

3 innodb_max_merged_io：設(shè)置可能合并到一個(gè)大IO請(qǐng)求中的相鄰IO請(qǐng)求的最大數(shù)量

Facebook使用MySQL作為鍵值存儲(chǔ)，其中數(shù)據(jù)隨機(jī)分布在一大組邏輯實(shí)例中。 這些邏輯實(shí)例分散在物理節(jié)點(diǎn)之間，負(fù)載均衡在物理節(jié)點(diǎn)級(jí)完成。 Facebook已經(jīng)開(kāi)發(fā)了一個(gè)分區(qū)方案，其中全局ID被分配給所有的用戶數(shù)據(jù)。 他們也有一個(gè)自定義的歸檔方案，它基于每個(gè)用戶的頻繁和最近的數(shù)據(jù)。 大部分?jǐn)?shù)據(jù)是隨機(jī)分布的。 令人驚訝的是，據(jù)傳Facebook有1800個(gè)MySQL服務(wù)器，但只有3個(gè)全職DBA

Facebook主要將MySQL用于結(jié)構(gòu)化數(shù)據(jù)存儲(chǔ)，例如墻貼，用戶信息等。這些數(shù)據(jù)在各個(gè)數(shù)據(jù)中心之間復(fù)制。 對(duì)于blob存儲(chǔ)（照片，視頻等），F(xiàn)acebook使用一個(gè)自定義的解決方案，涉及外部的CDN和內(nèi)部的NFS

同樣重要的是，F(xiàn)acebook大量使用Memcache，這是一種內(nèi)存緩存系統(tǒng)，通過(guò)在RAM中緩存數(shù)據(jù)和對(duì)象來(lái)加速動(dòng)態(tài)數(shù)據(jù)庫(kù)驅(qū)動(dòng)的網(wǎng)站，以減少閱讀時(shí)間。 Memcache是Facebook的主要緩存形式，大大減少了數(shù)據(jù)庫(kù)的負(fù)載。 擁有一個(gè)緩存系統(tǒng)可以使Facebook的速度與調(diào)用數(shù)據(jù)一樣快。 如果不需要訪問(wèn)數(shù)據(jù)庫(kù)，則只需根據(jù)用戶標(biāo)識(shí)從緩存中獲取數(shù)據(jù)

所以，“Facebook使用什么數(shù)據(jù)庫(kù)”似乎是一個(gè)簡(jiǎn)單的問(wèn)題，你可以看到他們已經(jīng)添加了各種其他系統(tǒng)，使其真正的具有網(wǎng)絡(luò)可擴(kuò)展性。 但是，仍然可以自由地使用這樣一個(gè)觀點(diǎn)：“MySQL和Oracle或者M(jìn)S SQL Server一樣好或者更好，因?yàn)榫退阒挥蠪acebook使用它，它也有5億用戶！”

被外包程序員植入了后門(mén)程序，觸發(fā)后刪除數(shù)據(jù)庫(kù)但他們死不承認(rèn)，該怎么辦？

以我多年的外包經(jīng)驗(yàn)，你可能是遇到以下幾種情況被刪庫(kù)了。

1.你找的外包公司應(yīng)該是業(yè)務(wù)型的外包公司，公司沒(méi)有技術(shù)好的程序員。

現(xiàn)在這樣的外包公司太多了，我敢說(shuō)目前國(guó)內(nèi)百分之八十的外包公司都是沒(méi)有程序員的，最多是前端套模版的技術(shù)員。

以現(xiàn)在外包行業(yè)，特別是網(wǎng)站建設(shè)這塊各種低價(jià)競(jìng)爭(zhēng)，大多外包公司根本沒(méi)能力養(yǎng)好的技術(shù)員。我曾經(jīng)一個(gè)人的開(kāi)發(fā)速度比過(guò)五六人的外包團(tuán)隊(duì)，可見(jiàn)他們有多水。

所以大部分外包公司接單都是轉(zhuǎn)包，比如從甲方收取10，最后到實(shí)際開(kāi)發(fā)者手上可能不到兩萬(wàn)。

你想想甲方的需求是十萬(wàn)塊的，而開(kāi)發(fā)者以兩萬(wàn)的標(biāo)準(zhǔn)去開(kāi)發(fā)，肯定效果是達(dá)不到的。

甲方肯定不滿意，或提出修改意見(jiàn)，或要求退款，但開(kāi)發(fā)者肯定不愿意繼續(xù)給你改，因?yàn)樗召M(fèi)就這么多。

外包公司也不愿意繼續(xù)加錢(qián)，然后就拖著，拖出糾紛來(lái)。開(kāi)發(fā)者兩萬(wàn)的報(bào)價(jià)應(yīng)該只拿了幾千塊的定金，這時(shí)候能不火么？而且大多又沒(méi)有簽合同的，錢(qián)又拿不到了，所以只好刪庫(kù)。

你們現(xiàn)在的辦法只能是給外包公司施加壓力讓恢復(fù)數(shù)據(jù)庫(kù)，這我估計(jì)是行不通，他們根本就沒(méi)這能力。

另外就是看源碼里有沒(méi)有實(shí)際開(kāi)發(fā)的那個(gè)程序員的聯(lián)系方式，把外包公司的尾款直接給他相信很快圓滿幫你們解決所有問(wèn)題。我以前作為個(gè)人開(kāi)發(fā)者時(shí)也經(jīng)常遇到這情況。

還有一定得起訴外包公司，不過(guò)估計(jì)成功性不高，你們公司肯定沒(méi)有技術(shù)員，沒(méi)留下任何證據(jù)。如果產(chǎn)品還沒(méi)交接完畢，直接起訴對(duì)方?jīng)]有達(dá)到合同要求。

外包公司大多是沒(méi)什么誠(chéng)信的，上忽悠甲方，下忽悠開(kāi)發(fā)者。把甲方的要求分解弄簡(jiǎn)單低價(jià)轉(zhuǎn)包。

如果只是用開(kāi)源程序套套模版找外包公司還行，復(fù)雜的系統(tǒng)開(kāi)發(fā)最好不要找，要找也得找了解，確實(shí)有技術(shù)團(tuán)隊(duì)的。反正報(bào)低價(jià)的基本不靠譜的，你想程序員多貴，工資都開(kāi)不出的價(jià)格怎么能做好。一般也就是接來(lái)單子轉(zhuǎn)包給兼職下班做了，兼職嗎只要有錢(qián)賺就行了。

另外兼職各位程序員最好不要去接復(fù)雜的二手單，大多拿不到尾款的。