huangleijay的专栏

在上述示例中，根据条件的不同结果，使用ResponseEntity返回不同的HTTP状态码。在上述示例中，当条件为true时，使用ResponseEntity返回状态码200（OK），自定义的头部信息，以及响应体"Custom response"。在Spring Boot中，ResponseEntity是一个带有HTTP响应的对象，它封装了响应的状态码、头部信息和响应体。返回自定义的响应体：ResponseEntity允许你返回自定义的Java对象作为响应体，而不仅仅局限于简单的字符串或基本类型。

打开终端, 在命令提示符后面直接输入 : javac , 按回车键,系统会输出 javac 的帮助信息, 如果成功说明已经成功配置了JDK , 否则需要仔细检查上面的步骤的配置是否正确。下载完成后，我们得到一个dmg的安装包，如下图所示，名称为 jdk-8u144-macosx-x64.dmg ，表示这是Java 8版本号为144的JDK安装包。其中Contents下的Home文件夹，是该JDK的根目录。第三步 : 安装好JDK后需要配置JDK的环境变量，再双击中间的pkg文件，开始安装，如下图所示。

Shallow Size对象自身占用的内存大小，不包括它引用的对象。针对非数组类型的对象，它的大小就是对象与它所有的成员变量大小的总和。当然这里面还会包括一些java语言特性的数据存储单元。针对数组类型的对象，它的大小是数组元素对象的大小总和。Retained SizeRetained Size=当前对象大小+当前对象可直接或间接引用到的对象的大小总和。(间接引用的含义：A->B->C, C就是间接引用)换句话说，Retained Size就是当前对象被GC后，从He

异步的使用场景：1、不涉及共享资源，或对共享资源只读，即非互斥操作2、没有时序上的严格关系 ## @hxx 这一点需要深刻理解，在云搜edoc-svc中，为什么不使用异步，因为帖子需要严格保序！3、不需要原子操作，或可以通过其他方式控制原子性4、常用于IO操作等耗时操作，因为比较影响客户体验和使用性能5、不影响主线程逻辑同步的使用场景：不使用异步的时候同步的好处：1、同步流程对结果处理通常更为简单，可以就近处理。2、同步

前言：1： 语法格式如下lambda 表达式的语法格式如下：(parameters) -> expression 或 (parameters) ->{ statements; }2： 什么时候用？在云搜中，为了获取pod中某一个元素的信息，需要一层一层的剥开json数组，使用for循环非常的烦恼用两行代码搞定// 当前shard所有副本都会拿到 List<Pod> allpods = client.pods().inNamespace(name

前言对于任何一个模块或服务或框架来说都需要具备可升级性。升级背后的诉求可能是多种： 版本的升级，寻求更安全的代码或者享用更强大的功能。 当前服务已经不能承担目前的用户量，急需要横向扩容升级。 其他外界因素引发的升级需求，如机房迁移等。 正文本文要讲的Kafka架构的升级，原因是上述讲的第二种。在kafka横向扩容中，首先调研了kafka本身架构具备的横向扩容能力。即将新broker加入到新的集群即可，新broke...

前言：如何在业务上敲定kafka的机器数目！需要遵循的前提是，单数原则，就是zookeeper和broker的节点数目最好是单数！分区分配给消费者有三个策略，默认是第一个。RangeAssignor策略：假设n=分区数/消费者数量，m=分区数%消费者数量，那么前m个消费者每个分配n+1个分区，后面的（消费者数量-m）个消费者每个分配n个分区。@hxx 针对于单个topic分区的分配，如果一个consumer同时订阅了多个topic，那么对于多个topic而言，某个consumer可能分配

todo：1： 修改proiority 打分逻辑，加上load的权重2： 编译新的调度器，打包推上线3： 为某些deployment 指定使用新的调度器正文2：编译新的调度器，打包上线参考 https://k8smeetup.github.io/docs/tasks/administer-cluster/configure-multiple-schedulers/3：指定调度器通过提供调度器名称作为spec.schedulerName参考同上连接...

背景加上machine_load 的打分权重，需要调研其他维度的分值区间，将load在其中的的地位加重！正文balanced_resource_allocation计算资源（request cpu和mem）的均衡情况，分值大小为0-10分，10分为最佳均衡image_locality镜像是否在本地存在，是根据镜像大小之和来计算，越大分值越高，分值区间是0-10interpod_affinitypod间亲和力和反亲和力打分，需要考虑是pref...

nodeSelector强制匹配，是podSpec的一个字段，键值对匹配，先为node打上标签，再为node指定标签，如proxy。Affinity and anti-affinitynodeAffinitynodeAffinity操作方式也和nodeSelect相同，优势是：语法更具表现力（不仅仅支持“与（AND）”完全匹配）可以指明规则是“soft/preference”而不是强制要求，所以如果不满足调度条件，pods依然可以被调度。可以将规则限制在运行在一个节点上的pods

