作者回复: 绝对避免是很难做到的,更多的是想办法去减轻这个影响。比如Redis配置一主一从的高可用方式。
作者回复: 这种情况需要先做一次全量同步,之后再开启binlog做增量同步。
作者回复: 写不放在Redis中有几个原因:
1. Redis不是可靠的存储,存在丢数据的风险;
2. Redis不支持事务;
3. Redis的查询能力太弱,没法满足各种各样的业务需求。
作者回复: MQ消费的时候有自动重试机制,并且不建议这个地方加重试次数的限制。如果Redis故障,就让同步卡在那儿,等Redis恢复之后,就可以继续同步,这样不会丢数据。
作者回复: 就行MySQL主从同步时延一样,只能接受它。一般这个时延都是毫米级的,不会对业务有很大影响。
作者回复: Canal也支持主备的方式来解决高可用的问题。
作者回复: 这里面需要注意一下,Binlog中记录的是“数据变化”,而不仅仅是数据。
作者回复: 它使用MySQL主从同步的协议来从主库接收Binlog,对于主库“看起来,缓存更新服务就像是一个从库一样”。
作者回复: 理论上可以把同步程序伪装者Redis的一个从节点,从Redis接收更新命令,但很少有系统这么做。原因是Redis的性能比MySQL要高出很多,这个数据同步很可能由于MySQL的性能问题,延迟很多。
作者回复: 在这种情况下,Redis需要做主从来保证高可用,不设数据过期时间,最好还要有补偿机制。
作者回复: 一般批量查询的时候可以用Redis的集合数据结构,比如SET,SET中的Value可以保存交易编号,而不用保存交易数据。
作者回复: 对于硬件的需求其实还好。目前主流的X86服务器256GB内存是比较正常的配置,10台就可以达到2.5T内存了。SSD也基本上是标配,很少新采购的服务器还使用传统机械硬盘了。
一般大型互联网公司服务器规模,约在几万台起步。
作者回复: 第一个问题,如果你能定义好冷热数据的严格界限(对于一条数据,在任何一个节点判断冷热的结果都是相同的,并且这个判断不能依赖于本地时钟),是可以做到的。但在实际生产中,很难做到“定义好冷热数据的严格界限”。
第二个问题,不推荐二个存储互相更新数据,这样很难保证数据一致性。