暂无个人介绍
2022年10月
2022年09月
因为如果没有同步机制的话,便会由于线程的不确定先后执行顺序,可能导致数据的讹误,因此Java中有两种机制可以防止代码块受并发访问的干扰,第一种就是synchronized关键字,第二种就是JavaSE 5.0引入的ReentranLock类。
Kafka的生产端发送数据到服务器,不是来一条就发一条,会经过内存缓冲区(默认是16KB),通过KafkaProducer发送出去的消息都是先进入到生产端本地的内存缓冲里,然后把很多消息收集到的Batch里面,再一次性发送到Broker上去的,这样性能才可能提高
在默认的情况下,每个segment文件容量最大是为500mb,如果超过了500mb 则会生成一个新的segment文件,且文件命名后几位为上个segment文件最后offset值,如:segment01 、segment500 、segment1000 。
同步方式是:按顺序一条一条数据执行
异步方式是:前一条数据不影响后一条数据执行
kafka建集群示例如下:
mkdir -p ~/bigdata/kafka
tar -zxvf kafka_2.11-2.1.0.tgz -C ~/bigdata/kafka/
cd /home/hadoop/bigdata/kafka/kafka_2.11-2.1.0/config
最小配置项
vi server.properties
broker.id=1
num.partitions=2
default.replication.factor=2
listeners=PLAINTEXT://centosnode01:9092
log.dirs=/home/hadoop/bigdata/kafka/kafka_2.11-2.1.0/kafka-logs
zookeeper.connect=centosnode01:2181centosnode02:2181,centosnode03:2181
必须把topic分成若干个部分,若干个partition,每个机器上可以存一个partition,partition里面所有的数据像日志一样,不断往里兑点,在写作可以按照一定的逻辑,比如在配送的时候,这台服务器领跑的服务器能力特别强,有50%的消息应该①,释放20%在②,在③释放30%,按这个概率去把用户发消息的请求在这三台机器之间做负载均衡,把他们放到消息队列里面。
kafka里面一个大的topic会给内部的结构分区,分区以后写消息,这些消息都是一次性写入,不会修改。也就是说给kafka或者其他的另外的交易供应链去发送消息的时候,要再发一个,不存在把消息发过来存在队列里改一改的情况,它没有这个功能,所有的消息都是一次性写入的。分区是指因为kfka可以建集群,这个集群有可能在多个机器上,topic在逻辑上应该是一个,但是因为他在一个卡板咨询卡位了负载均衡,或者要么是访问负载均衡,要么是数据量负载均衡,会把这个topic放到集群的多个节点上存储。
它也有生产者、消费者,生产一个消息要怎么把它通过stream api读出来,然后连接topic。
建集群是因为一台kafka服务不了大量的用户,所以要创建很多很多的kafka的实例。
kafka有一种存储来群发这个消息,也可以建集群。它是集群的管理器,知道集群里有哪些东西。
kafka消息可以被持久化,也可以初始化的文件。
有一个timeout值,超过一定时间不来就会删掉,这样不占硬盘空间。
一个注册名字来订阅,但是这个消息转发不成功,就把它存起来尝试不断转发直到下一次再创建,当发现用同样的名字在去订阅消息,他就把当时离线之后没有转发成功的中间的这些消息转发过来。
在topic里去订阅相应的东西,比如订阅新闻就可以通过属性去做筛选,订阅感兴趣的新闻。于是就可以知道任何一个消息。
Kafka是一种高吞吐量的分布式发布订阅消息系统,也是专职的消息中间件、消息服务器。它可以处理消费者在网站中的所有动作流数据。
负载不均但总的负载和总的处理能力相比是匹配的,在这种情况下,用异步通信的方式能解决问题。
首先,不是处理的结果马上就处理完,而是收到了会去处理的。其次,提高响应速度的前提是并发数必须有的时候低于系统的最大处理能力,有时候高于它才行。也就是忙的时候东西先收起来,不忙的时候慢慢处理。一般处理其他事情也都是这个逻辑。如果说负载最小速度超出处理能力,很显然无论怎么处理也处理不过来,就要集群再加一台机器进行处理。
前端来了下订单的要求之后,全部把它放到一个queue里面。等于服务器里要有一个类似这样的接收者。客户端那一端就是写的比如下订单的那一段,在外部应用里面支持那个service或control内层处理都可以,在接收到用户请求之后,不是真正在调dao去写数据库,而是把产生的消息扔到了queue里。sub这个后台应用会不断的读queue里的内容,处理完之后把处理结果再放到另外一个queue里面。用service监听这个返回结果的queue,就能知道有没有成功,一旦成功把这个消息再退回给用户。所以你看到的用户下订单之后,service马上告诉他已接收,请等待。然后把消息扔到队列里,所谓请等待不是线程阻塞而是用户直接往下做别的事。处理完之后再拿到这个反馈消息之后,想办法推给下一个,要主动地推给用户。
比如下订单的服务。这个服务要去写数据库,写出之后要在上面加锁,一旦加锁,大量的线程过来的同时写数据库将阻塞在这里等待,本来就是同步,也就是只要用户下订单,这件事情没有结束,代码就不能往下走,大量的这个请求过来之后,多线程在处理的时候,线程之间在访问数据库,为了做到失误的控制,它需要加速,于是就会等待。带来的问题就是大量的用使程序卡死在这里。
不可以提供这个功能。如果有人可以通过编码的方式在服务器增加queue和topic是一件很危险的事情。所以只能通过管理员权限去更改配置文件来实现。