背景

之前开发分布式追踪系统x-apm的时候，确认了2个目标：

1. x-apm的异常绝不能影响业务系统
2. x-apm应该尽可能的少暂用系统资源的前提下，尽可能的快(实时)

针对第2点，用来暂存追踪数据的数据结构碰到了伪共享的问题，导致收集发送的效率不够高，所以使用的缓存行填充。

这里记录下伪共享和缓存行填充的相关内容。

基础简介

cpu cache

一个典型的cpu cache架构：

访问速度：寄存器<L1 cache<L2 cache<L3 cache<主存

所以，充分利用它的结构和机制，可以有效的提高程序的性能

这里需要注意：一个cpu中的多核共享L3 cache,而L1、L2 cache是每个核心各自拥有的;一个缓存行一般缓存64byte大小的数据

背景

之前开发x-apm的时候，自定义增强一个spring bean的时候，出现了一个奇怪的异常 – 找不到无参构造方法，导致bean初始化失败。原来是bytebuddy这个类库在增强类的时候，会自动增加一个synthetic的构造方法，导致spring无法找打正确的构造方法初始化。这里记录下synthetic方法和bridge方法。

synthetic方法

synthetic方法是什么呢？先来看个实际例子：

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27

public class SyntheticTest {
    private int i;
    public void setI(int i) {
        this.i = i;
    }
    public class A {
        private int j;
        public int sum() {
            return j + i;
        }
        public void setJ(int j) {
            this.j = j;
        }
    }
    public static void main(String[] args) {
        SyntheticTest syntheticTest = new SyntheticTest();
        A a = syntheticTest.new A();
        a.setJ(1);
        System.out.println("sum=" + a.sum());
    }
}

什么是service mesh

服务网格是一个基础设施层，功能在于处理服务间通信，职责是负责实现请求的可靠传递。在实践中，服务网格通常实现为轻量级网络代理，通常与应用程序部署在一起，但是对应用程序透明

可以将它比作是微服务间的TCP/IP，负责服务之间的网络调用、限流、熔断、监控等功能。对于编写应用程序来说一般无须关心TCP/IP这一层（比如通过HTTP协议的RESTful应用），同样使用service mesh也就无须关心服务之间的那些原来是通过应用程序或者其他框架实现的事情，比如spring cloud，现在只要交给service mesh就可以了

另一方面，service mesh更强调由这些代理连接而形成的网络，而不仅仅是一个网络代理(sidecar)。

为什么要有service mesh

因为，基于框架或者类库实现的网络代理存在诸多弊端

背景

x-apm开发周期比较短，开发过程中用到的一些知识点没有深入理解，这里记录下apm用到的入口知识点 – javaagent

什么是javaagent

javaagent是Java中用来增强JVM上的应用的一种方式，这样的agent有机会修改目标应用或者应用所运行的环境。它可通过访问Java Instrumentation API来修改目标应用程序的class字节码

为什么要有javaagent

1. 暴露一些特定功能。比如运行时获得所有已加载类的字节码
2. 对于特定类做低侵入甚至无侵入的增强。比如对某个类的某个方法插入特定逻辑

所以，javaagent的主要功能其实类似aop，但是其原理是加载class文件之前做拦截，直接修改字节码，或者运行时动态修改字节码；而aop是生成一个新的代理类

摘录自知乎：https://www.zhihu.com/question/41252833/answer/195901726

讨论这个问题需要从香农的信息熵开始。小明在学校玩王者荣耀被发现了，爸爸被叫去开家长会，心里悲屈的很，就想法子惩罚小明。到家后，爸爸跟小明说：既然你犯错了，就要接受惩罚，但惩罚的程度就看你聪不聪明了。这样吧，我们俩玩猜球游戏，我拿一个球，你猜球的颜色，你每猜一次，不管对错，你就一个星期不能玩王者荣耀，当然，猜对，游戏停止，否则继续猜。当然，当答案只剩下两种选择时，此次猜测结束后，无论猜对猜错都能100%确定答案，无需再猜一次，此时游戏停止（因为好多人对策略１的结果有疑问，所以请注意这个条件）。

题目1：爸爸拿来一个箱子，跟小明说：里面有橙、紫、蓝及青四种颜色的小球任意个，各颜色小球的占比不清楚，现在我从中拿出一个小球，你猜我手中的小球是什么颜色？为了使被罚时间最短，小明发挥出最强王者的智商，瞬间就想到了以最小的代价猜出答案，简称策略1，小明的想法是这样的。

在这种情况下，小明什么信息都不知道，只能认为四种颜色的小球出现的概率是一样的。所以，根据策略1，1/4概率是橙色球，小明需要猜两次，1/4是紫色球，小明需要猜两次，其余的小球类似，所以小明预期的猜球次数为：H = 1/4 * 2 + 1/4 * 2 + 1/4 * 2 + 1/4 * 2 = 2

仅以此图，催眠我学习deep learning的动力！

深度学习的实质无非如此：根据模型产生的误差调整模型中的诸多权重，直到误差不能再减少为止

Bias（偏差）&Variance（方差）&Error(误差)的区别

首先Error = Bias + Variance

• Error反映的是整个模型的准确度
• Bias反映的是模型在样本上的输出与真实值之间的误差，即模型本身的精准度
• Variance反映的是模型每一次输出结果与模型输出期望之间的误差，即模型的精确性

本文根据官网文档及对公司日志平台es升级调优经验分享，如有错误，欢迎斧正。

