简述 K8S 如火如荼的发展着，越来越多人想学习和了解 K8S，但是由于 K8S 的入门曲线较高很多人望而却步。 然而随着 K8S 生态的蓬勃发展，社区也呈现了越来越多的部署方案，光针对生产可用的环境就有好几种部署方案，对于用来测试和学习环境也同样提供了好几种简单可用的方案。 今天我们来介绍一种用于测试、学习环境快速搭建 K8S 环境的方案：Kind。 Kind 的官网是：https://kind.sigs.k8s.io/ 那么 Kind 相比于 Minikube 有什么优势呢？ 基于 Docker 而不是虚拟化 运行架构图如下： Kind 不是打包一个虚拟化镜像，而是直接讲 K8S 组件运行在 Docker。带来了什么好处呢？ 不需要运行 GuestOS 占用资源更低。 不基于虚拟化技术，可以在 VM 中使用。 文件更小，更利于移植。 支持多节点 K8S 集群和 HA Kind 支持多角色的节点部署，你可以通过配置文件控制你需要几个 Master 节点，几个 Worker 节点，以更好的模拟生产中的实际环境。 回到目录 安装 Kind Kind 的安装非常简单，只有一个二进制文件，如果大家嫌麻烦，可以直接去 GitHub releases 上下载二进制文件即可。 下面的安装方式来自 Kind 文档 https://kind.sigs.k8s.io/docs/user/quick-start/ macOS / Linux curl -Lo ./kind https://kind.sigs.k8s.io/dl/v0.8.1/kind-$(uname)-amd64 chmod +x ./kind mv ./kind /some-dir-in-your-PATH/kind macOS / Linux 使用 Homebrew brew install kind Windows curl.exe -Lo kind-windows-amd64.exe https://kind.sigs.k8s.io/dl/v0.8.1/kind-windows-amd64 Move-Item .\kind-windows-amd64.exe c:\some-dir-in-your-PATH\kind.exe Windows 使用 Chocolatey choco install kind 回到目录 创建 K8S 集群 如果你在 macOS 或 Windows 中使用 Docker 那么至少需要设置 Docker VM 的内存至 6GB，Kind 建议设置为 8GB。 不是不基于虚拟化技术吗？为什么还有 Docker VM？ 因为 Docker 其实只支持 Linux，macOS 和 Windwos 是基于虚拟化技术创建了一个 Linux VM。在 Linux 系统上则不存在这些问题。 最简单的情况，我们使用一条命令就能创建出一个单节点的 K8S 环境 kind create cluster 可是呢，默认配置有几个限制大多数情况是不满足实际需要的，默认配置的主要限制如下： APIServer 只监听了 127.0.0.1，也就意味着在 Kind 的本机环境之外无法访问 APIServer 由于国内的网络情况关系，Docker Hub 镜像站经常无法访问或超时，会导致无法拉取镜像或拉取镜像

