Because we don’t have to mess up our local machine with dev configuration! We already know that all the cool devs are using Docker for the local development environment. And there is Kuberenetes for the coolest group. But if we want to try out the application in a local Kubernetes node before deploying it to the production, things might become a bit complicated. And we have an hassle free solution for it! Let’s see how we can do that. The only prerequisite is — Docker. Let’s assume we already have Docker installed and running. minikube (alternative) We can use minikube to run and test an application (image) in local Kubernetes. But it is super slow (my Macbook Pro starts radiating heat after a while). So, we are not going to use it. kind (Kubernetes) We are going to use — kind. It is runs local Kubernetes cluster in Docker container. Thus, it requires very little time to up and stop the Kubernetes node. We can follow the Quick Start section of their official docs to install kind. After we are done installing kind, we can create our Kubernetes cluster with the following command — kind create cluster --name local It may take a while to download the Docker image for the first time and we will see the following output when the cluster is created. Now, we have a running Kubernetes cluster for local development. Thankfully, it automatically switches to the newly created kubectl context :) Next stop, Helm! Helm Helm is a package manager for Kubernetes. We will use it to deploy our Kubernetes Dashboard with just a single line of command. Follow the installation guide in the official documentation to install Helm. If you are running OSX like me and using Homebrew then just run the following command in terminal brew install helm Kubernetes Dashboard Add Chart Repo Helm uses a chart file to deploy any application. These chart files hold the configuration for that application that defines the controller, service, secret, and other resources for the application. A reposito

Socket描述符选项[SOL_SOCKET] #include <sys/socket.h> int setsockopt( int socket, int level, int option_name,const void *option_value, size_t ，ption_len); 　　第一个参数socket是套接字描述符。第二个参数level是被设置的选项的级别，如果想要在套接字级别上设置选项，就必须把level设置为 SOL_SOCKET。 option_name指定准备设置的选项，option_name可以有哪些取值，这取决于level，以linux 2.6内核为例（在不同的平台上，这种关系可能会有不同），在套接字级别上(SOL_SOCKET)，option_name可以有以下取 值： SO_DEBUG，打开或关闭调试信息。 当option_value不等于0时，打开调试信息，否则，关闭调试信息。它实际所做的工作是在sock->sk->sk_flag中置 SOCK_DBG(第10)位，或清SOCK_DBG位。 SO_REUSEADDR，打开或关闭地址复用功能。 当option_value不等于0时，打开，否则，关闭。它实际所做的工作是置sock->sk->sk_reuse为1或0。 SO_DONTROUTE，打开或关闭路由查找功能。 当option_value不等于0时，打开，否则，关闭。它实际所做的工作是在sock->sk->sk_flag中置或清SOCK_LOCALROUTE位。 SO_BROADCAST，允许或禁止发送广播数据。 当option_value不等于0时，允许，否则，禁止。它实际所做的工作是在sock->sk->sk_flag中置或清SOCK_BROADCAST位。 SO_SNDBUF，设置发送缓冲区的大小。 发送缓冲区的大小是有上下限的，其上限为256 * (sizeof(struct sk_buff) + 256)，下限为2048字节。该操作将sock->sk->sk_sndbuf设置为val * 2，之所以要乘以2，是防 止大数据量的发送，突然导致缓冲区溢出。最后，该操作完成后，因为对发送缓冲的大小 作了改变，要检查sleep队列，如果有进程正在等待写，将它们唤醒。 SO_RCVBUF，设置接收缓冲区的大小。 接收缓冲区大小的上下限分别是：256 * (sizeof(struct sk_buff) + 256)和256字节。该操作将sock->sk->sk_rcvbuf设置为val * 2。 SO_KEEPALIVE，套接字保活。 如果协议是TCP，并且当前的套接字状态不是侦听(listen)或关闭(close)，那么，当option_value不是零时，启用TCP保活定时 器，否则关闭保活定时器。对于所有协议，该操 作都会根据option_value置或清 sock->sk->sk_flag中的 SOCK_KEEPOPEN位。 SO_OOBINLINE，紧急数据放入普通数据流。 该操作根据option_value的值置或清sock->sk->sk_flag中的SOCK_URGINLINE位。 SO_NO_CHECK，打开或关闭校验和。 该操作根据option_value的值，设置sock->sk->sk_no_ch

