“我这边现在有个问题,兵哥,你忙吗,想找你看看,有关冲突的,等等我联系下你”,这天接到线上求助。一般情况下jar包冲突开发都可以自己搞定,然后听说找了好几个人,按照常规手法没有搞定。感觉是遇到了疑难杂症,我听完挺有兴趣的,有什么jar包冲突是我们没遇到过的吗?我们今天来总结下jar包冲突相关的处理手法。
如何用java.io.*写一个服务器
写一个服务器
最近在看java nio相关的东西,照着书上的代码写了一个示例,然后就遇到了问题。为什么我们的服务器,只能接受一个请求,就卡在那里了,他到底在干啥呢?
CPU异常问题排查
背景
距离上次排查cpu异常问题已经过去了至少5年了,那个时候刚接触Java就遇到了hashmap导致的cpu100%问题,茫然无措的时候那叫一个难,现在我们有了基本的常识之后,就不慌了,按照排查思路排查,一定能发现问题。
又一起GC问题排查过程
背景
继上次找到redis导致的gc问题之后,又有一个应用发生了gc时间长的问题。每次gc的大概1s的停顿时间,导致这1s的请求全部超时,经常被业务方投诉。因为G1有更好的并行度,更短和确定的并行时间,因此负责的开发将应用从CMS升级到G1,然而问题依然没有解决. 这是一个网关类型的应用,负责接受rpc的调用,将请求转发到后端的http请求,将封装好的数据,转发给业务使用。所以实际上是
Application---->rpc-->GateWay(问题应用)-----http client ---> 其他服务.
生产FullGC问题排查
FullGC时间过长
问题
突然来了一波gc时间过长的告警,类似下面这个,接着接二连三的来了很多机器都是同样的
情况,看来集群同时发生了FullGC, 而且时间还不短。
flink读取kafka数据未能触发watermark
过年被病毒闹的出不了门,就顺带着把flink秒级统计的逻辑写了一下,逻辑很简单,就是从kafka消费数据,然后select count(*) from xxx group by xxx来一秒产出一个打点。程序代码非常简单
flink使用时间戳作为起始offset消费kafka的问题
代码如下
private static voidtest2()throwsException {
EnvironmentSettings fsSettings = EnvironmentSettings.newInstance().useOldPlanner().inStreamingMode().build();
StreamExecutionEnvironment fsEnv = StreamExecutionEnvironment.getExecutionEnvironment();
StreamTableEnvironment tttt = StreamTableEnvironment.create(fsEnv,fsSettings);
Properties properties =newProperties();
properties.setProperty("bootstrap.servers","localhost:9092");
properties.setProperty("group.id","test"+ System.currentTimeMillis());
FlinkKafkaConsumer011 kafkaConsumer011 =newFlinkKafkaConsumer011("test", newSimpleStringSchema(),properties);
kafkaConsumer011.setStartFromTimestamp(System.currentTimeMillis());
DataStream stream = fsEnv.addSource(kafkaConsumer011);
stream.print();
fsEnv.execute("test");
}2019-10-21 23:06:58.970 [Thread-8] INFO o.a.f.s.connectors.kafka.FlinkKafkaConsumerBase - Consumer subtask 0 creating fetcher with offsets {}.
表现为,无法收到kafka发送过来的消息。这就很奇怪了,因为我使用kafka-consumer-console.sh的方式可以看到实际上是有消息产出的,但是这里死活就收不到数据。
flink通过jdbc读取postgresql数据库里的数据
问题1: 从postgresql里使用flink-jdbc读取数据的问题, 数据类型不匹配,不支持jsonb等其他类型.
flink相关 – 通过Table API写入ElasticSearch的部分源码分析
New ElasticSearch()…xxx...registerTableSink();
ElasticSearch是一个ConnectorDescriptor: 最关键的就是一个toConnectorProperties就是一个配置的map,传给factory使用,他其实是一个配置收集器.
flink的动态表格
目的: 订阅kafka的消息(kafka的消息是从postgresql来的),将kafka的消息作为TableSource,执行sql,将结果输出到ElasticSearch中