Elasticsearch中ignore_above的作用
ignore_above一般配合keyword类型使用,指示该字段的最大索引长度(即超过该长度的内容将不会被索引),对于超过ignore_above长度的字符串,analyzer不会进行索引分析,所以超过该长度的内容将不会被搜索到。这个选项主要对not_analyzed字段有用,这些字段通常用来进行过滤、聚合和排序。而且这些字段都是整体存在的,不需要进行索引分析处理,所以一般不会允许在这些字段中索引过长的项。
ignore_above一般配合keyword类型使用,指示该字段的最大索引长度(即超过该长度的内容将不会被索引),对于超过ignore_above长度的字符串,analyzer不会进行索引分析,所以超过该长度的内容将不会被搜索到。这个选项主要对not_analyzed字段有用,这些字段通常用来进行过滤、聚合和排序。而且这些字段都是整体存在的,不需要进行索引分析处理,所以一般不会允许在这些字段中索引过长的项。
注:本文基于JDK1.8进行解析,其它JDK版本可能有所不同。
早在JDK1.5的时候就已经引入了大神Doug Lea的并发包体系,其中包括各种显式锁及实现,原子类,原子引用等,极大的丰富了JDK的并发生态。让我们实现数据同步从“原始社会”的synchroinzed阶段一下子过度到了基于CAS的“现代社会”,JDK1.5的AQS堪称当代并发的一个神器级的工具,然而追求永远是无穷尽的,当人们在享受到原子类带来的性能提升的时候,大神Doug Lea又一次为原子操作的Long和Double带来新的成员:Striped64及它的子类。它的原理相对来说比较简单,也是JDK常用的方式,就是通过CAS以及“分段技术”努力地减少争用,尽最大可能提高并发度。
Skywalking 是一款分布式系统的应用程序性能监视工具(APM),专为微服务、云本机架构和基于容器(Docker、K8s、Mesos)架构而设计。
详细的Skywalking介绍见:Skywalking官网
转载自并发编程网 – ifeve.com 本文链接地址: 伪共享)
原文地址:http://ifeve.com/false-sharing/
作者:Martin Thompson 译者:丁一
缓存系统中是以缓存行(cache line)为单位存储的。缓存行是2的整数幂个连续字节,一般为32-256个字节。最常见的缓存行大小是64个字节。当多线程修改互相独立的变量时,如果这些变量共享同一个缓存行,就会无意中影响彼此的性能,这就是伪共享。缓存行上的写竞争是运行在SMP系统中并行线程实现可伸缩性最重要的限制因素。有人将伪共享描述成无声的性能杀手,因为从代码中很难看清楚是否会出现伪共享。
为了让可伸缩性与线程数呈线性关系,就必须确保不会有两个线程往同一个变量或缓存行中写。两个线程写同一个变量可以在代码中发现。为了确定互相独立的变量是否共享了同一个缓存行,就需要了解内存布局,或找个工具告诉我们。Intel VTune就是这样一个分析工具。本文中我将解释Java对象的内存布局以及我们该如何填充缓存行以避免伪共享。
在开发单据规则计算引擎的时候引入了groovy脚本计算引擎,其中有一个规则函数:正则函数需要使用正则表达式计算,顺便找了一下groovy里的正则表达式:
groovy中对于正则表达式的书写进行了简化,同时它仍然是引用的java核心的正则表达式引擎,并没有自己实现一套正则引擎,更多的是从语法糖的形式上进行优化,让人使用起来格外的舒服。
在使用swagger传递json数据的时候,突然报错:1
org.codehaus.jackson.JsonParseException: Illegal unquoted character ((CTRL-CHAR, code 10))
最近一段时间在运维部署rocketmq的过程中,启动时频繁报一个奇怪的错:
1 | 2018-12-19 22:20:58 INFO StoreScheduledThread1 - begin to delete before 336 hours file. timeup: false spacefull: true manualDeleteFileSeveralTimes: 0 cleanAtOnce: false |
在使用SpringCloud构建微服务过程中,我们使用Consul作为服务的注册中心,中间过程也踩了不少的坑,今天又踩了一个:我们根据官方的建议,在注册springcloud服务的时候,instanceId使用的是以下的配置:1
2
3
4
5
6
7
8
9
10
11spring:
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的配置,它由服务名+服务端口+随机值组成。这种看起来唯一且没有什么问题的配置,却是接下来坑的开始。