1.前提

这次数据库的冷热分离算是第二次做了
其实之前已经做过一次冷热分离了,涉及到数据库复制时,当时是趋近于业务的(后面会详细讲),整体来讲不是很好用,这次算是重构了吧
做的最终结果还是和前一次一样:
数据库中的订单数据,是每时每刻都在增加
我们认为3个月以内的数据,用户会频繁的操作,称为热数据
3个月以前的数据,基本上不会有修改的地方了,查询也是很少量的,我们称为冷数据
所以将现有数据库称之为生产库,
然后再增加一个独立的库,我们称之为历史库,
我们要做的就是生产库中只放3个月内的数据,
历史库放所有的数据,
查询的时候,主查生产库,生产库没有,再考虑查询历史库,
生产库提供所有的业务操作,
历史库只提供查询功能,不提供其他业务功能,

2.前一次冷热分离的思路

因为项目在数据入库的时候,业务需求,会发一个mq消息给其他下游,前一次的思路就是复用这个消息
让我们的项目反过来再消费这个消息,就可以异步获得数据的变化情况,再将数据同步到历史库中
前一次冷热分离的细节,在这个文章里

正所谓 : 成也复用,败也复用

上次做完后,当时的效果也很好,确实冷热分离了,生产库的压力也确实小了很多

但是复用带来问题马上就暴露出来了:

项目设计到需求的变化,需要增加字段,并且原逻辑也有变化
这样带来的问题是,做需求的时候,需要格外注意数据的同步,
尤其是一些状态的变化,很容易造成生产库改了,没有同步到历史库中
久而久之,加上没人专门维护这个历史库,历史库的数据已经乱的不成样子

3.这一次冷热分离的思路

有了上次的经验教训,这次就老实多了,直接使用binlog日志,
数据库的每一次增加和修改操作,mysql开启binlog后,都能在binlog日志中记录,
采用这一特性,通过数据库级别的监控,就不需要担心业务上的变化带来的不一致了,
只要生产库的数据有变化,我们就可以根据binlog日志,直接将数据同步到历史库中
这一次冷热分离的细节,在这个文章里