目前有個(gè)項(xiàng)目，需要將系統(tǒng)克隆部署到內(nèi)服（內(nèi)網(wǎng)服務(wù)器），但是服務(wù)器本身可以訪問公服（公網(wǎng)服務(wù)器）。

內(nèi)服系統(tǒng)沒有固定公網(wǎng)ip，經(jīng)普通電信線路接入公網(wǎng)
因此無法使用復(fù)制集，最多只能使用傳統(tǒng)主從，設(shè)置slave source
主主同步也因?yàn)閮?nèi)網(wǎng)服務(wù)器公網(wǎng)ip不固定而不納入考慮。
DB version:2.4.6
NodeJs version 0.10.x

現(xiàn)在通過一個(gè)oplog導(dǎo)出工具進(jìn)行內(nèi)服Db與公服Db的同步：

1. 內(nèi)服發(fā)起ssh請(qǐng)求公服導(dǎo)出某個(gè)時(shí)間的oplog。
2. 內(nèi)服發(fā)起sftp將公服oplog下載到內(nèi)服。
3. 內(nèi)服使用下載得到的oplog增量數(shù)據(jù)到內(nèi)服數(shù)據(jù)庫。

但是有一個(gè)問題，就是由于公司為saas平臺(tái)，那么公服數(shù)據(jù)庫里面有不止是內(nèi)服客戶的數(shù)據(jù)存在，按照上面的做法，會(huì)出現(xiàn)這樣的問題：

1. 同步的數(shù)據(jù)中會(huì)有相當(dāng)一部分?jǐn)?shù)據(jù)對(duì)于內(nèi)服系統(tǒng)而言是相對(duì)無用數(shù)據(jù)。
2. 執(zhí)行ssh、sftp命令 導(dǎo)出——傳輸——導(dǎo)入oplog 比較費(fèi)時(shí)間，起碼效率遠(yuǎn)低于使用主從去處理。

于是有下面幾個(gè)方案希望可以改進(jìn)這個(gè)問題：

均要求公服數(shù)據(jù)庫需要開放遠(yuǎn)程連接（已設(shè)置auth），更改常用端口

1. 內(nèi)服直連公服數(shù)據(jù)庫，所有CRUD都提到公服數(shù)據(jù)庫中：

   • 相當(dāng)于內(nèi)服作為session管理與邏輯處理，內(nèi)服沒有數(shù)據(jù)庫。
   • 不需要涉及數(shù)據(jù)同步問題，因?yàn)閿?shù)據(jù)沒有落地到內(nèi)服。
   • 連接請(qǐng)求在網(wǎng)絡(luò)環(huán)境優(yōu)良的情況下（測(cè)試200M寬帶），使用統(tǒng)計(jì)查詢，XHR Time相差10%以內(nèi)。

2. 內(nèi)服做從數(shù)據(jù)庫，公服做主數(shù)據(jù)庫，使用主從同步

   • 內(nèi)服數(shù)據(jù)庫source公服數(shù)據(jù)庫，問題是：

     • 項(xiàng)目代碼沒有做讀寫分離，如果內(nèi)服數(shù)據(jù)庫Slave，由于Slave寫操作不許可，則需要大量重構(gòu)代碼實(shí)現(xiàn)讀寫分離。
     • 讀寫分離后，內(nèi)服將從本地從服讀，而寫依然需要直連公服數(shù)據(jù)庫。
     • 內(nèi)服數(shù)據(jù)庫作為slave，依然需要同步很大量的 相對(duì)無用數(shù)據(jù)。

3. 制作公網(wǎng)跳板數(shù)據(jù)庫實(shí)例，只儲(chǔ)存該客戶需要的數(shù)據(jù)，內(nèi)服從數(shù)據(jù)庫source公服跳板：

   • 公服系統(tǒng)代碼需要大量重構(gòu)代碼實(shí)現(xiàn)數(shù)據(jù)選擇同步到不同跳板數(shù)據(jù)庫中（不同客戶）。

除上所述我相信必定會(huì)有其他更加優(yōu)良的方式，但個(gè)人眼界不足，尚未發(fā)現(xiàn)其他更好的方案，因此亟待各位不吝賜教！

希望可以找到一個(gè)更加抽象的數(shù)據(jù)方案，因?yàn)槟壳癝aaS業(yè)務(wù)開展起來太耗費(fèi)開發(fā)資源，公司方向是逐漸往Daas上面靠攏，如果需要分庫，盡可能的希望保留數(shù)據(jù)關(guān)系。