直入主題，不討論為什麼遷移，直接談遷移方案。
既然是從amq（ativemq的簡稱）遷移到kafka，那麼遷移過程中肯定需要做到平滑遷移：對於業務沒有影響，對於上下游系統沒有依賴。由於系統一般會和多個上游，多個下游通過mq中介軟體保持依賴關係，遷移的過程中，肯定要做到各個系統上線沒有任何依賴。打個比方訂單系統傳送topic，會員系統和積分系統都會接收這個topic（會員增加成長值，積分系統加積分）。改造後發布時，訂單系統，會員系統，積分系統三個系統上線應該可以任意順序，任意時間發布上線。
給出具體方案之前，先捋一下各個系統之間的依賴關係。再複雜的系統，和其他系統之間的依賴關係也就如下圖所示，假設我們關注的是系統h。它會接受上游系統a和b傳送的topic，以及給下游系統x，y和z傳送topic（說明：下圖是系統依賴關係圖，而不是例項關係依賴圖）。
根據這張架構圖，我們將訊息分為幾個型別：
生產型(1-n)訊息，不能認為是topic的使用場景，而應該是virtualtopic的使用場景（至少大部分情況下）。兩者的區別如下圖所示（amq的virtualtopic具體用法網上一大堆，這裡就不累述了）：
如上圖所示，系統x有三個例項x-1，x-2，x-3；系統y有三個例項y-1，y-2，y-3。如果系統h傳送乙個virtualtopic，假如名為：
virtualtopic.pay_success_order。系統x和系統y分別接收佇列：
vconsumers.membergroup.virtualtopic.pay_success_order和
vconsumers.pointissue.virtualtopic.pay_success_order。那麼系統x的三個例項只會有乙個例項接收到
vconsumers.membergroup.virtualtopic.pay_success_order，系統y的三個例項也只有乙個例項接收到
vconsumers.pointissue.virtualtopic.pay_success_order。如果系統h傳送乙個topic，假如名為
pay_success_order那麼系統x的三個例項和系統y的三個例項都會接收到這個topic。
接下來我們分別討論這幾種訊息如何做到平滑遷移（假定系統h就是我們要改造的系統）。
這類訊息由於我們的系統h是消費者，即被動方，我們不確定上游系統a和b的傳送方式什麼時候從amq切換到kafka，另外我們無法預知我們訂閱的amq存量訊息什麼時候消費完。所以對於這種型別的訊息，系統h在改造時要保留原來的amq訊息接收方式，同時需要新增kafka訊息接收方式即可。
這種場景就是amq中queue的使用場景。這類訊息由於我們的系統h是生產者，即主動方。且依賴關係比較簡單，就是1對1。但是考慮到下游系統即消費者不確定什麼時候加入kafka接收方式。所以，我們重構時amq傳送方式要保留，kafka傳送方式也要新增。但是需要在傳送的地方增加乙個開關，在兩種傳送方式之間切換。當下游系統即消費者引入kafka接收方式後，這個開關就可以切換到kafka傳送。生產者的amq傳送方式的**和開關在下乙個版本就可以刪除了。同理，這個消費者的amq消費方式在下乙個版本也可以刪除。
這種場景就是amq中virtualtopic的使用場景。這類訊息由於我們的系統h是生產者，即主動方。但是依賴關係相比queue使用場景要複雜一點，因為消費者比較多。考慮到若干個下游系統即消費者不確定什麼時候加入kafka接收方式。所以，我們重構時amq傳送方式要保留，kafka傳送方式也要新增。但是需要在傳送的地方增加乙個開關，在兩種傳送方式之間切換。當下游系統即消費者全部引入kafka接收方式後，這個開關就可以切換到kafka傳送。生產者的amq傳送方式的**和開關在下乙個版本就可以刪除了。同理，若干個消費者的amq消費方式在下乙個版本也可以刪除。
這種型別的訊息，即使訊息的生產和消費都在我們的系統h中，整個過程我們能夠完全掌控。如果不考慮多個例項之間部署的時間差，那麼直接將amq的傳送方式和接收方式全部更新為kafka傳送方式和接收方式。例如本地快取定時重新整理這種場景。
如果考慮多個例項之間部署的時間差，那麼就比較麻煩了。
1-1
如果自產自消是1-1型別訊息，即系統h傳送乙個queue，消費者也是系統h，且需要考慮多個例項之間部署的時間差。這個切換過程比較簡單。直接將amq的傳送方式和接收方式全部更新為kafka傳送方式和接收方式，整個滾動部署過程如下：
如果自產自消是1-n型別訊息，即系統h傳送乙個topic，消費者也是系統h，且需要考慮多個例項之間部署的時間差。這個切相對麻煩一點。
需要保留amq的接收方式，同時新增kafka接收方式，發布乙個版本。
新增kafka傳送方式，刪除amq傳送方式，滾動發布，直到所有例項部署完成。
通過上面的方案設計，即使整個部門，或者整個公司相互之間通過mq中介軟體依賴的系統有成百上千個，也可以做到從容不迫，乙個系統乙個系統慢慢遷移。完全不受其他專案組，不受其他部門的影響。整個過**正做到平滑遷移。
原文發布時間為：2018-09-14
Mysql平滑遷移（重構後的資料平滑遷移）
一般思路 只是一般思路 1 線下備份表結構 2 線上備份表資料 3 建立臨時表 4 建立檢視 簡化步驟如下 只適合參考 1 只拷貝表結構，不拷貝資料 select into b from a where 1 1 2 表資料遷移表b已經存在 insert into b d,e,f select a,b...
資料平滑遷移方法
一 問題的提出 網際網路有很多 資料量較大，併發量較大，業務複雜度較高 的業務場景，其典型系統分層架構如下 1 上游是業務層biz，實現個性化的業務邏輯 2 中游是服務層service，封裝資料訪問 3 下游是資料層db，儲存固化的業務資料 服務化分層架構的好處是，服務層遮蔽下游資料層的複雜性，例如...
zookeeper 學習筆記 平滑公升級遷移
zookeeper集群 集群個數 2n 1 一般3 5 7的奇數 把zookeeper的安裝包重新命名為node 1 node 2 node 3 配置 zoo.cfg zookeeper node 1的配置 zookeeper node 1 conf zoo.cfg ticktime 2000 in...