偏移量

Kafka kafka是什么？kafka仅仅是属于消息 中间件吗？ kafka在设计之初的时候 开发人员们在除了消息中间件以外，还想吧kafka设计为一个能够存储数据的系统，有点像 常见的非关系型数据库，比如说NoSql等。除此之外 还希望kafka能支持持续变化，不断增长的数据流, 可以发布 和订阅数据流，还可以对于这些数据进行保存 也就是说kafka的本质 是一个数据存储平台，流平台 ， 只是他在做消息发布，消息消费的时候我们可以把他当做 消息中间件来用。 而且kafka在设计之初就是采用分布式架构设计的， 基于集群的方式工作，且可以自由伸缩，所以 kafka构建集群 非常简单 基本概念： Broker : 和AMQP里协议的概念一样， 就是消息中间件所在的服务器 Topic(主题) : 每条发布到Kafka集群的消息都有一个类别，这个类别被称为Topic。（物理上不同Topic的消息 分开存储，逻辑上一个Topic的消息虽然保存于一个或多个broker上但用户只需指定消息的Topic即可生产或消 费数据而不必关心数据存于何处） Partition(分区) : Partition是物理上的概念，体现在磁盘上面，每个Topic包含一个或多个Partition. Producer : 负责发布消息到Kafka broker Consumer : 消息消费者，向Kafka

虚拟继承的原理 虚拟继承解决数据冗余和二义性的奥秘就在于，它在继承之后并不会创造出两个基类成员给派生类各自继承，而是在派生类中记录两个偏移量，大小为从派生类中继承的基类成员的地址到真正的基类成员地址，而这个真正的成员，被放在最后一次继承的派生类（D类）的末尾。 如图所示，在不使用虚拟继承的前提下，各个类定义定义变量后我们可以看看他们各自所处的地址如下： 可以看出，A,B类继承的m_n处于不同的地址，是两个成员。而使用虚拟继承后他们所处地址的内容变成了如下： 可以看出，原本为值‘3’和‘4’的地方变成了两个偏移量，而我们调取这两个偏移量之后可以看到如下： e8 d2 f5 00 ：12(H) ac cb f5 00 ：20(H) 而我们发现，从起始位置到下面04的位置（D类中的末尾），偏移字节正好是12和20。 其实， 这里是通过B和C的两个指针，指向一张表，这两个指针叫做虚基表指针，这两个表叫虚基表，虚基表中存的偏移量，通过偏移量可以找到下面的A。 Ps：并不是所有派生类共用一分虚基表，每个派生类都有自己的表； 来源： 51CTO 作者： wx5cb188ffabeef 链接： https://blog.51cto.com/14289397/2478237

目录 单线程消费 pom consumerConfig consumer 批量消费 javaConfig 消费者 BatchConsumer 选择自动提交还是手动提交方式和业务场景相关，可以查看前面的博客，根据原理进行选择。 单线程消费 pom <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-web</artifactId> </dependency> <dependency> <groupId>org.apache.kafka</groupId> <artifactId>kafka-streams</artifactId> </dependency> <dependency> <groupId>org.springframework.kafka</groupId> <artifactId>spring-kafka</artifactId> </dependency> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-starter-test</artifactId> <scope>test</scope> <exclusions>

定位 将指定元素摆放到页面的任意位置，通过定位可以任意的摆放元素。 通过position属性来设置定位。 值 描述 absolute 生成绝对定位的元素，相对于 static 定位以外的第一个父元素进行定位。元素的位置通过 “left”, “top”, “right” 以及 “bottom” 属性进行规定。 fixed 生成绝对定位的元素，相对于浏览器窗口进行定位。元素的位置通过 “left”, “top”, “right” 以及 “bottom” 属性进行规定。 relative 生成相对定位的元素，相对于其正常位置进行定位。因此，“left:20” 会向元素的 LEFT 位置添加 20 像素。 static 默认值。没有定位，元素出现在正常的流中（忽略 top, bottom, left, right 或者 z-index 声明）。 inherit 规定应该从父元素继承 position 属性的值。 当开启了元素的定位，可以通过left 、right、top、boottom四个属性来设置元素的偏移量 left:元素相对于其定位位置的左侧偏移量 right：元素相对于其定位位置的右侧偏移量 top：元素相对于其定位位置的上边偏移量 boottom：元素相对于其定位位置下边的偏移量 相对定位（postion:relative） 特点： 当开启了元素的相对定位以后，而不设偏移量时

redis主从保证数据一致性 前言 在redis中 为了保证redis的高可用 ，一般会搭建一种集群模式就是 主从模式。 主从模式可以保证redis的高可用，那么redis是怎么保证主从服务器的数据一致性的，接下来我们浅谈下redis主(master)从(slave)同步的原理。 初次全量同步 当一个redis服务器初次向主服务器发送salveof命令时，redis从服务器会进行一次全量同步，同步的步骤如下图所示： slave服务器向master发送psync命令（此时发送的是psync ? -1），告诉master我需要同步数据了。 master接收到psync命令后会进行BGSAVE命令生成RDB文件快照。 生成完后，会将RDB文件发送给slave。 slave接收到文件会载入RDB快照，并且将数据库状态变更为master在执行BGSAVE时的状态一致。 master会发送保存在缓冲区里的所有写命令，告诉slave可以进行同步了 slave执行这些写命令。 3. 命令传播 slave已经同步过master了，那么如果后续master进行了写操作，比如说一个简单的set name redis，那么master执行过当前命令后，会将当前命令发送给slave执行一遍，达成数据一致性。 4. 重新复制 当slave断开重连之后会进行重新同步，重新同步分完全同步和部分同步

