一.高可用的由来
1.1 为什么需要Replication
在Kafka在0.8之前的版本中,是没有Replication,一旦某个broker宕机,则其上的所有Partition数据都不可被消费,这与Kafka的数据持久化和Delivery Guarantee设计原则相违背。
如果Producer使用同步模式则Producer则会在尝试重新发送message.send.max.retries(默认值是3)次后抛出异常,用户可以选择停止发送后续数据或者继续发送。而前者会造成数据的阻塞,后者会造成发送到Kafak数据的丢失。
如果Producer使用异步模式,则Producer会尝试重新发送message.send.max.retries(默认值是3)次后记录该异常并继续发送后续数据,这会造成数据丢失并且用户只能通过日志发现问题。同时,Kafka的Producer并没有对异步模式提供fallback接口。
由此可见,在没有Replication的情况下,一旦某机器宕机或者某个Broker停止工作会曹成整个系统的可用性的降低。随着集群规模的增加,整个集群中出现该类异常的几率大大增加,由此可见,Replication的引入是很有必要的。
1.2 Leader Election
引入Replication之后,同一个Partition可能会有多个Replica,而在这些之中需要选取一个Leader,Producer和Comsumer只会和这个Leader交互,其他作为Follower从Leader中复制数据。
因为需要保证同一个Partition中多个副本之间的数据一致性(其中一个宕机后其他副本必须继续服务,不能造成数据重复也不能造成数据丢失)。如果没有一个leader,所有副本都可同时读写数据,则需要多个副本之间联通,数据一致性和有序性非常难保证。引入leader之后,leader负责读写,follower只需要从leader中fetch数据。