groovy-expr-usage

在开发单据规则计算引擎的时候引入了groovy脚本计算引擎,其中有一个规则函数:正则函数需要使用正则表达式计算,顺便找了一下groovy里的正则表达式:

groovy中对于正则表达式的书写进行了简化,同时它仍然是引用的java核心的正则表达式引擎,并没有自己实现一套正则引擎,更多的是从语法糖的形式上进行优化,让人使用起来格外的舒服。

阅读全文

jackson-ctrl-char-problem-resovle

在使用swagger传递json数据的时候,突然报错:

1
org.codehaus.jackson.JsonParseException: Illegal unquoted character ((CTRL-CHAR, code 10))

阅读全文

solve-a-disk-warning-illusion-caused-by-rocketmq

最近一段时间在运维部署rocketmq的过程中,启动时频繁报一个奇怪的错:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
2018-12-19 22:20:58 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:20:58 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:08 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0
2018-12-19 22:21:08 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:21:08 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:15 INFO StoreStatsService - [STORETPS] put_tps 0.0 get_found_tps 0.0 get_miss_tps 1.799730040493926 get_transfered_tps 0.0
2018-12-19 22:21:15 INFO StoreStatsService - [PAGECACHERT] TotalPut 0, PutMessageDistributeTime [<=0ms]:0 [0~10ms]:0 [10~50ms]:0 [50~100ms]:0 [100~200ms]:0 [200~500ms]:0 [500ms~1s]:0 [1~2s]:0 [2~3s]:0 [3~4s]:0 [4~5s]:0 [5~10s]:0 [10s~]:0
2018-12-19 22:21:18 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0
2018-12-19 22:21:18 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:21:18 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:28 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0
2018-12-19 22:21:28 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:21:28 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:38 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0
2018-12-19 22:21:38 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:21:38 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:48 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0
2018-12-19 22:21:48 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false
2018-12-19 22:21:48 WARN StoreScheduledThread1 - disk space will be full soon, but delete file failed.
2018-12-19 22:21:58 INFO StoreScheduledThread1 - physic disk maybe full soon, so reclaim space, -1.0

阅读全文

hexoclient-usage

HexoClient使用帮助

使用方法链接见:HexoClient使用帮助

阅读全文

定制springcloud服务注册到consul中的instanceId

背景

在使用SpringCloud构建微服务过程中,我们使用Consul作为服务的注册中心,中间过程也踩了不少的坑,今天又踩了一个:我们根据官方的建议,在注册springcloud服务的时候,instanceId使用的是以下的配置:

1
2
3
4
5
6
7
8
9
10
11
spring:
cloud:
consul:
host: 127.0.0.1
port: 8500
discovery:
health-check-path: /management/health
service-name: mq-gateway
health-check-interval: 10s
prefer-ip-address: true
instance-id: ${spring.cloud.consul.discovery.service-name}:${server.port}:${random.value}

重点就在于这个instance-id的配置,它由服务名+服务端口+随机值组成。这种看起来唯一且没有什么问题的配置,却是接下来坑的开始。

阅读全文

Java DNS缓存

jdk1.5和1.5之前版本

默认DNS缓存时间是永久缓存

jdk 1.6以后

与security manager策略有关。

阅读全文

delete-git-submodule

删除一个submodule

  1. 删除 .gitsubmodule中对应submodule的条目

  2. 删除 .git/config 中对应submodule的条目

阅读全文

解决前端JS与后端数据交互长整型精度失真的问题

在项目中采用了twitter开源的snowflake算法的id生成器,生成的id是一个long型的大数,因数值太大,通过json形式传输到前端后,在js解析时,会丢失精度。

阅读全文

Apache Kafka,Purgatory以及多级时间轮

原文地址:Apache Kafka, Purgatory, and Hierarchical Timing Wheels

Time Wheels

Apache Kafka有一个称为“请求Purgatory”的数据结构。 这个数据结构会hold住任何尚未达到标准的成功,但又尚未造成错误的请求。 问题是:我们如何有效地跟踪群集中数以万计的的满足要求的异步请求?

Kafka实现了几个不能立即回应的延时请求类型。 例子:

  • 只有在所有同步副本已经确认写入之后,acks = all的产生请求才能被认为是完整的,并且如果领导失败,我们可以保证它不会丢失。

  • 对于min.bytes = 1的提取请求只有在至少有1个byte的数据能够被消费者消费时才会被回答。 这允许“长时间轮询”,使得消费者不必忙于等待检查新数据到达。

这些请求被认为是完成的:

(a)他们所要求的标准完成
(b)或者发生一些超时

时刻增长这些异步操作的数量与连接的数量成比例,对于Kafka来说,这往往是成千上万的连接数量。

请求Purgatory被设计用于如此大规模的请求处理,但是旧的实现有一些缺陷。

在这个博客中,我想解释一下旧执行的问题以及新实现如何解决这个问题。 我也将呈现基准测试结果。

阅读全文

基于Hash和多级时间轮:实现定时器的高效数据结构

原文地址:Hashed and Hierarchical Timing Wheels: Data Structures for the Efficient Implementation of a Timer Facility

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是“分层定时轮”。

阅读全文