Java中的Kafka消費(fèi)者詳解
一、消費(fèi)者工作流程
1.1 總體工作流程
1.2 消費(fèi)者組初始化流程
1.3 消費(fèi)者組詳細(xì)消費(fèi)流程
二、消費(fèi)者消費(fèi)消息方式
pull（拉）模 式：consumer采用從broker中主動(dòng)拉取數(shù)據(jù)。Kafka采用這種方式。
push（推）模式：Kafka沒有采用這種方式，因?yàn)橛蒪roker決定消息發(fā)送速率，很難適應(yīng)所有消費(fèi)者的 消費(fèi)速率。
例如推送的速度是50m/s，Consumer1、Consumer2就來不及處理消息。
pull模式不足之處是，如 果Kafka沒有數(shù)據(jù)，消費(fèi)者可能會(huì)陷入循環(huán)中，一直返回空數(shù)據(jù)
2.1 消費(fèi)者組
Consumer Group（CG）：消費(fèi)者組，由多個(gè)consumer組成。形成一個(gè)消費(fèi)者組的條件，是所有消費(fèi)者的groupid相同。
消費(fèi)者組內(nèi)每個(gè)消費(fèi)者負(fù)責(zé)消費(fèi)不同分區(qū)的數(shù)據(jù)，一個(gè)分區(qū)只能由一個(gè)組內(nèi)消費(fèi)者消費(fèi)。 消費(fèi)者組之間互不影響。所有的消費(fèi)者都屬于某個(gè)消費(fèi)者組，即消費(fèi)者組是邏輯上的一個(gè)訂閱者。
如果向消費(fèi)組中添加更多的消費(fèi)者，超過主題分區(qū)數(shù)量，則有一部分消費(fèi)者就會(huì)閑置，不會(huì)接收任何消息。
消費(fèi)者組之間互不影響。所有的消費(fèi)者都屬于某個(gè)消費(fèi)者 組，即消費(fèi)者組是邏輯上的一個(gè)訂閱者。
2.2 消費(fèi)一個(gè)主題
// 0 配置
Properties properties = new Properties();
// 連接 bootstrap.servers
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 配置消費(fèi)者組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test5");
// 1 創(chuàng)建一個(gè)消費(fèi)者 "", "hello"
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題 first
ArrayList<String> topics = new ArrayList<>();
topics.add("first");
kafkaConsumer.subscribe(topics);
// 3 消費(fèi)數(shù)據(jù)
while (true){
//1秒消費(fèi)一次
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
}2.3 消費(fèi)一個(gè)分區(qū)
需求：創(chuàng)建一個(gè)獨(dú)立消費(fèi)者，消費(fèi) first 主題 0 號(hào)分區(qū)的數(shù)據(jù)。
// 0 配置
Properties properties = new Properties();
// 連接
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");
// 1 創(chuàng)建一個(gè)消費(fèi)者
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題對(duì)應(yīng)的分區(qū)
ArrayList<TopicPartition> topicPartitions = new ArrayList<>();
topicPartitions.add(new TopicPartition("first",0));
kafkaConsumer.assign(topicPartitions);
// 3 消費(fèi)數(shù)據(jù)
while (true){
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
}三、分區(qū)的分配以及再平衡
1、一個(gè)consumer group中有多個(gè)consumer組成，一個(gè) topic有多個(gè)partition組成，現(xiàn)在的問題是，到底由哪個(gè)consumer來消費(fèi)哪個(gè) partition的數(shù)據(jù)。
2、Kafka有四種主流的分區(qū)分配策略： Range、RoundRobin、Sticky、CooperativeSticky。 可以通過配置參數(shù)partition.assignment.strategy，修改分區(qū)的分配策略。Kafka可以同時(shí)使用多個(gè)分區(qū)分配策略。
| 參數(shù)名稱 | 描述 |
| heartbeat.interval.ms | Kafka 消費(fèi)者和 coordinator 之間的心跳時(shí)間，默認(rèn) 3s。該條目的值必須小于 session.timeout.ms，也不應(yīng)該高于session.timeout.ms 的 1/3。 |
| session.timeout.ms | Kafka 消費(fèi)者和 coordinator 之間連接超時(shí)時(shí)間，默認(rèn) 45s。超過該值，該消費(fèi)者被移除，消費(fèi)者組執(zhí)行再平衡。 |
| max.poll.interval.ms | 消費(fèi)者處理消息的最大時(shí)長(zhǎng)，默認(rèn)是 5 分鐘。超過該值，該消費(fèi)者被移除，消費(fèi)者組執(zhí)行再平衡。 |
| partition.assignment.strategy | 消 費(fèi) 者 分 區(qū) 分 配 策 略 ， 默 認(rèn) 策 略 是 Range + CooperativeSticky。Kafka 可以同時(shí)使用多個(gè)分區(qū)分配策略?？?以 選 擇 的 策 略 包 括 ： Range 、 RoundRobin 、 Sticky 、CooperativeSticky |
3.1 分區(qū)分配策略之Range
- 默認(rèn)策略是Range + CooperativeSticky。
- 再平衡案例
（1）停止掉 0 號(hào)消費(fèi)者，快速重新發(fā)送消息觀看結(jié)果（45s 以內(nèi)，越快越好）。 1 號(hào)消費(fèi)者：消費(fèi)到 3、4 號(hào)分區(qū)數(shù)據(jù)。 2 號(hào)消費(fèi)者：消費(fèi)到 5、6 號(hào)分區(qū)數(shù)據(jù)。 0 號(hào)消費(fèi)者的任務(wù)會(huì)整體被分配到 1 號(hào)消費(fèi)者或者 2 號(hào)消費(fèi)者。 說明：0 號(hào)消費(fèi)者掛掉后，消費(fèi)者組需要按照超時(shí)時(shí)間 45s 來判斷它是否退出，所以需要等待，時(shí)間到了 45s 后，判斷它真的退出就會(huì)把任務(wù)分配給其他 broker 執(zhí)行。
（2）再次重新發(fā)送消息觀看結(jié)果（45s 以后）。 1 號(hào)消費(fèi)者：消費(fèi)到 0、1、2、3 號(hào)分區(qū)數(shù)據(jù)。 2 號(hào)消費(fèi)者：消費(fèi)到 4、5、6 號(hào)分區(qū)數(shù)據(jù)。說明：消費(fèi)者 0 已經(jīng)被踢出消費(fèi)者組，所以重新按照 range 方式分配。
3.2 分區(qū)分配策略之RoundRobin
properties.put(ConsumerConfig.PARTITION_ASSIGNMENT_STRATEGY_CONFIG,"org.apache.kafka.clients.consumer.RoundRobinAssignor");
- 再平衡案例
（1）停止掉 0 號(hào)消費(fèi)者，快速重新發(fā)送消息觀看結(jié)果（45s 以內(nèi)，越快越好）。 1 號(hào)消費(fèi)者：消費(fèi)到 2、5 號(hào)分區(qū)數(shù)據(jù) 2 號(hào)消費(fèi)者：消費(fèi)到 4、1 號(hào)分區(qū)數(shù)據(jù)0 號(hào)消費(fèi)者的任務(wù)會(huì)按照 RoundRobin 的方式，把數(shù)據(jù)輪詢分成 0 、6 和 3 號(hào)分區(qū)數(shù)據(jù)， 分別由 1 號(hào)消費(fèi)者或者 2 號(hào)消費(fèi)者消費(fèi)。說明：0 號(hào)消費(fèi)者掛掉后，消費(fèi)者組需要按照超時(shí)時(shí)間 45s 來判斷它是否退出，所以需 要等待，時(shí)間到了 45s 后，判斷它真的退出就會(huì)把任務(wù)分配給其他 broker 執(zhí)行。
（2）再次重新發(fā)送消息觀看結(jié)果（45s 以后）。 1 號(hào)消費(fèi)者：消費(fèi)到 0、2、4、6 號(hào)分區(qū)數(shù)據(jù)2 號(hào)消費(fèi)者：消費(fèi)到 1、3、5 號(hào)分區(qū)數(shù)據(jù)說明：消費(fèi)者 0 已經(jīng)被踢出消費(fèi)者組，所以重新按照 RoundRobin 方式分配
3.3 Sticky 以及再平衡
粘性分區(qū)定義：可以理解為分配的結(jié)果帶有“粘性的”。即在執(zhí)行一次新的分配之前，考慮上一次分配的結(jié)果，盡量少的調(diào)整分配的變動(dòng)，可以節(jié)省大量的開銷。
粘性分區(qū)是 Kafka 從 0.11.x 版本開始引入這種分配策略，首先會(huì)盡量均衡的放置分區(qū)到消費(fèi)者上面，在出現(xiàn)同一消費(fèi)者組內(nèi)消費(fèi)者出現(xiàn)問題的時(shí)候，會(huì)盡量保持原有分配的分區(qū)不變化
再平衡案例
（1）停止掉 0 號(hào)消費(fèi)者，快速重新發(fā)送消息觀看結(jié)果（45s 以內(nèi)，越快越好）。 1 號(hào)消費(fèi)者：消費(fèi)到 2、5、3 號(hào)分區(qū)數(shù)據(jù)。 2 號(hào)消費(fèi)者：消費(fèi)到 4、6 號(hào)分區(qū)數(shù)據(jù)。 0 號(hào)消費(fèi)者的任務(wù)會(huì)按照粘性規(guī)則，盡可能均衡的隨機(jī)分成 0 和 1 號(hào)分區(qū)數(shù)據(jù)，分別由 1 號(hào)消費(fèi)者或者 2 號(hào)消費(fèi)者消費(fèi)。說明：0 號(hào)消費(fèi)者掛掉后，消費(fèi)者組需要按照超時(shí)時(shí)間 45s 來判斷它是否退出，所以需要等待，時(shí)間到了 45s 后，判斷它真的退出就會(huì)把任務(wù)分配給其他 broker 執(zhí)行。
（2）再次重新發(fā)送消息觀看結(jié)果（45s 以后）。 1 號(hào)消費(fèi)者：消費(fèi)到 2、3、5 號(hào)分區(qū)數(shù)據(jù)。 2 號(hào)消費(fèi)者：消費(fèi)到 0、1、4、6 號(hào)分區(qū)數(shù)據(jù)。說明：消費(fèi)者 0 已經(jīng)被踢出消費(fèi)者組，所以重新按照粘性方式分配。
四、offset 位移
__consumer_offsets 主題里面采用 key 和 value 的方式存儲(chǔ)數(shù)據(jù)。key 是 group.id+topic+分區(qū)號(hào)，value 就是當(dāng)前 offset 的值。
每隔一段時(shí)間，kafka 內(nèi)部會(huì)對(duì)這個(gè) topic 進(jìn)行compact，也就是每個(gè) group.id+topic+分區(qū)號(hào)就保留最新數(shù)據(jù)。
4.1 自動(dòng)提交 offset
為了使我們能夠?qū)Ｗ⒂谧约旱臉I(yè)務(wù)邏輯，Kafka提供了自動(dòng)提交offset的功能。5s
| 參數(shù)名稱 | 描述 |
| enable.auto.commit | 默認(rèn)值為 true，消費(fèi)者會(huì)自動(dòng)周期性地向服務(wù)器提交偏移量。 |
| auto.commit.interval.ms | 自動(dòng)提交offset的時(shí)間間隔，默認(rèn)是5s，如果設(shè)置了 enable.auto.commit 的值為 true， 則該值定義了消費(fèi)者偏移量向 Kafka 提交的頻率，默認(rèn) 5s。 |
// 自動(dòng)提交 properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,true); // 提交時(shí)間間隔 properties.put(ConsumerConfig.AUTO_COMMIT_INTERVAL_MS_CONFIG,1000);
4.2 手動(dòng)提交offset
雖然自動(dòng)提交offset十分簡(jiǎn)單便利，但由于其是基于時(shí)間提交的，開發(fā)人員難以把握offset提交的時(shí)機(jī)。因 此Kafka還提供了手動(dòng)提交offset的API。
手動(dòng)提交offset的方法有兩種：分別是commitSync（同步提交）和commitAsync（異步提交）。兩者的相同點(diǎn)是，都會(huì)將本次提交的一批數(shù)據(jù)最高的偏移量提交；不同點(diǎn)是，同步提交阻塞當(dāng)前線程，一直到提交成功，并且會(huì)自動(dòng)失敗重試（由不可控因素導(dǎo)致，也會(huì)出現(xiàn)提交失?。欢惒教峤粍t沒有失敗重試機(jī)制，故有可能提交失敗。
commitSync（同步提交）：必須等待offset提交完畢，再去消費(fèi)下一批數(shù)據(jù)。 commitAsync（異步提交） ：發(fā)送完提交offset請(qǐng)求后，就開始消費(fèi)下一批數(shù)據(jù)了。
- 同步提交 offset
由于同步提交 offset 有失敗重試機(jī)制，故更加可靠，但是由于一直等待提交結(jié)果，提交的效率比較低。以下為同步提交 offset 的示例。
// 0 配置
Properties properties = new Properties();
// 連接 bootstrap.servers
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 配置消費(fèi)者組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");
// 手動(dòng)提交
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,false);
// 1 創(chuàng)建一個(gè)消費(fèi)者 "", "hello"
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題 first
ArrayList<String> topics = new ArrayList<>();
topics.add("first");
kafkaConsumer.subscribe(topics);
// 3 消費(fèi)數(shù)據(jù)
while (true){
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
// 同步提交 offset
kafkaConsumer.commitSync();
}- 異步提交 offset
雖然同步提交 offset 更可靠一些，但是由于其會(huì)阻塞當(dāng)前線程，直到提交成功。因此吞吐量會(huì)受到很大的影響。因此更多的情況下，會(huì)選用異步提交 offset 的方式。
// 0 配置
Properties properties = new Properties();
// 連接 bootstrap.servers
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 配置消費(fèi)者組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test");
// 手動(dòng)提交
properties.put(ConsumerConfig.ENABLE_AUTO_COMMIT_CONFIG,false);
// 1 創(chuàng)建一個(gè)消費(fèi)者 "", "hello"
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題 first
ArrayList<String> topics = new ArrayList<>();
topics.add("first");
kafkaConsumer.subscribe(topics);
// 3 消費(fèi)數(shù)據(jù)
while (true){
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
// 同步提交 offset
kafkaConsumer.commitAsync();
}4.3 指定 Offset 消費(fèi)
auto.offset.reset = earliest | latest | none 默認(rèn)是 latest。 當(dāng) Kafka 中沒有初始偏移量（消費(fèi)者組第一次消費(fèi)）或服務(wù)器上不再存在當(dāng)前偏移量時(shí)（例如該數(shù)據(jù)已被刪除），該怎么辦？
（1）earliest：自動(dòng)將偏移量重置為最早的偏移量，–from-beginning。
（2）latest（默認(rèn)值）：自動(dòng)將偏移量重置為最新偏移量。
（3）none：如果未找到消費(fèi)者組的先前偏移量，則向消費(fèi)者拋出異常。
// 0 配置信息
Properties properties = new Properties();
// 連接
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test3");
// 1 創(chuàng)建消費(fèi)者
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題
ArrayList<String> topics = new ArrayList<>();
topics.add("first");
kafkaConsumer.subscribe(topics);
// 指定位置進(jìn)行消費(fèi)
Set<TopicPartition> assignment = kafkaConsumer.assignment();
// 保證分區(qū)分配方案已經(jīng)制定完畢
while (assignment.size() == 0){
kafkaConsumer.poll(Duration.ofSeconds(1));
assignment = kafkaConsumer.assignment();
}
// 指定消費(fèi)的offset
for (TopicPartition topicPartition : assignment) {
kafkaConsumer.seek(topicPartition,600);
}
// 3 消費(fèi)數(shù)據(jù)
while (true){
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
}4.4 指定時(shí)間消費(fèi)
需求：在生產(chǎn)環(huán)境中，會(huì)遇到最近消費(fèi)的幾個(gè)小時(shí)數(shù)據(jù)異常，想重新按照時(shí)間消費(fèi)。例如要求按照時(shí)間消費(fèi)前一天的數(shù)據(jù)，怎么處理？
// 0 配置信息
Properties properties = new Properties();
// 連接
properties.put(ConsumerConfig.BOOTSTRAP_SERVERS_CONFIG,"hadoop102:9092,hadoop103:9092");
// 反序列化
properties.put(ConsumerConfig.KEY_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
properties.put(ConsumerConfig.VALUE_DESERIALIZER_CLASS_CONFIG, StringDeserializer.class.getName());
// 組id
properties.put(ConsumerConfig.GROUP_ID_CONFIG,"test3");
// 1 創(chuàng)建消費(fèi)者
KafkaConsumer<String, String> kafkaConsumer = new KafkaConsumer<>(properties);
// 2 訂閱主題
ArrayList<String> topics = new ArrayList<>();
topics.add("first");
kafkaConsumer.subscribe(topics);
// 指定位置進(jìn)行消費(fèi)
Set<TopicPartition> assignment = kafkaConsumer.assignment();
// 保證分區(qū)分配方案已經(jīng)制定完畢
while (assignment.size() == 0){
kafkaConsumer.poll(Duration.ofSeconds(1));
assignment = kafkaConsumer.assignment();
}
// 希望把時(shí)間轉(zhuǎn)換為對(duì)應(yīng)的offset
HashMap<TopicPartition, Long> topicPartitionLongHashMap = new HashMap<>();
// 封裝對(duì)應(yīng)集合
for (TopicPartition topicPartition : assignment) {
topicPartitionLongHashMap.put(topicPartition,System.currentTimeMillis() - 1 * 24 * 3600 * 1000);
}
Map<TopicPartition, OffsetAndTimestamp> topicPartitionOffsetAndTimestampMap = kafkaConsumer.offsetsForTimes(topicPartitionLongHashMap);
// 指定消費(fèi)的offset
for (TopicPartition topicPartition : assignment) {
OffsetAndTimestamp offsetAndTimestamp = topicPartitionOffsetAndTimestampMap.get(topicPartition);
kafkaConsumer.seek(topicPartition,offsetAndTimestamp.offset());
}
// 3 消費(fèi)數(shù)據(jù)
while (true){
ConsumerRecords<String, String> consumerRecords = kafkaConsumer.poll(Duration.ofSeconds(1));
for (ConsumerRecord<String, String> consumerRecord : consumerRecords) {
System.out.println(consumerRecord);
}
}五、消費(fèi)者事務(wù)
重復(fù)消費(fèi)：已經(jīng)消費(fèi)了數(shù)據(jù)，但是 offset 沒提交。
漏消費(fèi)：先提交 offset 后消費(fèi)，有可能會(huì)造成數(shù)據(jù)的漏消費(fèi)。
思考：怎么能做到既不漏消費(fèi)也不重復(fù)消費(fèi)呢？詳看消費(fèi)者事務(wù)。
如果想完成Consumer端的精準(zhǔn)一次性消費(fèi)，那么需要Kafka消費(fèi)端將消費(fèi)過程和提交offset過程做原子綁定。此時(shí)我們需要將Kafka的offset保存到支持事務(wù)的自定義介質(zhì)（比 如MySQL）。
數(shù)據(jù)積壓（消費(fèi)者如何提高吞吐量）
| 參數(shù)名稱 | 描述 |
| fetch.max.bytes | 默認(rèn) Default: 52428800（50 m）。消費(fèi)者獲取服務(wù)器端一批消息最大的字節(jié)數(shù)。如果服務(wù)器端一批次的數(shù)據(jù)大于該值（50m）仍然可以拉取回來這批數(shù)據(jù)，因此，這不是一個(gè)絕對(duì)最大值。一批次的大小受 message.max.bytes （broker config）or max.message.bytes （topic config）影響。 |
| max.poll.records | 一次 poll 拉取數(shù)據(jù)返回消息的最大條數(shù)，默認(rèn)是 500 條 |
到此這篇關(guān)于Java中的Kafka消費(fèi)者詳解的文章就介紹到這了,更多相關(guān)Kafka消費(fèi)者內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
在Java中使用redisTemplate操作緩存的方法示例
這篇文章主要介紹了在Java中使用redisTemplate操作緩存的方法示例，在Redis中可以存儲(chǔ)String、List、Set、Hash、Zset。感興趣的可以了解一下2019-01-01
這篇文章主要介紹了Java使用split截取字符串過程解析,文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友可以參考下2020-02-02
這篇文章主要介紹了如何利用反射批量修改java類某一屬性,本文通過實(shí)例代碼給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值，需要的朋友可以參考下2020-07-07
Springboot接收Get參數(shù)實(shí)踐過程
本文主要介紹了在Spring Boot中如何接收不同類型的請(qǐng)求參數(shù),包括在路徑中直接傳遞參數(shù)、跟在問號(hào)后面?zhèn)鬟f參數(shù)、使用Map接收參數(shù)、接收數(shù)組以及使用對(duì)象接收參數(shù)等方法2024-12-12
nohup命令允許程序在用戶退出賬戶或關(guān)閉終端后繼續(xù)運(yùn)行,常與"&"結(jié)合使用以實(shí)現(xiàn)程序的后臺(tái)執(zhí)行,配合重定向操作,nohup可以將程序輸出保存到日志文件中,如nohup java -jar XXX.jar &> myout.log &,此外,tail命令可用于實(shí)時(shí)監(jiān)控日志文件的變化2024-09-09
sprinboot項(xiàng)目啟動(dòng)一半到圖形化界面卡住了的解決
這篇文章主要介紹了sprinboot項(xiàng)目啟動(dòng)一半到圖形化界面卡住了的解決方案，具有很好的參考價(jià)值，希望對(duì)大家有所幫助。如有錯(cuò)誤或未考慮完全的地方，望不吝賜教2022-10-10
Sa-Token不同模式實(shí)現(xiàn)單地登錄?多地登錄?同端互斥登錄
這篇文章主要為大家介紹了Sa-Token不同模式實(shí)現(xiàn)單地登錄?多地登錄?同端互斥登錄，有需要的朋友可以借鑒參考下，希望能夠有所幫助，祝大家多多進(jìn)步，早日升職加薪2023-07-07
Java多線程實(shí)現(xiàn)阻塞隊(duì)列的示例代碼
本文主要介紹了Java多線程實(shí)現(xiàn)阻塞隊(duì)列的示例代碼,文中通過示例代碼介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值,需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2024-12-12
Java 守護(hù)線程_動(dòng)力節(jié)點(diǎn)Java學(xué)院整理
Java語言機(jī)制是構(gòu)建在JVM的基礎(chǔ)之上的，意思是Java平臺(tái)把操作系統(tǒng)的底層給屏蔽起來，所以它可以在它自己的虛擬的平臺(tái)里面構(gòu)造出對(duì)自己有利的機(jī)制，而語言或者說平臺(tái)的設(shè)計(jì)者多多少少是收到Unix思想的影響，而守護(hù)線程機(jī)制又是對(duì)JVM這樣的平臺(tái)湊合，于是守護(hù)線程應(yīng)運(yùn)而生2017-05-05
SpringBoot利用Redis實(shí)現(xiàn)防止訂單重復(fù)提交的解決方案
在涉及訂單操作的業(yè)務(wù)中,防止訂單重復(fù)提交是一個(gè)常見需求,用戶可能會(huì)因誤操作或網(wǎng)絡(luò)延遲而多次點(diǎn)擊提交訂單按鈕,導(dǎo)致訂單重復(fù)提交,所以本文給大家介紹了SpringBoot利用Redis實(shí)現(xiàn)防止訂單重復(fù)提交的解決方案,需要的朋友可以參考下2024-10-10