2019-5-10 早上 9:17，我们某服务的kafka某topic监控触发积压阈值发生告警，积压量达5W+。 正常情况下这个队列是不会产生积压的，因为这个队列的生产者的接口是个非常冷门的接口，调用量很少。 看了下这个积压的topic共有8个partition，8台机器每台机器单线程在消费这个队列。 这个队列在正常情况下量非常的少，量大的时候十分钟会产生有2W左右的数据，这样分配到8台机器， 单台的压力是十分钟处理2600条数据，一分钟处理260条，单线程一秒钟处理4条数据，这数据量单线程是没有问题的。 产生积压的时候，去看了下是否是因为gc过长导致的，查阅gc日志没有发现异常 我们开始断定是处理线程卡在了某处理区域，比如redis或者mysql或者网络， 马上找那时候的 `jstack` 的情况，找到当前topic的处理线程记录。 ``` xxx_jstack_09:17:00:000.jstack.txt "xxxxx (xxxxConsumerContext) thread #xx - KafkaTopic[xxxxxTopic]" #163 daemon prio=x os_prio...

graalVM高性能跨语言虚拟机 偶然看到oracle发布的这个虚拟机，听闻它可以支持很多种语言直接编译成二进制文件运行，甚至可以多语言混写编译成二进制文件运行。 特意试了下java下编译成二进制文件的效果。 首先下载graal 写了个hello world ``` public class HelloWorld { public static void main(String[] args) { System.out.println("Hello, World!"); } } ``` 编译执行命令 ``` javac HelloWorld.java java HelloWorld ``` 上面命令是我们直接使用jvm运行我们的hello world程序，下面是使用graal的命令将java文件编译成二进制文件 ``` /app/graal/graalvm-ce-1.0.0-rc16/bin/native-image HelloWorld ``` 这样就生成了一个helloworld二进制文件. ``` 2.4M May 8 10:24 helloworld 427 ...

心血来潮想看看jdk11的新特性，喵了下官方文档，简单的翻译了下和增添了些自己的理解。 jdk11是lts版本,这是自 Java 8 后的首个长期支持版本,根据oracle的尿性，三年一个lts，所以这个版本在当前来看算是非常重要的一个版本，未来可能会成为主流。 2018年，美国当地时间9月25日，Oracle 官方宣布 Java 11 (18.9 LTS) 正式发布。 新特性也在官网有了介绍： https://www.oracle.com/technetwork/java/javase/11-relnote-issues-5012449.html 翻看了下还是蛮多新奇的东西。 重要改变有： Applets 和 Web Start Applications 已经从jdk11中删除了，以前在大学的时候用这玩意儿写过贪吃蛇。 和浏览器有关的这部分都移除了，我记得那时候就说不安全了，基本上的浏览器都放弃了java的applet。 在windows和mac上的jre自动自动更新功能取消了。 在Windows和macOS中，以前的版本中安装JDK时可以选择安装JRE。在JDK 11中，没有这个选项...

项目里有一个需求是计算两台机器之间的距离，有了这两台机器的经纬度，距离就很好计算了。 有一个 `球面余弦定律` 可以用来可以计算球面两点距离，但是根据这个反余弦函数公式会有较大的舍入误差，所以最好选用 `半正矢公式` 是最好的，航海上运用广泛的也是半正矢公式。 根据 `半正矢函数（半正矢公式）` 的定义和两角和的余弦函数展开式求出使用半正矢函数计算大圆距离的公式。 首先 半正矢公式 的权威介绍可以参考维基百科： https://en.wikipedia.org/wiki/Haversine_formula 关于求大圆距离也就是从球面的一点A出发到达球面上另一点B，所经过的最短路径的长度，可以参考： https://en.wikipedia.org/wiki/Great-circle_distance 知道了数学理论基础，接下来就是要把计算方法翻译成计算机的计算逻辑。 如图所示 d 就是我们要求的距离，  代码如下： ``` /** * 根据经纬度计算两点间的距离距离 ...

翻看公司的wiki文档和邮件，偶然看到DBA对TiDB的性能测试数据，其中一条是纯写入速度TPS能达到5000多，我对这个数据表示怀疑， 因为这个TiDB的配置是还不错的，配置如下所示，且测试数据的数据量只是千万级别。 ``` cpu Xeon(R) E5-2650 v4 @ 2.20GHz 48核 memory 128GB storage RAID1+0 SSD 2TB EXT4 ``` 之所以表示怀疑是因为上次我在测试环境搭建了一套三个节点的 cockroachDB 集群，它的性能就不止这个数。 TiDB是对mysql做的兼容，cockroachDB是对PostgreSQL做的兼容，发现国内用PostgreSQL的比较少，只见过以前我的老东家以前用它做数据仓库，为此我还专门去认真拜读了一本关于这个数据库的书，内容现在早已忘却。。。印象深刻的一点就是它的函数太丰富了。 cockroachDB的搭建比较简单，添加节点的方式也是非常方便。 ``` wget https://binaries.cockroachdb.com/cockroach-v2.1.6.linux-amd64.tgz ...