主题

• 环境调优 - 磨刀不误砍柴工
• 概念普及 - 步调一致
• 如何合理高效查询 - 查询说明
• 如果合理高效的写入（另外写）

环境调优是先决条件，应对查询和写入都有帮助。重点分享查询，因为目前业务没有高频写入的场景

环境调优

注意：配置只针对centos，其他系统未做测试。

设置elasticsearch的jvm内存

编辑jvm.options，添加一下内容：

1
2

-Xms8g 
-Xmx8g

注意：具体大小应当<=系统内存的一半，建议直接设置为系统内存的一半

禁用swap交换空间

大多数操作系统试图尽可能多地为文件系统缓存使用内存，并急切地交换掉未使用的应用程序内存。这可能会导致JVM堆的部分甚至将其可执行页被交换到磁盘。

交换对于性能、节点稳定性是非常不利的，应该不惜一切代价避免。它可能导致垃圾收集持续数分钟而不是毫秒，并可能导致节点响应缓慢，甚至可能断开与群集的连接。

感谢@dingdang对开发的强力支持。

背景

在公司微服务化转型后，系统被拆分为多个由不同开发团队维护的分布式微服务。随着业务的发展，分布式服务越来越多，其关系越来越复杂。我们亟需一个工具能够梳理内部服务之间的关系，感知上下游服务的形态，快速定位冗长服务调用间的问题。

需要解决的核心问题：

• 一次请求的完整调用链
• 一次请求出现异常，能快速定位那个节点出现问题
• 一次请求经历的服务的详细信息
• 一次请求的瓶颈节点，并对节点资源分配提供数据支持
• 一次请求中出现异常、超时自动报警

简介

为了解决以上问题，自研了一个分布式追踪系统X-APM(APM = Application Performance Management，应用性能管理).其核心就是调用链：通过一个全局的ID将分布在各个服务节点上的同一次请求串联起来，还原原有的调用关系、追踪系统问题、分析调用数据、统计系统指标。
在阅读google 《dapper》的思想，open traceing的理念后,实现参考了skywalking

设计目标

• 低损耗: 对微服务的影响越低越好，包括cpu、内存、tps、响应时间等指标
• 低侵入: 作为非业务组件，应当尽可能少侵入或者无侵入其他业务系统，对于使用方透明，减少开发人员的负担
• 低延迟: 从数据的产生和收集，到数据计算和处理，再到最终展现，都要求尽可能快
• 可配置: 可以通过配置决定所收集数据的范围和粒度
• 可视化: 能够以图表方式展示调用链路等信息
• 可预警: 分析跟踪到的调用链数据，当出现调用耗时时间过长、调用异常、重复调用等情况，及时警告
• 决策支持: 这些数据最好能在决策支持层面发挥作用

背景

一直对于如何合理的处理InterruptedException不是很清晰.

参考以下链接内容理解：传送门

什么是InterruptedException

先来看看InterruptedException的java doc说明：

Thrown when a thread is waiting, sleeping, or otherwise occupied,
and the thread is interrupted, either before or during the activity.
Occasionally a method may wish to test whether the current
thread has been interrupted, and if so, to immediately throw
this exception. The following code can be used to achieve
this effect:

  if (Thread.interrupted())  // Clears interrupted status!
      throw new InterruptedException();
 

就是说只有在线程处于Object.wait()、Thread.sleep()或者被occupied(应该是指类似LockSupport.park()),并且线程被中断时会抛出InterruptedException异常。

如果有某个方法希望测试当前线程是否被中断，如果中断就抛出异常，有个推荐的用法：

1
2

if (Thread.interrupted())  // Clears interrupted status!
   throw new InterruptedException();

背景

由于一些历史原因，目前zookeeper集群（3个节点）和elasticsearch、hadoop部署在一起，导致几个组件相互影响，性能也逐渐下降。甚至出现某个组件异常（例如oom）导致了其他组件不可用。

由于大量项目使用dubbo且依赖zookeeper作为注册中心，zookeeper的不稳定可能是致命的，所以计划先将zookeeper迁出到3台独立的节点，在此记录下迁移方案。

zookeeper选举原理

在迁移前有必要了解zookeeper的选举原理，以便更科学的迁移。

快速选举FastLeaderElection

zookeeper默认使用快速选举，在此重点了解快速选举：

1. 向集群中的其他zookeeper建立连接，并且只有myid比对方大的连接才会被接受（也就是每2台只会有1个连接，避免连接浪费）
2. 每台zookeeper默认先投自己，然后向集群广播自己的选票
3. 收到对方的选票时，依次比较epoch（选举轮数）、zxid（事务id）、myid，较大者胜出，更新选票并广播
4. 如果收到的选票中有某个节点超过集群半数，则胜出当选为leader，其他节点为follower

注意事项

• zookeeper集群的数量应为奇数：

  因为根据paxos理论，只有集群中超过半数的节点还存活才能保证集群的一致性。假如目前集群有5个节点，我们最多允许2个节点不可用，因为3>5\2。当集群扩容到6个节点的时候，我们仍然只能最多允许2个节点不可用，到3个节点不可用时，将不满足paxos理论，因为3>6\2不成立。也就是说当集群节点数n为偶数时，其可用性与n-1是一样的，那我们何必多浪费一台机器呢？

• 由于zookeeper只允许mid大的节点连接到mid小的节点，我们启动zookeeper的顺序应该按照myid小的到myid大的，最后再启动leader节点！