作者回复: 第一个问题确实存在 如果从库同步延迟,只有缓存更新成功了,穿透访问数据库就会数据不一致,所以要保证数据库同步的及时性。
第二个问题看你理解的准实时有多实时,如果是秒级别的话目前里看还是强一致性的方案靠谱,但是这种方案比较复杂,需要付出一定的性能代价,对微博的业务场景来说目前没有这个强一致性的需求。
第三个问题异地多活就是靠多机房部署才能实现。
作者回复: 说的很对👍
作者回复: 目前微博业务要求的是最终一致性,强一致性还没达到
作者回复: 重试的前提是要满足服务的幂等
作者回复: 一般都是先写数据库再写缓存,以数据库的操作为准
作者回复: 后面就全是实践了,希望你能有所收获,哈哈
作者回复: 我上面说得通过对账机制就是一种方案
作者回复: 1.确实有这个问题,在异常情况下要靠缓存来扛。
2.实时同步只能是靠强一致性的解决方案,这样业务性能肯定会有一定影响,代码复杂度也会增加不少,阿里和腾讯都有自己的成熟方案,可以去看看。