#方案1，利用logstash定時向數據庫讀取數據然後寫入到elastic search中
架構：數據庫+logstash+elastic search
缺點：1）因為是定時讀取數據庫，存在一定的時延
2）若同步時間間隔調的比較短，比如每秒定時同步一次數據，此時會增大業務數據庫的壓力
相關鏈接：https://www.cnblogs.com/csts/p/6120644.html
#為了解決時延的問題，採用同步雙寫方案，實時同步數據，於是引入方案2：
方案2：同步雙寫，即在業務應用系統寫數據到數據庫時，同時插入一條數據到elastic search中
架構：業務應用 elastic search
缺點：硬編碼，強業務耦合，性能差等
#為了解決同步雙寫性能差的問題，那麼引入mq來實現異步雙寫，於是引入方案3：
方案3：異步雙寫，即引入mq並開發一個數據同步系統，在業務系統應用（生產者）中每做一筆交易，然後將數據發送到mq，數據同步系統（消費者）訂閲mq消息，
完成數據同步到elastic search中
架構：業務應用 mq 同步系統 elastic search
缺點：1）數據同步邏輯與業務應用系統強耦合在一起
相關鏈接：https://blog.csdn.net/lp2388163/article/details/80633190
#為了解決數據同步邏輯與業務應用系統強耦合的問題，為了解耦且解決logstash定時同步時延的問題，於是引入阿里的canal來同步數據，引入方案3：
方案4，利用canal訂閲數據庫的binlog日誌文件，然後實時發送數據到elastic search中
架構：mysql canal elastic search
缺點：1）若在高併發場景下，對canal服務器及客户端可能會造成性能壓力
2）若canal同步binlog日誌過程中，canal客户端宕機可能導致數據丟失
相關鏈接：https://www.jianshu.com/p/9677ca6ca34e
#為了解決方案3中高併發的性能壓力及canal客户端宕機數據丟失的問題，此時也引入mq，既做到限流削峯又起到數據緩存存儲的作用
方案5：利用canal訂閲數據庫的binlog日誌文件，然後實時發送數據到mq中，然後利用數據同步系統訂閲mq的消息完成數據同步到elastic search中
架構：mysql canal mq 數據同步系統 elastic search
缺點：增加了系統架構複雜性