草！（一种植物） 别问，问就是后悔。我就不该听信什么“轻量级同步”的鬼话，为了省那点ETL的功夫，动了歪心思，现在好了，连主站都跟着遭殃，被源站的防火墙标记为恶意攻击，IP段都被扬了。
你绝对想不到，你以为的“简单查询”在对方服务器日志里看起来有多恐怖——几百个连接池瞬间建立又断开，每秒几十个SELECT * FROM大表，还他妈没用索引！人家运维兄弟的告警短信估计都被刷爆了。换我我也封。现在想想都后怕，那种感觉就像你半夜偷偷摸摸想从邻居家接根水管，结果把人家总闸给撬了，水漫金山不说，人家拿着棍子就追出来了。我当时就是这么个憨批。
血泪教训就几点，你们听不听随意，反正我脑子已经清醒了，烟灰缸都满了：
第一，别想着直连！别想着直连！别想着直连！ 你永远不知道对方数据库的压力阈值在哪里，你以为的`limit 100`可能瞬间触发全表扫描把IO打满。就算、就算、万不得已非要连，也他妈别用生产库的账号密码硬上，去跟对方要只读副本的地址，或者求他们给你开个API接口。（这里有个血泪写成的《数据库交互保命手册》，我悔没早看）
第二，中间件！中间件！中间件！ 我后来才明白，为什么大厂都要搞一层Data API或者消息队列。你用Kafka、用RocketMQ，哪怕用最土的Flink搞个CDC流式同步，都比直接`jdbc:mysql://[对方IP]:3306/xxx`要强一万倍。这玩意儿是缓冲带，是护城河，出了问题你能掐掉中间件，不至于把战火烧到两端服务器。我就是少了这层，直接裸奔，一枪就被爆头了。
第三，监控和熔断必须配齐。 你写个脚本去拉数据，光`try-catch`有个屁用。你得设超时时间（我的连接超时设了30秒，纯纯等死），你得监控查询响应时间和网络延迟，一旦连续失败几次，立马熔断，发邮件、发钉钉、打电话叫你起床。我就是凌晨脚本跑崩了，它还在那无限重试，活生生把自己和对方都拖死了，早上起来一看监控图，两根直线，一根是请求量，一根是我的血压。
最后说点人话吧。搞数据同步，“拉”不如“推”。求爷爷告奶奶，让有数据的那边，用他们的调度系统，定时把增量数据生成个文件扔到SFTP或者OSS上，你再安安稳稳地去取。权限清晰，责任分明，天塌了也是他们调度任务失败，跟你无关。
我现在？呵呵，正在给对方的运维老大写第八版道歉邮件，并表示愿意承担那晚所有的云监控告警费用。真的，有些坑，踩一次就足以让你的技术生涯留下一个笑柄。 不说了，我继续去装孙子了。祝你们永远不用处理这种烂摊子。
