删除一个submodule
删除 .gitsubmodule中对应submodule的条目
删除 .git/config 中对应submodule的条目
在项目中采用了twitter开源的snowflake算法的id生成器,生成的id是一个long型的大数,因数值太大,通过json形式传输到前端后,在js解析时,会丢失精度。
原文地址:Apache Kafka, Purgatory, and Hierarchical Timing Wheels
Apache Kafka有一个称为“请求Purgatory”的数据结构。 这个数据结构会hold住任何尚未达到标准的成功,但又尚未造成错误的请求。 问题是:我们如何有效地跟踪群集中数以万计的的满足要求的异步请求?
Kafka实现了几个不能立即回应的延时请求类型。 例子:
只有在所有同步副本已经确认写入之后,acks = all的产生请求才能被认为是完整的,并且如果领导失败,我们可以保证它不会丢失。
对于min.bytes = 1的提取请求只有在至少有1个byte的数据能够被消费者消费时才会被回答。 这允许“长时间轮询”,使得消费者不必忙于等待检查新数据到达。
这些请求被认为是完成的:
(a)他们所要求的标准完成
(b)或者发生一些超时
时刻增长这些异步操作的数量与连接的数量成比例,对于Kafka来说,这往往是成千上万的连接数量。
请求Purgatory被设计用于如此大规模的请求处理,但是旧的实现有一些缺陷。
在这个博客中,我想解释一下旧执行的问题以及新实现如何解决这个问题。 我也将呈现基准测试结果。
Yashiro Matsuda最近写了一篇博文Apache Kafka’s use of Hierarchical Timing Wheels 用于监控大量的延时操作。 在Kafka用例中,每个请求都处于“Purgatory”数据结构中,并且与事件驱动处理的超时计时器和观察者列表图相关联。 有效跟踪到期定时器是一个常见问题。 这个原则可以适用于任何跟踪未完成的请求或延时消息系统。
今天的选择是Varghese和Lauck在1987年发表的一篇论文,他们在这篇论文中研究了一些有效管理定时器的方法,并介绍了Kafka所使用的分层定时轮的概念。 他们将定时器建模为两个面向用户的操作,即启动和停止,以及两个内部操作:每个滴答步进和过期处理。
启动计时器由客户端调用,指定一个计时器持续时间和一个回调。在作者的模型中,客户端还传入一个请求ID来区分计时器,但是现在我们更倾向于返回一个计时器ID来响应启动计时器的请求。
停止定时器接收一个请求(定时器)ID,并找到并停止(删除)相关的定时器。
在计时器时钟的每个“滴答声”上都会发生清算。如果设置定时器的粒度单位是T个单位时间(例如1秒),则每T个单位时间将发生一个清算。它检查是否有任何未完成的定时器已经过期,如果是则删除它们并调用过期处理。
到期处理负责调用用户提供的回调(或其他用户请求的操作,具体取决于您的模型)。
不同的数据结构和算法在执行这些操作的成本方面有不同的复杂性(例如,启动一个定时器是一个恒定的时间操作,取决于现有定时器的数量,或者甚至是一些其他变量?)。 我们有七种不同的计时器管理方案,指导方针是“对于一个普通的定时器模块,这个模块预计在各种环境下都能正常工作,我们推荐方案6或7”。方案6是“散列定时轮”和方案7是“分层定时轮”。
给定两个非空的链表,表示两个非负整数。 数字以相反的顺序存储,每个节点包含一个数字。 添加两个数字并将其作为链表返回。
您可以假设两个数字不包含任何前导零,除了数字0本身。
给定一个已经按升序排序的整数数组,找到两个数字,使它们相加到一个特定的目标数。
函数twoSum应该返回两个数字的索引,使它们相加到目标,其中index1必须小于index2。 请注意,您返回的答案(index1和index2)都不是基于零的。
您可以假设每个输入都将具有一个解决方案,您可能不会使用相同的元素两次。
输入:numbers = {2,7,11,15},target = 9
输出:index1 = 1,index2 = 2