相同数据源情况下,使用Kafka实时消费数据 vs 离线环境下全部落表后处理数据,结果存在差异

原因分析:

  1. 当某个consumer宕机时,消费位点(例如2s提交一次)尚未提交到zookeeper,此时Kafka集群自动rebalance后另一consumer来接替该宕机consumer继续消费,因为先前宕机consumer最近的消费位点尚未提交,导致数据重复消费
  2. 突发流量、跨机房(网络请求延时高)、网络不稳定,出现丢包现象
  3. 业务逻辑有偏差

常见丢包现象如突然掉线、页面卡住、视频卡住、图片加载卡主等,使用Ping测量丢包的最佳方法是向一个IP地址发送大量的Ping命令,然后检查没有应答的那些Ping命令。如果快速地发出了50次Ping命令,可以检查没有没有应答的次数,并把没有应答的次数作为丢包。没有应答的次数超过5%可能就值得担心了。

在一台Windows计算机上,在命令提示符后面输入如下命令就可以完成这个任务:Ping -n 50(IP地址或者域名,如www.website.com)这个命令中的“-n”开关告诉发送ping命令的次数,“50”是发送的次数。如ping –n 100 www.baidu.com

然后,将得到一个测试总结。这个总结将包括丢失的数量和百分比:

199.181.132.250地址Ping的统计结果:

包:发送 = 6, 接收 = 6, 丢失 = 0 (0%)大约往返时间以毫秒(ms)显示:最小 = 26ms, 最大= 29ms, 平均 = 27ms。

上一篇:Entity Framework:三种开发模式实现数据访问


下一篇:《Entity Framework 6 Recipes》中文翻译系列 (23) -----第五章 加载实体和导航属性之预先加载与Find()方法