首页 > 代码库 > Kafka系列之1—Kafka的总体认识
Kafka系列之1—Kafka的总体认识
Kafka的总体认识
1.非中心的架构模型
2.基于TCP的一套Kafka通信协议
3.消息中间件&存储系统
4.存储逻辑层的高并发保证
5.isr机制降低了保证分布式一致性的代价
1. 非中心的架构模型
我们知道，在分布式系统的架构类型里，既有主从式的架构，也有非中心式的架构，像hadoop和hbase都采用了主从式的架构模型，主从式的架构优点有很多，但是主从式下为了避免单点故障而采取的各种策略使得主从式架构的优点并不那么理想，kafka作为一个分布式的消息系统，它采用了非中心式的架构模型，每个节点都作为独立的Server向Client提供服务，在集群环境下，多个节点依赖zookeeper维护client在读写访问中的分布式一致性。
在早期0.8.2之前的kafka版本中，kafka对zookeeper的依赖非常大，producer、server、consumer都非常依赖zookeeper，虽然zookeeper作为一个轻量级的文件系统（已经成为分布式服务的基础服务，用以提供分布式环境下的一致性），但是大量的与其交互仍然会导致一些性能问题和不稳定的方面，在0.8.2之后的改进中，通过将一些状态保持在kafka自身中，减少与zookeeper的大量交互，为读写提供了更稳定的实现。
2. 基于TCP的一套Kafka通信协议
2.1 概述
kafka的通信协议相当的简单，只有六类核心的客户端请求APIs。
Metadata：描述当前可用的brokers的host和port信息，并给出每个broker上分配了哪些partitions；
Send：发送messages到broker；
Fetch：从broker中获取messages，包括获取data、获取集群的元数据信息以及获取某个topic的offset信息；
Offsets：获取某个给定topic partition的可用offsets信息；
Offset Commit：提交consumer group的offsets信息；
Offset Fetch：获取某个consumer group的offsets信息集合。
这些都会在下面详细描述。另外，0.9版本的kafka对consumers和kafka connect支持一般的group management。这部分的Client Api包括五种requests：
GroupCoordinator：定位当前consumer group的coordinator；
JoinGroup：加入一个consumer group，如果没有就创建一个；
SyncGroup：同步同一个group下的所有consumer状态（partition分配到consumer的分布情况）；
Heartbeat：用来检测group中的成员的存活状态；
LeaveGroup：直接离开一个group。
还有一些用于监控/管理 kafka集群的administrativeAPIs
DescribeGroups：用来检测当前的groups；
ListGroups：列出broker中管理的groups。
和response格式
Request格式如下：
RequestMessage => ApiKey ApiVersionCorrelationId ClientId RequestMessage
ApiKey => int16
ApiVersion => int16
CorrelationId => int32
ClientId => string
RequestMessage => MetadataRequest | ProduceRequest | FetchRequest |OffsetRequest | OffsetCommitRequest | OffsetFetchRequest
Response格式如下：
Response => CorrelationIdResponseMessage
CorrelationId => int32
ResponseMessage => MetadataResponse |ProduceResponse | FetchResponse | OffsetResponse | OffsetCommitResponse |OffsetFetchResponse
ApiKey | 这个int数值是用来表明是哪一种请求，KafkaApis根据这个值来调用相应的处理逻辑 |
ApiVersion | 由于不同的Kafka版本支持的ApiVersion不同，因此要根据KafkaServer支持的ApiVersion来发送对应格式的Request |
CorrelationId | 客户端提供的一个整型值，在response中会原封不动的返回，它的作用主要是用来匹配client和server之间的request和response。 |
2.3 ApiKey
下面的列表是ApiKey的整型值对应的Request类：
API name | ApiKey Value |
ProduceRequest | 0 |
FetchRequest | 1 |
OffsetRequest | 2 |
MetadataRequest | 3 |
Non-user facing control APIs | 4-7 |
OffsetCommitRequest | 8 |
OffsetFetchRequest | 9 |
GroupCoordinatorRequest | 10 |
JoinGroupRequest | 11 |
HeartbeatRequest | 12 |
LeaveGroupRequest | 13 |
SyncGroupRequest | 14 |
DescribeGroupsRequest | 15 |
ListGroupsRequest | 16 |
2.4Response中的Error Codes
Error | Code | 重试 | 描述 |
NoError | 0 | 没有错误，执行成功！ | |
Unknown | -1 | 未知的server error | |
OffsetOutRange | 1 | 请求的offset值超出了server端维护的对应topic/partition的offset值（可以大于也可以小于） | |
InvalidMessage/CorruptMessage | 2 | YES | 消息内容不能通过CRC校验 |
UnknownTopicOrPartition | 3 | YES | 请求的topic或partition不再发往的broker上 |
InvalidMessageSize | 4 | 消息的大小为负值 | |
LeaderNotAvailable | 5 | YES | 请求发生在leader选举过程中时抛出这个异常，此时请求的partition没有leader无法读写 |
NotLeaderForPartition | 6 | YES | 在客户端尝试向不是leader的replica写入信息时抛出，意味着客户端的元数据信息过期了 |
RequestTimedOut | 7 | YES | request超过了用户指定的时间，一般是值socket超时 |
BrokerNotAvailable | 8 | 这个错误不是client遇到的，往往发生在工具类的请求中 | |
ReplicaNotAvailable | 9 | broker上没有期望的replica（可以被安全的忽视） | |
MessageSizeTooLarge | 10 | server有一个最大消息的配置，当client向server端写入超过配置大小的message时抛出 | |
StaleControllerEpochCode | 11 | 在broker和broker通信时发生的内部错误 | |
OffsetMetadataTooLargeCode | 12 | 如果指定了一个大于配置的offset metadata大小的string | |
GroupLoadInProgressCode | 14 | YES | 当topic partition的leader发生变化后，新的leader在load offsets时，offset fetch request请求时抛出，或者在group membership（例如heartbeat）的response中返回当coordinator在load group metadata时 |
GroupCoordinatorNotAvailableCode | 15 | YES | offsets topic还没创建或者group coordinator没有active |
NotCoordinatorForGroupCode | 16 | YES | offset fetch或commit request的请求发往一个不是coordinator的节点 |
InvalidTopicCode | 17 | 访问一个不可用的topic或者尝试对内部topic（__consumer_offset）进行写入操作时 | |
RecordListTooLargeCode | 18 | 如果produce的message batch超过了配置的segment size | |
NotEnoughReplicasCode | 19 | YES | 处于in-sync的replicas数量小于配置的produce要求的最小replicas和requiredAcks=-1 |
NotEnoughReplicasAfterAppendCode | 20 | YES | 当message被写入到log后，但是in-sync的replicas数小于需要的 |
InvalidRequiredAcksCode | 21 | 请求的requiredAcks是不可获得的 | |
IllegalGenerationCode | 22 | server端的generation id和request中的generation id不一致 | |
InconsistentGroupProtocolCode | 23 | 当前group能够接受的protocol type中不包含join group时给出的protocol type | |
InvalidGroupIdCode | 24 | 当join group时groupId为空或者null | |
UnknownMemberIdCode | 25 | 当前generation里group中不包含请求的memberId | |
InvalidSessionTimeoutCode | 26 | join group时超出了配置的request session timeout | |
RebalanceInProgressCode | 27 | 当请求发起时coodinator正在对group进行rebalance，此时client要重新join group | |
InvalidCommitOffsetSizeCode | 28 | 当offset commit超过metadata的最大限制被拒绝时 | |
TopicAuthorizationFailedCode | 29 | client没有访问请求的topic的权限时 | |
GroupAuthorizationFailedCode | 30 | ||
ClusterAuthorizationFailedCode | 31 |
kafka实现了基于tcp的一种通信协议，只要符合通信协议的规范，即可与kafka server进行通信，因而kafka client是跨语言的
3. 消息中间件&存储系统
kafka既可以被认为是消息中间件，也可以作为存储系统使用
由于kafka可以将producer发送的消息保存起来供consumer消费，因此既可以作为消息中间件使用，也可以作为存储系统来保存数据。
4. 存储逻辑层的高并发保证
kafka在存储逻辑层的设计为高吞吐量提供了可能
kafka存储数据的逻辑单元是partition，producer和consumer的处理单元也是基于partition的，针对某个topic，可以有多个partition，而多个partition又可以分布在不同的节点上，从而在存储层保证了I/O的并发，为高吞吐量提供了可能。
5. isr机制降低了保证分布式一致性的代价
kafka的isr同步机制使得保证分布式一致性的代价大大降低
kafka的isr机制，允许isr中的replica和主副本之前有一定的差距，这样做保证了响应的及时性，另一方面，由于在isr层面没有考虑严格的分布式一致性，没有使用paxos的leader选举策略，使得kafka的leader选举更加容易，没有严格的节点数要求的限制，只要有一个节点是isr中的，就不会丢数据。
本文出自 “数字科技” 博客，请务必保留此出处http://7639538.blog.51cto.com/7629538/1883631
Kafka系列之1—Kafka的总体认识