作者回复: 加一颗星:),问题1,此时访问的领导者可能不是真正的领导者,比如3节点集群(A、B、C),A是领导者,发生了网络分区,B、C选举出了新领导者C,当我们继续加一颗星:),访问节点A时,A可能仍处于稳定状态(在 leader leasing 时间内),认为自己领导者(其实它已经不是了),这时它返回数据给客户端,这份数据可能不是最新的。问题2:这个说法不严谨,必须确认主节点仍是领导者,但因为zab不支持该功能,所以,这个做法落地性差,已修正。
作者回复: 加一颗星:)。问题1:可以容忍少数节点故障,也就是说,当少数节点故障时,系统能稳定运行。问题2:节点故障,需要我们做监控来发现,然后修复的。另外,其实你可以通过20讲的raftdb程序,来测试下Raft的节点故障容错能力,感性体验下。
作者回复: 加一颗星:),创建集群时,才需要以bootstrap的形式启动,第一个节点是领导者,这是Hashicorp Raft实现的一个功能,方便添加节点创建集群。正常启动,是不需要bootstrap的,领导者由选举产生。具体可以参考下raftdb的Store.Open()的实现。使用Raft,是不需要指定领导者(也就是master的)。
作者回复: 加一颗星:),我后面做个补充吧。
作者回复: 加一颗星:),冷热的本质区别是访问速度,根据实际场景妥协权衡,比如,可以考虑数据类型,对访问效率要求高的业务数据,全部是热数据,要求不高的,冷数据;另外实现时间局部性,访问到的冷数据,在热数据中停留些时间,再老化,下沉为冷数据。
作者回复: 加一颗星:),SET操作(比如SET X = 1)具有冥等性的,执行多次,和执行一次,效果是一样的,即使有多个日志项,后面也会去重压缩处理的,不会有影响的。
作者回复: 比如redis、memcached、etcd、zookeeper等。