kafka深入 1 分片与副本机制 分片机制：主要解决了 单台服务器存储容量有限 的问题 当数据量非常大的时候，一个服务器存放不了，就将数据分成两个或者多个部分，存放在多台服务器上。每个服务器上的数据，叫做一个分片 副本 ：副本备份机制解决了 数据存储的高可用 问题 当数据只保存一份的时候，有丢失的风险。为了更好的容错和容灾，将数据拷贝几份，保存到不同的机器上。 kafka中对于分片的数量可以是任意的,建议不要超过节点数,但对于副本的数量,最多等于节点数 2 kafka保证数据不丢失机制 2.1 producer到kafka过程 解决方案:当producer发送数据到kafka后,kafka应该给予一个响应信息, ACK校验机制 ack校验机制的三种状态码: a) 0：生产者只负责发送数据,不关心kafka是否接受的到 b) 1：某个partition的leader收到数据给出响应 c) -1：某个partition的所有副本都收到数据后给出响应 在生产环境下设置状态码的时候, 根据数据的效率和重要性判断设置标准 数据在发送的过程中主要有二种模式: 同步模式 和 异步模式 同步模式: 发送一条数据, 等待响应, 响应成功后, 发送下一条数据即可 在同步模式下, 如果broker一直不给于响应, 设置超时(10s), 超时后, 进行重试(3)即可,最终会报错 异步模式: 引入缓冲池,

1 redis的事务(pipeline)测试 　　Redis本身对数据进行操作，单条命令是原子性的，但事务不保证原子性，且没有回滚。事务中任何命令执行失败，其余的命令仍会被执行，将Redis的多个操作放到一起执行，要成功多成功，如果失败了，可以把整个操作放弃，可以实现类似事物的功能。redis事务包含三个阶段：开始事务，命令入队，执行事务。redis的分片副本集集群不支持pipeline，redis只支持单机版的事务（pipeline），Redis的主从复制也支持pipeline（目前一些公司就是这样干的）。若是想用集群，可以使用MongoDB， MongoDB集群支持事物，是一个NoSQL文档数据库，支持存储海量数据、安全、可扩容。 RedisPipelineTest package com._51doit.spark14 import com._51doit.utils.JedisConnectionPool import redis.clients.jedis.{Jedis, Pipeline} object RedisPipeLineTest { def main(args: Array[String]): Unit = { val jedis: Jedis = JedisConnectionPool.getConnection jedis.select(1) //

元素偏移量offset 获取元素距离带有定位父元素的位置 获得元素自身的大小（宽度高度） 注意：返回的数值都不带单位 offset系列属性 作用 element.offsetParent 返回作为该元素带有定位的父级元素，如果父级都没有定位则返回body element.offsetTop 返回元素相对带有定位父元素上方的偏移 element.offsetLeft 返回元素相对带有定位父元素左边框的偏移 element.offsetWidth 返回自身包括padding，边框，内容区的宽度，返回数值不带单位 element.offsetHeight 返回自身包括padding，边框，内容区的高度，返回数值不带单位 offset与style的区别 鼠标移动事件分析 可拖拽的模态框 来源： oschina 链接： https://my.oschina.net/u/4454049/blog/3178355

一、遇到问题：Confluent.Kafka.KafkaException: Broker: Specified group generation id is not valid 这个问题很诡异，网卡一直没有找到解决方案。 首先来说，出现这个问题环境。 1.创建一个分了3个区的topic。 2.启动一个生产者。 3.消费者用手动提交偏移量的方式，且拿到队列之后，每个消息处理时间大约20ms。 4.依次启动三个消费者，前面的消费就会报这样的错。 猜测：可能是因为手动提交偏移量，不及时，导致服务器不当知道如何再分配到三个分区上面。 解决：不用手动提交偏移量方式。//c.Commit(); 因为即使用了手动提交偏移量的试，并且最后不提交，消费者拿到的偏移量也是会变化到下一个的。查阅资料，这个是消费者与服务器之间的Session连接后，本地会有一个偏移量，会自动变化到下一个。但是消费者如果断开，再次连接，又会从头获取队列。 二、问题：Kafka设置为手动提交偏移量时，消费者不提交偏移量，也会自动拿下一条队列。 此问题是kafka自己的机制问题，导致程序最初的错误设计：当处理消息失败时，不提交偏移量，直接处理消息，这样拿到的也是下一条队列。 解决：不用手动提交偏移量的方式，还是采用自动提交，出错的时候，记录topic和offset。单独出错处理！ 三、测试代码，生产者与消费者。 static

Kafka中的消息是以主题为基本单位进行归类的，各个主题在逻辑上相互独立。每个主题又可以分为一个或多个分区。 不考虑多副本的情况，每个分区对应一个日志（Log），每个日志包含多个日志分段（LogSegment），对应到物理存储，可以理解为Log对应日志一个目录，每个LogSegment对应一个日志文件和两个索引文件，以及可能的其他可能文件（比如事务索引文件）。 举例说明，假设有名为topic-log的主题，此主题有4个分区，那么在实际物理存储上表现如下图。 1. __consumer_offsets- * 如图中绿色标记部分，用来保存客户端消费消息之后提交的消费位移，以便在机器重启或者宕机恢复之后正确得知客户端消费消息的位置。（不是本章重点，不再赘述） 2. Log目录 图中蓝色标记部分，可以理解为每个分区对应一个目录。本例中topic-log主题包含四个分区，所以有"topic-log-0"，“topic-log-1”，“topic-log-2”，"topic-log-3"这4 个文件夹。 3. 检查点文件 与Log目录平级的，存在4个检查点文件，用于日志的compaction。 cleaner-offset-checkpoint文件是 清理检查点文件 ，记录每个主题的每个分区中已经清理的偏移量，如下图（下文介绍日志压缩时会详细阐述） 4. 日志分段