问题描述： 在向一个文件写入可序列化对象时，每次只想向文件的末尾添加一个可序列化的对象，于是使用了FileOutputStream（文件名，true）间接的构建了ObjectOutputStream流对象，在向外读数据的时候第一次运行的时候不会报错，在第二次就会报java.io.StreamCorruptedException: invalid type code: AC错误。 原因： 在一个文件都有一个文件的头部和文件体。由于对多次使用FileOutputStream（文件名，true）构建的ObjectOutputStream对象向同一个文件写数据，在每次些数据的时候他都会向这个文件末尾先写入header在写入你要写的对象数据，在读取的时候遇到这个在文件体中的header就会报错。导致读出时，出现streamcorrput异常。 解决办法：所以这里要判断是不是第一次写文件，若是则写入头部，否则不写入。 代码示例： 1.MyObjectOutputStream.java文件 1 import java.io.*;class MyObjectOutputStream extends ObjectOutputStream { 2 public MyObjectOutputStream() throws IOException { 3 super(); 4 } 5 public MyObjectOutputStream(OutputStream out) throws IOException { 6 super(out); 7 } 8 @Override protected void writeStreamHeader() throws IOException { 9 return; 10 } 11 } 2.ObjectSave.Java文件 1 import java.io.*; 2 import java.util.*; 3 public class ObjectSave { 4 /** * @param args 5 * * @throws IOException 6 * * @throws IOException 7 * @throws FileNotFoundException 8 * */ 9 public static void main(String[] args) { 10 ObjectOutputStream out = null; 11 ObjectInputStream in = null; 12 List<User> list = new ArrayList<User>(); 13 list.add(new User("admin", "admin", "123", 1)); 14 list.add(new User("zhang", "zhang", "123", 0)); 15 String path = "d://abc"; 16 try { //判断文件大小并调用不同的方法 17 File file = new File(path); 18 FileOutputStream fos = new FileOutputStream(file, true); 19 if(file.length()<1){ 20 out = new ObjectOutputStream(fos); 21 }else{ 22 out = new MyObjectOu

汇总情况 Quzrzt LTS Elastic-Job xxl-Job saturn opencorn antares 1. 什么是集群，分布式定时任务 把分散的，可靠性差的计划任务纳入统一的平台，并实现集群管理调度和分布式部署的一种定时任务的管理方式。叫做分布式定时任务。 2. 常见开源方案 elastic-job , xxl-job ，quartz , saturn, opencron , antares, lts 2.1 elastic-job elastic-job 是由当当网基于quartz 二次开发之后的分布式调度解决方案 ， 由两个相对独立的子项目Elastic-Job-Lite和Elastic-Job-Cloud组成 。 Elastic-Job-Lite定位为轻量级无中心化解决方案，使用jar包的形式提供分布式任务的协调服务。 Elastic-Job-Cloud使用Mesos + Docker(TBD)的解决方案，额外提供资源治理、应用分发以及进程隔离等服务 亮点： 基于quartz 定时任务框架为基础的，因此具备quartz的大部分功能 使用zookeeper做协调，调度中心，更加轻量级 支持任务的分片 支持弹性扩容 ， 可以水平扩展 ， 当任务再次运行时，会检查当前的服务器数量，重新分片，分片结束之后才会继续执行任务 失效转移，容错处理，当一台调度服务器宕机或者跟zookeeper断开连接之后，会立即停止作业，然后再去寻找其他空闲的调度服务器，来运行剩余的任务 提供运维界面，可以管理作业和注册中心。 官方亮点说明： 分布式 重写Quartz基于数据库的分布式功能，改用Zookeeper实现注册中心。 并行调度 采用任务分片方式实现。将一个任务拆分为n个独立的任务项，由分布式的服务器并行执行各自分配到的分片项。 弹性扩容缩容 将任务拆分为n个任务项后，各个服务器分别执行各自分配到的任务项。一旦有新的服务器加入集群，或现有服务器下线，elastic-job将在保留本次任务执行不变的情况下，下次任务开始前触发任 务重分片。 集中管理 采用基于Zookeeper的注册中心，集中管理和协调分布式作业的状态，分配和监听。外部系统可直接根据Zookeeper的数据管理和- 监控elastic-job。 定制化流程型任务 作业可分为简单和数据流处理两种模式，数据流又分为高吞吐处理模式和顺序性处理模式，其中高吞吐处理模式可以开启足够多的线程快速的处理数据，而顺序性处理模式将每个分片项分配到一个 独立线程，用于保证同一分片的顺序性。 失效转移 弹性扩容缩容在下次作业运行前重分片，但本次作业执行的过程中，下线的服务器所分配的作业将不会重新被分配。失效转移功能可以在本次作业运行中用空闲服务器抓取孤儿作业分片执行。同样 失效转移功能也会

零、总结 文章数据来源于网络，可能存在变动，但是原理是一样的。 HTTP 协议 未规定 GET 和POST的长度限制 GET的最大长度显示是因为 浏览器和 web服务器限制了 URI的长度 不同的浏览器和WEB服务器，限制的最大长度不一样 要支持IE，则最大长度为2083byte，若只支持Chrome，则最大长度 8182byte 一、误解 大家都知道http 中 存在 GET 和 POST 这两种最常用的请求方式。（PUT，DELETE不在本文讨论范围之内） 误解：HTTP 协议下的 Get 请求参数长度是有大小限制的，最大不能超过XX，而 Post 是无限制的。 1、首先即使有长度限制，也是限制的是整个 URI 长度，而不仅仅是你的参数值数据长度。 2、HTTP 协议从未规定 GET/POST 的请求长度限制是多少。 **以下内容摘自 《关于 HTTP GET/POST 请求参数长度最大值的一个理解误区》， 文章时间为 2013年的。可能以当前最新的浏览器有出入 ** The HTTP protocol does not place any a priori limit on the length of a URI. Servers MUST be able to handle the URI of any resource they serve, and SHOULD be able to handle URIs of unbounded length if they provide GET-based forms that could generate such URIs. A server SHOULD return 414 (Request-URI Too Long) status if a URI is longer than the server can handle (see section 10.4.15). Note: Servers ought to be cautious about depending on URI lengths above 255 bytes, because some older client or proxy implementations might not properly support these lengths. 3、所谓的请求长度限制是由浏览器和 web 服务器决定和设置的，各种浏览器和 web 服务器的设定 均不一样，这依赖于各个浏览器厂家的规定或者可以根据 web 服务器的处理能力来设定。 The limit is in MSIE and Safari about 2KB, in Opera about 4KB and in Firefox about 8KB, (255 bytes if we count very old browsers) . We may thus assume that 8KB is the maximum possible length and that 2KB is a more affordable length to rely on at the server side and that 255 bytes is the safest length to assume that the entire URL will come in. If the limit is exceeded in either the browser or the server, most will just truncate the characters outside the limit without any warning. Some servers however may send a HTTP 414 error. If you nee

摘要 HashMap是Java程序员使用频率最高的用于映射(键值对)处理的数据类型。随着JDK（Java Developmet Kit）版本的更新，JDK1.8对HashMap底层的实现进行了优化，例如引入红黑树的数据结构和扩容的优化等。本文结合JDK1.7和JDK1.8的区别，深入探讨HashMap的结构实现和功能原理。 简介 Java为数据结构中的映射定义了一个接口java.util.Map，此接口主要有四个常用的实现类，分别是HashMap、Hashtable、LinkedHashMap和TreeMap，类继承关系如下图所示： 下面针对各个实现类的特点做一些说明： (1) HashMap：它根据键的hashCode值存储数据，大多数情况下可以直接定位到它的值，因而具有很快的访问速度，但遍历顺序却是不确定的。 HashMap最多只允许一条记录的键为null，允许多条记录的值为null。HashMap非线程安全，即任一时刻可以有多个线程同时写HashMap，可能会导致数据的不一致。如果需要满足线程安全，可以用 Collections的synchronizedMap方法使HashMap具有线程安全的能力，或者使用ConcurrentHashMap。 (2) Hashtable：Hashtable是遗留类，很多映射的常用功能与HashMap类似，不同的是它承自Dictionary类，并且是线程安全的，任一时间只有一个线程能写Hashtable，并发性不如ConcurrentHashMap，因为ConcurrentHashMap引入了分段锁。Hashtable不建议在新代码中使用，不需要线程安全的场合可以用HashMap替换，需要线程安全的场合可以用ConcurrentHashMap替换。 (3) LinkedHashMap：LinkedHashMap是HashMap的一个子类，保存了记录的插入顺序，在用Iterator遍历LinkedHashMap时，先得到的记录肯定是先插入的，也可以在构造时带参数，按照访问次序排序。 (4) TreeMap：TreeMap实现SortedMap接口，能够把它保存的记录根据键排序，默认是按键值的升序排序，也可以指定排序的比较器，当用Iterator遍历TreeMap时，得到的记录是排过序的。如果使用排序的映射，建议使用TreeMap。在使用TreeMap时，key必须实现Comparable接口或者在构造TreeMap传入自定义的Comparator，否则会在运行时抛出java.lang.ClassCastException类型的异常。 对于上述四种Map类型的类，要求映射中的key是不可变对象。不可变对象是该对象在创建后它的哈希值不会被改变。如果对象的哈希值发生变化，Map对象很可能就定位不到映射的位置了。 通过上面的比较，我们知道了HashMap是Java的Map家族中一个普通成员，鉴于它可以满足大多数场景的使用条件，所以是使用频度最高的一个。下文我们主要结