Kafka消息的可靠性测试--针对直播业务的方案选择

转自：http://blog.csdn.net/bailove/article/details/44240303

业务场景

来疯直播互动平台，每天有数百万人上下线，有数十万人同时参与互动直播聊天。用户的登陆、退出及用户间的各种交互行为如聊天、送礼、关注、投票、抢沙发等等事件都会产生大量的消息。这些消息具有瞬间爆发性，比如热门直播间刚开播，直播表演的高潮等等。而用户的礼物、星星、喇叭、沙发等这类消息是不允许丢失，必须100%送达。这就需要有一个高性能，高可靠，稳定可拓展的消息服务平台的支撑。它要求在网络压力大及服务器宕机等灾害的情况下，保证消息至少被发送到服务器一次。我们需要对大数据平台已提供的消息服务kafka进行测试。

测试环境

cpu：24 Intel(R) Xeon(R) CPU E5-2620 v2 @ 2.10GHz

内存：32G

磁盘数量：1 （普通sata盘）

kafka版本：0.8.2

集群规模：4节点

Topic副本数：3

Topic分片数(partition)：4

灾难模拟

 

1. 消息发送过程中宕掉其中一个节点，或同时宕掉两个节点（最多同时宕2台，因为副本数为3）

2. 频繁宕机重启其中某个节点

3. 交替宕机重启某一个或两个broker但是保证不能同时有3个节点宕机

（PS：同时出现三个节点宕机的情况，在近1年多运营中我们还没有遇到过，最多出现两个点宕机。)

 

测试结果

结论

同步_ack模式能够保证消息至少被发送一次到服务器。在三备份情况下，kafka集群不同时宕机两台以上时，能够正常给生产端和消费端提供服务。但是采用这种模式可能由于网络或服务问题导致重复发送数据，所以消费端的消费操作需要是幂等的。

同步_ack非batch

同步_ack 在不做batch的情况下单进程的发送效率比较低发送速率大概 500kb/s，增加进程数量可以提高总的发送效率。

采用这种模式，数据丢失或表现为丢失情况：

①:kafka服务器同时宕机三台以上时（副本数为3),由于没有leader服务导致producer产生的数据没有写入kafka，数据丢失。

②:消费端程序宕机,可能造成业务方面的统计错误，表现为数据丢失。此时数据没有真正丢失而是消费端消费掉的部分消息没有执行完业务逻辑表现的出来的数据丢失。消费端出现这种情况，需要有数据回滚，重新消费，补数据的机制。

同步_ack_batch

同步_ack_ batch(200条)的情况下基本达到异步_noack不做batch模式的发送速率。单客户端7m/s(如果增大batch量这个速率还会增加）,多客户端基本呈线性增加，瓶颈受限于网络带宽。

采用这种模式，数据丢失或表现为丢失情况：

①:同上

②:同上

③:因是batch发送，producer会缓存了一部分数据，如果producer宕机会造成batch在内存中且还没发送出去的消息丢失。对于这种情况producer端需要做消息持久化,定时做offset的checkpoint,将已经持久化的消息发送到kafka，如果producer意外宕机，那么从checkpoint开始恢复数据重新发送。

参考方案

针对来疯的业务场景，我们大概可以将消息分为以下三种：

1.数据量大，且允许少量数据丢失。例如用户进入频道、聊天、上下线等采用异步_noack模式

2.数据量不大，数据不允许丢失。例如用户金喇叭、抢沙发、守护等采用同步_ack模式

3.数据量大，数据不允许丢失。例如用户使用星星、送礼物、投票等Producer采用同步_ack_batch模式

针对不同类消息的应用场景定制不同的发送策略，来保证消息能够可靠高效的发送到kafka服务端。

当然要保证业务可靠，除了kafka服务端的消息可靠性及性能保障外，客户端（生产端和消费端）还要做到数据持久化，数据校验及恢复，幂等操作及事务等。

此外运维也是必不可少的一环，监控客户端及服务端的各项状态，对异常情况快速报警,及时处理以保证kafka集群稳定。后续我们将继续推出kafka、storm运营相关的文章，尽情期待！

------作者简历-----------

杨万民,毕业于北京邮电大学，目前就职于优酷土豆大数据基础平台，负责集团实时计算平台的优化与运营。个人专注于storm、kafka底层技术研究。