kafka学习之路（三）——高级_汤高的博客-CSDN博客_kafka高级学习
kafka学习之路（三）——高级
汤高
于 2016-07-17 21:34:43 发布
8393
收藏
17
分类专栏：
大数据与云计算
kafka
大数据生态系统技术
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/tanggao1314/article/details/51934748
版权
大数据与云计算
同时被 3 个专栏收录
50 篇文章
3 订阅
订阅专栏
kafka
5 篇文章
4 订阅
订阅专栏
大数据生态系统技术
60 篇文章
100 订阅
订阅专栏
设计原理
kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力.
持久性
kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为了减少磁盘写入的次数,broker会将消息暂时buffer起来,当消息的个数(或尺寸)达到一定阀值时,再flush到磁盘,这样减少了磁盘IO调用的次数.
性能
需要考虑的影响性能点很多,除磁盘IO之外,我们还需要考虑网络IO,这直接关系到kafka的吞吐量问题.kafka并没有提供太多高超的技巧;对于producer端,可以将消息buffer起来,当消息的条数达到一定阀值时,批量发送给broker;对于consumer端也是一样,批量fetch多条消息.不过消息量的大小可以通过配置文件来指定.对于kafka broker端,有个sendfile系统调用可以潜在的提升网络IO的性能:将文件的数据映射到系统内存中,socket直接读取相应的内存区域即可,而无需进程再次copy和交换. 其实对于producer/consumer/broker三者而言,CPU的开支应该都不大,因此启用消息压缩机制是一个良好的策略;压缩需要消耗少量的CPU资源,不过对于kafka而言,网络IO更应该需要考虑.可以将任何在网络上传输的消息都经过压缩.kafka支持gzip/snappy等多种压缩方式.
生产者
负载均衡: producer将会和Topic下所有partition leader保持socket连接;消息由producer直接通过socket发送到broker,中间不会经过任何"路由层".事实上,消息被路由到哪个partition上,由producer客户端决定.比如可以采用"random""key-hash""轮询"等,如果一个topic中有多个partitions,那么在producer端实现"消息均衡分发"是必要的.
其中partition leader的位置(host:port)注册在zookeeper中,producer作为zookeeper client,已经注册了watch用来监听partition leader的变更事件.
异步发送：将多条消息暂且在客户端buffer起来，并将他们批量的发送到broker，小数据IO太多，会拖慢整体的网络延迟，批量延迟发送事实上提升了网络效率。不过这也有一定的隐患，比如说当producer失效时，那些尚未发送的消息将会丢失。
消费者
consumer端向broker发送"fetch"请求,并告知其获取消息的offset;此后consumer将会获得一定条数的消息;consumer端也可以重置offset来重新消费消息.
在JMS实现中,Topic模型基于push方式,即broker将消息推送给consumer端.不过在kafka中,采用了pull方式,即consumer在和broker建立连接之后,主动去pull(或者说fetch)消息;这中模式有些优点,首先consumer端可以根据自己的消费能力适时的去fetch消息并处理,且可以控制消息消费的进度(offset);此外,消费者可以良好的控制消息消费的数量,batch fetch.
其他JMS实现,消息消费的位置是由producer保留,以便避免重复发送消息或者将没有消费成功的消息重发等,同时还要控制消息的状态.这就要求JMS broker需要太多额外的工作.在kafka中,partition中的消息只有一个consumer在消费,且不存在消息状态的控制,也没有复杂的消息确认机制,可见kafkabroker端是相当轻量级的.当消息被consumer接收之后,consumer可以在本地保存最后消息的offset,并间歇性的向zookeeper注册offset.由此可见,consumer客户端也很轻量级.
消息传送机制
对于JMS实现,消息传输担保非常直接:有且只有一次(exactly once).在kafka中稍有不同:
1) at most once: 最多一次,这个和JMS中"非持久化"消息类似.发送一次,无论成败,将不会重发.
2) at least once: 消息至少发送一次,如果消息未能接受成功,可能会重发,直到接收成功.
3) exactly once: 消息只会发送一次.
at most once: 消费者fetch消息,然后保存offset,然后处理消息;当client保存offset之后,但是在消息处理过程中出现了异常,导致部分消息未能继续处理.那么此后"未处理"的消息将不能被fetch到,这就是"atmost once".
at least once: 消费者fetch消息,然后处理消息,然后保存offset.如果消息处理成功之后,但是在保存offset阶段zookeeper异常导致保存操作未能执行成功,这就导致接下来再次fetch时可能获得上次已经处理过的消息,这就是"at least once"，原因offset没有及时的提交给zookeeper，zookeeper恢复正常还是之前offset状态.
exactly once: kafka中并没有严格的去实现(基于2阶段提交,事务),我们认为这种策略在kafka中是没有必要的.
通常情况下"at-least-once"是我们首选.(相比at most once而言,重复接收数据总比丢失数据要好).
6、复制备份
kafka将每个partition数据复制到多个server上,任何一个partition有一个leader和多个follower(可以没有);备份的个数可以通过broker配置文件来设定.leader处理所有的read-write请求,follower需要和leader保持同步.follower和consumer一样,消费消息并保存在本地日志中;leader负责跟踪所有的follower状态,如果follower"落后"太多或者失效,leader将会把它从replicas同步列表中删除.当所有的follower都将一条消息保存成功,此消息才被认为是"committed",那么此时consumer才能消费它.即使只有一个replicas实例存活,仍然可以保证消息的正常发送和接收,只要zookeeper集群存活即可.(不同于其他分布式存储,比如hbase需要"多数派"存活才行)
当leader失效时,需在followers中选取出新的leader,可能此时follower落后于leader,因此需要选择一个"up-to-date"的follower.选择follower时需要兼顾一个问题,就是新leaderserver上所已经承载的partition leader的个数,如果一个server上有过多的partition leader,意味着此server将承受着更多的IO压力.在选举新leader,需要考虑到"负载均衡".
日志
如果一个topic的名称为"my_topic",它有2个partitions,那么日志将会保存在my_topic_0和my_topic_1两个目录中;日志文件中保存了一序列"log entries"(日志条目),每个log entry格式为"4个字节的数字N表示消息的长度" + "N个字节的消息内容";每个日志都有一个offset来唯一的标记一条消息,offset的值为8个字节的数字,表示此消息在此partition中所处的起始位置..每个partition在物理存储层面,有多个logfile组成(称为segment).segmentfile的命名为"最小offset".kafka.例如"00000000000.kafka";其中"最小offset"表示此segment中起始消息的offset.
其中每个partiton中所持有的segments列表信息会存储在zookeeper中.
当segment文件尺寸达到一定阀值时(可以通过配置文件设定,默认1G),将会创建一个新的文件;当buffer中消息的条数达到阀值时将会触发日志信息flush到日志文件中,同时如果"距离最近一次flush的时间差"达到阀值时,也会触发flush到日志文件.如果broker失效,极有可能会丢失那些尚未flush到文件的消息.因为server意外实现,仍然会导致log文件格式的破坏(文件尾部),那么就要求当server启东是需要检测最后一个segment的文件结构是否合法并进行必要的修复.
获取消息时,需要指定offset和最大chunk尺寸,offset用来表示消息的起始位置,chunk size用来表示最大获取消息的总长度(间接的表示消息的条数).根据offset,可以找到此消息所在segment文件,然后根据segment的最小offset取差值,得到它在file中的相对位置,直接读取输出即可.
日志文件的删除策略非常简单:启动一个后台线程定期扫描log file列表,把保存时间超过阀值的文件直接删除(根据文件的创建时间).为了避免删除文件时仍然有read操作(consumer消费),采取copy-on-write方式.
简单来说，在复制一个对象时并不是真的在内存中把原来对象的数据复制一份到另外一个地址，而是在新对象的内存映射表中指向同原对象相同的位置，并且把那块内存的 Copy-On-Write位设为 1。在对这个对象执行读操作的时候，内存数据没有变动，直接执行就可以。在写的时候，才真正将原始对象复制一份到新的地址，修改新对象的内存映射表到这个新的位置，然后往这里写。
分配
kafka使用zookeeper来存储一些meta信息,并使用了zookeeperwatch机制来发现meta信息的变更并作出相应的动作(比如consumer失效,触发负载均衡等)
1) Broker node registry: 当一个kafkabroker启动后,首先会向zookeeper注册自己的节点信息(临时znode),同时当broker和zookeeper断开连接时,此znode也会被删除.
格式: /broker/ids/[0...N] -->host:port;其中[0..N]表示broker id,每个broker的配置文件中都需要指定一个数字类型的id(全局不可重复),znode的值为此broker的host:port信息.
2) Broker Topic Registry: 当一个broker启动时,会向zookeeper注册自己持有的topic和partitions信息,仍然是一个临时znode.
格式: /broker/topics/[topic]/[0...N] 其中[0..N]表示partition索引号.
3) Consumer and Consumer group: 每个consumer客户端被创建时,会向zookeeper注册自己的信息;此作用主要是为了"负载均衡".
一个group中的多个consumer可以交错的消费一个topic的所有partitions;简而言之,保证此topic的所有partitions都能被此group所消费,且消费时为了性能考虑,让partition相对均衡的分散到每个consumer上.
4) Consumer id Registry: 每个consumer都有一个唯一的ID(host:uuid,可以通过配置文件指定,也可以由系统生成),此id用来标记消费者信息.
格式:/consumers/[group_id]/ids/[consumer_id]
仍然是一个临时的znode,此节点的值为{"topic_name":#streams...},即表示此consumer目前所消费的topic + partitions列表.
5) Consumer offset Tracking: 用来跟踪每个consumer目前所消费的partition中最大的offset.
格式:/consumers/[group_id]/offsets/[topic]/[broker_id-partition_id]-->offset_value
此znode为持久节点,可以看出offset跟group_id有关,以表明当group中一个消费者失效,其他consumer可以继续消费.
6) Partition Owner registry: 用来标记partition被哪个consumer消费.临时znode格式:
/consumers/[group_id]/owners/[topic]/[broker_id-partition_id]-->consumer_node_id当consumer启动时,所触发的操作:
A) 首先进行"Consumer id Registry";
B) 然后在"Consumer id Registry"节点下注册一个watch用来监听当前group中其他consumer的"leave"和"join";只要此znode path下节点列表变更,都会触发此group下consumer的负载均衡.(比如一个consumer失效,那么其他consumer接管partitions).
C) 在"Broker id registry"节点下,注册一个watch用来监听broker的存活情况;如果broker列表变更,将会触发所有的groups下的consumer重新balance.
1) Producer端使用zookeeper用来"发现"broker列表,以及和Topic下每个partitionleader建立socket连接并发送消息.
2) Broker端使用zookeeper用来注册broker信息,已及监测partitionleader存活性.
3) Consumer端使用zookeeper用来注册consumer信息,其中包括consumer消费的partition列表等,同时也用来发现broker列表,并和partition leader建立socket连接,并获取消息.
汤高
关注
关注
点赞
17
收藏
打赏
评论
kafka学习之路（三）——高级
设计原理kafka的设计初衷是希望作为一个统一的信息收集平台,能够实时的收集反馈信息,并需要能够支撑较大的数据量,且具备良好的容错能力.持久性kafka使用文件存储消息,这就直接决定kafka在性能上严重依赖文件系统的本身特性.且无论任何OS下,对文件系统本身的优化几乎没有可能.文件缓存/直接内存映射等是常用的手段.因为kafka是对日志文件进行append操作,因此磁盘检索的开支是较小的;同时为...
复制链接
扫一扫
专栏目录
Hello Kafka（四）——Kafka高级功能
天山老妖
02-24
835
一、Kafka无消息丢失配置
1、Kafka消息丢失简介
Kafka只针对已提交消息（committed message）做有限度的持久化保证。
当Kafka的若干个Broker成功地接收到一条消息并写入到日志文件后，会通知生产者程序相应消息已成功提交。多少个Broker成功保存消息算是已提交，可以由Producer参数或Broker端参数指定。
有限度的持久化保证是指Kafka不可能保证在任何情况下都做到不丢失消息，Kafka不丢消息的前提条件是保存消息的N个Kafka Broker 中至少有1个
Kafka高级特性
weixin_38910645的博客
07-08
500
幂等设计
消息语义
At most once：消息可能会丢失，但不会重复。
At least once：消息不会丢失，但有可能重复。
Exactly once：正好一次。消息不会重复也不会丢失。
在0.11.0.0之前，如果生产者未能收到已提交消息的响应，除了重新发送消息外别无选择，但提供了至少一次的语义保证。即原始请求实际上已经成功，但是遇上某些意外情况，则会在重新发送时将消息再次写入日志。
如：网络抖动、超时等问题，导致Producer没有收到Broker返回的税局Ack，则Producer会继续重试
参与评论
您还未登录，请先
登录
后发表或查看评论
【kafka】docker + 单点kafka部署 + nodejs生产者和消费者
最新发布
weixin_42815846的博客
10-29
966
而且他的consumer和producer都是在local，可以直接连到kafka的broker，而我的consumer和producer都在另一个container，因此也遇到了访问不到的问题，但正如前面所述已经解决。在我的案例中，kafka在一个container，zookeeper在另一个container，而nodejs的consumer和producer又在另一个container，一共有三个containers。而是开了一个node的container，OS是debian，来安装。
【Kafka学习】
qq_44496147的博客
01-13
193
Kafka介绍kafka背景一、 什么是kafka1.1 kafka基本术语1.2 kafka特性1.3 kafka使用场景1.4 kafka的topic为什么要分区？二、Kafka安装2.1 kafak启动三、SpringBoot+Kafka3.1 依赖引入3.2 kafka配置3.3 生产者config3.4 消费者config3.5 注册topic并发送消息3.6 监听器3.7 KafkaTemplate发送消息及结果确认3.8 启动类
kafka背景
一、 什么是kafka
Kafka 是一个分布式
大数据------kafka高级
jinyusheng_1991的博客
08-26
361
1.深入学习kafka，我们要搭建一个kafka集群，配置好，运行起来，完成消息的发布与接收其实实现起来很简单，但是在kafka的底层是如何实现的，如何在大量消息中快速找到想要的消息，消息怎样才会在传递中不丢失，运行过程中会会经常遇到哪些比较棘手的问题接下来我们进入kafka高级的探入。
2.Kafka的结构组成以及详细解释：
2.1Producer：生产者，用于消息的生产，通过P...
Kafka使用入门教程
下雨天__的专栏
12-01
8952
介绍
Kafka是一个分布式的、可分区的、可复制的消息系统。它提供了普通消息系统的功能，但具有自己独特的设计。这个独特的设计是什么样的呢？
首先让我们看几个基本的消息系统术语：
Kafka将消息以topic为单位进行归纳。将向Kafka topic发布消息的程序成为producers.将预订topics并消费消息的程序成为consumer.Kafka以集群的方式运行
Qt 中使用librdkafka librdkafka++ 创建消费者
weixin_46068528的博客
05-12
757
1、首先需要编译rdkafka 编译kafka
2、编译好kafka 我们只需要用到 librdkafka.lib librdkafkacpp.lib librdkafka.dll librdkafka.dll (本人编译的是 windows下的release x64位 版本)这四个文件
3、在Qt 中将kafka消费者封装在线程中
头文件.h
#ifndef UDPCLIENT_H
#define UDPCLIENT_H
#include <QThread>
#incl...
kafka可靠性
Zhang_Jian
09-28
519
kafka最初是被LinkedIn设计用来处理log的分布式消息系统，因此它的着眼点不在数据的安全性（log偶尔丢几条无所谓），换句话说kafka并不能完全保证数据不丢失。尽管kafka官网声称能够保证at-least-once，但如果consumer进程数小于partition_num，这个结论不一定成立。考虑这样一个case，partiton_num=2，启动一个consumer进程订阅这个to
Qt 中使用librdkafka librdkafka++ 创建生产者
weixin_46068528的博客
05-12
248
1、如果还没有编译rdkafka 可以查看我的另一篇博客 创建消费者
2 、Qt 中使用rdkafka 创建生产者
生产者.h
#ifndef PRODUCER_H
#define PRODUCER_H
#include <iostream>
#include <string>
#include <cstdlib>
#include <cstdio>
#include <csignal>
#include <QDebug...
CentOS+QT+KAFKA开发环境部署及测试
ThistleZhang
07-12
572
CentOS+QT+KAFKA开发环境部署及测试
本文档记录了在CentOS环境下通过QT开发KAFKA程序的步骤，关于CentOS中安装QT集成开发环境，不再赘述。此处默认是在QT编译环境已经完备的情况下，如何配置KAFKA的编译环境及测试实例演示。
安装librdkafka
librdkafa是一个开源的KAFKA客户端，由C/C++实现，提供了生产者、消费者、管理者的客户端，是一款稳定的、高性能的消息中间件。对于生产者每秒可发送百万量级的消息数，对于消费者每秒可以消费掉3百万量级的消息数。
下载
Kafka实现精确一次（exactly once）发送消息的原理
xzh_blog
11-22
2699
语义介绍
At-least-once（最少一次）：如果生产者从Kafka broker接收到一个确认(ack)并且ack = all，这意味着消息已经被写入Kafka topic一次。然而，如果生产者ack超时或收到一个错误，它可能会重试发送消息，假设消息没有写入Kafka topic，如果broker在它发送ack之前失败，但在消息被成功写入Kafka topic后，此重试将导致消息被写入两次，因此将不止一次地传递给最终使用者。这种方法可能会导致消息重复和错误的结果。
At-most-once（最多一
Kafka3.0新特性
m0_46377295的博客
02-16
4100
Kakfa3.0新特性1. Kafka Core升级第一部分 基础升级第二部分 Kafka Raft快照第三部分 Kraft模式下的生产者ID生成第四部分 Producer将默认启动最强的交付保障第五部分 增加默认消费者会话超时第六部分：删除对消息格式V0和V1的支持2. Kafka Connect升级2.1 什么是Kafka connect第一部分 连接API以重新启动连接器和任务第二部分 默认启动连接客户端覆盖第三部分 启动连接器日志上下文3. Kafka Stream升级第一部分 开放在流中关于偏移量
Kafka系列-3、kafka高级
李卫行
12-29
1938
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
大数据系列文章目录
kafka的中文网站
目录kafka的分片副本机制分片机制副本kafka如何保证数据不丢失如何保证生产端数据不丢失如果保证broker端和消费者端数据不丢失broker消费者端消息存储及查询机制生产者数据分发策略消费者负载均衡机制kafka的监控工具:kafka-eagleKafka中数据积压问题Kafka配额限速机制限制producer端的速率限制consumer端的速率取消kaf
kafka学习之路（一）——入门
热门推荐
至道
07-16
1万+
kafka学习之路（一）——入门Kafka学习之路...一、入门..1、 简介2、 主题（Topics）、日志（Logs）3、 分布式（Distribution）4、 生产者（Producers）5、 消费者（Consumers） 一、入门1、简介Kafka 是linkedin 公司用于日志处理的分布式消息队列，同时支持离线和在线日志处理。kafk...
Kafka 从基础到高级（附图讲解）
weixin_42073629的博客
04-27
2886
1、为什么有消息系统
解耦合
异步处理 例如电商平台，秒杀活动。一般流程会分为：1:风险控制、2：库存锁定、3：生成订单、4：短信通知、5：更新数据通过消息系统将秒杀活动业务拆分开，将不急需处理的业务放在后面慢慢处理；流程改为：1：风险控制、2：库存锁定、3:消息系统、4:生成订单、5：短信通知、6：更新数据
流量的控制 3.1 网关在接受到请求后，就把请求放入到消息队列里面 3.2 后端的服务从消息队列里面获取到请求，完成后续的秒杀处理流程。然后再给用户返回结果。优点：控制了流.
Kafka高级应用
通往神秘的道路的专栏
02-03
896
除了正常的消息发送和消费， 在使用Kafka的过程中难免会遇到一些其他高级应用类的需求， 比如消费回溯， 这个可以通过原生Kafka提供的Kafka Consumer.seek() 方法来实现， 然而类似延时队列、消息轨迹等应用需求在原生Kafka中就没有提供了。我们在使用其他消息中间件时， 比如Rabbit MQ，使用到了延时队列、消息轨迹的功能， 如果我们将应用直接切换到Kafka中， 那么只能选择舍弃它们。但这也不是绝对的， 我们可以通过一定的手段来扩展Kafka， 本章讲述的就是如何实现这类扩展的高
Qt在linux下实现kafka客户端开发(二)
only_1的专栏
05-18
1519
一. Qt创建工程Qt使用qmake模式,在.pro文件中添加以下内容:QMAKE_LFLAGS += -lrdkafka -lrdkafka++-lz -lpthread -lrt #-lrdkafka等价于 LIBS += /usr/local/lib/librdkafka.so KafkaClientTest.pro代码如下: QT += core gui
greate...
Kafka学习之路 （三）Kafka的高可用
tby6686的专栏
11-25
153
目录
一、高可用的由来
1.1　为何需要Replication
1.2　Leader Election
二、Kafka HA设计解析
2.1　如何将所有Replica均匀分布到整个集群
2.2　Data Replication（副本策略）
2.2.1　消息传递同步策略
2.2.2　ACK前需要保证有多少个备份
2.2.3　Leader Election算法
2.2.4　如何处理所有Replica都不工作
2.2.5　选举Leader
三、HA相关ZooKeeper结构
3.1　ad
【译】Kafka学习之路
weixin_34096182的博客
01-19
76
　　一直在思考写一些什么东西作为2017年开篇博客。突然看到一篇《Kafka学习之路》的博文，觉得十分应景，于是决定搬来这“他山之石”。虽然对于Kafka博客我一向坚持原创，不过这篇来自Confluent团队Gwen Shapira女士的博文实在精彩，所以还是翻译给大家，原文参见这里。
~~~~~~~~~~~~
Kafka学习之路
　　看上去很多工程师都已经把“学习Kafka”加到了2017年的t...
Kafka学习之路 （一）Kafka的简介
weixin_33910137的博客
05-07
118
一、简介
1.1　概述
Kafka是最初由Linkedin公司开发，是一个分布式、分区的、多副本的、多订阅者，基于zookeeper协调的分布式日志系统（也可以当做MQ系统），常见可以用于web/nginx日志、访问日志，消息服务等等，Linkedin于2010年贡献给了Apache基金会并成为顶级开源项目。
主要应用场景是：日志收集系统和消息系统。
Kafka主要设计目标如下：
...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
©️2022 CSDN
皮肤主题：编程工作室
设计师：CSDN官方博客
返回首页
汤高
CSDN认证博客专家
CSDN认证企业博客
码龄8年
暂无认证
159
原创
5万+
周排名
160万+
总排名
122万+
访问
等级
9433
积分
955
粉丝
923
获赞
411
评论
2241
收藏
私信
关注
热门文章
hash算法原理详解
234235
Java面试笔试题大汇总(最全+详细答案)
90564
Java接入Spark之创建RDD的两种方式和操作RDD
45372
Hadoop2.6（新版本）----MapReduce工作原理
34395
Python快速学习第二天
28176
分类专栏
大数据生态系统技术
60篇
数据结构与算法
5篇
Java网络编程
11篇
23天征服--23种设计模式
22篇
Spark
6篇
Web Service
5篇
Java技术
8篇
JavaScript
26篇
数据库
4篇
Java EE
7篇
Java线程
7篇
网络编程
3篇
Struts2
4篇
Java设计模式
23篇
软件环境搭建
2篇
Java面试题
2篇
数据结构与算法
5篇
大型数据库技术
Mybatis
2篇
JDK源码分析
中间件
1篇
Redis
3篇
hbase集群安装
4篇
大数据与云计算
50篇
Java疑难杂症
6篇
kafka
5篇
scala
storm
8篇
spark
6篇
linux学习
13篇
工作总结
14篇
Python学习
12篇
quartz
2篇
算法大杂烩
3篇
算法面试题
最新评论
数据挖掘算法之贝叶斯网络
Gao_Yaya:
使用假设：在c已知的情况下，ab独立。然后使用了这个假设证明了，在c条件下，ab独立。这样可以吗？
hash算法原理详解
小白pk菜鸡:
1位、2位、……、6位、7位、8位是指千万位、百万位、……百位、十位、个位。
JDK动态代理的底层实现原理
z563394688:
设置jvm参数让生成的class文件不消失
hash算法原理详解
carth.r:
博主你好，原文中的” 2) 由于哈希函数是一个压缩映象，因此，在一般情况下，很容易产生“冲突”现象，即： key1！=key2，而 f (key1) = f(key2)。“中的” f (key1) = f(key2)“是否应该改成” f (key1) == f(key2)”更好
JDK动态代理的底层实现原理
帅气呢杰哥:
请问楼主，我跑了下代码，看不到有代理对象生成，也就看不了.class文件，这个怎么破？
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
Spring 配置数据库用户名密码加密
Google 面试题分析 | 字典里面的最长单词
Trie树分析
2018年3篇
2017年4篇
2016年137篇
2015年51篇
目录
目录
分类专栏
大数据生态系统技术
60篇
数据结构与算法
5篇
Java网络编程
11篇
23天征服--23种设计模式
22篇
Spark
6篇
Web Service
5篇
Java技术
8篇
JavaScript
26篇
数据库
4篇
Java EE
7篇
Java线程
7篇
网络编程
3篇
Struts2
4篇
Java设计模式
23篇
软件环境搭建
2篇
Java面试题
2篇
数据结构与算法
5篇
大型数据库技术
Mybatis
2篇
JDK源码分析
中间件
1篇
Redis
3篇
hbase集群安装
4篇
大数据与云计算
50篇
Java疑难杂症
6篇
kafka
5篇
scala
storm
8篇
spark
6篇
linux学习
13篇
工作总结
14篇
Python学习
12篇
quartz
2篇
算法大杂烩
3篇
算法面试题
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
打赏作者
汤高
你的鼓励将是我创作的最大动力
¥2
¥4
¥6
¥10
¥20
输入1-500的整数
余额支付
(余额：-- )
扫码支付
扫码支付：¥2
获取中
扫码支付
您的余额不足，请更换扫码支付或充值
打赏作者
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值