etcdctl --endpoints "http://10.16.**.**:2377" member listexport ETCDCTL_API=3#etcdctl --endpoints "http://10.16.**.**:2377" --prefix --keys-only=true get /etcdctl --endpoints "http://10.16.**.**：2377" get /registry/configmaps/wcs-online/indexproxy.

前言1: 在日常启动中，一个容器含有多个进程。那么哪个才是与容器生命周期相关的进程呢？2: 在容器的dockerfile文件中，CMD可以指定容器需要执行的命令（或者entrypoint），其实这就是docker容器的住进程3: 其实docker容器建议使用单进程，但是我们经常使用多进程，并且采取了讲多个命令写到pod的一个脚本中。然后在Dockerfile中，将start-kubernetes.sh指定为Docker容器默认执行的命令即可:CMD ["start-kubernetes.

前言遇到好几个问题1: docker push 到仓库后，docker run 进去看到的文件的权限，是源目录的文件权限相似还是与执行push命令的权限相似？ 目前看不是与源目录的权限相同2： docker运行的账户怎么指定？3： kubernetes中docker运行的账户怎么指定？正文1： 对应上面第一点在镜像源目录下，对所有的源文件修改了账户和分组，push 后，使用docker run依然看到的是root权限。 整个打镜像的过程都是使用root操作镜像的！..

背景：解释 kube-proxy 和kube-dns 的区别@hxx 一句话总结访问任何一个服务都需要知道ip+port，这是无疑的，那么访问service也当然需要，kube-dns是为了解决通过域名来访问service！而，从pod 访问 service（也可以说是到service后面的pod），是需要kube-proxy来实现的，kube-proxy实现的方式有两个：userspace 和iptables！可以理解为 kube-dns 只是其中的一个域名服务，和edoc一样，只要部

背景：云搜同一query多次查询，结果数目不一致，或者排序不稳定？经过排查，结果数目不一致，是因为副本间数据不一致导致（build请求edoc偶发超时），而云搜的svc模式并不能保证同一个query落到一个副本上，所以出现了同query多次请求结果变化而，排序不稳定，部分是因为，当多个doc打分相同的情况下，排序规则是根据索引中的docid来排的（注意，非主键id，而是从1开始算的），此docid从1开始根据如索引时间来递增，而在多副本的的build中，不同doc进入索引的时机并不能保证！.

背景：k8s调度的基本单元是pod，但是对资源的限制是在容器粒度上的k8s对资源的限制设置，最终原理是赋值到docker使用linux 的cgroup 的cpuset来实现k8s--->docker--->linuxcgroupk8s的设置参数主要有：Limits:cpu: 16memory: 20GiRequests:cpu: 10mmemory: 10Midocker的参数主要有：v1.13以后–cpus 指定容器所需的cpu核数...

1：按照网上说的，这种情况很有可能下面的情况等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就体现到负载过大了，cpu使用率低。使用“iostat -txk 1”或者“sar -d 1”（每个一秒采样）来查看：io阻塞会让出cpu，如果大多数的进程都在阻塞，那么会造成太多的上下文切换，这种切换消耗了cpu的时间，但是没有真正的执行任务！根据load的官方解释：System load averages is the average numbe..

前言本笔记详解，kubernetes调度器在调度时的策略a：预选的策略b：优选的策略，会考虑哪些维度，各个维度的权重如何优选和预选考虑的机器负载指标（cpu+mem），不是线上实时的指标，而是分配出去的资源上下限！ @hxx 这就要求我们分配的量是否和线上真实load是否成正相关关系！正文摘自 http://dockone.io/article/28851：预选策略a： NoDiskConflict ， pod所需的卷是否和节点已存在的卷冲突。如果节点已经挂载了某个卷，.

Kubernetes有个出名的监控agent—cAdvisor。在每个kubernetes Node上都会运行cAdvisor，它会收集本机以及容器的监控数据(cpu,memory,filesystem,network,uptime)。在较新的版本中，K8S已经将cAdvisor功能集成到kubelet组件中。每个Node节点可以直接进行web访问。Heapster是一个收集者，Heapster可以收集Node节点上的cAdvisor数据，将每个Node上的cAdvisor的数据进行汇总，还可以按.

1： 一个个pod剔除，直到机器load为0（空机器）关注“上下文切换” 指标记录移除了哪些pod 产生了哪些变化验证free少的机器，load高？结论：a：进程数越多，即使CPU空闲率比较高，但是load还是有可能比较高，因为进程切换占用CPU时间b：io wait 也会造成load虚高，需要排查 iostat -xz 1 看%util是否过高分析结果：a：机器没有流量，pod比较多（20+searcher pod），负载在2左右，比较高机器没有流量，无po..