导言： 对于java程序员来说，在虚拟机自动内存管理机制的帮助下，不需要自己实现释放内存，不容易出现内存泄漏和内存溢出的问题，由虚拟机管理内存这一切看起来非常美好，但是一旦出现内存溢出或者内存泄漏的问题，对于不熟悉jvm虚拟机是怎么使用内存的话，那么排查错误将会是一项非常艰巨的任务。所以在了解内存溢出之前先要搞明白JVM的内存模型。 JVM（Java虚拟机）是一个抽象的计算模型。就如同一台真实的机器，它有自己的指令集和执行引擎，可以在运行时操控内存区域。目的是为构建在其上运行的应用程序提供一个运行环境。JVM可以解读指令代码并与底层进行交互：包括操作系统平台和执行指令并管理资源的硬件体系结构。 JVM内存模型 根据 JVM8 规范，JVM 运行时内存共分为虚拟机栈、堆、元空间、程序计数器、本地方法栈五个部分。还有一部分内存叫直接内存，属于操作系统的本地内存，也是可以直接操作的。 元空间(Metaspace） 元空间的本质和永久代类似，都是对JVM规范中方法区的实现。不过元空间与永久代之间最大的区别在于：元空间并不在虚拟机中，而是使用本地内存。 2.虚拟机栈(JVM Stacks） 每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。 本地方法栈(Native Method Stack) 与虚拟机栈类似，区别是虚拟机栈执行java方法，本地方法站执行native方法。在虚拟机规范中对本地方法栈中方法使用的语言、使用方法与数据结构没有强制规定，因此虚拟机可以自由实现它。 程序计数器(Program Counter Register) 程序计数器可以看成是当前线程所执行的字节码的行号指示器。在任何一个确定的时刻，一个处理器（对于多内核来说是一个内核）都只会执行一条线程中的指令。因此，为了线程切换后能恢复到正确的执行位置，每条线程都需要一个独立的程序计数器，我们称这类内存区域为“线程私有”内存。 5.堆内存(Heap) 堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出 OutOfMemoryError。堆是JVM内存占用最大，管理最复杂的一个区域。其唯一的用途就是存放对象实例：所有的对象实例及数组都在对上进行分配。jdk1.8后，字符串常量池从永久代中剥离出来，存放在队中。 6.

从MySQL5.5开始，MySQL以插件的形式支持半同步复制。如何理解半同步呢？首先我们来看看异步，全同步的概念 异步复制（Asynchronous replication） MySQL默认的复制即是异步的，主库在执行完客户端提交的事务后会立即将结果返给给客户端，并不关心从库是否已经接收并处理，这样就会有一个问题，主如果crash掉了，此时主上已经提交的事务可能并没有传到从上，如果此时，强行将从提升为主，可能导致新主上的数据不完整。 全同步复制（Fully synchronous replication） 指当主库执行完一个事务，所有的从库都执行了该事务才返回给客户端。因为需要等待所有从库执行完该事务才能返回，所以全同步复制的性能必然会收到严重的影响。 半同步复制（Semisynchronous replication） 介于异步复制和全同步复制之间，主库在执行完客户端提交的事务后不是立刻返回给客户端，而是等待至少一个从库接收到并写到relay log中才返回给客户端。相对于异步复制，半同步复制提高了数据的安全性，同时它也造成了一定程度的延迟，这个延迟最少是一个TCP/IP往返的时间。所以，半同步复制最好在低延时的网络中使用。 下面来看看半同步复制的原理图： 半同步复制的潜在问题 客户端事务在存储引擎层提交后，在得到从库确认的过程中，主库宕机了，此时，可能的情况有两种 事务还没发送到从库上 此时，客户端会收到事务提交失败的信息，客户端会重新提交该事务到新的主上，当宕机的主库重新启动后，以从库的身份重新加入到该主从结构中，会发现，该事务在从库中被提交了两次，一次是之前作为主的时候，一次是被新主同步过来的。 事务已经发送到从库上 此时，从库已经收到并应用了该事务，但是客户端仍然会收到事务提交失败的信息，重新提交该事务到新的主上。 无数据丢失的半同步复制 针对上述潜在问题，MySQL 5.7引入了一种新的半同步方案：Loss-Less半同步复制。 针对上面这个图，“Waiting Slave dump”被调整到“Storage Commit”之前。 当然，之前的半同步方案同样支持，MySQL 5.7.2引入了一个新的参数进行控制-rpl_semi_sync_master_wait_point rpl_semi_sync_master_wait_point有两种取值 AFTER_SYNC 这个即新的半同步方案，Waiting Slave dump在Storage Commit之前。 AFTER_COMMIT 老的半同步方案，如图所示。 半同步复制的安装部署 要想使用半同步复制，必须满足以下几个条件： 1. MySQL 5.5及以上版本 2. 变量have_dynamic_loading为YES 3. 异步复制已经存在 首先加载插件

一、JVM 内存模型 　　根据 JVM 规范，JVM 内存共分为虚拟机栈、堆、方法区、程序计数器、本地方法栈五个部分。 　　1、虚拟机栈：每个线程有一个私有的栈，随着线程的创建而创建。栈里面存着的是一种叫“栈帧”的东西，每个方法会创建一个栈帧，栈帧中存放了局部变量表（基本数据类型和对象引用）、操作数栈、方法出口等信息。栈的大小可以固定也可以动态扩展。当栈调用深度大于JVM所允许的范围，会抛出StackOverflowError的错误，不过这个深度范围不是一个恒定的值，我们通过下面这段程序可以测试一下这个结果： 栈溢出测试源码： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 package com.paddx.test.memory; public class StackErrorMock { private static int index = 1; public void call(){ index++; call(); } public static void main(String[] args) { StackErrorMock mock = new StackErrorMock(); try { mock.call(); }catch (Throwable e){ System.out.println("Stack deep : "+index); e.printStackTrace(); } } } 代码段 1 运行三次，可以看出每次栈的深度都是不一样的，输出结果如下。 至于红色框里的值是怎么出来的，就需要深入到 JVM 的源码中才能探讨，这里不作详细阐述。 虚拟机栈除了上述错误外，还有另一种错误，那就是当申请不到空间时，会抛出 OutOfMemoryError。这里有一个小细节需要注意，catch 捕获的是 Throwable，而不是 Exception。因为 StackOverflowError 和 OutOfMemoryError 都不属于 Exception 的子类。 　　2、本地方法栈： 　　这部分主要与虚拟机用到的 Native 方法相关，一般情况下， Java 应用程序员并不需要关心这部分的内容。 　　3、PC 寄存器： 　　PC 寄存器，也叫程序计数器。JVM支持多个线程同时运行，每个线程都有自己的程序计数器。倘若当前执行的是 JVM 的方法，则该寄存器中保存当前执行指令的地址；倘若执行的是native 方法，则PC寄存器中为空。 　　4、堆 　　堆内存是 JVM 所有线程共享的部分，在虚拟机启动的时候就已经创建。所有的对象和数组都在堆上进行分配。这部分空间可通过 GC 进行回收。当申请不到空间时会抛出 OutOfMemoryError。下面我们简单的模拟一个堆内存溢出的情况： 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 package com.paddx.test.memory; import java.util.ArrayList; import java.util.List; public class HeapOomMock { public static void ma