本文共 2471 字，大约阅读时间需要 8 分钟。
本节重点介绍在运行过程中，这两个组件会出现什么问题及解决方式
场景如下： 场景1、第一次上线kafka的partition与realtime的个数关系 场景2、kafka数据写入最优方式 场景3、realtime配置文件在实际过程的变化及重点参数 场景4、segment堆积产生的原因及如何避免 场景5、realtime对JVM的要求 场景6、多个dataSource，大小表拆分，多topic消费初次上线要当前的数据量、集群规模等因素来综合考虑。基本定律是（以一个topic为例）：
partitions＝N＊realtimes partitions表示当前topic的分区数 N表示每台realtime消费的partition的个数 realtimes表示realtime节点总数举例说明：
3个partitions，3台realtime，那么N就是1。表示每台realtime节点消费1个partitions。 6个partitions，3台realtime，那么N就是2。表示每台realtime节点消费2个partitions。 同理都是类似方式计算。 为撒这样计算？主要考虑就是均衡，充分利用好每台realtime节点的资源。随着数据量的增加，会碰到当前topic的消费速率变慢的情况，这个时候就会对kafka集群增加节点或增加kafka节点硬盘或扩展partition个数。
增加节点和增加硬盘都属于kafka本身的操作，不会影响到realtime这层。但扩展partition个数时，realtime节点在水平扩展的时候，就需要考虑下realtime节点增加的个数（参考上面的公式来算）。kafka写入最优方式是均衡，如果不均衡，会影响到两个点：
所以使用新的hash算法（这个调整后一定要进行测试验证），我们重新开发了分配算法。默认情况下，Kafka根据传递消息的key来进行分区的分配，即hash(key) % numPartitions。
但因为Key的关系默认情况下，写入各partition数据还是会出现不均衡的。 调整成轮训方式即可。这里先说的参数重点是指runtime.properties文件里属性druid.realtime.specFile所对应的json文件内容。涉及的参数如下：
第一：shardSpec 第二：rejectionPolicy 第三：intermediatePersistPeriod ≤ windowPeriod < segmentGranularity 和 queryGranularity ≤ segmentGranularity默认设置成
"shardSpec": {"type": "none"} 这种情况单机版还可以玩一玩。在多个realtime节点的情况下，这个不能这样设置了。
现在官方文档提供：linear and numbered，但在源码中还提供了另一种SingleDimensionShardSpec，这种使用较少。 这里可以给大家分享一下，当多个realtime节点时还配置成默认值的效果（这是当初文档没有现在这么详细导致我们疏忽了），那么就是当前小时范围内的数据是跳跃的，简单的说，就是同一个查询条件发多次，返回的结果集大小不同，有时候返回30多条，有时候又返回50多条。在当时对初学的人来说很紧张，后面通过源码分析和大家的努力，终于发现了是这个参数配置失误导致。 但这个调整是有要求的，就是调整完后，必须对当前时间段realtime所有节点已经存储的数据要删除掉，不然查询的结果还是跳跃的。 举例说明： 当前时间段是12点－13点（假设segment是按小时进行），我是在12点20分调整此参数，那么再重启全部realtime节点之前，必须把12点－13点之间已经持久化的数据要删除掉，不然调整成linear后，是没有任何效果的。这个步骤非常重要。 另外注意下： realtime 节点1设置为： “partitionNum” : 1 realtime 节点2设置为： “partitionNum” : 2 realtime 节点3设置为： “partitionNum” : 3 依次类推。 关于numbered和linear的区别很小，主要在查询上面的限制，大家查看官方文档再实践下就知道了。此参数要是不理解，带来的效果就是丢失数据，会让你误认为系统有bug。
有三个值：serverTime（推荐使用）、messageTime、none。 如果想不丢弃数据就用none，另外一个用系统时间作为参考，一个用event里的timestamp作为参考。如果此参数是none的话，windowPeriod这个参数就没有什么效果了。 所以当数据有丢失的时候，首先检查时间戳和这个参数。也就是检查数据里面的timestamp和系统时间是否有较大的误差。（提醒下：首先要保证json数据格式要能正常解析）在实际的使用过程中，这几个参数的关联关系一定要当心。
首先介绍下intermediatePersistPeriod、windowPeriod、segmentGranularity三个是紧密关联的，特别windowPeriod这个参数不光控制数据消费延迟，也控制着segment合并持久化。 并且intermediatePersistPeriod参与的逻辑部分和windowPeriod参与的逻辑部分，是两个线程分开进行的。 举例说明下：转载地址：http://pdzob.baihongyu.com/