offset

ylbtech-ionic-CSS：ionic 网格(Grid) 1. 返回顶部 1、 ionic 网格(Grid) ionic 的网格(Grid)和其他大部分框架有所不同，它采用了弹性盒子模型(Flexible Box Model) 。而且在移动端，基本上的手机都支持。row 样式指定行，col 样式指定列。 同等大小网格 在带有 row 的样式的元素里如果包含了 col 的样式，col 就会设置为同等大小。 以下实例中 row 的样式包含了 5 个 col 样式，每个 col 的宽度为 20%。 <div class="row"> <div class="col">.col</div> <div class="col">.col</div> <div class="col">.col</div> <div class="col">.col</div> <div class="col">.col</div> </div> 尝试一下 » 指定列宽 你可以设定一行中各个列的大小不一样。默认情况下，列都会被划分为同等大小。但你也可以按百分比来设置列的宽度（一行为 12 个网格）。 <div class="row"> <div class="col col-50">.col.col-50</div> <div class="col">.col</div> <div class="col"

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

1. Unsafe 类 Java 不能直接访问操作系统底层，而是通过本地方法来访问。Unsafe 类提供了硬件级别的原子操作。 Unsafe 类在 sun.misc 包下，不属于 Java 标准。很多 Java 的基础类库，包括一些被广泛使用的高性能开发库都是基于 Unsafe 类开发，比如 Netty、Hadoop、Kafka 等。 Unsafe 是用于在实质上扩展 Java 语言表达能力、便于在更高层（Java 层）代码里实现原本要在更低层（C 层）实现的核心库功能用的。 这些功能包括裸内存的申请/释放/访问，低层硬件的 atomic/volatile 支持，创建未初始化对象等。 它原本的设计就只应该被标准库使用，因此不建议在生产环境中使用。 1.1 获取实例 Unsafe 对象不能直接通过 new Unsafe() 或调用 Unsafe.getUnsafe() 获取。 Unsafe 被设计成单例模式，构造方法私有。 getUnsafe 被设计成只能从引导类加载器（bootstrap class loader）加载。 private Unsafe() { } public static Unsafe getUnsafe() { Class var0 = Reflection.getCallerClass(2); if (var0.getClassLoader() != null

最近希望在nginx的rpm监控上增加显示昨日同时段数据，方便对比。找了一圈资料，发现prometheus本身就支持带时间偏移量的查询。具体语法如下： http_requests_total offset 5m sum(http_requests_total{method="GET"} offset 5m) rate(http_requests_total[5m] offset 1w) 所以在grafana中增加一条带offset查询语句即可。实现效果如下： 总结来说，官方文档还是值得通读一边的。以前看文档都是查询配置说明，查询function，根本没注意到basics还藏着offset 这么有用的查询语法。 来源： 51CTO 作者： oudemen 链接： https://blog.51cto.com/14601432/2476546

原创文章，转载请务必将下面这段话置于文章开头处。（已授权 InfoQ中文站发布 ） 　　本文转发自 Jason's Blog ， 原文链接 　 http://www.jasongj.com/2015/08/09/KafkaColumn4 摘要 本文主要介绍了Kafka High Level Consumer，Consumer Group，Consumer Rebalance，Low Level Consumer实现的语义，以及适用场景。以及未来版本中对High Level Consumer的重新设计--使用Consumer Coordinator解决Split Brain和Herd等问题。 High Level Consumer 很多时候，客户程序只是希望从Kafka读取数据，不太关心消息offset的处理。同时也希望提供一些语义，例如同一条消息只被某一个Consumer消费（单播）或被所有Consumer消费（广播）。因此，Kafka Hight Level Consumer提供了一个从Kafka消费数据的高层抽象，从而屏蔽掉其中的细节并提供丰富的语义。 Consumer Group High Level Consumer将从某个Partition读取的最后一条消息的offset存于Zookeeper中( Kafka从0.8.2版本

在mysql中limit可以实现快速分页，但是如果数据到了几百万时我们的limit必须优化才能有效的合理的实现分页了，否则可能卡死你的服务器哦。 当一个表数据有几百万的数据的时候成了问题！ 如 * from table limit 0,10 这个没有问题 当 limit 200000,10 的时候数据读取就很慢，可以按照一下方法解决 第一页会很快 PERCONA PERFORMANCE CONFERENCE 2009上，来自雅虎的几位工程师带来了一篇”EfficientPagination Using MySQL”的报告 limit10000,20的意思扫描满足条件的10020行，扔掉前面的10000行，返回最后的20行，问题就在这里。 LIMIT 451350 , 30 扫描了45万多行，怪不得慢的都堵死了。 但是，limit 30 这样的语句仅仅扫描30行。 那么如果我们之前记录了最大ID，就可以在这里做文章 举个例子 日常分页SQL语句 select id,name,content from users order by id asc limit 100000,20 扫描100020行 如果记录了上次的最大ID select id,name,content from users where id>10073 order by id asc limit 20 扫描20行。

3 月，跳不动了？>>> 上次的 Kafka 重启失败事件，对为什么重启失败的原因似乎并没有解释清楚，那么我就在这里按照我对 Kafka 的认识，从源码和日志文件结构去尝试寻找原因。 从源码中定位到问题的根源 首先把导致 Kafka 进程退出的异常栈贴出来： 注：以下源码基于 kafka 0.11.0.2 版本。 我们直接从 index 文件损坏警告日志的位置开始： kafka.log.Log#loadSegmentFiles 从前一篇文章中已经说到，Kafka 在启动的时候，会检查kafka是否为 cleanshutdown，判断依据为 ${log.dirs} 目录中是否存在 .kafka_cleanshutDown 的文件，如果非正常退出就没有这个文件，接着就需要 recover log 处理，在处理中会调用 。 在 recover 前，会调用 sanityCheck() 方法用于检验每个 log sement 的 index 文件，确保索引文件的完整性 ，如果发现索引文件损坏，删除并调用 recoverSegment() 方法进行索引文件的重构，最终会调用 recover() 方法： kafka.log.LogSegment#recover 源码中相关变量说明： log：当前日志 Segment 文件的对象； batchs：一个 log segment 的消息压缩批次；

分析Ajax爬取今日头条街拍 站点分析 源码及遇到的问题 代码结构 方法定义 需要的常量 关于在代码中遇到的问题 01. 数据库连接 02.今日头条的反爬虫机制 03. json解码遇到的问题 04. 关于response.text和response.content的区别 源代码 站点分析 首先,打开头条,在搜索框输入关键字之后,在返回的页面中,勾选Perserve log,这玩意儿在页面发生变化的时候,不会清除之前的交互信息. 在返回的response中,我们看不到常见的HTML代码,所以初步判定,这个网站是通过ajax动态加载的. pic-1581682361199.png 切换到XHR过滤器,进一步查看. pic-1581682361200.png 发现随着网页的滚动,会产生类似这样的的Ajax请求出来. 仔细查看内容,可以看到与网页中条目对应的title和article_url. 所以初步思路,通过article_url字段先抓取文章条目 分析json数据,可以看到,这里有 article_url ,另外,这次要抓取的是图集形式的页面,所以要注意下这个 has_gallery 然后我们再来看具体的页面 在具体页面的html中,我们发现,图片的所有链接直接在网页源代码中包含了,所以,我们直接拿到源码,正则匹配一下就好了. pic-1581682361200.png 至此

kafka的offset理解 kafka是顺序读写，具备很好的吞吐量。实现原理是 每次生产消息时，都是往对应partition的文件中追加写入，而消息的被读取状态是由consumer来维护的 所以每个partition中offset一般都是连续递增的（如果开启了压缩，因为对旧数据的merge会导致不连续） 被读取的消息并不会删除，所以每次都是追加写入顺序读写，具备很好的吞吐量。 这也是为什么说kafka的broker是无状态的，整个过程中伴随由zookeeper的协调参与，一般是不同broker存储了不同partition或副本数据，当存在多个副本时，从那个broker读取数据时由zookeeper决定的，一般会由一台kafka作为leader(被读取)，如果该kafka不可用时，zookeeper切换到别的broker，因为broker在zookeeper上维护一个 /broker/ids/{id}的临时节点，如果kafka不可用，该节点也会被删除，kafka集群会根据该节点的信息，切换被读取的kafka 实现过程是 consumer在消费消息后，向broker中有个专门维护每个consumer的offset的topic生产一条消息，记录自己当前已读的消息的offset+1的值作为新的offset的消息。当然在旧版本的实现是在zookeeper上有个节点存放这个offset

jQuery 中 position() 与 offset() 区别 position() 获取相对于它最近的具有相对位置 ( position:relative 或 position:absolute ) 的父级元素的距离，如果找不到这样的元素，则返回相对于浏览器的距离。 offset() 始终返回相对于浏览器文档的距离，它会忽略外层元素。 //获取相对于最近的父级(position:relative或position:absolute)的位置 var vposition = $("#inner").position(); alert(vposition.left); //输出：50 alert(vposition.top); //输出：60 var voffset = $("#inner").offset(); alert(voffset.left); //输出：$("#outer").offset().left+50 alert(voffset.top); //输出：$("#outer").offset().top+60 参考文章：http://www.365mini.com/page/jquery-position.htm 技术交流QQ群：15129679 来源： https://www.cnblogs.com/yeminglong/p/7273104.html