#方案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
缺点：增加了系统架构复杂性