C:Consistency,一致性
1. 通过某个节点的写操作结果对后面通过其他节点的读操作可见
2. 如果更新数据后,并发访问情况下可立即感知该更新,成为强一致性
3. 如果允许之后部分或者全部感知不到该更新,称为弱一致性
4. 若在之后的一段时间(时间不固定)后,一定可以感知该更新,称为最终一致性
A:Availability 可用性
1. 任何一个没有发生故障的节点必须在有限的时间返回合理的结果
P:partition tolerance 分区容忍性
1. 部分节点宕机或者无法与其它节点通信时候,各分区还可以保持分布式系统的功能
CAP理论:分布式系统中,一致性/可用性/分区容忍性最多可以满足俩个条件
一般分区容忍性都要求有保障,因此很多时候是在可用性与一致性之间做权衡
一致性方案:
1. Master-slave
a. RDBMS的读写分离即为典型的Master-salave方案
b.同步复制可保证一致性但会影响可用性
c.异步复制可提供高可用性但会降低一致性
ISR
1. Leader会维护一个与其基本保持同步的Replica列表,该列表称为ISR
每个partition都会有一个leader,每个partition都会有一个ISR
2. 如果一个Follower比leader落后太多,或者超过一定时间未发起数据复制请求,则Leader将其从ISR移除
3. 当ISR中所有Replica都向Leader发送ACK时,Leaders即Commit
Commit策略
server配置
replica.lag.time.max.ms = 10000 //你能在落后的时间是10s,超过10s你一直没有想leader发送finish请求,这时就认为follower,有问题,那么就将他从ISR中移除
replica.lag.max.messages = 4000 //如果follower和leader相差4000条,那么也会将它从ISR中移除
当后边我们的follower落后的时间不是10s,然后相差也小于4000条,那么leader会将它重新加入到ISR中
这时就体现了一个 可用性和一致性的动态应用,再做一个权衡
Topic配置
min.insync.replicas = 1
这个可以指定,再我们的ISR中replica最小为1,这里就是没有备份,当我们一致性更好的化,那么就将他设置为2或者3
Producer配置
request.required.acks = 0
这里是异步的情况,不用等待返回,当为1是那么就是同步的,必须给出返回,才认为是成功 -1 这里其实就不是我们自己维护,这里的话是配合我们上一个参数使用的,当我们的replicas大于等于2的时候,这是必须等待我们的俩个副本都进行返回,然后才是成功